Nginxホットデプロイメントの実装

Nginxホットデプロイメントの実装

上記のブログ投稿に従ってください。ファイアウォールをオフにして、ブラウザ経由でNginxサービスへのローカル アクセスを許可します。

[root@localhost ~]# systemctl stop ファイアウォールd

ここに画像の説明を挿入

セマフォ

セマフォを表示します:

[root@localhost ~]# kill -l
 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
 6) シガバRT 7) シグバス 8) SIGFPE 9) シグキル 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
63) シグマートマックス-1 64) シグマートマックス

セマフォには64種類あります。次に、よく使用されるセマフォをいくつか示します。

  • SIGINT 、 SIGTERM : 高速シャットダウン。
  • SIGQUIT : 正常なシャットダウン (プロセスを正常に終了し、つまり、終了する前に要求が完了するのを待機します)。
  • SIGHUP : スムーズな再起動、構成ファイルの再読み込み (スムーズな再起動、構成ファイルを変更した後にサーバーを再起動する必要はありません)。
  • SIGUSR1 : ログ ファイルを再読み取りします。これは、ログ ファイルをカットするときに非常に便利です。
  • SIGUSR2 : nginxのアップグレード時に使用され、実行可能プログラムをスムーズにアップグレードします。
  • SIGWINCH : ワーカープロセスを正常にシャットダウンします。

Nginx ホットデプロイメント

Nginxは、 masterプロセスと複数のworkerプロセス ( workerプロセスの数は、 nginx.conf構成ファイルのworker_processesパラメータで設定でき、デフォルトは1 ) を含む、マルチ プロセスの高性能リバース プロキシ サーバーであり、マルチコア プロセッサを最大限に活用できます。

ここに画像の説明を挿入

デフォルトは1 workerプロセスです。

ここに画像の説明を挿入

masterプロセスとworkerプロセスは親子プロセスの関係にあります。

ここに画像の説明を挿入

Nginxマルチプロセス モードで動作します。起動後、 Nginxはmasterプロセスと複数のworkerプロセス (デフォルトでは1 ) が存在します。複数のworkerプロセスは、 master親プロセスがリッスンするポートをリッスンし (親プロセスと子プロセスの関係を参照)、リクエストを並列に処理します。 master親プロセスは、主にworkerプロセスの管理（実際にサービスを提供するworkerプロセスの管理、 workerプロセスへのシグナルの送信、 workerプロセスの実行状態の監視、 workerプロセスが異常終了した場合に新しいworkerプロセスを再起動する）、構成情報の読み取りと検証に使用されます。 masterプロセスはユーザー要求に対してサービスを提供せず、ユーザー要求はworkerプロセスによって処理されます。

Nginx停止や再起動など、 Nginxはセマフォによって制御されます。セマフォはプロセス間通信のメカニズムです。 masterプロセスはセマフォを通じて複数のworkerプロセスを制御します。

ここに画像の説明を挿入

ここで、 Nginxホット デプロイメントを実装する方法を説明します。ブロガーは、 Nginx構成ファイルを変更して (最初にcopy作成)、 Nginxのアップグレードをシミュレートします。

[root@localhost ~]# cd /usr/local/nginx/conf/
[root@localhost conf]# ll
総投与量 68
-rw-r--r--。1 ルート ルート 1077 12月 20 20:24 fastcgi.conf
-rw-r--r--. 1 ルート ルート 1077 12月 20 20:24 fastcgi.conf.default
-rw-r--r--。1 ルート ルート 1007 12月 20 20:24 fastcgi_params
-rw-r--r--. 1 ルート ルート 1007 12月 20 20:24 fastcgi_params.default
-rw-r--r--。1 ルート ルート 2837 12月 20 20:24 koi-utf
-rw-r--r--。1 ルート ルート 2223 12月 20 20:24 koi-win
-rw-r--r--. 1 ルート ルート 5231 12月 20 20:24 mime.types
-rw-r--r--. 1 ルート ルート 5231 12月 20 20:24 mime.types.default
-rw-r--r--。1 ルート ルート 2656 12月20日 21:26 nginx.conf
-rw-r--r--。1 ルート ルート 2656 12月 20 20:24 nginx.conf.default
-rw-r--r--。1 ルート ルート 636 12月 20 20:24 scgi_params
-rw-r--r--。1 ルート ルート 636 12月 20 20:24 scgi_params.default
-rw-r--r--。1 ルート ルート 664 12月 20 20:24 uwsgi_params
-rw-r--r--。1 ルート ルート 664 12月 20 20:24 uwsgi_params.default
-rw-r--r--。1 ルート ルート 3610 12月 20 20:24 win-utf
[root@localhost conf]# cp nginx.conf nginx_old.conf
[root@localhost conf]# vim nginx.conf

