Docker-Swarm-Lastverteilung mit NGINX und NGINX Plus

Auf der nginx.conf 2016, die diesen September in Austin stattfand, hielt ich eine Präsentation über den Einsatz von NGINX und NGINX Plus in einem Docker-Swarm-Cluster. In diesem Beitrag erläutere ich, wie sich NGINX und NGINX Plus zusammen mit den in Docker 1.12 eingeführten Funktionen für den Lastenausgleich in Docker Swarm einsetzen lassen. Alle Dateien, die ich während meiner Demo auf der nginx.conf verwendet habe (und weitere), stehen auf GitHub zum Ausprobieren bereit.

Überblick

Docker Version 1.12, die Ende Juli 2016 veröffentlicht wurde, integriert Docker Engine und Swarm und bietet einige neue Orchestrierungsfunktionen. Dadurch entsteht eine Plattform, die anderen Containerplattformen wie Kubernetes ähnelt. Mit dem Swarm-Modus in Docker 1.12 können Sie mehrere Docker-Hosts zu einem Swarm zusammenfassen und so eine fehlertolerante, selbstheilende und dezentrale Architektur schaffen. Die neue Plattform erleichtert außerdem die Einrichtung eines Swarm-Clusters, sichert alle Knoten mit einem Schlüssel ab und verschlüsselt die gesamte Kommunikation zwischen den Knoten mittels TLS.

Gleichzeitig wurde die Docker-API um die Unterstützung von Diensten erweitert. Dabei handelt es sich um Gruppen von Containern, die dasselbe Image verwenden (ähnlich wie Dienste in Docker Compose, jedoch mit mehr Funktionen). Sie können Dienste erstellen und skalieren, schrittweise Aktualisierungen durchführen, Zustandsprüfungen einrichten und vieles mehr. DNS-basierte Diensterkennung und Lastverteilung sind integriert. Außerdem können Sie clusterweite Overlay-Netzwerke einrichten.

Topologie für den Lastenausgleich in Docker Swarm

Für diese Erläuterung und Demo verwende ich drei Swarm-Knoten – einen Manager und zwei Worker. Auf dem Manager-Knoten werden die Swarm-Befehle ausgeführt. Swarm übernimmt auf allen Knoten die Ablaufplanung, die DNS-Diensterkennung, die Skalierung und den Lastenausgleich für Container (in der Abbildung durch die kleinen Kästchen dargestellt).

Abbildung 1. Ein Docker-Swarm-Cluster mit einem Manager- und zwei Worker-Knoten

Um eine private Netzwerkkommunikation zwischen Containern innerhalb eines Clusters zu ermöglichen, können die Container mit mehreren internen Overlay-Netzwerken verbunden werden, die sich über alle Knoten im Cluster erstrecken. Über den Swarm-Load-Balancer können die Container außerhalb des Clusters zugänglich gemacht werden.

Abbildung 2. Interne und externe Netzwerkkonnektivität in einem Docker-Swarm-Cluster

Der Docker-Swarm-Load-Balancer wird auf jedem Knoten ausgeführt und kann Anfragen auf beliebige Container auf allen Hosts im Cluster verteilen. In einer Swarm-Bereitstellung ohne NGINX oder NGINX Plus verarbeitet der Swarm-Load-Balancer sowohl eingehende Client-Anfragen (in Abbildung 3 durch die grünen Pfeile dargestellt) als auch interne Anfragen zwischen Diensten (durch die roten Pfeile dargestellt).

Abbildung 3. Lastverteilung von Client- und Service-zu-Service-Anfragen in einem Swarm-Cluster ohne NGINX oder NGINX Plus

Da Swarm nun Load Balancing umfasst, stellt sich die Frage, warum Sie einen weiteren Load Balancer benötigen. Ein Grund dafür ist, dass der Swarm Load Balancer lediglich ein einfacher Layer-4-Load-Balancer (TCP) ist. Viele Anwendungen benötigen zusätzliche Funktionen, darunter beispielsweise:

• SSL/TLS-Terminierung
• Inhaltsbasiertes Routing (beispielsweise auf Grundlage der URL oder eines Headers)
• Zugriffskontrolle und Autorisierung
• Umschreibungen und Weiterleitungen

Darüber hinaus haben Sie möglicherweise bereits Erfahrung mit einem Load Balancer. Wenn Sie diesen mit Swarm verwenden können, profitieren Sie von den Tools und Kenntnissen, die Sie bereits nutzen.

NGINX Open Source und NGINX Plus verwenden

NGINX Open Source und NGINX Plus sind zwei Load Balancer, die anwendungskritische Funktionen bereitstellen, die dem nativen Swarm-Load-Balancer fehlen.

NGINX Open Source verwenden

NGINX Open Source bietet die zuvor genannten Funktionen (SSL/TLS-Terminierung usw.) und darüber hinaus unter anderem:

• Eine Auswahl an Lastverteilungsalgorithmen
• Weitere Protokolle, zum Beispiel HTTP/2 und WebSocket
• Konfigurierbare Protokollierung
• Datenverkehrslimits, einschließlich Anfragerate, Bandbreite und Verbindungen
• Skripterstellung für fortgeschrittene Anwendungsfälle mit Lua, Perl und JavaScript (mit dem dynamischen nginScript-Modul [Redaktion – heißt jetzt dynamisches NGINX-JavaScript-Modul])
• Sicherheitsfunktionen wie Positiv- und Negativlisten

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 freigegeben, und die Swarm-Load-Balancer verteilen Anfragen an diesen Ports auf die NGINX-Container.

Abbildung 4. Swarm-Load-Balancer verteilen Anfragen für die NGINX-Dienste auf die Instanzen

In diesem Beispiel stellt NGINX die SSL/TLS-Terminierung als Dienst bereit. Um die Funktionsweise zu veranschaulichen, stellen wir im Cluster einen Backend-Dienst A bereit und skalieren ihn auf drei Container (zwei Instanzen auf einem Knoten und eine Instanz auf einem anderen, wie in Abbildung 5 dargestellt). Swarm weist Dienst A eine virtuelle IP-Adresse (VIP) zur Verwendung innerhalb des Clusters zu. In der NGINX-Konfiguration der Upstream-Gruppe für Dienst A verwenden wir diese VIP, anstatt die einzelnen IP-Adressen der Container aufzulisten. So können wir Dienst A skalieren, ohne die NGINX-Konfiguration ändern zu müssen.

Wie in Abbildung 5 dargestellt, leitet der Swarm-Load-Balancer auf dem ersten Swarm-Knoten eine Clientanfrage für Dienst A an NGINX weiter. NGINX verarbeitet die Anfrage – in diesem Beispiel durch SSL/TLS-Entschlüsselung – und leitet sie an die VIP von Dienst A weiter. Der Swarm-Load-Balancer leitet die nun unverschlüsselte Anfrage an einen der Container von Dienst A auf einem beliebigen Swarm-Knoten weiter.

Abbildung 5. NGINX übernimmt die SSL/TLS-Terminierung für externe Clientanfragen

Es ist möglich, NGINX Anfragen direkt auf die Backend-Container verteilen und auch interne Anfragen zwischen Diensten verarbeiten zu lassen. Dies erfordert jedoch eine komplexere Lösung, bei der die NGINX-Konfiguration jedes Mal geändert und neu geladen werden muss, wenn Dienst A skaliert wird. Später werde ich erläutern, wie sich dies mit NGINX Plus problemlos umsetzen lässt.

NGINX Plus verwenden

Zu den zusätzlichen Funktionen von NGINX Plus gehören:

• Aktive Zustandsprüfungen für Anwendungen – NGINX Plus überprüft kontinuierlich die Backend-Knoten, um sicherzustellen, dass sie fehlerfrei funktionieren und ordnungsgemäß reagieren, und entfernt fehlerhafte Knoten aus der Load-Balancing-Rotation.
• Sitzungspersistenz – Auch bekannt als Sticky Sessions, und erforderlich für Anwendungen, bei denen die Anfragen eines Clients weiterhin an dasselbe Backend gesendet werden müssen. NGINX Plus unterstützt das kontrollierte Beenden von Sitzungen, wenn Backend-Server offline genommen werden müssen, ohne Clients mit offenen Sitzungen zu beeinträchtigen.
• Dynamische Neukonfiguration – Damit können Backends nach Bedarf hoch- und herunterskaliert werden, ohne dass die NGINX-Konfiguration geändert und neu geladen werden muss. Dies ist besonders bei der Serviceerkennung mit einer Microservices-Plattform wie Swarm hilfreich und eine der wichtigsten Funktionen, die eine vollständige Integration von NGINX Plus in diese Plattformen ermöglicht. Für die dynamische Neukonfiguration gibt es zwei Methoden: eine API, über die Änderungen an NGINX Plus übertragen werden können, und DNS, das NGINX Plus kontinuierlich auf Änderungen an der Anzahl der mit einem Domainnamen verknüpften Knoten überprüft. In dieser NGINX Plus-Demo wird diese Methode zur Integration in die integrierte Serviceerkennung von Swarm verwendet.
• Live-Aktivitätsüberwachung – Stellt eine API zum Abrufen umfangreicher Metriken von NGINX Plus sowie ein auf der API basierendes Web-Dashboard bereit, in dem Sie die Metriken anzeigen und Backend-Server hinzufügen, entfernen und ändern können.

