So implementieren Sie ein dynamisches automatisches Hoch- und Herunterfahren von Upstream-Servern ohne Neuladen basierend auf Nginx

Im Internet gibt es viele Einführungen zu nginx. Hier werden wir darüber sprechen, wie Upstream-Dienste (wie der Java1-Dienst in der folgenden Abbildung) über nginx ohne „Gateway“ dynamisch online und offline gebracht werden können.

Der traditionelle Ansatz besteht darin, die Upstream-Datei von nginx manuell zu ändern, die Java1-Konfiguration auszukommentieren oder als inaktiv zu markieren und dann nginx neu zu laden, damit die Änderung wirksam wird. Natürlich können Sie ein Skript erstellen, um die Änderung zu automatisieren. Bei einem stark ausgelasteten Nginx führt ein hastiges Neuladen jedoch im besten Fall zu einer langsamen Reaktion oder im schlimmsten Fall zu einem enormen Datenverlust.

Wie kann Nginx also die Upstream-Konfiguration dynamisch laden? Im Allgemeinen gibt es online drei Lösungen:

• Kombinieren Sie Lua-Skript mit Nginx, der Openresty-Lösung.
• Fügen Sie jedem Nginx-Server einen zusätzlichen Port hinzu und ändern Sie den Upstream, indem Sie jedes Mal diesen Port aufrufen.
• Fügen Sie nginx eine Datenbank hinzu, speichern Sie die Upstream-Daten in der Datenbank und ändern Sie die Upstream-Konfiguration, indem Sie die Datenbankdaten ändern.

Für eine laufende Produktionsumgebung mit Nginx ist die dritte Option zweifellos die kostengünstigste. Schauen wir uns das genauer an:

Technische Lösung: nginx1.16+nginx_upstream_check_module+nginx-upsync-module+consul

veranschaulichen:

• Der Konsul hier ist die oben erwähnte Datenbank. Es handelt sich nicht nur um eine Schlüssel- / Werttypbibliothek, sondern verfügt auch über eine übersichtliche Webverwaltungsseite, auf der Schlüssel-Wert-Daten problemlos verwaltet werden können.
• nginx_upstream_check_module ist Alibabas Open-Source-Integritätscheckmodul für Upstream-Dienste.
• nginx-upsync-module ist ein Open-Source-Modul von Weibo, das mit Consul/etcd kombiniert werden kann.

Im Folgenden werden die Implementierungsdetails nacheinander anhand von drei Aspekten erläutert: Consul-Clusterbereitstellung, Nginx-Transformation und Erstellen von Upstream-Daten.

1. Konsul-Cluster bereitstellen

Offizielle Website: https://www.consul.io/

Angenommen, ein Consul-Cluster besteht aus den folgenden drei Maschinen:

192.168.21.11
192.168.21.12
192.168.21.13
192.168.21.14 # Diese IP ist die Proxy-IP, die zum Proxy der oben genannten 3 Maschinen verwendet wird

1. Vorbereitung

Laden Sie das komprimierte Consul-Paket von der offiziellen Website herunter und laden Sie es jeweils auf die oben genannten drei Server hoch. Die Consul-Version hier ist 1.8.4:

entpacken Sie consul_1.8.4_linux_amd64.zip
mv consul /usr/local/bin/
[root@nginx-11 tmp]# Konsul
Verwendung: consul [--version] [--help] <Befehl> [<Argumente>]

Verfügbare Befehle sind:
 acl Interagieren Sie mit den ACLs von Consul
 agent Betreibt einen Consul-Agenten
 Interagieren Sie mit dem Katalog
 ....

Erstellen Sie auf den drei Computern jeweils Konsuldaten-, Protokoll- und Konfigurationsdateiverzeichnisse:

mkdir -p /Daten/Consul/{Daten,Protokoll}
mkdir /etc/consul

2. Generieren Sie eine Konsul-Konfigurationsdatei

Im Folgenden wird die Konfigurationsdatei von 192.168.21.11 als Beispiel verwendet:

