Capistrano が Mongrel クラスターを適切に再起動しない
-
03-07-2019 - |
質問
nginx で実行されている 3 つの雑種のクラスターがあり、Capistrano 2.4.3 を使用してアプリをデプロイしています。実行中のシステムがあるときに「キャップ デプロイ」を行うと、動作は次のようになります。
- アプリがデプロイされます。コードは正常に更新されました。
キャップ デプロイの出力には、次のようになります。
- 「sudo -p 」を実行しています sudo パスワード:'mongrel_railsクラスター:: Restart -C /var/www/rails/myapp/current/config/mongrel_cluster.yml "
- サーバー:[「ミイプ」]
- [myip] コマンドを実行しています
- ** [外 ::myip] ポート 9096 を停止しています
- ** [外 ::myip] ポート 9097 を停止しています
- ** [外 ::myip] ポート 9098 を停止しています
- ** [外 ::myip] はすでにポート 9096 を開始しています
- ** [外 ::myip] はすでにポート 9097 を開始しています
- ** [外 ::myip] はすでにポート 9098 を開始しています
- すぐにサーバーを確認すると、Mongrel がまだ実行中であり、前の 3 つのインスタンスの PID ファイルがまだ存在していることがわかります。
- しばらくして (1 分未満)、Mongrel が実行されておらず、PID ファイルも失われ、再起動に失敗していることがわかりました。
- サーバー上で mongrel を手動で起動すると、アプリは正常に起動します。
「Mongrel_railsクラスター::再起動」は、クラスターの再起動を試みる前に完全な停止を適切に待っていないようです。この問題を診断して解決するにはどうすればよいですか?
編集:答えは次のとおりです。
mongrel_cluster は、「再起動」タスクで次のように単純に実行します。
def run
stop
start
end
「start」を呼び出す前にプロセスが終了したかどうかを確認するための待機やチェックは行いません。これは 未処理のパッチが提出された既知のバグ. 。Mongrel Cluster にパッチを適用したところ、問題は解消されました。
解決
capistranoレシピに以下を追加することにより、mongrel_clusterレシピに明示的にpidファイルを削除してから開始することができます。
# helps keep mongrel pid files clean
set :mongrel_clean, true
これにより、--cleanオプションがmongrel_cluster_ctlに渡されます。
私は戻って展開レシピの1つを見て、再起動タスクの動作方法も変更したことに気付きました。 mongrel usersグループの次のメッセージをご覧ください。
以下は私のdeploy:restartタスクです。ちょっとしたハックだと思います。
namespace :deploy do
desc "Restart the Mongrel processes on the app server."
task :restart, :roles => :app do
mongrel.cluster.stop
sleep 2.5
mongrel.cluster.start
end
end
他のヒント
まず、呼び出しのみでテストの範囲を絞ります。 cap deploy:restart
. 。を渡したいかもしれません --debug
リモート実行前にプロンプトを表示するオプション、または --dry-run
このオプションは、設定を調整するときに何が起こっているかを確認するためだけに使用します。
一見すると、これは pid ファイルまたは mongrel プロセスのアクセス許可の問題のように思えますが、確実に知ることは困難です。私の目に留まる点は次のとおりです。
- の
:runner
変数は明示的に次のように設定されますnil
――具体的な理由があったのでしょうか? - カピストラーノ 2.4 では、
:admin_runner
変数. 。レシピ全体を見ないと、これはあなたの問題に関連している可能性がありますか?:ランナー vs.:admin_runner (から capistrano 2.4 リリース)一部のキャッパーは、展開:セットアップと展開:クリーンアップ実行:ランナーユーザーが慎重に作成された権限を台無しにしたことに注目しています。私はこれが問題であることに同意しました。このリリースでは、deploy:start、deploy:stop、およびdeploy:restartはすべて、sudo実行時に引き続き:runnerユーザーを使用しますが、deploy:setupとdeploy:cleanupは:admin_runnerユーザーを使用します。デフォルトでは、:admin_runner 変数は設定されていません。つまり、これらのタスクは root として sudo を実行しますが、:runner として実行したい場合は、「set :admin_runner,runner」を実行するだけです。
次に何をすべきかについての私の推奨事項。雑種を手動で停止し、PID をクリーンアップします。雑種を手動で起動します。次に、実行を続けます cap deploy:restart
問題をデバッグしているとき。必要に応じて繰り返します。
いずれにせよ、前の停止コマンドがすべてのシャットダウンを完了する前に、私のおばあちゃんは起動します。
sleep 2.5は、実行中のすべてのmongrelsを停止するのに2.5秒以上かかる場合、良い解決策ではありません。
の必要性があるようです:
stop && start
対
stop; start
(これがbashの仕組みです。&&は最初のコマンドがエラーなしで終了するのを待ち、&quot ;; quot;は次のコマンドを実行するだけです。)
:があるのだろうか:
wait cluster_stop
then cluster_start
あまりにも基本的なことは嫌いですが、pidファイルを起動しようとすると、まだpidファイルがぶらぶらしているようです。雑種が手で停止していることを確認してください。 pidファイルを手動でクリーンアップします。次に、キャップデプロイを実行します。