Rack： `bundle install --deployment`中のBundler :: GemNotFoundエラー

Question

私は、ラックの上にSinatraアプリケーションを実行しているいくつかのマシンを稼働させています。通常は、サーバーの変更を同期するために使用しているPuppetがプロジェクトのGemfile.lockが変更され、結果としてbundle install --binstubs --deploymentコマンドを発行して新しい宝石を入手する必要があることに気付くまで、すべてが大変です。この場合、新しいGemがまだインストールされていないため、ANY httpリクエストはBundlerに呼び出して宝石を要求すると500エラーが発生します。

通常、サーバが稼動していることを定期的に確認する別のプロセスがあるため、少なくとも1つのRackプロセスがハングアップしていますが、この場合、Rackプロセスは稼働していません。 PassengerMinInstancesディレクティブは、問題が新しいインスタンスにあった場合に役立つかもしれませんが、定期的にページを取得してサーバーがまだ稼動していることをテストするプロセスがあるため、少なくとも1つのRackプロセスがまだ稼動していなければなりません要求。

bundle installが完了するまで、人形は実際にはRackを再起動しません（touchによってrestart.txtファイルが作成される）ので、私たちのRackプロセスがこれで離れる理由はわかりません時間。誰もこれに遭遇しましたか？私が見落としてきたすべての要求に対して、環境全体をリロードしないラックオプションがありますか？

Answer 1

後悔のため、私はこの質問に答えます。配備の一環として、すべてのファイルにchown -Rをつけました。これはファイルのctime（mtimeではなく）を更新します。 Passengerに興味深いbug/featureがあり、/tmp/restart.txtファイルのmtimeまたはctimeが変更されるたびにサーバを再起動します。

解決方法：展開中にディレクトリをchowningしないでください。

Answer 2

これはあなたの質問に直接答えるものではないことは知っていますが、この種の問題を回避するために私が過去に行ったことは、バージョン番号の付いたディレクトリに、 （Nginx）プロキシサーバーが要求をそのリンクにルーティングします。デプロイの終わりに、デプロイスクリプトは新しいアプリケーションへのリンクを示します。

私にとってはうまくいくように思えましたが、実際に問題が起こった場合はいつでも手動でリンクを元のバージョンに戻すことができます。