[root@nginx-11 tmp]# cat /etc/consul/config.json
{
 "Datencenter": "dc1",
 "primäres_Rechenzentrum": "dc1",
 "bootstrap_expect":3,
 "start_join":[
 "192.168.21.11",
 "192.168.21.12",
 „192.168.21.13“
 ],
 "erneut versuchen beizutreten":[
 "192.168.21.11",
 "192.168.21.12",
 „192.168.21.13“
 ],
 "advertise_addr": "192.168.21.11",
 "bind_addr": "192.168.21.11",
 "client_addr": "0.0.0.0",
 "Server":true,
 "verbinden":{
 "aktiviert":true
 },
 "Knotenname": "192.168.21.11",
 "ui": wahr,
 "Datenverzeichnis": "/data/consul/data",
 "enable_script_checks":false,
 "enable_local_script_checks":wahr,
 "Protokolldatei": "/data/consul/log/",
 "log_level":"Informationen",
 "log_rotate_bytes":100000000,
 "log_rotate_duration":"24h",
 "verschlüsseln":"a2zC4ItisuFdpl7IqwoYz3GqwA5W1w2CxjNmyVbuhZ4=",
 "acl": {
 "aktiviert":true,
 "Standardrichtlinie": "Verweigern",
 "enable_token_persistence":wahr,
 "enable_key_list_policy":true,
 "Token": {
 "Meister":"6c95012f-d086-4ef3-b6b9-35b60f529bd0"
 }
 }
}

veranschaulichen:

• Ändern Sie in den Konfigurationsdateien der anderen beiden Server die Werte advertise_addr, bind_addr und node_name in die entsprechenden IP-Adressen. Andere Konfigurationen müssen nicht geändert werden.
• Der Parameter „bootstrap_expect“:3 bedeutet, dass Sie einen Cluster mit 3 Knoten bereitstellen möchten. Bitte konfigurieren Sie ihn entsprechend der tatsächlichen Situation.
• Die der Verschlüsselung und den Token entsprechenden Werte sollten auf den drei Maschinen konsistent sein. Der Verschlüsselungswert kann mit dem Befehl consul keygen generiert werden, der Tokenwert kann mit dem Befehl uuidgen generiert werden oder beide können mit diesen beiden Tools generiert werden.
• Informationen zu den zugehörigen Parametern finden Sie unter: https://juejin.im/post/6844903860717240334

3. Erstellen Sie einen Konsul-Cluster

Starten Sie Consul einfach jeweils auf drei Maschinen:

Konsul-Agent -Konfigurationsdatei=/etc/consul/config.json &

Sie können auf die Consul-Hintergrundschnittstelle zugreifen, indem Sie über den Browser http://192.168.21.14:8500 (oder einen beliebigen IP:Port) aufrufen und den Token-Wert des obigen Masters eingeben, um den spezifischen Inhalt anzuzeigen.

Beachten:

• In der ACL-Konfiguration in der obigen Konfigurationsdatei muss die Konfiguration „enable_key_list_policy“ hinzugefügt und der Wert auf „true“ gesetzt werden, da anonyme Benutzer sonst möglicherweise nicht auf den Inhalt der Konsul-Konfiguration zugreifen können.

4. Erstellen Sie Konsul-Zugriffsberechtigungen für Nicht-Administratoren

1) Erstellen Sie eine Zugriffsrichtlinie

Greifen Sie über den Browser auf Consul zu, klicken Sie oben rechts auf ACL -> Zugriffskontrollen -> Richtlinien -> Erstellen, um eine schreibgeschützte „Upstreams“-KV-Richtlinie mit dem Namen „readonlykv“ zu erstellen. Der Regelinhalt lautet:

Schlüsselpräfix "Upstreams/" {
 Richtlinie = "Liste"
}

Erstellen Sie eine KV-Richtlinie, die „Upstreams“ schreiben kann, mit dem Namen: writekv. Der Regelinhalt lautet:

Schlüsselpräfix "Upstreams/" {
 Richtlinie = "schreiben"
}

Die Screenshots der beiden erstellten Strategien sind wie folgt:

2) Erstellen Sie einen Zugriffstoken

Fügen Sie dem anonymen Benutzertoken den Zugriff auf die schreibgeschützte KV-Richtlinie „Upstreams“ hinzu, um dem Nginx-Modul das anonyme Lesen der Consul-Konfiguration zu ermöglichen:
Klicken Sie auf 00000002 und wählen Sie in den Richtlinien „readonlykv“ aus.

