序章

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

前提条件

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

Ubuntu 14.04を使用している場合は、sudo権限ここでユーザーを設定する方法を学ぶことができます。 このガイドに従ってNginxをインストールできます。

CentOS 7を使用している場合は、このガイドsudoユーザー向けに実行し、次にこのガイドを実行してNginxをインストールすることでセットアップできます。

アップグレードの仕組み

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

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

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

  • USR2 :これにより、古いセットに影響を与えることなく、マスター/ワーカープロセスの新しいセットが生成されます。
  • WINCH :これは、Nginxマスタープロセスに、関連付けられたワーカーインスタンスを正常に停止するように指示します。
  • HUP :これは、Nginxマスタープロセスに構成ファイルを再読み込みし、ワーカープロセスを新しい構成に準拠しているプロセスに置き換えるように指示します。 古いマスターと新しいマスターが実行されている場合、これを古いマスターに送信すると、元の構成を使用してワーカーが生成されます。
  • QUIT :これにより、マスターとそのワーカーが正常にシャットダウンされます。
  • TERM :これにより、マスターとそのワーカーの高速シャットダウンが開始されます。
  • KILL :これにより、クリーンアップなしでマスターとそのワーカーが即座に強制終了されます。

NginxプロセスPIDの検索

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

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

  1. ps aux | grep nginx
output
root 10846 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ファイルの内容を印刷することです。

  1. cat /run/nginx.pid
output
10846

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

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

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

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

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

  1. sudo kill -s USR2 10846

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

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

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

  1. ps aux | grep nginx
output
root 10846 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 11003 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に書き込まれていることもわかります。

  1. tail -n +1 /run/nginx.pid*
output
==> /run/nginx.pid <== 11003 ==> /run/nginx.pid.oldbin <== 10846

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

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

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

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

マスタープロセスにWINCH信号を発行して、元のセットのワーカーを停止します。

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

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

  1. ps aux | grep nginx
output
root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf root 11003 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シグナルを送信すると、構成ファイルが再度読み取られ、新しいワーカーが起動します。 ただし、ターゲットが古いマスターの場合、元の作業構成を使用して新しいワーカーを生成するだけです。

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

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

  1. ps aux | grep nginx
output
root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf root 11003 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信号を送信して、新しいバグのあるマスタープロセスとそのワーカーを停止します。

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

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

  1. ps aux | grep nginx
output
root 10846 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の機能により、サーバーマシンをオフラインにすることなくサーバーソフトウェアをアップグレードすることができます。