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

前書き

Nginxは強力なWebサーバーであり、世界で最も人気のあるサイトの多くにサービスを提供するリバースプロキシです。 このガイドでは、クライアント接続を失うことなく、Nginx実行可能ファイルを適切にアップグレードする方法を示します。

前提条件

このガイドを始める前に、 `+ sudo +`権限で設定されたサーバー上に非rootユーザーが必要です。 また、Nginxをインストールする必要があります。

Ubuntu 14.04を使用している場合は、「+ sudo +」権限を持つユーザーを設定する方法を学ぶことができますhttps://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 [ここに]。 Nginxはhttps://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-14-04-lts [このガイド]に従ってインストールできます。

CentOS 7を使用している場合は、https://www.digitalocean.com/community/tutorials/initial-server-setup-with-centos-7 [このガイド]を実行して、「+ sudo +」ユーザー、続いてhttps://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-centos-7 [このガイド]でNginxをインストールします。

アップグレードの仕組み

Nginxは、サービスの開始時にマスタープロセスを生成することで機能します。 マスターサービスは、実際のクライアント接続を処理する1つ以上のワーカープロセスを起動します。 Nginxは、管理者から特定の信号を受信したときに特定のアクションを実行するように設計されています。 これらの信号を使用すると、クライアント接続を失うことなく、Nginxまたはその構成をインプレースで簡単にアップグレードできます。

配布パッケージのメンテナーによって提供される特定のサービススクリプトは、従来のアップグレードで使用できるこの機能を提供します。 ただし、手動でアップグレードすると、アプローチの柔軟性が向上し、問題がある場合はアップグレードを監査して迅速に元に戻すことができます。 また、ソースからNginxをインストールした場合、またはこの機能を提供しない方法を使用している場合、正常にアップグレードするオプションも提供されます。

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

  • * + USR2 + *:これにより、古いセットに影響を与えることなく、マスター/ワーカープロセスの新しいセットが生成されます。

  • * + WINCH + *:これは、関連するワーカーインスタンスを正常に停止するようにNginxマスタープロセスに指示します。

  • * + HUP + *:これは、Nginxマスタープロセスに構成ファイルを再読み込みし、ワーカープロセスを新しい構成に準拠するワーカープロセスに置き換えるよう指示します。 古いマスターと新しいマスターが実行されている場合、これを古いマスターに送信すると、元の構成を使用してワーカーが生成されます。

  • * + QUIT + *:これにより、マスターとそのワーカーが正常にシャットダウンされます。

  • * + TERM + *:これにより、マスターとそのワーカーの高速シャットダウンが開始されます。

  • * + KILL + *:これは、クリーンアップせずにマスターとそのワーカーを即座に殺します。

NginxプロセスPIDの検索

さまざまなプロセスに信号を送信するには、ターゲットプロセスのPIDを知る必要があります。 これを見つけるには2つの簡単な方法があります。

最初に、 `+ ps `ユーティリティを使用してから、結果の中でNginxに対して ` grep +`を使用できます。 これは簡単で、マスタープロセスとワーカープロセスを確認できます。

ps aux | grep nginx
outputroot       0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    10847  0.0  0.1  47936  1908 ?        S    13:26   0:00 nginx: worker process
user     10961  0.0  0.0 112640   964 pts/0    S+   13:53   0:00 grep --color=auto nginx

2番目の列には、選択したプロセスのPIDが含まれています。 強調表示されているのは、プロセスのPIDです。 最後の列は、最初の結果がNginxマスタープロセスであることを明確にします。

マスターNginxプロセスのPIDを見つける別の方法は、 `+ / run / nginx.pid +`ファイルの内容を出力することです:

cat /run/nginx.pid
output

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

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

実行可能ファイルを適切に更新する最初のステップは、実際にバイナリを更新することです。 これは、パッケージマネージャーまたはソースインストールを介して、Nginxのインストールに適した方法を使用して行います。

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

