So führen Sie ein direktes Upgrade von Nginx durch, ohne dass die Clientverbindungen unterbrochen werden

Einführung

Nginx ist ein leistungsstarker Webserver und Reverse-Proxy, mit dem viele der beliebtesten Websites der Welt bedient werden. In diesem Handbuch wird gezeigt, wie Sie die ausführbare Nginx-Datei direkt aktualisieren, ohne die Clientverbindungen zu verlieren.

Voraussetzungen

Bevor Sie mit diesem Handbuch beginnen, sollten Sie einen Benutzer ohne Rootberechtigung auf Ihrem Server haben, der mit den Rechten "+ sudo +" konfiguriert ist. Außerdem muss Nginx installiert sein.

Wenn Sie Ubuntu 14.04 verwenden, erfahren Sie, wie Sie einen Benutzer mit den Rechten "+ sudo +" einrichten. Https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 [ Hier]. Sie können Nginx installieren, indem Sie this guide befolgen.

Wenn Sie CentOS 7 verwenden, können Sie das Programm einrichten, indem Sie this guide für + sudo + aufrufen Benutzer, gefolgt von this guide, um Nginx zu installieren.

So funktioniert das Upgrade

Nginx erzeugt beim Starten des Dienstes einen Master-Prozess. Der Master-Service startet wiederum einen oder mehrere Worker-Prozesse, die die tatsächlichen Client-Verbindungen verarbeiten. Nginx wurde entwickelt, um bestimmte Aktionen auszuführen, wenn bestimmte Signale vom Administrator empfangen werden. Mit diesen Signalen haben Sie die Möglichkeit, Nginx oder dessen Konfiguration direkt zu aktualisieren, ohne die Client-Verbindungen zu verlieren.

Bestimmte Service-Skripte, die von Betreuern von Distributionspaketen bereitgestellt werden, bieten diese Möglichkeit für die Verwendung mit herkömmlichen Upgrades. Ein manuelles Upgrade bietet jedoch mehr Flexibilität bei der Vorgehensweise und ermöglicht es Ihnen, das Upgrade zu überwachen, damit es bei Problemen schnell wiederhergestellt werden kann. Dies bietet auch die Möglichkeit, ein ordnungsgemäßes Upgrade durchzuführen, wenn Sie Nginx von der Quelle installiert haben oder eine Methode verwenden, die diese Funktion nicht bietet.

Die folgenden Signale werden verwendet:

  • * + USR2 + *: Dies erzeugt eine neue Menge von Master / Worker-Prozessen, ohne die alte Menge zu beeinflussen.

  • * + WINCH + *: Damit wird der Nginx-Master-Prozess angewiesen, die zugeordneten Worker-Instanzen ordnungsgemäß zu stoppen.

  • * + HUP + *: Dies weist einen Nginx-Master-Prozess an, seine Konfigurationsdateien erneut zu lesen und Worker-Prozesse durch solche zu ersetzen, die der neuen Konfiguration entsprechen. Wenn ein alter und ein neuer Master ausgeführt werden, werden die Worker mit ihrer ursprünglichen Konfiguration erstellt, wenn diese an den alten Master gesendet werden.

  • * + QUIT + *: Hiermit werden ein Master und seine Mitarbeiter ordnungsgemäß heruntergefahren.

  • * + TERM + *: Dies löst ein schnelles Herunterfahren des Masters und seiner Arbeiter aus.

  • * + KILL + *: Tötet sofort einen Meister und seine Arbeiter ohne Aufräumarbeiten.

Finden von Nginx-Prozess-PIDs

Um Signale an die verschiedenen Prozesse zu senden, müssen wir die PID für den Zielprozess kennen. Es gibt zwei einfache Möglichkeiten, dies zu finden.

Zuerst können Sie das Hilfsprogramm "+ ps " und dann " grep +" für Nginx unter den Ergebnissen verwenden. Dies ist einfach und ermöglicht es Ihnen, die Master- und Worker-Prozesse zu sehen:

