Auf der nginx.conf 2016 in Austin diesen September habe ich eine Präsentation über die Verwendung von NGINX und NGINX Plus in einem Docker-Swarm-Cluster gehalten. In diesem Beitrag erläutere ich, wie man NGINX und NGINX Plus für den Lastenausgleich von Docker Swarm in Verbindung mit den in Docker 1.12 eingeführten Funktionen verwendet. Alle Dateien, die ich während meiner Demo bei nginx.conf (und mehr) verwendet habe, stehen auf GitHub zum Experimentieren zur Verfügung.
Die Ende Juli 2016 veröffentlichte Docker-Version 1.12 integriert Docker Engine und Swarm und fügt einige neue Orchestrierungsfunktionen hinzu, um eine Plattform zu erstellen, die anderen Containerplattformen wie Kubernetes ähnelt. In Docker 1.12 können Sie im Swarm-Modus eine Reihe von Docker-Hosts zu einem Schwarm kombinieren und so eine fehlertolerante, selbstheilende, dezentrale Architektur bereitstellen. Die neue Plattform erleichtert außerdem die Einrichtung eines Swarm-Clusters, sichert alle Knoten mit einem Schlüssel und verschlüsselt die gesamte Kommunikation zwischen den Knoten mit TLS.
Gleichzeitig wurde die Docker-API erweitert, um Dienste zu berücksichtigen. Dabei handelt es sich um Containersätze, die dasselbe Image verwenden (ähnlich den Diensten in Docker Compose, jedoch mit mehr Funktionen). Sie können Dienste erstellen und skalieren, fortlaufende Updates durchführen, Integritätschecks erstellen und vieles mehr. DNS‑Diensterkennung und Lastenausgleich sind integriert und Sie können auch clusterweite Overlay‑Netzwerke einrichten.
Für diese Diskussion und Demo habe ich drei Swarm-Knoten – einen Manager und zwei Worker. Der Managerknoten ist der Ort, an dem die Swarm-Befehle ausgeführt werden. Swarm übernimmt die Planung, die DNS-Diensterkennung, die Skalierung und den Container-Lastausgleich (in der Abbildung durch die kleinen Kästchen dargestellt) auf allen Knoten.
Um eine private Netzwerkkommunikation zwischen Containern innerhalb eines Clusters zu ermöglichen, können Container mit mehreren internen Overlay-Netzwerken verbunden werden, die sich über alle Knoten im Cluster erstrecken. Container können über den Swarm-Load Balancer außerhalb des Clusters verfügbar gemacht werden.
Der Docker Swarm-Load Balancer wird auf jedem Knoten ausgeführt und kann die Last von Anforderungen auf alle Container auf allen Hosts im Cluster verteilen. In einer Swarm-Bereitstellung ohne NGINX oder NGINX Plus verarbeitet der Swarm-Load Balancer eingehende Clientanforderungen (dargestellt durch die grünen Pfeile in Abbildung 3) sowie interne Service-zu-Dienst-Anfragen (dargestellt durch die roten Pfeile).
Da Swarm nun Lastenausgleich unterstützt, warum brauchen Sie dann noch einen weiteren Lastenausgleich? Ein Grund dafür ist, dass der Swarm-Load Balancer ein grundlegender Layer 4-Load Balancer (TCP) ist. Viele Anwendungen erfordern zusätzliche Funktionen, wie diese, um nur einige zu nennen:
Darüber hinaus verfügen Sie möglicherweise bereits über Erfahrung mit einem Load Balancer. Durch die Verwendung mit Swarm können Sie die Tools und Kenntnisse nutzen, die Sie bereits verwenden.
NGINX Open Source und NGINX Plus sind zwei Load Balancer, die anwendungskritische Funktionen bereitstellen, die beim nativen Swarm-Load Balancer fehlen.
NGINX Open Source bietet die zuvor genannten Funktionen (SSL/TLS-Terminierung usw.) und mehr, darunter:
Die einfachste Möglichkeit, NGINX Open Source zu verwenden, besteht darin, es als Dienst mit einem oder mehreren Containern bereitzustellen. Die erforderlichen Ports für den NGINX-Dienst werden im Cluster bereitgestellt und die Swarm-Load Balancer verteilen Anforderungen über diese Ports an die NGINX-Container.
Für die Zwecke dieses Beispiels ist der von NGINX bereitgestellte Dienst die SSL/TLS-Terminierung. Um zu veranschaulichen, wie das funktioniert, stellen wir einen Back-End-Dienst A im Cluster bereit und skalieren ihn so, dass er drei Container hat (zwei Instanzen auf einem Knoten und eine Instanz auf einem anderen, wie in Abbildung 5 dargestellt). Swarm weist dem Dienst A eine virtuelle IP-Adresse (VIP) zur Verwendung innerhalb des Clusters zu. Wir verwenden diese VIP in der NGINX-Konfiguration der Upstream-Gruppe für Dienst A, anstatt die einzelnen IP-Adressen der Container aufzulisten. Auf diese Weise können wir Dienst A skalieren, ohne die NGINX-Konfiguration ändern zu müssen.
Wie in Abbildung 5 gezeigt, leitet der Swarm-Load Balancer auf diesem Knoten die Anforderung an NGINX weiter, wenn ein Client eine Anforderung für Dienst A an den ersten Swarm-Knoten sendet. NGINX verarbeitet die Anforderung (in diesem Beispiel durch SSL/TLS-Entschlüsselung) und leitet sie an den VIP für Dienst A weiter. Der Swarm-Load Balancer leitet die (jetzt unverschlüsselte) Anforderung an einen der Container für Dienst A auf einem beliebigen Swarm-Knoten weiter.
Es ist möglich, NGINX-Lastausgleichsanforderungen direkt an die Back-End-Container zu senden und auch interne Dienst-zu-Dienst-Anfragen zu verarbeiten, jedoch nur mit einer komplexeren Lösung, die erfordert, dass die NGINX-Konfiguration bei jeder Skalierung von Dienst A geändert und neu geladen wird. Ich werde später erläutern, wie dies mit NGINX Plus ganz einfach erreicht werden kann.
Einige der zusätzlichen Funktionen von NGINX Plus sind:
Dynamische Neukonfiguration – Dies bietet die Möglichkeit, Backends hoch- und herunterskalieren, ohne dass die NGINX-Konfiguration geändert und neu geladen werden muss. Dies ist insbesondere bei der Diensterkennung mit einer Microservices-Plattform wie Swarm nützlich und stellt eine der wichtigsten Funktionen dar, die eine vollständige Integration von NGINX Plus in diese Plattformen ermöglicht.
Es gibt zwei Methoden zur dynamischen Neukonfiguration: eine API, mit der Sie Änderungen an NGINX Plus übertragen können, und DNS, das NGINX Plus kontinuierlich auf Änderungen der Anzahl der an einen Domänennamen angehängten Knoten überprüft. Dies ist die Methode, die in dieser NGINX Plus-Demo zur Integration mit der integrierten Diensterkennung in Swarm verwendet wird.
In der oben beschriebenen NGINX Open Source-Konfiguration verteilt der Swarm-Load Balancer sowohl externe Anfragen an die Backend-Container als auch verarbeitet Service-zu-Service-Anfragen zwischen ihnen. Die Rolle von NGINX besteht im SSL/TLS-Offloading.
Bei Verwendung von NGINX Plus erreichen Clientanforderungen von externen Clients zuerst den Swarm-Load Balancer, aber NGINX Plus übernimmt den eigentlichen Lastenausgleich für die Back-End-Container (Abbildung 6). Indem Clientanforderungen zuerst an den Swarm-Load Balancer gesendet werden, lässt sich NGINX Plus auf einfache Weise hochverfügbar machen.
In ähnlicher Weise empfängt der Swarm-Load Balancer Anfragen zwischen Diensten, aber NGINX Plus verteilt sie tatsächlich auf die Dienste (Abbildung 7).
Um einige Beispiele für die Verwendung von Swarm für den Docker-Lastausgleich mit und ohne NGINX zu geben, habe ich drei Demonstrationen erstellt. Alle Dateien für diese Demonstrationen sind zusammen mit ausführlichen Anweisungen auf GitHub verfügbar. Die drei Demonstrationen sind:
Dies demonstriert die Lastverteilung von Anfragen durch Docker Swarm an ein einfaches Web-App-Backend ohne NGINX oder NGINX Plus.
Diese Demo fügt NGINX Open Source hinzu, um SSL/TLS-Offload für externe Anfragen bereitzustellen. Der Swarm-Load Balancer verteilt Anfragen an dasselbe einfache Web-App-Backend wie in der vorherigen Demo und verarbeitet interne Service-zu-Service-Anfragen.
Diese Demo besteht aus zwei Teilen. Der erste Teil verwendet NGINX Plus, das neben der SSL/TLS-Entlastung auch die Lastverteilung von Anfragen direkt an die Back-End-Container übernimmt und auch interne Service-zu-Service-Anfragen verarbeitet. Es ist in die Swarm-Diensterkennung integriert und verwendet dynamisches DNS, um den mit den Backends verknüpften Domänennamen häufig neu aufzulösen. NGINX Plus führt einen Lastausgleich für zwei Backend-Dienste durch, Service1 und Service2 . Es demonstriert interne Service-zu-Service-Anfragen, indem Service1 eine Anfrage an Service2 stellt.
Der zweite Teil zeigt, wie Sie die NGINX Status API mit der Docker Service API kombinieren können, um die Backend-Container automatisch zu skalieren. Ein Python-Programm verwendet die NGINX Plus Status API, um die Auslastung von Service1 und Service2 zu überwachen, und die Docker Swarm Service API, um die Backend-Container nach oben oder unten zu skalieren.
Die in Docker 1.12 eingeführten neuen Funktionen machen Swarm zu einer noch leistungsfähigeren Plattform, die jedoch durch die Nutzung von NGINX Open Source und noch mehr durch die Verwendung von NGINX Plus noch verbessert werden kann. Die Fähigkeit von NGINX Plus, die Back-End-Container dynamisch neu zu konfigurieren, um über DNS einen Lastenausgleich durchzuführen, und die durch die Status-API bereitgestellte Sichtbarkeit ergeben eine sehr leistungsstarke Containerlösung.
Um NGINX Plus auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.
Und probieren Sie die in unserem GitHub -Repository verfügbaren Demonstrationen aus.
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."