これを行うには、クエリしたPID番号に「+ USR2 +」シグナルを直接送信します(ここで、独自のNginxマスタープロセスのPIDを必ず置き換えてください)。

sudo kill -s USR2

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

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

現在のプロセスを確認すると、Nginxマスター/ワーカーの_two_セットがあることがわかります。

ps aux | grep nginx
outputroot       0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    10847  0.0  0.1  47936  1908 ?        S    13:26   0:00 nginx: worker process
root       0.0  0.3  47564  3132 ?        S    13:56   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    11004  0.0  0.1  47936  1912 ?        S    13:56   0:00 nginx: worker process
user     11031  0.0  0.0 112640   960 pts/0    S+   14:01   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 <==


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

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

この時点で、マスター/ワーカーセットは両方とも動作可能であり、クライアントリクエストを処理できます。 最初のセットは元のNginx実行可能ファイルと構成を使用しており、2番目のセットは新しいバージョンを使用しています。 それらは並行して動作し続けることができますが、一貫性を保つために、新しいセットへの移行を開始する必要があります。

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

新しいセットへの移行を開始するために、最初にできることは、元のマスターのワーカープロセスを停止することです。 元のワーカーは、現在の接続をすべて処理して終了します。

マスタープロセスに「+ WINCH +」シグナルを発行して、元のセットのワーカーを停止します。

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

これにより、新しいマスターのワーカーは新しいクライアント接続のみを処理できます。 古い_master_プロセスは引き続き実行されますが、ワーカーはありません。

ps aux | grep nginx
outputroot       0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root       0.0  0.3  47564  3132 ?        S    13:56   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    11004  0.0  0.1  47936  1912 ?        S    13:56   0:00 nginx: worker process
user     11089  0.0  0.0 112640   964 pts/0    R+   14:13   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
outputroot       0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root       0.0  0.3  47564  3132 ?        S    13:56   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    11004  0.0  0.1  47936  1912 ?        S    13:56   0:00 nginx: worker process
nginx    19918  0.0  0.1  47936  1900 ?        S    14:47   0:00 nginx: worker process
user     19920  0.0  0.0 112640   964 pts/0    R+   14:48   0:00 grep --color=auto nginx

最新のワーカーは古いワーカーに関連付けられています。 両方のワーカーセットは、この時点でクライアント接続を受け入れます。 次に、 `+ QUIT +`シグナルを送信して、新しいバグのあるマスタープロセスとそのワーカーを停止します。

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

古いマスターとワーカーに戻る必要があります。

ps aux | grep nginx
outputroot       0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    19918  0.0  0.1  47936  1900 ?        S    14:47   0:00 nginx: worker process
user     19935  0.0  0.0 112640   964 pts/0    R+   14:50   0:00 grep --color=auto nginx

元のマスターは、PIDの `+ / run / nginx.pid +`ファイルを取り戻します。

上記が何らかの理由で機能しない場合は、シャットダウンを開始するはずの「+ TERM 」シグナルを新しいマスターサーバーに送信するだけで済みます。 これにより、新しいマスターとすべてのワーカーが停止し、古いマスターが自動的にキックされてワーカープロセスが開始されます。 深刻な問題があり、バグの多いワーカーが終了しない場合は、それぞれに「 KILL +」シグナルを送信してクリーンアップできます。 ただし、接続を切断するため、これは最後の手段と見なす必要があります。

古いバイナリに戻った後、新しいバージョンがシステムにインストールされていることに注意してください。 Nginxが再起動時に問題なく実行されるように、バグのあるバージョンを削除して以前のバージョンにロールバックする必要があります。

結論

これで、マシンを1つのNginxバイナリから別のバイナリにシームレスに移行できるはずです。 関係に関する情報を維持しながら2つのマスター/ワーカーセットを処理するNginxの機能により、サーバーマシンをオフラインにすることなくサーバーソフトウェアをアップグレードできます。