クライアントの接続を切らずに、Nginxを現地でアップグレードする方法
以下の文章を日本語で自然な表現に言い換えてください。1つのオプションのみ必要です：
イントロダクション
Nginxは世界で最も人気のある多くのサイトを提供するために使用される、強力なウェブサーバー兼リバースプロキシです。このガイドでは、クライアント接続を失うことなく、Nginxの実行ファイルをアップグレードする方法を実演します。
前提条件
このガイドを始める前に、サーバー上に非ルートユーザーが設定されていることと、sudo特権が付与されていることが必要です。また、Nginxがインストールされている必要もあります。
Ubuntu 22.04の最初のサーバー設定ガイドに従って、そのサーバーにNginxをインストールすることができます。
アップグレードの仕組みはどのように働くのですか。
Nginxは、サービスが起動するとマスタープロセスを起動します。マスターサービスは、実際のクライアント接続を処理する1つ以上のワーカープロセスを生成します。Nginxは、システムから特定の低レベルのシグナルを受け取った際に特定のアクションを実行するように設計されています。これらのシグナルを使用することで、クライアント接続を失わずにNginxやその設定を現地でアップグレードする機会が得られます。
Nginxの提供するインストールおよびアップグレードスクリプトは、Nginxを起動、停止、再起動する際にこれらのシグナルを送信するように設計されています。ただし、これらのシグナルを手動で送信することで、アップグレードを監査し、問題があれば迅速に元に戻すことができます。また、Nginxをソースからインストールしたり、パッケージマネージャーに依存せずにサービスを構成している場合でも、スムーズなアップグレードのオプションを提供します。
以下の信号が使用されます。
- USR2: This spawns a new set of master/worker processes without affecting the old set.
- WINCH: This tells the Nginx master process to gracefully stop its associated worker instances.
- HUP: This tells an Nginx master process to re-read its configuration files and replace worker processes with those adhering to the new configuration. If an old and new master are running, sending this to the old master will spawn workers using their original configuration.
- QUIT: This shuts down a master and its workers gracefully.
- TERM: This initiates a fast shutdown of the master and its workers.
- KILL: This immediately kills a master and its workers without any cleanup.
NginxプロセスのPIDを見つける
さまざまなプロセスに信号を送信するためには、ターゲットのプロセスのPIDを知る必要があります。これを見つける方法は2つあります。
最初に、psユーティリティを使用して、結果の中からNginxをgrepで検索することができます。これにより、マスタープロセスとワーカープロセスを確認することができます。
- ps aux | grep nginx
root 16653 0.0 0.2 119160 2172 ? Ss 21:48 0:00 nginx: master process /usr/sbin/nginx nginx 16654 0.0 0.9 151820 8156 ? S 21:48 0:00 nginx: worker process sammy 16688 0.0 0.1 221928 1164 pts/0 S+ 21:48 0:00 grep –color=auto nginx
選択されたプロセスのPIDは、2番目にハイライトされた列に含まれています。最後の列は、最初の結果がNginxのマスタープロセスであることを明示しています。
マスターNginxプロセスのPIDを見つける別の方法は、/run/nginx.pidファイルの内容を出力することです。
- cat /run/nginx.pid
16653
Nginxのマスタープロセスが2つ実行されている場合、古いプロセスは/run/nginx.pid.oldbinに移動されます。
新しいNginxのマスター/ワーカーセットを生成する。
上手くアップデートするための最初のステップは、実際にNginxパッケージやバイナリをアップデートすることです。パッケージマネージャーまたはソースインストールのどちらの方法でも、Nginxのインストールに適切な方法で行ってください。
新しいバイナリが配置された後、新しい実行ファイルを使用する第二セットのマスター/ワーカープロセスを生成することができます。
あなたは、確認した自分自身のNginxマスタープロセスのPIDを置き換えることを忘れずに、USR2シグナルを直接クエリしたPID番号に送ることでこれを実行できます。
- sudo kill -s USR2 16653
または、次のようにして、PIDファイルに格納されている値を直接コマンドに代入して読み取ることもできます。
- sudo kill -s USR2 `cat /run/nginx.pid`
もし実行中のプロセスを確認すると、Nginxのマスターとワーカーがそれぞれ2つのセット存在していることが分かります。
- ps aux | grep nginx
root 16653 0.0 0.2 119160 2172 ? Ss 21:48 0:00 nginx: master process /usr/sbin/nginx nginx 16654 0.0 0.9 151820 8156 ? S 21:48 0:00 nginx: worker process root 16699 0.0 1.5 119164 12732 ? S 21:54 0:00 nginx: master process /usr/sbin/nginx nginx 16700 0.0 0.9 151804 8008 ? S 21:54 0:00 nginx: worker process sammy 16726 0.0 0.1 221928 1148 pts/0 R+ 21:55 0:00 grep –color=auto nginx
また、元の/run/nginx.pidファイルが/run/nginx.pid.oldbinに移動され、新しいマスタープロセスのPIDが/run/nginx.pidに書き込まれていることも確認できます。
- tail -n +1 /run/nginx.pid*
==> /run/nginx.pid <== 16699 ==> /run/nginx.pid.oldbin <== 16653
これらのファイルに含まれているPIDを使用して、マスタープロセスのどちらにもシグナルを送信できます。
この時点では、マスターとワーカーのセットは両方とも稼働しており、クライアントのリクエストに対応することができます。最初のセットは元のNginxの実行ファイルと設定を使用しており、2番目のセットは新しいバージョンを使用しています。両方のセットは同時に稼働することができますが、統一感を持たせるために新しいセットへの移行を開始すべきです。
最初のマスターの労働者をシャットダウンしてください。
新しいセットへの移行を開始するためには、最初に元のマスターのワーカープロセスを停止する必要があります。元のワーカーは、現在のすべての接続の処理を終了した後、終了します。
元のセットの作業員にマスタープロセスにWINCHシグナルを送ることで停止させます。
- sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
これにより、新しいマスターの作業員は新しいクライアントの接続を単独で処理できるようになります。古いマスタープロセスはまだ実行中ですが、作業員はいません。
- ps aux | grep nginx
root 16653 0.0 0.2 119160 2172 ? Ss 21:48 0:00 nginx: master process /usr/sbin/nginx root 16699 0.0 1.5 119164 12732 ? S 21:54 0:00 nginx: master process /usr/sbin/nginx nginx 16700 0.0 0.9 151804 8008 ? S 21:54 0:00 nginx: worker process sammy 16755 0.0 0.1 221928 1196 pts/0 R+ 21:56 0:00 grep –color=auto nginx
新入社員が接続を個別に受け入れる際に、これにより彼らを監査することができます。
結果を評価し、次のステップを踏む。
この段階でシステムをテストして監査することで、問題の兆候がないことを確認すべきです。新しいNginxのプログラムがバグフリーでトラフィックを処理できるようにするため、設定をこの状態のまま時間をかけても問題ありません。
あなたの次のステップは、問題に遭遇するかどうかに完全に依存します。
もしアップグレードが成功していれば
新しいセットの手が不具合がなければ、安全に古いマスタープロセスをシャットダウンできます。これを行うために、古いマスターにQUITシグナルを送信してください。
- sudo kill -s QUIT `cat /run/nginx.pid.oldbin`
古いマスタープロセスは優雅に終了し、新しいNginxのマスター/ワーカーのみが残ります。この時点で、クライアントの接続を中断することなく、Nginxのバイナリをインプレースでアップデートすることが成功しました。
もしアップグレードがうまく行かなかった場合
もし新しい従業員のチームに問題があるようであれば、古い設定とバイナリに戻ることができます。ただし、古いマスタープロセスが終了していない限り、この操作は可能です。
これを行う最も良い方法は、以前のマスターのワーカーをHUPシグナルで再起動させることです。通常、NginxマスターにHUPシグナルを送信すると、設定ファイルを再読み込みし、新しいワーカーを開始します。ただし、対象が古いマスターの場合、元の動作していた設定を使用して新しいワーカーを生成します。
- sudo kill -s HUP `cat /run/nginx.pid.oldbin`
現在、マスター/ワーカープロセスのセットを2つ持つように戻っているはずです。
- ps aux | grep nginx
root 16653 0.0 0.2 119160 2172 ? Ss 21:48 0:00 nginx: master process /usr/sbin/nginx nginx 16654 0.0 0.9 151820 8156 ? S 21:48 0:00 nginx: worker process root 16699 0.0 1.5 119164 12732 ? S 21:54 0:00 nginx: master process /usr/sbin/nginx nginx 16700 0.0 0.9 151804 8008 ? S 21:54 0:00 nginx: worker process sammy 16726 0.0 0.1 221928 1148 pts/0 R+ 21:55 0:00 grep –color=auto nginx
最新の労働者は古いマスターと関連付けられています。両方の労働者グループは、この時点でクライアント接続を受け入れます。そして、新しいバグのあるマスタープロセスとその労働者を停止するために、QUITシグナルを送ってください。
- sudo kill -s QUIT `cat /run/nginx.pid`
あなたは昔のマスターや同僚に戻るべきです。 (Anata wa mukashi no masutaa ya douryou ni modorubeki desu.)
- ps aux | grep nginx
root 16653 0.0 0.2 119160 2172 ? Ss 21:48 0:00 nginx: master process /usr/sbin/nginx nginx 16654 0.0 0.9 151820 8156 ? S 21:48 0:00 nginx: worker process sammy 16688 0.0 0.1 221928 1164 pts/0 S+ 21:48 0:00 grep –color=auto nginx
元のマスターは、PIDに対して/run/nginx.pidファイルの所有権を取り戻すでしょう。
もしどうしてもうまくいかない場合には、新しいマスターサーバーに対してTERMシグナルを送信することを試してみることができます。これによりシャットダウンが開始されるはずです。これにより新しいマスターサーバーとその他のワーカーが停止し、古いマスターは自動的にワーカープロセスを開始します。もし深刻な問題があってバグがあるワーカーが終了していない場合には、それぞれにKILLシグナルを送信してクリーンアップすることができます。ただし、これは最終手段であり、接続が切断される可能性があるため注意が必要です。
古いバイナリに戻った後も、システムに新しいバージョンがインストールされていることを忘れずに覚えておいてください。問題なくNginxが再起動時に動作するようにするため、不具合のあるバージョンを削除し、以前のバージョンに戻してください。
結論
日本語での言い換え案：
現在の段階では、Nginxのバイナリを切り替えることがスムーズに可能になっているはずです。Nginxのマスター・ワーカー二つの組を同時に扱う能力により、サーバーソフトウェアのアップグレードをオフラインにすることなく行うことができます。