Erstellen Sie ein Token, das in den KV „Upstreams“ schreiben kann. Dieses wird vom Skript verwendet, um die Konsulkonfiguration mit diesem Token zu ändern:
Greifen Sie über den Browser auf Consul zu, klicken Sie oben rechts auf ACL -> Zugriffskontrollen -> Token -> Erstellen und wählen Sie in den Richtlinien writekv aus.
Die Screenshots der beiden Token, die geändert/erstellt wurden, sind wie folgt:

An diesem Punkt ist die Bereitstellung des Consul-Clusters abgeschlossen.

2. Nginx-Transformation

1. Upgrade von nginx

Laden Sie nginx-bezogene Module herunter:

nginx-upsync-Modul: https://github.com/weibocom/nginx-upsync-module

nginx_upstream_check_module: https://github.com/xiaokai-wang/nginx_upstream_check_module

Beachten:

• Achten Sie beim Herunterladen des Moduls nginx_upstream_check_module darauf, es von xiaokai-wangs GitHub herunterzuladen und niemals von Alibabas offiziellem GitHub. Andernfalls ist die Version inkompatibel und kann nicht kompiliert werden.
• Bitte sichern Sie Ihre Daten, bevor Sie Nginx aktualisieren.

1) Patch nginx_upstream_check_module

cd nginx-1.16.0
patch -p1 < /usr/local/src/nginx-1.16/nginx_upstream_check_module-master/check_1.12.1+.patch

Hinweis: Ich habe die beiden heruntergeladenen Quellpakete des Nginx-Moduls im Pfad /usr/local/src/nginx-1.16/ abgelegt.

2) Kompilieren Sie nginx

./configure --prefix=/usr/local/nginx --add-module=/usr/local/src/nginx-1.16/nginx_upstream_check_module-master --add-module=/usr/local/src/nginx-1.16/nginx-upsync-module-master …

veranschaulichen:

Ich habe nginx unter /usr/local/ installiert;

Die Auslassungspunkte nach dem Befehl sind die Module, die Sie installieren möchten. Bitte fügen Sie sie entsprechend der tatsächlichen Situation hinzu. Sie können über nginx -V sehen, welche Module derzeit installiert sind, und sie dann hinzufügen.

3) Installieren Sie nginx

machen
# Wenn es sich um ein reibungsloses Upgrade handelt, führen Sie in diesem Schritt „make install“ nicht aus

4) Aktualisieren Sie nginx

#Sichern Sie die Nginx-Binärdatei erneut mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx16.old
#Ersetzen Sie die alte Nginx-Binärdatei durch die neue cp objs/nginx /usr/local/nginx/sbin/
#Zeigen Sie das installierte Nginx-Modul /usr/local/nginx/sbin/nginx -V

Erinnerung: Nach dem Testen wurde festgestellt, dass der alte Nginx-Prozess nicht beendet wird, wenn nginx1.6 neu geladen oder der Befehl kill -USR2 gesendet wird. Nginx muss neu gestartet werden, damit die Änderungen wirksam werden. Ich weiß nicht, ob es sich um einen Fehler handelt.

/usr/local/nginx/sbin/nginx -s stoppen
#Wenn der alte Nginx-Prozess nicht gestartet wurde, erzwingen Sie mit kill -9 die Beendigung. ps -ef |grep nginx
#Öffnen Sie nginx
/usr/local/nginx/sbin/nginx 
# Beschreibung: Senden Sie den Befehl kill -USR2 kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`

An diesem Punkt ist das Nginx-Upgrade abgeschlossen.

2. Konfigurieren Sie nginx

1) Konfigurieren Sie zunächst die Nginx-Anzeigeseite, um den Ausführungsstatus von Nginx schnell zu verstehen

