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 のネイティブ ページ互換性の問題に対する解決策についての簡単な説明

推薦する

ネイティブ JS を使用してタッチスライド監視イベントを実装する方法

序文今日はちょっとしたデモを書きました。左右にスワイプするロジックに関わる部分があります。当初はプラ...

docker を使用して Redis マスター/スレーブを構築する方法

1. Docker環境を構築する1. Dockerfileを作成する Centos:latest か...

ECMAScriptにおけるプリミティブ値と参照値の詳しい説明

目次序文動的プロパティとは何ですか?値のコピー値の種類を決定する要約する序文これは JavaScri...

WeChatアプレットでQRコードを識別するために長押しする実装プロセス

序文公式アカウントのQRコードは長押しで認識できることは皆さんご存じですが、ミニプログラムに対する制...

Dockerイメージサイズを最適化する一般的な方法

通常、私たちが構築する Docker イメージはサイズが大きく、多くのディスク領域を占有します。コン...

Linux カーネル デバイス ドライバー Linux カーネル 基本メモの概要

1. Linuxカーネルドライバモジュールの仕組み静的ロードでは、ドライバモジュールをカーネルにコン...

Linux/CentOS サーバー セキュリティ構成の一般ガイド

Linux はオープン システムです。インターネット上には、既成のプログラムやツールが多数存在します...

HTML にオーディオファイルを挿入してブラウザで再生する場合の互換性の問題

HTML にオーディオ ファイルを挿入した後 (mp3 ファイルを再生した後) に発生したいくつかの...

CentOS 6.9 で glibc ダイナミック ライブラリをアップグレードする詳細なプロセス

glibc は、gnu によってリリースされた libc ライブラリ、つまり c ランタイム ライブ...

JavaScript イベント キャプチャ バブリングとキャプチャの詳細

目次1. イベントの流れ1. コンセプト2. DOMイベントフロー2. イベントの委任1. イベント...

Docker での FastAPI デプロイの詳細なプロセス

Docker 学習https://www.cnblogs.com/poloyy/p/15257059...

Dockerはコンテナ外のコンテナ内でコマンドを実行します

コンテナ内でコマンドを実行したいが、コンテナに入りたくない場合があります。ではどうすればいいでしょう...

MySQLのスレッド実行の急増とクエリの遅延の問題を解決する

目次背景問題の説明原因分析CPUクエリが遅い接続数分析する拡大する総括する背景新年を迎える前は、一年...

ウェブサイトを構築するときは、UTF-8 または GB2312 エンコードを使用する必要がありますか?

外国のウェブサイトを開くと文字化けした文字が表示されることが多く、また、英語以外の外国のウェブサイト...

Vue3 の父子値転送に関する簡単な説明

目次父から息子へ： 1. 親コンポーネントのサブコンポーネントタグに、サブコンポーネントに渡されるデ...