In der oben beschriebenen NGINX Open Source-Konfiguration verteilt der Swarm-Load-Balancer sowohl externe Anfragen auf die Backend-Container als auch Service-zu-Service-Anfragen zwischen ihnen. NGINX übernimmt dabei die SSL/TLS-Terminierung.

Bei Verwendung von NGINX Plus erreichen Clientanfragen von externen Clients zunächst den Swarm-Load-Balancer, das eigentliche Load-Balancing zu den Backend-Containern übernimmt jedoch NGINX Plus (Abbildung 6). Indem Clientanfragen zuerst den Swarm-Load-Balancer erreichen, lässt sich auf einfache Weise eine hohe Verfügbarkeit von NGINX Plus gewährleisten.

Abbildung 6. Der Docker-Swarm-Load-Balancer leitet Clientanfragen an NGINX Plus weiter, das sie auf die Serviceinstanzen verteilt

In ähnlicher Weise empfängt der Swarm-Load-Balancer dienstübergreifende Anfragen, doch NGINX Plus verteilt sie tatsächlich auf die Dienste (Abbildung 7).

Abbildung 7. Der Docker-Swarm-Load-Balancer leitet dienstübergreifende Anfragen an NGINX Plus weiter, das sie auf die Dienstinstanzen verteilt

Demonstrationen

Um einige Beispiele für die Verwendung von Swarm zum Docker-Lastausgleich mit und ohne NGINX zu geben, habe ich drei Demonstrationen erstellt. Alle Dateien für diese Demonstrationen sind auf GitHub verfügbar, zusammen mit ausführlichen Anleitungen. Die drei Demonstrationen sind:

• Docker-Swarm-Lastverteilung
• Docker-Swarm-Lastverteilung mit NGINX Open Source
• Docker-Swarm-Lastverteilung mit NGINX Plus

Docker-Swarm-Lastverteilung

Dies demonstriert den Lastenausgleich von Anfragen an das Backend einer einfachen Webanwendung mit Docker Swarm – ohne NGINX oder NGINX Plus.

Docker-Swarm-Lastverteilung mit NGINX Open Source

Diese Demo ergänzt NGINX Open Source, um die SSL/TLS-Terminierung für externe Anfragen zu übernehmen. Der Swarm-Load-Balancer verteilt Anfragen an dasselbe einfache Web-App-Backend wie in der vorherigen Demo und verarbeitet interne Anfragen zwischen Diensten.

Docker-Swarm-Lastverteilung mit NGINX Plus

Diese Demo besteht aus zwei Teilen. Im ersten Teil kommt NGINX Plus zum Einsatz, das neben der SSL/TLS-Terminierung Anfragen direkt auf die Backend-Container verteilt und auch interne Anfragen zwischen Diensten verarbeitet. Es ist in die Diensterkennung von Swarm integriert und verwendet dynamisches DNS, um den mit den Backends verknüpften Domainnamen regelmäßig neu aufzulösen. NGINX Plus verteilt die Last auf zwei Backend-Dienste: Service1 und Service2. Interne Anfragen zwischen Diensten werden veranschaulicht, indem Service1 eine Anfrage an Service2 sendet.

Abbildung 8. NGINX Plus nutzt beim Lastenausgleich für Backend-Dienste den dynamischen DNS-Diensterkennungsmechanismus von Swarm

Im zweiten Teil wird gezeigt, 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 Anzahl der Backend-Container nach oben oder unten zu skalieren.

Abbildung 9. Docker Swarm nutzt die Live-Aktivitätsüberwachung von NGINX Plus, um die Dienstauslastung für die automatische Skalierung zu erfassen

Zusammenfassung

Die mit Docker 1.12 eingeführten neuen Funktionen machen Swarm zu einer leistungsfähigeren Plattform. Durch den Einsatz von NGINX Open Source und insbesondere von NGINX Plus lässt sie sich jedoch noch weiter verbessern. Die Fähigkeit von NGINX Plus, die Backend-Container für den Lastausgleich über DNS dynamisch neu zu konfigurieren, sowie die von der Status-API bereitgestellte Transparenz ermöglichen eine äußerst leistungsfähige Container-Lösung.

Wenn Sie NGINX Plus ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.

Probieren Sie auch die Demos in unserem GitHub-Repository aus.

---