きっかけ
AWS EC2へのアプリケーションの自動デプロイについて調査しているとき、Systemdに触れる機会があったため改めてアウトプットします。
Systemd とは
Unix系のOSで動くプログラムの元となるプログラムのこと。
読み方は「システムディー」
initプロセスとも呼び、PID（プロセスID）が1のプロセスとして起動する。
OSが起動すると一番最初に実行される。
なぜアプリケーションの実行にSystemdを使うのか
initプロセスとして使われるのはSystemdしか無いというわけではありませんが、現在Systemdはほとんどのディストリビューションで使われているそうです。
Systemdではあらかじめ用意した設定ファイルを元にしてシステムを構築します。
そのため、そこにアプリケーションのデプロイも設定しておけば自動デプロイが実現するわけですが、その際にどのような恩恵を受けられるのでしょうか。
Systemdを使うメリットは
- システムが何かしらの理由で停止しまった際に自動で再実行してくれる
- アプリケーションが出力したログを勝手に管理してくれる
などがあるとのことです。
イメージとしてはOSが、私が用意したアプリケーションを我が子のように面倒を見てくれるようになるということでしょうか。例えるなら、託児所に我が子を預ける（その場合はSystemdが託児所）みたいな。
方法
前提
AWS EC2のインスタンスを用意して、そこにsample-appというnode環境で動くアプリケーションをデプロイさせる想定で進めます。
EC2のOSイメージは、LinuxOSを使うためUbuntuを選択します。
EC2にSSH接続し、あらかじめsample-appのindex.jsをEC2のホームディレクトリに置いておきます。
準備
方法はシンプルで、設定ファイルを一つ用意してあげるだけです。
/etc/systemd/system/配下にSystemdの設定ファイルが詰め込まれているのでここに追加します。
そのため設定ファイルのパスは、/etc/systemd/system/sample-app.serviceのようになります。
[Unit]
Description=Express
[Service]
ExecStart=/usr/bin/node index.js
WorkingDirectory=/home/ubuntu
Restart=always
Environment=NODE_ENV=production PORT=80
[Install]
WantedBy=multi-user.target
重要な部分のみ簡単に説明します。
-
ExecStart
Systemdに実行してもらうコマンドを指定 -
WorkingDirectory
実行するディレクトリ -
Environment
環境変数（ポート番号など）
実行
-
systemdの設定ファイル再読み込み
$ sudo systemctl daemon-reload -
アプリケーション実行
$ sudo systemctl start sample-app -
実行状況を確認
systemstl status sample-appAvtive:がactiveになっていれば成功です。
-
Systemdが実行したシステムのログを確認
journalctl -u backend
以上でデプロイ完了です。
EC2インスタンスのパブリックIPv4アドレスにhttpでアクセスすると、アプリケーションがブラウザ上で動きます。
感想
「システムD」っていう名前の響きがかっこいい。
参考
こちらのUdemy講座の「セクション6: AWS の EC2 の環境構築と手動でのデプロイ」を参考にしました。