systemdは怖くない

ちょうど1年前ぐらいからVPSを使い始め、開発用(かつ仕事用)のサーバとして日々運用しています。
昔は個人用のPCを使っていましたが、今は常時稼働・外部からの接続・自分の勉強のためなどでVPSを使っています。
(そしてずっとUbuntuユーザなので「apt! deb! gnome! (Unity?)」です)。

個人で開発したツールやサービスについては、これまでサーバ上で動作させる際にはSysV initを利用してきました。
ところが、先日のUbuntuアップグレード(16.04LTS→18.04)の際、愛用していた「sysv-rc-conf(GUIチックにサービスの起動設定を行えるツール)」がインストールできなくなりました。
どうやら巷ではSysV initやUpstartからsystemdへの移行が進んでいるようで、Ubuntuも17.04でsystemdへ切り替わったようです。
※個々の違いや経緯については、詳しい記事がたくさんあるのでそちらを御覧ください。

なぜsystemdなのか?
上記でも少し触れられていますが、実行時の環境変数引き継ぎなどで過去何度かハマった経緯もあったため、これを機にsystemdへ移行することを決意しました。
これまで自分が作成したサービス起動スクリプトは/etc/init/{serviceName}で用意していましたが、数も多くないためすべて書き換えました。

Unit定義ファイルの作成

簡単に言うとサービスの管理に関する設定ファイルで、/etc/systemd/system以下に作成します。
以降は個人用に使っているRedmineの場合として記載しています。

設定を記述していきます。

ExecStartに実行するコマンドを記載します。
起動時に読み込ませたい環境変数がある場合、KEY=VALUEで列挙したファイルのパスをEnvironmentFileに記載します。

また、WantedByがSysvでいうランレベルに該当します。
multi-user.targetはSysv時代のランレベルでいう「2〜4」です。
他にもpoweroff.target(システム停止:ランレベル0)やreboot.target(再起動:ランレベル6)などがあり、半角スペース区切りで複数定義可能です。

Unitの有効化

作成したUnitを有効化します。

起動

所感

「かなり簡略化だが直感的だな」という印象でした。
これまで/etc/init/{serviceName}に記載していた場合、PIDとかSocketの管理をすべて自分で書く必要がありました。
これがかなり面倒に感じていたので、systemdで設定する際の簡単さが嬉しく感じました。
ただ、既定以外のコマンドを用意するとかは調べた限り現時点では難しいようです。

インフラ周りはこれまであまりちゃんとやってこなかったんですが、最近はJenkinsやDockerの普及でこういったスクリプトを書くことも多くなってきました。
今後はこういった運用面の記事も書いていけたらと思っています。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA