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種類あります。次に、よく使用されるセマフォをいくつか示します。

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

Nginx ホットデプロイメント

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

ここに画像の説明を挿入

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

ここに画像の説明を挿入

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

ここに画像の説明を挿入

Nginxマルチプロセス モードで動作します。起動後、 Nginxmasterプロセスと複数の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シグナルを送信することで、すべての新しいプロセスを適切にシャットダウンできます。

新しいプロセスがない場合 ( masterworkerプロセスのセットのみ) は、構成ファイルを変更し、 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 のネイティブ ページ互換性の問題に対する解決策についての簡単な説明

推薦する

Linux マルチスレッドにおけるフォークとミューテックス ロック プロセスの例

目次質問: 1. 最初の試み2. 合理的な分析3. 問題解決(1) pthread_join()の使...

VUEはG2チャートを使用した実装を導入します

目次G2チャートについて使用テンプレートで使用される完全なコード (棒グラフ)世界地図を追加するG2...

現在のマウススライドの座標を取得するVue+openlayer5メソッド

序文: Vue プロジェクトで現在のマウスの座標を取得するにはどうすればよいでしょうか。ここで共有す...

MySQLトリガーの詳細な説明と簡単な例

MySQLトリガーの簡単な例文法CREATE TRIGGER <トリガー名> -- トリ...

JS 非同期コードユニットテストの魔法 Promise

目次序文プロミスチェーンMDN エラー連鎖デフォルト処理略語非同期待機序文この記事を書いた理由は、ユ...

CSS3でカルーセル画像を作成する方法

スライドショーは Web ページでよく見られます。美しい写真が使われています。こちらは純粋な CSS...

Vueカスタム命令の詳細な説明

目次Vueカスタムディレクティブカスタムディレクティブフック機能出力関連属性アプリケーション例要約す...

MySQLクエリは、フィールドが数値とカンマではないことを指定します。

コアSQL文数字を含まない MySQL クエリ ステートメント: SELECT * FROM tes...

ドキュメントの場所の比較

<br />2 年前に PPK が投稿した素晴らしいブログ記事では、contains()...

エコー後に要素編集フォームel-radioが選択できない問題を解決します

目次序文質問オンラインソリューション序文この記事の内容は私がこの業界に入ったときのメモを元にしている...

Linux の ufw ファイアウォールの紹介

Linux のufw (Uncomplicated Firewall) を見て、ファイアウォールに変...

順序再構築に関する簡単な説明: MySQL シャーディング

目次1. 目的2. 環境整備1. 基本情報2. データベース環境の準備3. データベースを構築し、サ...

Dockerを使用してクローンリポジトリを使用してGitイメージを構築する

概要私は 1 年以上 Docker を使用しています。最近、サービスをすばやくオーケストレーションし...

MySQL Bツリーインデックスとインデックス最適化の概要についての簡単な説明

MySQL の MyISAM エンジンと InnoDB エンジンはどちらもデフォルトで B+ ツリー...

ファイルをアップロードするための HTML フォームの「参照」ボタンを変更する方法

コードをコピーコードは次のとおりです。 <!DOCTYPE HTML PUBLIC "...