ps aux | grep nginx
outputroot       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

Die zweite Spalte enthält die PIDs für die ausgewählten Prozesse. Hervorgehoben ist die PID für den Prozess. Die letzte Spalte verdeutlicht, dass das erste Ergebnis ein Nginx-Masterprozess ist.

Eine andere Möglichkeit, die PID für den Master-Nginx-Prozess zu ermitteln, besteht darin, den Inhalt der Datei "+ / run / nginx.pid +" auszudrucken:

cat /run/nginx.pid
output

Wenn zwei Nginx-Master-Prozesse ausgeführt werden, wird der alte nach "+ / run / nginx.pid.oldbin +" verschoben.

Bringe ein neues Nginx-Meister- / Arbeiterset hervor

Der erste Schritt zum ordnungsgemäßen Aktualisieren unserer ausführbaren Datei besteht darin, Ihre Binärdatei tatsächlich zu aktualisieren. Verwenden Sie dazu die für Ihre Nginx-Installation geeignete Methode, entweder über einen Paketmanager oder eine Quellinstallation.

Nachdem die neue Binärdatei erstellt wurde, können Sie einen zweiten Satz von Master- / Worker-Prozessen erzeugen, die die neue ausführbare Datei verwenden.

Sie können dies entweder tun, indem Sie das Signal "+ USR2 +" direkt an die von Ihnen abgefragte PID-Nummer senden (stellen Sie sicher, dass Sie hier die PID Ihres eigenen Nginx-Master-Prozesses einsetzen):

sudo kill -s USR2

Oder Sie können den in Ihrer PID-Datei gespeicherten Wert wie folgt direkt in den Befehl einlesen und ersetzen:

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

Wenn Sie Ihre aktuellen Prozesse überprüfen, werden Sie feststellen, dass Sie jetzt zwei Sätze von Nginx-Mastern / -Arbeitern haben:

ps aux | grep nginx
outputroot       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       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

