Implementierung von Nginx Hot Deployment

Folgen Sie einfach dem obigen Blogbeitrag. Schalten Sie die Firewall aus und erlauben Sie den lokalen Zugriff auf Nginx -Dienst über einen Browser.

[root@localhost ~]# systemctl stoppe Firewall

Semaphor

Sehen Sie sich das Semaphor an:

[root@localhost ~]# kill -l
 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 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) SIGRTMAX-1 64) SIGRTMAX	

Es gibt 64 Arten von Semaphoren. Im Folgenden sind einige häufig verwendete Semaphoren aufgeführt:

• SIGINT , SIGTERM : schnelles Herunterfahren.
• SIGQUIT : ordnungsgemäßes Herunterfahren (ordnungsgemäßes Schließen des Prozesses, d. h. Warten auf den Abschluss der Anforderung vor dem Schließen).
• SIGHUP : Sanfter Neustart, Konfigurationsdatei neu laden (sanfter Neustart, kein Neustart des Servers nach dem Ändern der Konfigurationsdatei erforderlich).
• SIGUSR1 : Lesen Sie die Protokolldatei erneut, was beim Ausschneiden von Protokolldateien sehr nützlich ist.
• SIGUSR2 : Problemloses Upgrade ausführbarer Programme, wird beim Upgrade nginx verwendet.
• SIGWINCH : Einen Arbeitsprozess ordnungsgemäß beenden.

Nginx-Hot-Bereitstellung

Nginx ist ein Multiprozess-Reverse-Proxy-Server mit hoher Leistung, der einen master und mehrere worker umfasst (die Anzahl der worker kann durch den Parameter worker_processes in der Konfigurationsdatei nginx.conf festgelegt werden, der Standardwert ist 1 ), der Mehrkernprozessoren voll ausnutzen kann.

Der Standardwert ist 1 worker .

Und der master und der worker sind Eltern-Kind-Prozessbeziehungen.

Nginx arbeitet im Multiprozessmodus. Nach dem Start verfügt Nginx über einen master und mehrere worker (standardmäßig 1 ). Mehrere worker Child-Prozesse hören auf dem Port, auf den master Parent-Prozess hört (siehe die Beziehung zwischen Parent- und Child-Prozessen) und verarbeiten Anfragen parallel. Der übergeordnete master wird hauptsächlich zum Verwalten worker verwendet (Verwalten des worker , der tatsächlich Dienste bereitstellt, Senden von Signalen an den worker , Überwachen des Ausführungsstatus des worker und Neustarten eines neuen worker , wenn der worker abnormal beendet wird), Lesen und Überprüfen von Konfigurationsinformationen. Der master stellt keine Dienste für Benutzeranforderungen bereit, und Benutzeranforderungen werden vom worker verarbeitet.

Nginx wird durch Semaphoren gesteuert, beispielsweise das Stoppen und Neustarten Nginx . Semaphore sind ein Mechanismus zur Kommunikation zwischen Prozessen. master steuert mehrere worker über Semaphore.

Lassen Sie uns nun demonstrieren, wie Nginx Hot Deployment implementiert. Der Blogger simuliert das Upgrade von Nginx , indem er die Nginx -Konfigurationsdatei ändert (erstellen Sie zuerst eine copy ).

[root@localhost ~]# cd /usr/local/nginx/conf/
[root@localhost conf]# ll
Gesamtdosis 68
-rw-r--r--. 1 root root 1077 20. Dezember 20:24 fastcgi.conf
-rw-r--r--. 1 root root 1077 20. Dezember 20:24 fastcgi.conf.default
-rw-r--r--. 1 root root 1007 Dez 20 20:24 fastcgi_params
-rw-r--r--. 1 root root 1007 20. Dezember 20:24 fastcgi_params.default
-rw-r--r--. 1 root root 2837 20. Dezember 20:24 koi-utf
-rw-r--r--. 1 root root 2223 20. Dezember 20:24 koi-win
-rw-r--r--. 1 root root 5231 20. Dezember 20:24 mime.types
-rw-r--r--. 1 root root 5231 20. Dezember 20:24 mime.types.default
-rw-r--r--. 1 root root 2656 20. Dezember 21:26 nginx.conf
-rw-r--r--. 1 root root 2656 20. Dezember 20:24 nginx.conf.default
-rw-r--r--. 1 root root 636 Dez 20 20:24 scgi_params
-rw-r--r--. 1 root root 636 Dez 20 20:24 scgi_params.default
-rw-r--r--. 1 root root 664 Dez 20 20:24 uwsgi_params
-rw-r--r--. 1 root root 664 20. Dez. 20:24 uwsgi_params.default
-rw-r--r--. 1 root root 3610 20. Dezember 20:24 win-utf
[root@localhost conf]# cp nginx.conf nginx_old.conf
[root@localhost conf]# vim nginx.conf