ここに画像の説明を挿入

Nginxまだホットデプロイされていないため、 http://192.168.1.199/にアクセスすると、元のNginxページが表示されます。

ここに画像の説明を挿入

Nginxプロセスを表示します。

[root@localhost conf]# ps -ef | grep nginx
root 14964 1 0 22:25 ? 00:00:00 nginx: マスタープロセス ./nginx
誰も 14965 14964 0 22:25 ? 00:00:00 nginx: ワーカープロセス
ルート 15016 1521 0 23:07 pts/0 00:00:00 grep --color=auto nginx

SIGUSR2シグナルをmasterプロセスに送信して、 Nginx実行可能プログラムをスムーズにアップグレードできるようにします。 Nginx masterプロセスとworkerプロセスのセットを再起動し、新しいmasterプロセスが古いmasterプロセスの子プロセスになっていることがわかります (親プロセスと子プロセス間の継承関係により、新しいmasterプロセスは古いmasterプロセスの関連リソースを簡単に継承できます)。

[root@localhost conf]# kill -s SIGUSR2 14964
[root@localhost conf]# ps -ef | grep nginx
root 14964 1 0 22:25 ? 00:00:00 nginx: マスタープロセス ./nginx
誰も 14965 14964 0 22:25 ? 00:00:00 nginx: ワーカープロセス
root 15019 14964 0 23:18 ? 00:00:00 nginx: マスタープロセス ./nginx
誰も 15020 15019 0 23:18 ? 00:00:00 nginx: ワーカープロセス
ルート 15022 1521 0 23:19 pts/0 00:00:00 grep --color=auto nginx

そして、 Nginx古い pid ファイルと新しいpidファイルをログ ディレクトリに保存します (新しいマスター プロセスと古いmasterプロセスのID保存します)。

[root@localhost conf]# ll ../logs
総投与量 16
-rw-r--r--. 1 ルート ルート 2729 12月20日 23:20 access.log
-rw-r--r--. 1 ルート ルート 708 12月20 23:18 error.log
-rw-r--r--。1 ルート ルート 6 12月 20 23:18 nginx.pid
-rw-r--r--。1 ルート ルート 6 12月 20 22:25 nginx.pid.oldbin
[root@localhost conf]# cat ../logs/nginx.pid
15019
[root@localhost conf]# cat ../logs/nginx.pid.oldbin 
14964

古いmasterプロセスにSIGWINCHシグナルを送信して、古いmasterプロセスが古いworkerプロセスをシャットダウンできるようにします。

[root@localhost conf]# kill -s SIGWINCH 14964
[root@localhost conf]# ps -ef | grep nginx
root 14964 1 0 22:25 ? 00:00:00 nginx: マスタープロセス ./nginx
root 15019 14964 0 23:18 ? 00:00:00 nginx: マスタープロセス ./nginx
誰も 15020 15019 0 23:18 ? 00:00:00 nginx: ワーカープロセス
ルート 15030 1521 0 23:27 pts/0 00:00:00 grep --color=auto nginx

ここでhttp://192.168.1.199/にアクセスすると、 404が応答します。

ここに画像の説明を挿入

