私の現在のセットアップは、多数のアップストリームサーバーの前にあるロードバランサーとしてのnginxです。
ユーザーエクスペリエンスを変えずにデプロイできるようにしたいと考えています。これは、502がなく、ページ時間が増加しないことを意味します。
私の理解では、nginx -s reload
が発行されると、nginxは新しいスレッドを正常に生成して、新しい構成の新しい接続を処理しますが、リロード時に処理中だったリクエストの処理を終了します。さらに、アップストリームブロックでアップストリームをdown
としてマークし、リロードすると、ローテーションからアップストリームが取得されますが、実行中の接続はすべて終了することをどこかで読みました。
これのいずれか/すべてが正しいですか?
現在の計画では、nginxホストに小さなプロセスを配置します。これにより、基本的にnginx構成が変更され、内部REST APIを介して要求されたときに、これらの正常なリロードが発行されます。
次に、デプロイツールはそのプロセスに接続し、各アップストリームの正常なシャットダウンと起動/ウォームアップが完了した後、nginxconfigからアップストリームを順番に追加/削除します。
これは意味がありますか?他の人はこれをどのようにやっていますか?このためにすでに利用可能なツールはありますか?
私はこれに関する情報を検索するのに多くの運がありませんでした...
はい、nginxはリロード時に現在のリクエストを処理し続け、新しい構成で新しいリクエストの処理を開始すると考えるのは正しいです。
http://nginx.org/en/docs/beginners_guide.html#control
古いワーカープロセスは、シャットダウンするコマンドを受信し、新しい接続の受け入れを停止し、そのようなすべての要求が処理されるまで現在の要求を処理し続けます。その後、古いワーカープロセスが終了します。
アップストリームをdown
としてマークすることは、構成からそれを削除することと大きな違いはありません。どちらの場合も、新しいリクエストは受け付けません。
Nginx構成(cog https://nedbatchelder.com/code/cog/ を使用して生成)を頻繁にリロードしますが、プロキシに関する限り、ダウンタイムは発生しません上流の場所。アップストリーム自体が要求を処理する準備ができている限り、ダウンタイムはありません。