Katze nginx.conf
 Server {
 hören Sie 80;
 Servername localhost;

 # Upstream in Server 80 anzeigen, was der globalen Konfiguration entspricht. Für andere Konfigurationsdateien ist keine Konfiguration erforderlich. # Browserzugriff http://nginx-ip:80/upstream_show, um die spezifischen Konfigurationsinformationen von nginx Upstream location = /upstream_show { anzuzeigen.
  upstream_show;
 }

 # Zeigt die Prüfdetails auf Server 80 an, was der globalen Konfiguration entspricht. Andere Konfigurationsdateien müssen nicht konfiguriert werden. # Browserzugriff http://nginx-ip:80/status, um den Integritätsstatus des Upstream-Dienstes anzuzeigen. Rot bedeutet, dass ein Problem vorliegt, und Weiß bedeutet, dass der Standort /status { normal ist.
  Status prüfen;
 }

 # Zeigt den Status von nginx auf Server 80 an, was der globalen Konfiguration entspricht. Andere Konfigurationsdateien müssen nicht konfiguriert werden. # nginx nativer Funktionsspeicherort /NginxStatus {
  stub_status ein;
  Zugriff_Abmeldung;
  erlaube 192.168.0.0/16;
  alles leugnen;
 }
 }
     # Spezifische Serverkonfiguration einführen. Jeder Server muss das Modul nginx-upsync-module konfigurieren. Die Modulkonfiguration umfasst /usr/local/nginx/conf/vhosts/*.conf;

2) Serverkonfiguration

HTTP-Methodenerkennung

Upstream rs1 {
 Server 127.0.0.1:11111;
 upsync 192.168.21.14:8500/v1/kv/upstreams/rs1/ upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=aus;
 upsync_dump_path /usr/local/nginx/conf/servers/servers_rs1.conf;

 Prüfintervall=1000 Anstieg=2 Abfall=2 Timeout=3000 Typ=http Standard_Abstieg=false;
 check_http_send "HEAD /health.htm HTTP/1.0\r\n\r\n";
 check_http_expect_alive http_2xx http_3xx;
}