http://192.168.1.199/nacosにアクセスすると、 Nacosサービスにアクセスできます。

ここに画像の説明を挿入

アップグレードしたバージョンに問題がなければ、古いmasterプロセスにSIGQUITシグナルを送信してシャットダウンすることができます。これにより、 master masterと新しいworkerプロセスのみが残り、 Nginxのホットデプロイメントが実現します。

[root@localhost conf]# kill -s SIGQUIT 14964
[root@localhost conf]# ps -ef | grep nginx
root 15019 1 0 23:18 ? 00:00:00 nginx: マスタープロセス ./nginx
誰も 15020 15019 0 23:18 ? 00:00:00 nginx: ワーカープロセス
ルート 15034 1521 0 23:31 pts/0 00:00:00 grep --color=auto nginx

アップグレードしたバージョンに問題があり、以前のバージョンにロールバックする必要がある場合は、古いmasterプロセスにSIGHUPシグナルを送信できます。ブロガーが再テストしたため、プロセス番号は変更されていますが、古いmasterプロセスが古いworkerプロセスを再作成し、アップグレードされたmasterプロセスとworkerプロセスが閉じられていないことは明らかです。

[root@localhost conf]# kill -s SIGHUP 15084
[root@localhost conf]# ps -ef | grep nginx
root 15084 1 0 12月20日? 00:00:00 nginx: マスタープロセス ./nginx
root 15106 15084 0 12月20日 ? 00:00:00 nginx: マスタープロセス ./nginx
誰も 15107 15106 0 12月20日 ? 00:00:00 nginx: ワーカープロセス
誰も 15131 15084 0 00:02 ? 00:00:00 nginx: ワーカープロセス
ルート 15141 1521 0 00:09 pts/0 00:00:00 grep --color=auto nginx

新しいmasterプロセスにSIGQUITシグナルを送信してシャットダウンします。これにより、 master masterと新しく作成された古いworkerプロセスのみが残り、ロールバックが実現されます。

[root@localhost conf]# kill -s SIGQUIT 15106
[root@localhost conf]# ps -ef | grep nginx
root 15084 1 0 12月20日? 00:00:00 nginx: マスタープロセス ./nginx
誰も 15131 15084 0 00:02 ? 00:00:00 nginx: ワーカープロセス
ルート 15159 1521 0 00:25 pts/0 00:00:00 grep --color=auto nginx

ロールバックが成功しました。

ここに画像の説明を挿入

また、バージョンをロールバックする必要があります (つまり、ここで構成ファイルをロールバックします。そうしないと、次回再起動したときに問題が発生します)。

[root@localhost conf]# cp -f nginx_old.conf nginx.conf
cp: 「nginx.conf」を上書きしますか?ええ

古いmasterプロセスがSIGHUPシグナルを送信したときに、古いmasterプロセスによって作成されたworkerプロセスが構成ファイルの再読み取りに失敗するのはなぜですか?公式の説明は次のとおりです。

古いマスター プロセスに HUP シグナルを送信します。古いマスター プロセスは、構成を再読み込みせずに新しいワーカー プロセスを開始します。その後、新しいマスター プロセスに QUIT シグナルを送信することで、すべての新しいプロセスを正常にシャットダウンできます。

古いmasterプロセスにSIGHUPシグナルを送信します。古いmasterプロセスは、構成を再読み取りせずに新しいworkerプロセスを開始します。その後、新しいmasterプロセスにSIGQUITシグナルを送信することで、すべての新しいプロセスを適切にシャットダウンできます。

新しいプロセスがない場合 ( masterとworkerプロセスのセットのみ) は、構成ファイルを変更し、 masterプロセスにSIGHUPシグナルを送信して、構成ファイルが再ロードされるかどうかを確認します。

ここに画像の説明を挿入

[root@localhost conf]# kill -s SIGHUP 15084

