クライアント接続を切断せずにNginxをインプレースでアップグレードする方法

投稿日: 2019-11-08 2022-10-19
タグ: nginx

序章

Nginx is a powerful web server and reverse proxy that is used to serve many of the most popular sites in the world. このガイドでは、クライアント接続を失うことなく、Nginx実行可能ファイルを適切にアップグレードする方法を示します。

前提条件

このガイドを開始する前に、サーバー上にroot以外のユーザーがいて、次のように構成されている必要があります。 sudo privileges. また、Nginxをインストールする必要があります。

You can follow our initial server setup guide for Ubuntu 22.04 and then install Nginx on that server.

アップグレードの仕組み

Nginx works by spawning a master process when the service starts. The master service, in turn, spawns one or more worker processes that handle the actual client connections. Nginx is designed to perform certain actions when it receives specific low-level signals from the system. Using these signals provides you with the opportunity to upgrade Nginx or its configuration in-place, without losing client connections.

Nginx’s provided installation and upgrade scripts are designed to send these signals when starting, stopping, and restarting Nginx. However, sending these signals manually allows you to audit the upgrade and revert quickly if there are problems. This will also provide an option to upgrade gracefully if you have installed Nginx from source or are not relying on your package manager to configure the service.

次の信号が使用されます。

USR2 ：これにより、古いセットに影響を与えることなく、マスター/ワーカープロセスの新しいセットが生成されます。
WINCH ：これは、Nginxマスタープロセスに、関連付けられたワーカーインスタンスを正常に停止するように指示します。
HUP: This tells an Nginx master process to re-read its configuration files and replace worker processes with those adhering to the new configuration. 古いマスターと新しいマスターが実行されている場合、これを古いマスターに送信すると、元の構成を使用してワーカーが生成されます。
QUIT ：これにより、マスターとそのワーカーが正常にシャットダウンされます。
TERM ：これにより、マスターとそのワーカーの高速シャットダウンが開始されます。
KILL ：これは、クリーンアップなしでマスターとそのワーカーを即座に殺します。

NginxプロセスPIDの検索

In order to send signals to the various processes, we need to know the PID for the target process. There are two ways to find this.

まず、あなたは使用することができます ps ユーティリティそして次に grep for Nginx among the results. This allows you to see the master and worker processes:

ps aux | grep nginx

output
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

The second, highlighted column contains the PIDs for the selected processes. 最後の列は、最初の結果がNginxマスタープロセスであることを明確にしています。

マスターNginxプロセスのPIDを見つける別の方法は、コンテンツを印刷することです。 /run/nginx.pid ファイル：

cat /run/nginx.pid

output
16653

2つのNginxマスタープロセスが実行されている場合、古いプロセスはに移動されます /run/nginx.pid.oldbin.

新しいNginxマスター/ワーカーセットを生成します

The first step to gracefully updating is to actually update your Nginx package and/or binaries. パッケージマネージャーまたはソースインストールのいずれを使用する場合でも、Nginxインストールに適した方法を使用してこれを実行します。

新しいバイナリが配置されたら、新しい実行可能ファイルを使用するマスター/ワーカープロセスの2番目のセットを生成できます。

You can do this by sending the USR2 照会したPID番号に直接通知します（ここでは、必ず独自のNginxマスタープロセスのPIDに置き換えてください）。

sudo kill -s USR2 16653

または、次のように、PIDファイルに保存されている値を直接コマンドに読み込んで置き換えることができます。

sudo kill -s USR2 `cat /run/nginx.pid`

If you check your running processes, you will see that you now have two sets of Nginx masters and workers:

ps aux | grep nginx

outputroot       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*

output==> /run/nginx.pid <==
16699

==> /run/nginx.pid.oldbin <==
16653

これらのファイルに含まれているPIDを使用して、いずれかのマスタープロセスに信号を送信できるようになりました。

At this point, both master/worker sets are operational and capable of serving client requests. The first set is using the original Nginx executable and configuration and the second set is using the newer versions. それらは並行して動作し続けることができますが、一貫性を保つために、新しいセットへの移行を開始する必要があります。

最初のマスターの労働者をシャットダウンします

In order to begin the transition to the new set, the first thing to do is stop the original master’s worker processes. 元のワーカーは、現在のすべての接続の処理を終了してから終了します。

元のセットのワーカーを発行して停止します WINCH マスタープロセスへのシグナル：

sudo kill -s WINCH `cat /run/nginx.pid.oldbin`

This will let the new master’s workers handle new client connections alone. 古いmasterプロセスは引き続き実行されますが、ワーカーはありません。

ps aux | grep nginx

outputroot       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

This lets you audit the new workers as they accept connections in isolation.

結果を評価し、次のステップに進む

You should test and audit your system at this point to make sure that there are no signs of problems. 新しいNginx実行可能ファイルにバグがなく、トラフィックを処理できることを確認したい限り、構成をこの状態のままにしておくことができます。

Your next step will depend entirely on whether you encounter problems.

If Your Upgrade was Successful

If you experienced no issues with your new set’s workers, you can safely shut down the old master process. To do this, send the old master the QUIT 信号：

sudo kill -s QUIT `cat /run/nginx.pid.oldbin`

The old master process will exit gracefully, leaving only your new set of Nginx master/workers. この時点で、クライアント接続を中断することなく、Nginxのインプレースバイナリ更新を正常に実行できました。

If Your Upgrade was Unsuccessful

If your new set of workers seem to be having problems, you can transition back to the old configuration and binary. This is possible as long as you have not QUIT the older master process.

これを行うための最良の方法は、古いマスターのワーカーを再起動して、 HUP signal. 通常、Nginxマスターを送信すると HUP signal, it will re-read its configuration files and start new workers. However, when the target is an older master, it will spawn new workers using its original, working configuration:

sudo kill -s HUP `cat /run/nginx.pid.oldbin`

これで、マスター/ワーカープロセスの2つのセットに戻るはずです。

ps aux | grep nginx

outputroot       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

The newest workers are associated with the old master. Both worker sets will be accepting client connections at this point. ここで、新しいバグのあるマスタープロセスとそのワーカーを停止するには、 QUIT 信号：

sudo kill -s QUIT `cat /run/nginx.pid`

あなたはあなたの古いマスターと労働者に戻るべきです：

ps aux | grep nginx

output
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

元のマスターは /run/nginx.pid そのPIDのファイル。

If this does not work for any reason, you can try just sending the new master server the TERM signal, which should initiate a shutdown. This should stop the new master and any workers while automatically kicking over the old master to start its worker processes. 深刻な問題があり、バギーワーカーが退出していない場合は、それぞれに KILL signal to clean up. This should be a last resort, however, as it will cut off connections.

After transitioning back to the old binary, remember that you still have the new version installed on your system. 再起動時にNginxが問題なく実行されるように、バグのあるバージョンを削除して以前のバージョンにロールバックする必要があります。

結論

By now, you should be able to seamlessly transition your machines from one Nginx binary to another. 関係に関する情報を維持しながら2つのマスター/ワーカーセットを処理するNginxの機能により、サーバーマシンをオフラインにすることなくサーバーソフトウェアをアップグレードすることができます。

getdocs

13036