はじめに
こんにちは。近頃railsを触っていますが、webサーバさえ起動すればリクエストを受け付けてくれるPHPと違い、railsはrackサーバの起動が必要になりますね。
そこで今回はCentOS7でsystemdに自作のスクリプトを登録してサービスとして操作し、サーバ起動時にpumaが自動で起動するところまで設定してみます。
chkconfigについてざっくり
サーバサイドに詳しくない方向けに。ご存知の方は読み飛ばしてOKです。
- chkconfigは、サービスの自動起動を管理するコマンドです。CentOS6まで使われていました。
- 端末としてみなさんが使っているmacやwindowsでは、マシンの起動時に様々なサービスが立ち上がっています。
サーバでもそれは同様で、例えばNginxやMySQLがインストールされています。それらの起動を管理するのがchkconfigです。 - CentOS7でもchkconfigコマンドは実行できますが、systemctl(systemd)へのリダイレクトになっているので、今後はRedhat系を使うのであればsystemdになります（AmazonLinux2でもsystemdですし）。
- 参考
chkconfigまとめ
chkconfig – サービスの自動起動の設定 / CentOS
CentOS7系と6系のコマンドの違いについて
chkconfigって結局なんなんだ
前提
- CentOS7.5
- rbenv, ruby-build, rails, bundlerインストール済み
- ユーザー名「testuser」のホームディレクトリ配下にrails new済みで、
rails sすれば問題なくpumaが起動する
起動スクリプトを作成する
puma起動のコマンドをシェルスクリプトで作成します。
場所はどこでもよいですが、testuserがアクセスおよび実行できるパスにします。
1 2 3 4 5 6 7 8 9 10 | $ cd ~ $ vi puma.sh #!/bin/bash # 「testapp」はrails newで指定したアプリ名です。 cd /home/testuser/testapp bundle exec pumactl start # シェルの実行権限設定 $ chmod 755 ~/puma.sh |
Unitを定義する
/etc/systemd/system/以下に定義ファイルを作成します。これでsystemdでの操作が可能になります。
他にももっと細かく記述できますが、以下は起動のための最低限の内容です。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | $ vi /etc/systemd/system/puma.service [Unit] # サービスの説明文です。内容は自由です。 Description = puma as service [Service] # スクリプト実行時のユーザを指定します。 User = testuser # スクリプト実行時の環境変数を記述したファイルのパスです。次項で説明します。 EnvironmentFile=/etc/systemd/env # systemctl start [サービス名] を実行すると、ここに設定されたスクリプトをsystemdが実行します。 ExecStart = /home/testuser/puma.sh # サービスが停止した際の動作を指定します。alwaysで常に再起動を実施します。 Restart = always # 起動完了の判定方法です。simpleでコマンド実行時に起動完了と判断します。 Type = simple [Install] WantedBy=multi-user.target |
EnvironmentFileを作成する
systemdは環境変数を一切読み込まないため、スクリプト実行時に読み込まれてほしい環境変数はEnvironmentFileに記述します。以下記載例です。
なおこのファイル内では変数を評価しないので、値は全てべた書きになります。Userに指定するユーザでログインして、printenv | more等であらかじめ環境変数の値を確認しておきましょう。
1 2 3 | $ vi /etc/systemd/env PATH=/home/testuser/.rbenv/shims:/home/testuser/.rbenv/plugins/ruby-build/bin:/home/testuser/.rbenv/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/testuser/.local/bin:/home/testuser/bin |
確認と設定
systemdで管理できるようになっているか
systemctl list-unit-files --type=service | grep pumaでpuma.serviceが表示されていればOKです。
自動起動を有効化する
systemctl enable puma
実行後、メッセージは特に表示されません。
手動で起動してみる
systemctl start pumaを実行し、ブラウザでアクセスします。
失敗時はsystemctl status pumaで最後数行分のログが確認できますが、もっと表示したい場合はjournalctl -b | lessで、サーバ起動後のログが一覧できます。
成功していれば、下記のようなステータスになります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | $ systemctl status puma ● puma.service - puma as service Loaded: loaded (/etc/systemd/system/puma.service; enabled; vendor preset: disabled) Active: active (running) since Sun 2018-07-22 07:38:55 UTC; 41min ago Main PID: 11831 (puma.sh) CGroup: /system.slice/puma.service ├─11831 /bin/bash /home/testuser/puma.sh └─11832 puma 3.11.4 (tcp://0.0.0.0:3000) [testapp] Jul 22 07:38:55 localhost.localdomain systemd[1]: puma.service holdoff time over, scheduling restart. Jul 22 07:38:55 localhost.localdomain systemd[1]: Started puma as service. Jul 22 07:38:55 localhost.localdomain systemd[1]: Starting puma as service... Jul 22 07:38:55 localhost.localdomain puma.sh[11831]: Puma starting in single mode... Jul 22 07:38:55 localhost.localdomain puma.sh[11831]: * Version 3.11.4 (ruby 2.4.4-p296), codename: Love Song Jul 22 07:38:55 localhost.localdomain puma.sh[11831]: * Min threads: 5, max threads: 5 Jul 22 07:38:55 localhost.localdomain puma.sh[11831]: * Environment: development Jul 22 07:38:56 localhost.localdomain puma.sh[11831]: * Listening on tcp://0.0.0.0:3000 Jul 22 07:38:56 localhost.localdomain puma.sh[11831]: Use Ctrl-C to stop |
自動起動確認
shutdown -r等でサーバを再起動後、再度ブラウザでアクセスします。失敗している時は上述したsystemctl statusやjournalctlでログを確認しましょう。
さいごに
いかがでしたでしょうか。今回は自動起動の設定を紹介しましたが、.serviceファイルにはもっと様々な設定項目があり、細かい制御が可能です。
例えば[Unit]セクションではサービス起動の順番や他サービスとの依存関係など、[Service]セクションではsystemctl stopやsystemctl reloadの設定ができます。
長らくCentOS5/6を使っていたせいで、ついついservice httpd startなどとタイプしてしまうのですが、こうして実際に使いつつ整理することで、少しずつ手に馴染んできました。