明らかに設定ファイルが再読み込みされています。ブロガーはソースコードを読んでいないので、 Nginxの実装を推測することしかできません (間違っている場合はコメントして補足してください)。Nginx は、ホット デプロイメントが現在進行中かどうか (新しいmasterプロセスがあるかどうか) に基づいて、 SIGHUPシグナルNginx設定ファイルを再読み込みする必要があるかどうかを判断する必要があります。

ここに画像の説明を挿入

Nginx ホット デプロイメントの実装に関するこの記事はこれで終わりです。Nginx ホット デプロイメントに関するより関連性の高いコンテンツについては、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません:
  • Nginx での SSL 証明書のインストールと展開手順の概要
  • tomcat+nginx を使用してマルチアプリケーション デプロイメントを実装するためのサンプル コード
  • 複数のシェルスクリプトを使用して nginx をデプロイする詳細なチュートリアル
  • vue プロジェクトのデプロイと Nginx でのプロキシ設定の問題の分析
  • nginx で複数のフロントエンド プロジェクトをデプロイするいくつかの方法
  • Dockerはnginxをデプロイし、フォルダとファイル操作をマウントします

<<:  W3C標準に準拠したHTML標準で注意すべき点を詳細に解説

>>:  IE9 のネイティブ ページ互換性の問題に対する解決策についての簡単な説明

推薦する

MySQL の lru リンク リストの簡単な分析

1. 従来のLRUリンクリストについて簡単に説明するLRU：最も最近使われなかったものLRU リンク...

MySQL テーブルスペースの断片化の概念と関連する問題の解決策

目次背景表領域の断片化とは何ですか?表領域の断片化を確認する方法表スペースの断片化問題を解決する方法...

MySQL 8.0.18 ハッシュ結合は左/右結合をサポートしていません 左と右の結合の問題

MySQL 8.0.18 では、インデックスが作成されていないフィールドに適用でき、等価値の関連付け...

Windows システムの MySQL が中国語を入力および表示できない問題の解決方法

ステップ 1: メモ帳を使用して、MySQL インストール ディレクトリの「my.ini」ファイルを...

JS を使用してファイルを操作する (FileReader は --node の fs を読み取ります)

目次JS はファイルを読み取る FileReader書類イベントとメソッド基本的な使い方イベント処理...

Nginx+Tomcat 負荷分散クラスタのインストールと構成のケースの詳細な説明

目次序文1. Nginx+Tomcat 2. Nginxサーバーを構成する3. Tomcatアプリケ...

vue-resource インターセプターの使用に関する詳細な説明

序文インターセプター最近のフロントエンド フレームワークでは、インターセプターは基本的に非常に基本的...

Vueはechartsを使用して組織図を描画します

昨日、円形のプログレスバー (Vue 円形プログレスバーを参照してください) についてブログを書きま...

Vue はデータの変更をどのように追跡しますか?

目次背景例誤解 - コールスタックを表示するためにウォッチでブレークポイントを設定する正しいアプロー...

Vant アップローダーは、画像をアップロードするためのドラッグ アンド ドロップ機能を実装します (カバーとして設定)

効果図は以下のとおりです。 <!DOCTYPE html> <html lang=...

忘れられたMySQLパスワードとログインエラーの問題について簡単に説明します

MySQL ログイン パスワードを忘れた場合、解決方法は実はとても簡単です。MySQL メイン構成フ...

Pycharm2017はpython3.6とmysqlの接続を実現します

この記事では、pycharm2017でpython3.6とmysqlを接続する方法を参考までに紹介し...

mysql5.7 以降で my.ini を設定するための詳細な手順

Windows 64 ビット版 MySQL 5.7 以降の解凍パッケージにデータディレクトリ、my-...

Vue3の組み込みコンポーネントであるTeleportの使い方を詳しく説明します

目次1. テレポートの使用2. モーダルダイアログコンポーネントを完成させる3. コンポーネントのレ...

Dockerfile 内の予約語命令の解析処理

目次1. Dockerfile とは何ですか? 2. Dockerfile構築プロセスの分析3. D...