Sie können auch sehen, dass die ursprüngliche Datei "+ / run / nginx.pid " nach " / run / nginx.pid.oldbin " verschoben und die PID des neueren Masterprozesses nach " / run / nginx.pid +" geschrieben wurde `:

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


==> /run/nginx.pid.oldbin <==

Mit den in diesen Dateien enthaltenen PIDs können Sie nun Signale an einen der Master-Prozesse senden.

Zu diesem Zeitpunkt sind beide Master / Worker-Sets betriebsbereit und können Client-Anforderungen bedienen. Der erste Satz verwendet die ursprüngliche ausführbare Datei und Konfiguration von Nginx und der zweite Satz verwendet die neueren Versionen. Sie können nebeneinander weiterarbeiten, aus Gründen der Konsistenz sollten wir jedoch mit dem Übergang zum neuen Set beginnen.

Fahren Sie die Arbeiter des Ersten Meisters herunter

Um mit dem Übergang zum neuen Satz zu beginnen, können wir zunächst die Arbeitsprozesse des ursprünglichen Masters stoppen. Die ursprünglichen Mitarbeiter werden alle ihre aktuellen Verbindungen abwickeln und dann beenden.

Stoppen Sie die Worker des Originalsets, indem Sie das Signal "+ WINCH +" an den Master-Prozess senden:

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

Auf diese Weise können die Mitarbeiter des neuen Masters neue Clientverbindungen alleine verwalten. Der alte master -Prozess wird weiterhin ausgeführt, jedoch ohne Worker:

ps aux | grep nginx
outputroot       0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root       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

Auf diese Weise können Sie die neuen Worker überwachen, da sie Verbindungen isoliert akzeptieren, und gleichzeitig die alte ausführbare Datei wiederherstellen, wenn etwas nicht stimmt.

Bewerten Sie das Ergebnis und unternehmen Sie die nächsten Schritte

Sie sollten Ihr System zu diesem Zeitpunkt testen und prüfen, um sicherzustellen, dass keine Anzeichen von Problemen vorliegen. Sie können Ihre Konfiguration in diesem Zustand belassen, solange Sie sicherstellen möchten, dass die neue ausführbare Nginx-Datei fehlerfrei ist und Ihren Datenverkehr verarbeiten kann.

Ihr nächster Schritt wird ganz davon abhängen, ob Sie auf Probleme gestoßen sind.

Wenn Ihr Upgrade erfolgreich war, schließen Sie den Übergang ab

Wenn bei den Mitarbeitern Ihres neuen Sets keine Probleme aufgetreten sind, können Sie den alten Master-Prozess sicher herunterfahren. Senden Sie dazu einfach das Signal + QUIT + an den alten Master:

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

Der alte Master-Prozess wird ordnungsgemäß beendet, und nur die neuen Nginx-Master / Worker bleiben erhalten. Zu diesem Zeitpunkt haben Sie erfolgreich eine direkte binäre Aktualisierung von Nginx durchgeführt, ohne die Clientverbindungen zu unterbrechen.

Wenn die neuen Mitarbeiter Probleme haben, kehren Sie zur alten Binärdatei zurück

Wenn Ihre neue Gruppe von Workern Probleme zu haben scheint, können Sie zur alten Konfiguration und Binärdatei zurückkehren. Dies ist während derselben Sitzung möglich.

Am besten starten Sie die Arbeiter Ihres alten Meisters neu, indem Sie ihm das "+ HUP " - Signal senden. Wenn Sie einem Nginx-Master das Signal " HUP +" senden, liest er normalerweise die Konfigurationsdateien erneut und startet neue Worker. Wenn das Ziel jedoch ein älterer Master ist, werden nur neue Worker mit der ursprünglichen Arbeitskonfiguration erzeugt:

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

Sie sollten nun wieder über zwei Sätze von Master- / Worker-Prozessen verfügen:

ps aux | grep nginx
outputroot       0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root       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

Die neuesten Arbeiter sind mit den alten Arbeitern verbunden. Beide Worker-Sets akzeptieren zu diesem Zeitpunkt Client-Verbindungen. Stoppen Sie nun den neueren, fehlerhaften Master-Prozess und seine Worker, indem Sie das Signal + QUIT + senden:

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

Sie sollten zu Ihrem alten Meister und Ihren Arbeitern zurückkehren:

ps aux | grep nginx
outputroot       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

Der ursprüngliche Master erhält die Datei "+ / run / nginx.pid +" für seine PID zurück.

Wenn dies aus irgendeinem Grund nicht funktioniert, können Sie einfach versuchen, dem neuen Master-Server das Signal "+ TERM " zu senden, das ein Herunterfahren auslösen sollte. Dies sollte den neuen Master und alle Worker stoppen, während der alte Master automatisch überfahren wird, um die Worker-Prozesse zu starten. Wenn es ernsthafte Probleme gibt und die fehlerhaften Arbeiter nicht aussteigen, können Sie jedem von ihnen ein " KILL +" - Signal senden, um aufzuräumen. Dies sollte jedoch als letzter Ausweg angesehen werden, da dadurch Verbindungen unterbrochen werden.

Denken Sie nach dem Wechsel zur alten Binärdatei daran, dass auf Ihrem System immer noch die neue Version installiert ist. Sie sollten die fehlerhafte Version entfernen und auf Ihre vorherige Version zurücksetzen, damit Nginx beim Neustart ohne Probleme ausgeführt wird.

Fazit

Inzwischen sollten Sie in der Lage sein, Ihre Maschinen nahtlos von einer Nginx-Binärdatei auf eine andere umzustellen. Durch die Fähigkeit von Nginx, zwei Master / Worker-Sets zu verwalten und gleichzeitig Informationen zu ihren Beziehungen zu pflegen, können wir Server-Software aktualisieren, ohne die Server-Maschinen offline zu schalten.