Da Nginx noch nicht im laufenden Betrieb bereitgestellt wurde, wird beim Besuch http://192.168.1.199/ immer noch die ursprüngliche Nginx -Seite angezeigt.

Sehen Sie sich den Nginx -Prozess an:

[root@localhost conf]# ps -ef | grep nginx
root 14964 1 0 22:25 ? 00:00:00 nginx: Masterprozess ./nginx
niemand 14965 14964 0 22:25 ? 00:00:00 nginx: Arbeitsprozess
root 15016 1521 0 23:07 pts/0 00:00:00 grep --color=auto nginx

Senden Sie ein SIGUSR2 Signal an master , damit Nginx das ausführbare Programm reibungslos aktualisieren kann. Sie können sehen, dass Nginx eine Reihe von master und worker neu gestartet hat und der neue master ein untergeordneter Prozess des alten master ist (durch die Vererbungsbeziehung zwischen übergeordneten und untergeordneten Prozessen kann der neue master problemlos die relevanten Ressourcen des alten master erben).

[root@localhost conf]# kill -s SIGUSR2 14964
[root@localhost conf]# ps -ef | grep nginx
root 14964 1 0 22:25 ? 00:00:00 nginx: Masterprozess ./nginx
niemand 14965 14964 0 22:25 ? 00:00:00 nginx: Arbeitsprozess
root 15019 14964 0 23:18 ? 00:00:00 nginx: Master-Prozess ./nginx
niemand 15020 15019 0 23:18 ? 00:00:00 nginx: Arbeitsprozess
root 15022 1521 0 23:19 Punkte/0 00:00:00 grep --color=auto nginx

Und Nginx speichert die alten und neuen pid Dateien im Protokollverzeichnis (wobei ID der neuen und alten master gespeichert werden).

[root@localhost conf]# ll ../logs
Gesamtdosis 16
-rw-r--r--. 1 root root 2729 20. Dezember 23:20 access.log
-rw-r--r--. 1 root root 708 20. Dezember 23:18 Fehler.log
-rw-r--r--. 1 root root 6 Dez 20 23:18 nginx.pid
-rw-r--r--. 1 root root 6 Dez 20 22:25 nginx.pid.oldbin
[root@localhost conf]# cat ../logs/nginx.pid
15019
[root@localhost conf]# cat ../logs/nginx.pid.oldbin 
14964

Senden Sie ein SIGWINCH Signal an den alten master worker master .

[root@localhost conf]# kill -s SIGWINCH 14964
[root@localhost conf]# ps -ef | grep nginx
root 14964 1 0 22:25 ? 00:00:00 nginx: Masterprozess ./nginx
root 15019 14964 0 23:18 ? 00:00:00 nginx: Master-Prozess ./nginx
niemand 15020 15019 0 23:18 ? 00:00:00 nginx: Arbeitsprozess
root 15030 1521 0 23:27 pts/0 00:00:00 grep --color=auto nginx

Besuchen Sie jetzt http://192.168.1.199/ und die Antwort lautet 404 .

Und wenn Sie http://192.168.1.199/nacos aufrufen, greifen Sie auf den Nacos -Dienst zu.

Wenn mit der aktualisierten Version kein Problem vorliegt, können Sie ein SIGQUIT -Signal an den alten master senden, um ihn herunterzufahren. Auf diese Weise bleiben nur master master der neue worker übrig, wodurch die Hot-Bereitstellung von Nginx realisiert wird.

