Erstellen eines Docker Swarms auf Azure mit Terraform, Teil 1

13. Oktober 2020

Tobias Fenster

Dieser Blogbeitrag ist ein Repost und stammt im Original aus dem Know-how-Bereich von TechWiese, dessen Artikel in diesem Blog aufgegangen sind.

Die Nutzung von Containern in Microservice-Architekturen wie auch Lift-and-Shift-Szenarien ist mittlerweile etablierte Praxis und auch die Nutzung von Windows-basierten Containern gewinnt an Bedeutung. Sehr schnell kommt man dabei an die Stelle, dass mehrere Container gemeinsam arbeiten müssen und eine Orchestrierung notwendig ist. Wenn es einmal nicht Kubernetes sein soll, dann kann Docker Swarm eine sehr valide Alternative sein und in diesem Beitrag soll gezeigt werden, wie mittels des Terraform Azure-Providers schnell und einfach ein solcher Swarm auf Azure aufgebaut werden kann.

Das TL;DR

Docker Swarm ist der Container-Orchestrator, der von Docker selbst bereitgestellt wird und es Ihnen ermöglicht, mehrere virtuelle Maschinen zu einem Cluster namens "Swarm" zusammenzubringen, auf dem Sie Docker-Container laufen lassen können. Indem ich Azure Virtual Machine Scale Sets im Hintergrund verwende, kann ich sehr einfach Maschinen (oder "Knoten") zu diesem Swarm hinzufügen und entfernen oder ihn sogar automatisch skalieren lassen. Um den Einsatz zu automatisieren, habe ich terraformverwendet, ein Infrastructure as Code (IaC)-Tool, das es mir erlaubt, die benötigte Azure-Infrastruktur zu definieren, terraform apply auszuführen, ein wenig zu warten und damit meinen Swarm zum Laufen zu bringen. Die gesamte Architektur ist etwas komplexer, da sie unter anderem auch einen Azure Files Share, einen Azure Load Balancer und einen Azure Key Vault enthält, aber insgesamt ist das alles. Ich gehe davon aus, dass derjenige, der diese Infrastruktur verwendet, etwas über das Web bereitstellen will, und ein Verwaltungswerkzeug für den Swarm sollte sich als nützlich erweisen, daher habe ich standardmäßig Traefik als Reverse-Proxy und Portainer als Container-Verwaltungswerkzeug hinzugefügt.

Um die Umgebung einfach so zu benutzen, wie ich sie vorgesehen habe, sind folgende Schritte notwendig:

• Vorbedingungen:
  • Stellen Sie sicher, dass Sie sowohl Azure CLIinstalliert als auch terraform installiert haben.
  • Stellen Sie sicher, dass Sie einen öffentlichen SSH-Schlüssel in $HOME\.ssh\id_rsa.pub zur Verfügung haben, da dieser hochgeladen wird. Wenn Sie keinen haben, können Sie den Anweisungen hier folgen, um einen zu erstellen. Beachten Sie, dass in der Dokumentation von Linux-VMs die Rede ist, aber es funktioniert auch mit den Windows-VMs in meinem Setup.
• Führen Sie git clone https://github.com/cosmoconsult/azure-swarm aus, um mein Setup zu erhalten.
• Öffnen Sie die Datei variables.tf im Unterordner tf und ändern Sie den Standardwert für die Variable eMail auf Ihre eMail-Adresse.
• Öffnen Sie ein cmd oder eine PowerShell und gehen Sie in den Unterordner tf.
• Führen Sie az login aus, um sich in Ihr Azure-Konto einzuloggen
• Wenn Sie mehrere Subscriptions haben, können Sie az account set --subscription="<subscription-id>" ausführen, um die gewünschte auszuwählen.
• Führen Sie terraform init aus, um Terraform zu initialisieren
• Führen Sie terraform apply -auto-approve aus, um die Infrastruktur aufzubauen

Nach ein paar Minuten sollten Sie in etwa so etwas sehen:

Apply complete! Resources: 47 added, 0 changed, 0 destroyed.

Outputs:

password = 2kwVQZlc2xOj%cfL
portainer = https://swarm-bbzavtmk.westeurope.cloudapp.azure.com/portainer/
ssh-copy-private-key = If you know what you are doing (this is copying your PRIVATE ssh key): ssh -l VM-Administrator swarm-bbzavtmk-ssh.westeurope.cloudapp.azure.com "mkdir c:\users\VM-Administrator\.ssh"; scp $HOME\.ssh\id_rsa VM-Administrator@swarm-bbzavtmk-ssh.westeurope.cloudapp.azure.com:c:\users\VM-Administrator\.ssh
ssh-to-jumpbox = ssh -l VM-Administrator swarm-bbzavtmk-ssh.westeurope.cloudapp.azure.com

Wenn Sie zu der in Zeile 6 angegebenen URL gehen (Ihre wird etwas anders sein, weil die acht Buchstaben nach swarm- zufällig generiert sind) und als Benutzername admin sowie das Passwort in Zeile 5 eingeben (auch das wird natürlich bei Ihnen ein anderes sein), dann haben Sie das Admin-Interface von portainer, das Ihren Swarm mit drei Manager-Knoten und zwei Worker-Knoten zeigen sollte.

Die Einzelheiten: Die Basiskomponenten und die Gesamtarchitektur

Ich möchte Ihnen nicht die Basiskomponenten vorstellen, die ich verwendet habe, denn jede von ihnen bietet eine sehr gute Dokumentation:

• Docker gibt eine Einführung in die Schlüsselkonzepte eines Swarms.
• Terraform hat ein sehr gutes Intro, um Ihnen eine Idee zu geben, und dann können Sie sich die Informationen und Beispiele für den Azure-Provider entweder von terraform oder von Microsoft ansehen. Nicht zuletzt gibt es eine tolle Einführung zum terraform Azure-Provider im Kontext mit Azure DevOps hier.
• Traefik hat eine sehr schöne Dokumentation, die Ihnen einen schnellen Einstieg ermöglicht
• Portainer ist auf der Dokumentation-Seite eigentlich etwas dünn, aber sehr intuitiv zu bedienen

Die vereinfachte Übersicht sieht wie folgt aus:

Entschuldigung, ich konnte nicht widerstehen, das zu zeigen :) Natürlich handelt es sich hierbei nicht um eine vereinfachte Übersicht, sondern vielmehr um die vollständige Einrichtung, die mit dem großartigen ARM Template Viewer visualisiert wird. Nun zu einer wirklich vereinfachten Übersicht:

Sie können sehen, dass ich eine Jumpbox für den administrativen Zugriff verwende, was bedeutet, dass ich eine dedizierte VM habe, um Zugriff auf das Terminal auf jeder der beteiligten virtuellen Maschinen zu erhalten, da keine von ihnen direkt erreicht werden kann. Dies ist eine Sicherheitsmaßnahme, um es Angreifern zu erschweren, Zugang zum System zu erhalten. Als grundlegendste, aber auch effizienteste Möglichkeit, Ihre Umgebung zu sichern, können Sie die Jumpbox abschalten, wenn sie nicht benötigt wird, und dann gibt es buchstäblich keinen direkten Weg zu irgendeiner der Maschinen. Um die Sicherheit weiter zu verbessern, kann die Jumpbox nur über SSH mit einer Kombination aus privatem und öffentlichem Schlüssel erreicht werden. Als Teil der Terraform-Bereitstellung wird Ihr öffentlicher Schlüssel in den Azure Key Vault hochgeladen, und wenn die Jumpbox startet, lädt sie den Schlüssel aus dem Key Vault herunter und legt ihn an der richtigen Stelle ab, so dass Sie, wenn Sie später versuchen, sich mit Ihrem privaten Schlüssel zu verbinden, so einfach wie mit dem in Zeile 8 oben gezeigten ssh-to-jumpbox-Befehl eine Verbindung herstellen können, ohne ein Passwort angeben zu müssen. Das bedeutet auch, dass niemand Ihr Passwort erraten oder über brute-force-Attacken finden kann...

Wenn Sie Hilfe beim Einrichten der SSH-Schlüssel benötigen, sehen Sie in Microsofts Dokumentation zur OpenSSH-Schlüsselverwaltung nach. In der obigen Übersicht können Sie auch sehen, dass ein Azure Load Balancer verwendet wird, um den in den Swarm eingehenden Web-Traffic zu verteilen. Der Load Balancer ist mit drei Manager-VMs verbunden, aber dazu später mehr. Der Swarm ist auch mit dem Azure Key Vault verbunden, um die Swarm-Join-Token zu verwalten. Das sind Geheimnisse, die benötigt werden, um dem Swarm beizutreten. Der erste Manager initialisiert den Swarm und legt dieses Token in den Key Vault, die anderen Knoten erhalten sie von dort. Dies geschieht ohne Passwörter, stattdessen wird den VMs eine verwaltete Identität zugewiesen, die wiederum Lesezugriff (oder Lesen und Schreiben im Falle des ersten Managers) auf den Key Vault erhält. Die letzte Komponente, die Sie sehen können, ist der Azure Files Share, der als Laufwerk für alle VMs mit Ausnahme der Jumpbox gemountet ist und Konfigurationsdateien etc. speichert, die für alle Swarmknoten relevant sind. Der Swarm selbst sieht wie folgt aus:

Docker Swarm hat Manager, die die in diesem Swarm laufenden Services kontrollieren und verwalten, wobei jeder Service 1-n Tasks hat, was letztlich die Container sind. Und es gibt Worker in einem Docker Swarm, in denen die Container laufen, die die eigentlichen Workloads enthalten.

Die Manager sind drei separate Azure Virtual Machines, die Teil eines Verfügbarkeitssets sind und alle vom Load Balancer angesprochen werden. Aus mehreren Gründen, die ich später erläutern werde, habe ich keine gute Möglichkeit gefunden, für diesen Teil ein Azure Virtual Machine Scale Set zu verwenden, obwohl es eigentlich sehr sinnvoll wäre. Wegen der Art wie das Docker Swarm Eingangsnetzwerk ("ingress") funktioniert, ist es egal, auf welchem dieser Manager der Reverse-Proxy Traefik läuft, er bekommt immer die eingehenden Anfragen. Er nimmt sie dann entgegen und leitet sie an die richtigen Container weiter, die auf den Workern laufen, die wiederum ein Azure Virtual Machine Scale Set sind. Das ist wichtig, denn es bringt uns buchstäblich einen Schieberegler, um die Anzahl der VMs im Skalensatz zu skalieren. Viel einfacher geht es nicht, oder?

Portainer läuft auch auf einem der Manager, weil Swarm-Management nur dort möglich ist.

Damit hoffe ich, dass Sie einen guten Überblick über meinen Aufbau bekommen haben. In einem folgenden Beitrag werde ich mehr über die technischen Details, Konfigurationen und Skripte erklären.

Hinweis: Dieser Post ist ursprünglich auf Englisch auf dem Blog des Authors erschienen.