Laravel:workerを自動起動させるSupervisor設置でハマったところ

Laravel:workerを自動起動させるSupervisor設置でハマったところ

Supervisor設定でハマったところ

もう2度と同じ間違いをうろつかないように、しっかりまとめたいと思います。

■supervisorインストールまで

  1. 『$ sudo yum install supervisor』でインストールするとバージョンが古い
  2. 『$ sudo apt-get install supervisor』はUbuntuのコマンド。CentOSでは使えない
  3. 『$ sudo easy_install supervisor』を使うには準備が必要(sudo yum install python-setuptoolsを先に実行しておく)
  4. supervisorはpython2系がデフォルトになっているとインストールに失敗する事がある。
  5. pythonのデフォルトを変更した場合、リンク先を変えないとyumが動かない

■supervisorインストール後(設定)

  1. supervisorの設定を紹介したページにはsupervisord.confに直接記載とiniを作り読み込ませている場合がある
  2. 起動スクリプトをRPMから抽出させる場合、『curl -LO』にてDownloadしたPRMが壊れることがある点に注意する
  3. Laravel Queueの設定を登録するときはマニュアルをそのまま記載せずに自分の環境に置き換える

こんだけ書くと特にインストールでハマってたことがよくわかりますね。
1つづつ確認していきます。

yum でインストールするとバージョンが古い

私の場合は確か2.4がインストールされました。
でも、この記事を記載している時点の最新はsupervisor 4.0.3 全然違うじゃん!

インストール後の設定のお手本となるサイト記事さんたちはバージョン3系が多いようなのでそっちをインストールしたい。
結論を先に書いてしまうと、その場合は下のコマンドが最適です。

apt-get はCentOSでは使えない

インストールについてネット上の記事を読み漁っていると apt-get コマンドでインストールしている方を見かけます。

Laravelマニュアルにも次のように記載されています。

UbuntuにSupervisorをインストールするには、次のコマンドを使ってください。

うちはUbuntuじゃないんだよという方、他のインストール方法を考えましょう。

easy_install を使うには準備が必要

easy_install でsupervisorのインストールを行っている記事も多く目にします。
私も実行してみました。

その結果『そんなコマンド知らねーよ』と怒られてしまいました。
この場合、先に下のコマンドを実行しておく必要があります。

これでeasy_installを使える環境が整います。

supervisorはpython2系がデフォルトになっているとインストールに失敗する事がある

私の場合はpython2.2がデフォルトになっていました。

そのため、インストールを始めてもエラーを吐き出してました。
どうやらsupervisor4.0.3ではpython2.7以上が必要な様子、pythonのバージョンを変更しなくてはなりません。

最近のpythonでは、インストールをすると2系と3系のバージョンが両方入る様です。
そのため、2系がデフォルトになっていても3系がインストールされている可能性があります。

3系の存在確認には次のコマンドを使います。

これでバージョンが表示されれば3系のpythonがすでに入っていることになります。
シンボリックリンクを変更することでデフォルトのpythonを3系にする事は簡単にできますが、これが結構大きな落とし穴になる可能性があります。

pythonのデフォルト変更後yumが動かない

デフォルトPythonの変更をし、意気揚々と sudo yum install python-setuptools を走らせたら 「yumなんて知らねーよ!」と怒られました。

どうやらyumのリンク先をpython3系にしろとの事

でリンク先を変更すると使えるようになります。

ただし、多々問題もある様です。詳細は参考としたサイトさんの記事を確認しましょう。

pythonのデフォルトバージョンを3.7にしたい

Ubuntu16.04でPythonのバージョンを2.7から3.6にバージョンアップする

CentOS7 yum updateでエラーが出るとき

supervisord.confの設定は人それぞれ

いろいろなサイトを参考にさせて頂いていると「どれが正しいんだ?」と思うことがあります。
supervisord.confの設定もそうです。その理由はsupervisord.confに直接記載する説明とiniを作り読み込ませている説明があるからです。

iniで実行ファイルを外部に保存し読み込ませる場合、これらのファイルを保管するフォルダはインストール時に作成されません。
理由は自由だからです。
/usr/の中に作ってもいいし、/etc/の中に作ってもいいし、 /home/user/の中に作ってもいいわけです。

ちなみに/etc/supervisor/を作りここに記載をする例が多かったため、最初はこの設定じゃないといけないのかと思いましたが全く自由で自分で決められるようです。
※supervisord.confにちゃんと登録していればしっかり読み込んでくれます。

『curl -LO』にてDownloadしたPRMが壊れることがある

これも今回下記サイトを参考にしたところ経験したことです。

Supervisorのインストールで起動スクリプトを書きたくなかったのでRPMから抽出して利用した話

としたところ、rpmがわからないと言われてしまいました。

調べるとcurl で取得した場合、壊れているときがあるとの事。

supervisor-2.1-9.el6.noarch.rpm

supervisor-3.0-1.gf.el6.noarch.rpm

直接Downloadできるので入手してアップロードしましょう。

上記の場合は cd ~ なのでユーザーのホームディレクトリに上げれば参考サイトの続きをそのまま継続できます。

マニュアルをそのまま記載せずに自分の環境に置き換える

当たり前と言えば至極当たり前の話。

でも記載内容の意味が解らないと変更もできません。

Laravel Queueでは次の通り マニュアルより

▼変更後

commandについては、directoryを使わず下の様に1行にまとめても良い。

また、ログファイルの保存先『stdout_logfile』をLaravelプロジェクトのstrage/logs/supervisor.logとすれば、Laravelのログと同じ場所で管理でき利便性が高くなる。

まとめ

まぁこんな感じで右往左往しながらでしたが、supervisorの設置設定はマスタしました。
失敗が多いほど記憶には定着するというね。
歩みは遅くなるけどね。

作成中のシステムには非同期処理が必須なので、うまくいかない時は焦ってましたがしっかりと着地できてよかったです。
この記事も少しでも同じポイントで悩む方の参考になればうれしいです。

さぁ、もうひと頑張りするかなっ!