[root@localhost conf]# kill -s SIGQUIT 14964
[root@localhost conf]# ps -ef | grep nginx
root 15019 1 0 23:18 ? 00:00:00 nginx: Masterprozess ./nginx
niemand 15020 15019 0 23:18 ? 00:00:00 nginx: Arbeitsprozess
root 15034 1521 0 23:31 Punkte/0 00:00:00 grep --color=auto nginx

Wenn ein Problem mit der aktualisierten Version vorliegt und Sie zur vorherigen Version zurückkehren müssen, können Sie ein SIGHUP -Signal an den alten master senden. Da der Blogger erneut getestet hat, haben sich die Prozessnummern geändert, aber es ist offensichtlich, dass der alte master den alten worker neu erstellt hat und master und worker nicht geschlossen wurden.

[root@localhost conf]# kill -s SIGHUP 15084
[root@localhost conf]# ps -ef | grep nginx
root 15084 1 0 20. Dezember ? 00:00:00 nginx: Masterprozess ./nginx
root 15106 15084 0 20. Dezember ? 00:00:00 nginx: Masterprozess ./nginx
niemand 15107 15106 0 20. Dezember ? 00:00:00 nginx: Arbeitsprozess
niemand 15131 15084 0 00:02 ? 00:00:00 nginx: Arbeitsprozess
root 15141 1521 0 00:09 Punkte/0 00:00:00 grep --color=auto nginx

Senden Sie ein SIGQUIT -Signal an den neuen master , um ihn herunterzufahren. Auf diese Weise bleiben nur master master der neu erstellte alte worker erhalten, wodurch ein Rollback erreicht wird.

[root@localhost conf]# kill -s SIGQUIT 15106
[root@localhost conf]# ps -ef | grep nginx
root 15084 1 0 20. Dezember ? 00:00:00 nginx: Masterprozess ./nginx
niemand 15131 15084 0 00:02 ? 00:00:00 nginx: Arbeitsprozess
root 15159 1521 0 00:25 Punkte/0 00:00:00 grep --color=auto nginx

Rollback erfolgreich.

Außerdem ist ein Versionsrücksetzen erforderlich (also hier ein Zurücksetzen der Konfigurationsdatei, da es sonst beim nächsten Neustart zu Problemen kommt).

[root@localhost conf]# cp -f nginx_old.conf nginx.conf
cp: „nginx.conf“ überschreiben? j

Warum kann der vom alten master erstellte worker die Konfigurationsdatei nicht erneut lesen, wenn der alte master das SIGHUP -Signal sendet? Hier ist die offizielle Beschreibung:

Senden Sie das HUP-Signal an den alten Masterprozess. Der alte Masterprozess startet neue Arbeitsprozesse, ohne die Konfiguration erneut zu lesen. Danach können alle neuen Prozesse ordnungsgemäß heruntergefahren werden, indem das QUIT-Signal an den neuen Masterprozess gesendet wird.

Senden Sie ein SIGHUP -Signal an den alten master . Der alte master startet neue worker , ohne die Konfiguration erneut zu lesen . Anschließend können alle neuen Prozesse ordnungsgemäß heruntergefahren werden, indem ein SIGQUIT -Signal an den neuen master gesendet wird.

Wenn kein neuer Prozess vorhanden ist (nur eine Reihe von master und worker -Prozessen), ändern Sie die Konfigurationsdatei und senden Sie ein SIGHUP Signal an den master , um zu sehen, ob die Konfigurationsdatei neu geladen wird.

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

Offensichtlich wurde die Konfigurationsdatei neu geladen. Da der Blogger den Quellcode nicht gelesen hat, kann er die Implementierung von Nginx nur erraten (wenn sie falsch ist, bitte kommentieren und ergänzen). Nginx sollte entscheiden, ob SIGHUP -Signal die Konfigurationsdatei neu laden muss, basierend darauf, ob gerade eine Hot-Bereitstellung ausgeführt wird (es gibt einen neuen master Prozess).

Dies ist das Ende dieses Artikels über die Implementierung von Nginx Hot Deployment. Weitere relevante Inhalte zu Nginx Hot Deployment finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!