Server {
 hören Sie 80;
...

TCP-Erkennung (TCP ist die Standarderkennungsmethode)

Upstream rs2 {
 Server 127.0.0.1:11111;
 upsync 192.168.21.14:8500/v1/kv/upstreams/rs2/ upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=aus;
 upsync_dump_path /usr/local/nginx/conf/servers/servers_rs2.conf;

 Prüfintervall=1000 Anstieg=2 Abfall=2 Timeout=3000 Typ=TCP Standard_Down=False;
}

Server {
 hören Sie 80;
...

veranschaulichen:

• Es wird empfohlen, die HTTP-Erkennung zu verwenden, die genauer ist als TCP. Diese Erkennungsmethode wird von nginx_upstream_check_module bereitgestellt, das leistungsstark ist und einfache Parametererklärungen hat: Alle 1 Sekunde wird eine Integritätsprüfung durchgeführt, mit einem Timeout von jeweils 3 Sekunden. Wenn zwei aufeinanderfolgende Integritätsprüfungen erfolgreich sind, gilt der Upstream-Dienst als fehlerfrei und wird online gestellt oder bleibt online; wenn zwei aufeinanderfolgende Integritätsprüfungen fehlschlagen, gilt der Upstream-Dienst als fehlerhaft und wird aus der Leitung entfernt. „/health.htm“ ist die Integritätsprüfungsschnittstelle des Upstream-Dienstes, mit der ermittelt wird, ob der Dienst fehlerfrei ist. Eine ausführliche Erläuterung der Parameter finden Sie unter: http://tengine.taobao.org/document_cn/http_upstream_check_cn.html
• Einfache Erklärung der Parameter: Das Modul nginx-upsync-module überprüft alle 0,5 Sekunden die Konfiguration aus der Consul-Datenbank und jedes Timeout beträgt 6 Minuten. Eine ausführliche Parametererklärung finden Sie unter: https://github.com/weibocom/nginx-upsync-module
• Nginx erstellt ein Server-Unterverzeichnis unter dem Verzeichnis /usr/local/nginx/conf und erstellt in diesem Unterverzeichnis automatisch relevante Serverkonfigurationsdateien.

An diesem Punkt ist die Änderung der Nginx-Konfiguration abgeschlossen.

3. Erstellen Sie Upstream-Daten (Consul-Schlüssel-Wert-Paare)

Sie können Upstream-Daten über Webseiten oder Skripte wie folgt erstellen:

1. Betrieb der Webseite

Wenn Sie ein Verzeichnis erstellen müssen, fügen Sie nach dem zu erstellenden Feld "/" hinzu, z. B.: upstreams/.

Unter „Key/Value“ müssen Sie zunächst das Verzeichnis „upstreams“ (mit dem Buchstaben s am Ende) anlegen und anschließend den entsprechenden Servernamen vergeben. Der Screenshot sieht wie folgt aus:

2. Befehlszeilenoperation

Wenn Sie die Kommandozeile verwenden, müssen Sie das Verzeichnis „upstreams/“ nicht erst anlegen. Das Verzeichnis und die Serverdaten werden vom Befehl automatisch angelegt.

Im Folgenden wird der Upstream-Dienst Java1 (IP ist 192.168.20.100, Portnummer ist 8080, Upstream-Gruppenname ist rs1) als Beispiel verwendet:

Hinzufügen eines Datensatzes

curl -X PUT http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token

Nachdem der obige Befehl ausgeführt wurde, werden die Standardkonfigurationsinformationen für den Upstream von Nginx erstellt, und zwar:

Server 192.168.20.100:8080 Gewicht=1 max_fails=2 Fail_Timeout=10s;

Sie können Gewichte und andere Werte mit dem folgenden Befehl anpassen:

curl -X PUT -d "{\"Gewicht\":100, \"max_fails\":2, \"fail_timeout\":10}" http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token
# oder curl -X PUT -d '{"weight":100, "max_fails":2, "fail_timeout":10}' http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token

Löschen von Datensätzen

curl -X LÖSCHEN http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token

Gewichte aktualisieren

curl -X PUT -d "{\"Gewicht\":100, \"max_fails\":2, \"fail_timeout\":10}" http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token
# oder curl -X PUT -d '{"weight":100, "max_fails":2, "fail_timeout":10}' http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token

Offline-Dienst

curl -X PUT -d "{\"Gewicht\":2, \"max_fails\":2, \"fail_timeout\":10, \"down\":1}" http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token
# oder curl -X PUT -d '{"weight":2, "max_fails":2, "fail_timeout":10, "down":1}' http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token

Überprüfen Sie, welche Upstream-Server sich unter Upstream rs1 befinden

curl http://192.168.21.14:8500/v1/kv/upstreams/rs1?recurse

Es wird empfohlen, Befehlszeilenoperationen zu verwenden und die Befehlszeilen in Skripten zusammenzustellen, um DevOps zu implementieren

4. Einige Erkenntnisse

Während der Transformation der dynamischen Erkennungslösung stieß ich auf viele Probleme. Das schwierigste war, dass nginx in der Testumgebung ständig Fehler meldete und die Upstream-Daten nicht vollständig heruntergeladen werden konnten. Nach verschiedenen Untersuchungen wurden keine Probleme gefunden. Zwischendurch vermutete ich, dass es ein Problem mit Consul war. Ich wechselte zu etcd, meldete aber immer noch denselben Fehler. Schließlich stellte ich durch Paketerfassung und -verfolgung fest, dass die Linux-Kernelparameter falsch konfiguriert waren, was zu einem Warteschlangenüberlauf und einem Fehler beim TCP-Dreiwege-Handshake führte, was die Kommunikation zwischen nginx und Consul beeinträchtigte.

Theoretisch sind viele Lösungen gut und manche Leute haben sie sogar erfolgreich eingesetzt. Wenn Sie sie jedoch tatsächlich selbst implementieren, werden Sie immer noch auf verschiedene Probleme stoßen, von denen einige sogar tödlich sind. Zu diesem Zeitpunkt müssen Sie sie geduldig lösen. Ich hoffe, dass jeder, der diesen Artikel sieht, es ausprobiert. Wenn Sie auf Probleme stoßen, beruhigen Sie sich bitte und beheben Sie geduldig das Problem.

Außerdem sagen viele Leute, dass Betrieb und Wartung keinen Wert schaffen. Ich denke, das ist falsch. Es gibt viele Werte, die Betrieb und Wartung widerspiegeln müssen, und SRE ist einer davon.

Damit ist dieser Artikel über die dynamische und automatische Online- und Offline-Anmeldung von Upstream-Servern ohne Neuladen auf Basis von nginx abgeschlossen. Weitere Informationen zur automatischen Online-Anmeldung von Upstream-Servern mit nginx finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!