Hochfahren der Softwarebereitstellung – Ein Docker Swarm-Tutorial

Sofern Sie nicht in einem Schiffscontainer gelebt haben, haben Sie wahrscheinlich schon von Containern gehört. Die Branche hat einen deutlichen Schritt weg von einer dauerhaften hin zu einer flüchtigen Infrastruktur gemacht, und Container befinden sich mittendrin in diesem Schritt. Der Grund ist ganz einfach: Während Container Entwicklerteams sicherlich dabei helfen, schnell einsatzbereit zu sein, haben sie noch mehr Potenzial, das Erscheinungsbild des Betriebs vollständig zu verändern.

Aber wie sieht das genau aus? Was passiert, wenn Sie bereit sind, Container lokal oder manuell auf einigen wenigen Servern auszuführen? In einer idealen Welt möchten Sie Ihre Anwendung einfach auf einen Cluster von Servern werfen und sagen: „Run it!“

Zum Glück sind wir heute da.

In diesem Artikel werden wir untersuchen, was Docker Swarm ist, zusammen mit einigen der großartigen Funktionen, die es zu bieten hat. Dann werfen wir einen Blick darauf, wie die tatsächliche Verwendung des Swarm-Modus und die Bereitstellung in einem Schwarm aussehen, und wir schließen mit einigen Beispielen ab, wie der tägliche Betrieb mit einem bereitgestellten Schwarm aussieht. Grundlegende Kenntnisse über Docker und Container werden auf jeden Fall empfohlen, aber Sie können sich zuerst diesen hervorragenden Blog-Beitrag ansehen, wenn Container neu für Sie sind.

Was ist Docker Swarm?

Bevor wir uns mit der Erstellung und Bereitstellung für unseren ersten Schwarm befassen, ist es hilfreich, eine Vorstellung davon zu haben, was Docker Swarm ist. Docker selbst gibt es schon seit Jahren, und die meisten Leute betrachten es heute als Container-Laufzeit. Tatsächlich besteht Docker jedoch aus vielen verschiedenen Teilen, die alle zusammenarbeiten. Dieser Container-Laufzeitteil wird beispielsweise von zwei kleineren Komponenten namens runC und containerd verwaltet. Während sich Docker weiterentwickelt und der Community zurückgegeben hat, haben sie festgestellt, dass das Erstellen dieser kleineren Komponenten der beste Weg ist, um schnell zu wachsen und Funktionen hinzuzufügen. Als solches haben wir jetzt SwarmKit und den Swarm-Modus, der direkt in Docker integriert ist.

Docker Swarm ist eine Container-Orchestrierungs-Engine. Auf hoher Ebene werden mehrere Docker-Engines benötigt, die auf verschiedenen Hosts ausgeführt werden, und Sie können sie gemeinsam verwenden. Die Verwendung ist einfach: Deklarieren Sie Ihre Anwendungen als Stapel von Diensten und lassen Sie Docker den Rest erledigen. Dienste können alles sein, von Anwendungsinstanzen bis hin zu Datenbanken oder Dienstprogrammen wie Redis oder RabbitMQ. Dies sollte Ihnen bekannt vorkommen, wenn Sie jemals in der Entwicklung mit docker-compose gearbeitet haben, da es sich um genau dasselbe Konzept handelt. Tatsächlich ist eine Stack-Deklaration buchstäblich nur eine docker-compose.yml Datei mit der Syntax der Version 3.1. Das bedeutet, dass Sie eine ähnliche (und in vielen Fällen identische) Compose-Konfiguration für Entwicklung und Swarm-Bereitstellung verwenden können, aber ich greife hier etwas vor. Was passiert, wenn Sie Instanzen von Docker im Swarm-Modus haben?

Fallen Sie nicht vom Floß

Wir haben zwei Arten von Knoten (Servern) in der Swarm-Welt: Manager und Arbeiter. Es ist wichtig zu bedenken, dass Manager auch Arbeiter sind, sie haben nur die zusätzliche Verantwortung, die Dinge am Laufen zu halten. Jeder Schwarm beginnt mit einem als Anführer bezeichneten Manager-Knoten. Von dort aus müssen Sie nur noch einen Befehl ausführen, um Knoten sicher zum Schwarm hinzuzufügen.

Swarm ist dank der Implementierung des Raft-Algorithmus hochverfügbar. Ich werde auf Raft nicht zu sehr ins Detail gehen, da es bereits ein großartiges Tutorial zur Funktionsweise gibt, aber hier ist die allgemeine Idee: Der Leader-Knoten meldet sich ständig bei seinen anderen Manager-Knoten und synchronisiert deren Zustände. Damit eine Zustandsänderung „akzeptiert“ wird, erreichen die Manager-Knoten einen Konsens, der eintritt, wenn eine Mehrheit der Knoten die Zustandsänderung anerkennt.

Das Schöne daran ist, dass Manager-Knoten sporadisch abfallen können, ohne den Konsens des Schwarms zu gefährden. Wenn eine Zustandsänderung einen Konsens erzielt, wissen wir, dass sie garantiert auf einer Mehrheit der Manager-Knoten vorhanden ist und auch dann bestehen bleibt, wenn der aktuelle Leader ausfällt.

Nehmen wir an, wir haben drei Manager-Knoten namens A, B und C. Natürlich ist A unser furchtloser Anführer. Nun, eines Tages schlägt ein vorübergehender Netzwerkfehler A offline und lässt B und C allein. Nachdem sie längere Zeit nichts von A gehört haben (einige hundert Millisekunden), warten B und C eine zufällig generierte Zeit, bevor sie sich zur Wahl stellen und den anderen benachrichtigen. Natürlich wird in diesem Fall der erste gewählt, der sich zur Wahl stellt. In diesem Beispiel wird B der neue Leiter und ein Quorum wird wiederhergestellt. Aber dann, Plot Twist: Was passiert, wenn A wieder online geht? Es wird denken, dass es immer noch der Anführer ist, richtig? Jeder Wahl ist eine Amtszeit zugeordnet, also wurde A tatsächlich in Amtszeit 1 gewählt. Sobald A wieder online ist und anfängt, B und C herumzukommandieren, teilen sie ihm freundlicherweise mit, dass B der Anführer von Amtszeit 2 ist, und A tritt zurück.

Derselbe Prozess funktioniert natürlich in einem viel größeren Maßstab. Sie können viel mehr als drei Manager-Knoten haben. Ich werde jedoch eine weitere kurze Anmerkung hinzufügen. Jeder Schwarm kann nur eine bestimmte Anzahl an Managerverlusten hinnehmen. Ein Schwarm von n Managerknoten kann (n-1)/2 Manager verlieren, ohne das Quorum zu verlieren. Das bedeutet, dass Sie bei einem Schwarm aus drei Managern einen verlieren können, bei fünf können Sie zwei verlieren usw. Der zugrunde liegende Grund dafür liegt in der Idee des Mehrheitskonsenses, und das ist definitiv etwas, das Sie im Hinterkopf behalten sollten, wenn Sie in die Produktion gehen.

Aufgabenplanung und -abstimmung

Bisher haben wir festgestellt, dass unsere Manager wirklich gut darin sind, synchron zu bleiben. Toll! Aber was machen sie eigentlich? Erinnern Sie sich, wie ich sagte, dass Sie einen Stapel von Diensten für Swarm bereitstellen? Wenn Sie Ihre Dienste deklarieren, geben Sie Swarm wichtige Informationen darüber, wie Ihre Dienste tatsächlich ausgeführt werden sollen. Dazu gehören Parameter wie die Anzahl der Replikate, die Sie von jedem Dienst wünschen, wie die Replikate verteilt werden sollen, ob sie nur auf bestimmten Knoten ausgeführt werden sollen und vieles mehr.

Sobald ein Dienst bereitgestellt ist, ist es die Aufgabe der Manager, sicherzustellen, dass alle von Ihnen festgelegten Bereitstellungsanforderungen weiterhin erfüllt werden. Angenommen, Sie stellen einen Nginx-Dienst bereit und geben an, dass es drei Replikate geben soll. Die Manager sehen, dass keine Container ausgeführt werden, und verteilen die drei Container gleichmäßig auf die verfügbaren Knoten.

Noch cooler ist jedoch, dass der Swarm automatisch Container auf den verbleibenden Knoten erstellt, wenn ein Container ausfallen sollte (oder ein ganzer Knoten offline gehen sollte), um den Unterschied auszugleichen. Wenn Sie sagen, dass Sie drei Container ausführen möchten, werden drei Container ausgeführt, während Swarm alle wesentlichen Details übernimmt. Außerdem – und das ist ein großes Plus – ist das Hoch- oder Herunterskalieren so einfach wie das Vergeben einer neuen Replikationseinstellung für Swarm.

Diensterkennung und Lastenausgleich

Ich möchte auf ein wichtiges, aber subtiles Detail dieses letzten Beispiels hinweisen: Wenn Swarm Container auf intelligenten Knoten seiner Wahl startet, wissen wir nicht unbedingt, wo diese Container ausgeführt werden. Das mag zunächst beängstigend klingen, ist aber tatsächlich eines der mächtigsten Features von Swarm.

Um dasselbe Nginx-Beispiel fortzusetzen, stellen Sie sich vor, wir hätten Docker gesagt, dass diese Container Port 80 verfügbar machen sollten. Wenn Sie Ihren Browser auf einen Knoten verweisen, auf dem dieser Container auf Port 80 ausgeführt wird, sehen Sie den Inhalt dieses Containers. Da gibt es keine Überraschung. Was jedoch überraschen mag, ist, dass Sie immer noch denselben Inhalt sehen, wenn Sie Ihre Anfrage an einen Knoten senden, der diesen Container nicht ausführt! Was passiert hier?

Swarm verwendet tatsächlich ein Ingress-Netzwerk, um Ihre Anfrage an einen verfügbaren Knoten zu senden, auf dem dieser Container ausgeführt wird, und gleicht ihn gleichzeitig aus. Wenn Sie also drei Anfragen an denselben Knoten stellen, werden Sie wahrscheinlich auf die drei verschiedenen Container treffen. Solange Sie die IP eines einzelnen Knotens im Schwarm kennen, können Sie auf alles zugreifen, was darin läuft. Umgekehrt können Sie auf diese Weise einen Load Balancer (z. B. einen ELB) auf alle Knoten im Schwarm richten, ohne sich Gedanken darüber machen zu müssen, was wo ausgeführt wird.

Es hört nicht bei externen Verbindungen auf. Dienste, die auf demselben Stack ausgeführt werden, verfügen über ein Overlay-Netzwerk, über das sie miteinander kommunizieren können. Anstatt IP-Adressen in Ihrem Code fest zu codieren, können Sie einfach den Namen des Dienstes als Hostnamen verwenden, zu dem Sie eine Verbindung herstellen möchten. Wenn Ihre App beispielsweise mit einem Redis-Dienst namens „redis“ kommunizieren muss, kann sie einfach „redis“ als Hostnamen verwenden und Swarm leitet seine Anfrage an den entsprechenden Container weiter. Und da dies in der Entwicklung mit Docker-Compose und in der Produktion mit Docker Swarm nahtlos funktioniert, müssen Sie sich bei der Bereitstellung Ihrer App keine Gedanken mehr machen.

Laufende Updates

Wenn Sie im Einsatz sind, haben Sie wahrscheinlich eine Panikattacke erlebt, wenn ein Produktionsupdate fürchterlich schief geht. Es könnte ein fehlerhaftes Code-Update oder auch nur ein Konfigurationsfehler sein, aber plötzlich steht die Produktion still! Die Chancen stehen gut, dass sich der Chef so oder so nicht darum kümmern wird. Sie werden einfach wissen, dass es deine Schuld ist. Machen Sie sich keine Sorgen, Swarm hält auch hier Ihren Rücken.

Beim Aktualisieren eines Dienstes können Sie festlegen, wie viele Container gleichzeitig aktualisiert werden sollen und was passieren soll, wenn die neuen Container ausfallen. Ab einem bestimmten Schwellenwert kann Swarm entweder das Update stoppen oder (ab Docker 17.04) die Container auf das vorherige Image und die vorherigen Einstellungen zurücksetzen. Machen Sie sich keine Sorgen, dass Sie Ihrem Chef morgen früh einen Kaffee bringen müssen.

Sicherheit

Zu guter Letzt verfügt Docker Swarm über hervorragende Sicherheitsfunktionen, die sofort einsatzbereit sind. Wenn ein Knoten dem Schwarm beitritt, verwendet er ein Token, das sich nicht nur selbst verifiziert, sondern auch bestätigt, dass er dem Schwarm beitritt, für den Sie ihn halten. Von diesem Moment an findet die gesamte Kommunikation zwischen den Knoten unter Verwendung einer gegenseitigen TLS-Verschlüsselung statt. Diese Verschlüsselung wird vollständig automatisch vom Swarm bereitgestellt und verwaltet, sodass Sie sich nie um die Erneuerung von Zertifikaten und andere typische Sicherheitsprobleme kümmern müssen. Und wenn Sie eine Schlüsselrotation erzwingen möchten, gibt es natürlich einen Befehl dafür.

Die neueste Version von Docker Swarm verfügt außerdem über eine integrierte Secrets-Verwaltung. Auf diese Weise können Sie Geheimnisse wie Schlüssel und Kennwörter sicher für die Dienste bereitstellen, die sie benötigen, und nur für die Dienste, die sie benötigen. Wenn Sie einen Dienst mit einem Geheimnis bereitstellen, wird in den Containern für diesen Dienst eine spezielle Datei in ihrem Dateisystem bereitgestellt, die den Wert des Geheimnisses enthält. Es versteht sich von selbst, aber dies ist viel sicherer als die Verwendung von Umgebungsvariablen, die der traditionelle Ansatz waren.

Eintauchen in den Schwarm

Wenn Sie so etwas wie ich sind, juckt es Sie, hineinzuspringen und all diese Funktionen auszuprobieren! Lassen Sie uns also ohne weiteres eintauchen!

Docker Swarm-Beispiel-App

Ich habe eine sehr rudimentäre Flask-App erstellt, um die Leistungsfähigkeit und Benutzerfreundlichkeit von Docker Swarm zu demonstrieren. Die Web-App zeigt einfach eine Seite an, die Ihnen mitteilt, welcher Container Ihre Anfrage bedient hat, wie viele Anfragen insgesamt bedient wurden und wie das „geheime“ Datenbankpasswort lautet.

Es ist in drei Dienste unterteilt: die eigentliche Flask-App, einen Nginx-Reverse-Proxy und einen Redis-Keystore. Bei jeder Anfrage erhöht die App den Schlüssel num_requests in Redis, sodass unabhängig davon, welche Flask-Instanz Sie treffen, die richtige Anzahl von Anfragen angezeigt wird.

Der gesamte Quellcode ist auf GitHub verfügbar, wenn Sie „auschecken“ möchten, was vor sich geht.

Spielen Sie mit Docker!

Fühlen Sie sich frei, Ihre eigenen Server zu verwenden, während Sie dieses Tutorial durcharbeiten, aber ich empfehle dringend, play-with-docker.com zu verwenden, wenn Sie einfach einsteigen möchten. Es ist eine Website, die von einigen Docker-Entwicklern betrieben wird, mit der Sie mehrere vernetzte Server erstellen können Knoten, auf denen Docker vorinstalliert ist. Sie werden nach vier Stunden heruntergefahren, aber das reicht für dieses Beispiel!

Erstellen eines Schwarms

Okay, los geht's! Machen Sie weiter und erstellen Sie drei Instanzen in PWD (Play-with-Docker) oder starten Sie drei Server in Ihrem bevorzugten VPS-Dienst (Virtual Private Server) und installieren Sie die Docker-Engine auf allen. Denken Sie daran, dass Sie jederzeit ein Image erstellen und dieses beim Hinzufügen von Knoten in der Zukunft wiederverwenden können. Es gibt in Bezug auf die Software keinen Unterschied zwischen einem Manager-Knoten und einem Worker-Knoten, sodass Sie nicht zwei verschiedene Images verwalten müssen.

Dreht sich immer noch? Keine Sorge, ich warte. Okay, jetzt erstellen wir unseren ersten Manager- und Leader-Knoten. Initialisieren Sie bei Ihrer ersten Instanz einen Schwarm:

 docker swarm init --advertise-addr <node ip here>

Ersetzen Sie <node_ip_here> durch die IP-Adresse Ihres Knotens. Auf PWD wird die IP-Adresse oben angezeigt, und wenn Sie Ihren eigenen VPS verwenden, können Sie die private IP-Adresse Ihres Servers verwenden, solange sie von den anderen Knoten in Ihrem Netzwerk aus zugänglich ist.

Sie haben jetzt einen Schwarm! Es ist jedoch ein ziemlich langweiliger Schwarm, da es nur einen Knoten hat. Lassen Sie uns fortfahren und die anderen Knoten hinzufügen. Sie werden feststellen, dass beim Ausführen von init eine lange Meldung angezeigt wurde, in der erklärt wird, wie das Join-Token verwendet wird. Wir werden diesen nicht verwenden, weil er die anderen Knoten zu Arbeitern machen würde, und wir wollen, dass sie Manager sind. Lassen Sie uns das Join-Token für einen Manager abrufen, indem Sie dies auf dem ersten Knoten ausführen:

 docker swarm join-token manager

Kopieren Sie den resultierenden Befehl und führen Sie ihn auf Ihrem zweiten und dritten Knoten aus. Seht, ein Drei-Knoten-Schwarm! Lassen Sie uns überprüfen, ob alle unsere Knoten wirklich existieren. Der Befehl docker node ls listet alle Knoten in unserem Schwarm auf. Sie sollten so etwas sehen:

 $ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS su1bgh1uxqsikf1129tjhg5r8 * node1 Ready Active Leader t1tgnq38wb0cehsry2pdku10h node3 Ready Active Reachable wxie5wf65akdug7sfr9uuleui node2 Ready Active Reachable

Beachten Sie, dass unser erster Knoten ein Sternchen neben der ID hat. Das sagt uns einfach, dass dies der Knoten ist, mit dem wir gerade verbunden sind. Wir können auch sehen, dass dieser Knoten derzeit der Anführer ist und die anderen Knoten erreichbar sind, wenn ihm etwas passieren sollte.

Nehmen Sie sich einen Moment Zeit, um zu verstehen, wie einfach das war, und lassen Sie uns unsere erste App bereitstellen!

Es versenden!

Gerade eben hat das Business Development Team einem Kunden versprochen, dass seine neue App innerhalb einer Stunde bereitgestellt und fertig sein würde! Typisch, ich weiß. Aber keine Angst, wir werden nicht annähernd so viel Zeit brauchen, da es mit Docker erstellt wurde! Die Entwickler waren so freundlich, uns ihre docker-compose Datei zu leihen:

 version: '3.1' services: web: image: lsapan/docker-swarm-demo-web command: gunicorn --bind 0.0.0.0:5000 wsgi:app deploy: replicas: 2 secrets: - db_password nginx: image: lsapan/docker-swarm-demo-nginx ports: - 8000:80 deploy: mode: global redis: image: redis deploy: replicas: 1 secrets: db_password: external: true

Wir werden es gleich aufschlüsseln, aber dafür ist noch keine Zeit. Bringen wir es zum Einsatz! Fahren Sie fort und erstellen Sie auf Ihrem ersten Knoten eine Datei mit dem Namen docker-compose.yml und füllen Sie sie mit der obigen Konfiguration. Sie können dies ganz einfach mit echo "<pasted contents here>" > docker-compose.yml .

Normalerweise könnten wir dies einfach bereitstellen, aber unsere Konfiguration erwähnt, dass wir ein Geheimnis namens db_password , also erstellen wir dieses Geheimnis schnell:

 echo "supersecretpassword" | docker secret create db_password -

Toll! Jetzt müssen wir Docker nur noch sagen, dass es unsere Konfiguration verwenden soll:

 docker stack deploy -c docker-compose.yml demo

Wenn Sie diesen Befehl ausführen, sehen Sie, wie Docker die drei von uns definierten Dienste erstellt: web , nginx und redis . Da wir unseren Stack jedoch Demo genannt haben, heißen unsere Dienste tatsächlich demo_web , demo_nginx und demo_redis . Wir können unsere laufenden Dienste anzeigen, indem wir den Befehl docker service ls ausführen, der in etwa so aussehen sollte:

 $ docker service ls ID NAME MODE REPLICAS IMAGE PORTS cih6u1t88vx7 demo_web replicated 2/2 lsapan/docker-swarm-demo-web:latest u0p1gd6tykvu demo_nginx global 3/3 lsapan/docker-swarm-demo-nginx:latest *:8000->80/ tcp wa1gz80ker2g demo_redis replicated 1/1 redis:latest

Voila! Docker hat unsere Images auf die entsprechenden Knoten heruntergeladen und Container für unsere Dienste erstellt. Wenn Ihre Replikate noch nicht voll ausgelastet sind, warten Sie einen Moment und prüfen Sie erneut. Docker lädt die Images wahrscheinlich immer noch herunter.

Sehen ist Glauben

Nehmen Sie jedoch nicht mein Wort (oder Dockers Wort) dafür. Versuchen wir, eine Verbindung zu unserer App herzustellen. Unsere Dienstkonfiguration weist Docker an, NGINX auf Port 8000 bereitzustellen. Wenn Sie PWD verwenden, sollte oben auf der Seite ein blauer Link mit der Aufschrift „8000“ vorhanden sein. PWD hat tatsächlich automatisch erkannt, dass auf diesem Port ein Dienst läuft! Klicken Sie darauf, und Sie werden zum ausgewählten Knoten auf Port 8000 geleitet. Wenn Sie Ihre eigenen Server gerollt haben, navigieren Sie einfach zu einer der IPs Ihrer Server auf Port 8000.

Sie werden mit einem schön gestalteten Bildschirm begrüßt, der Ihnen einige grundlegende Informationen gibt:

Notieren Sie sich, welcher Container Ihre Anfrage bedient hat, und aktualisieren Sie dann die Seite. Chancen sind es geändert. Aber warum? Nun, wir haben Docker angewiesen, zwei Replikate unserer Flask-App zu erstellen, und es verteilt Anfragen an diese beiden Instanzen. Du hast gerade beim zweiten Mal den anderen Container getroffen. Sie werden auch feststellen, dass die Anzahl der Anfragen gestiegen ist, weil beide Flask-Container mit der einzelnen von uns angegebenen Redis-Instanz kommunizieren.

Sie können gerne versuchen, Port 8000 von einem beliebigen Knoten aus zu erreichen. Sie werden weiterhin ordnungsgemäß zur App weitergeleitet.

Die Magie entmystifizieren

An diesem Punkt funktioniert alles und hoffentlich war der Prozess schmerzlos! Schauen wir uns diese docker-compose.yml Datei genauer an und sehen, was wir Docker tatsächlich gesagt haben. Auf hoher Ebene sehen wir, dass wir drei Dienste definiert haben: web , nginx und redis . Genau wie eine normale Compose-Datei haben wir Docker mit einem Image versehen, das für jeden Dienst verwendet werden kann, sowie mit einem auszuführenden Befehl. Im Fall von nginx haben wir außerdem angegeben, dass Port 8000 auf dem Host Port 80 im Container zugeordnet werden soll. All dies ist bisher die Standard-Compose-Syntax.

Neu sind hier die Schlüssel deploy und secrets. Diese Schlüssel werden von docker-compose ignoriert, sodass sie sich nicht auf Ihre Entwicklungsumgebung auswirken, aber von docker stack verwendet werden. Schauen wir uns den Webservice an. Einfach genug, wir teilen Docker mit, dass wir zwei Replikate unserer Flask-App ausführen möchten. Wir teilen Docker auch mit, dass der Webdienst das Geheimnis db_password benötigt. Dadurch wird sichergestellt, dass der Container eine Datei mit dem Namen /run/secrets/db_password enthält, die den Wert des Geheimnisses enthält.

Wenn wir nach unten zu Nginx gehen, können wir sehen, dass der Bereitstellungsmodus auf global eingestellt ist. Der Standardwert (der implizit im Web verwendet wird) ist replicated , was bedeutet, dass wir angeben, wie viele Replikate wir wollen. Wenn wir global angeben, teilt es Docker mit, dass jeder Knoten im Schwarm genau eine Instanz des Dienstes ausführen soll. Führen Sie docker service ls erneut aus, Sie werden feststellen, dass nginx drei Replikate hat, eines für jeden Knoten in unserem Schwarm.

Schließlich haben wir Docker angewiesen, irgendwo im Schwarm eine einzelne Instanz von Redis auszuführen. Es spielt keine Rolle, wo, da unsere Webcontainer automatisch dorthin geleitet werden, wenn sie den Redis-Host anfordern.

Swarm Tag für Tag verwenden

Herzlichen Glückwunsch zur Bereitstellung Ihrer ersten App in einem Docker Swarm! Nehmen wir uns einen Moment Zeit, um einige häufig verwendete Befehle zu überprüfen.

Inspektion Ihres Schwarms

Müssen Sie Ihre Dienste überprüfen? Probieren Sie docker service ls und docker service ps <service name> . Ersteres zeigt Ihnen einen allgemeinen Überblick über jeden Dienst, und letzteres gibt Ihnen Informationen zu jedem Container, der für den angegebenen Dienst ausgeführt wird. Das ist besonders hilfreich, wenn Sie sehen möchten, auf welchen Knoten ein Dienst ausgeführt wird.

Laufende Updates

Was ist, wenn Sie bereit sind, eine App zu aktualisieren? Nun, das Coole an docker stack deploy ist, dass es tatsächlich auch Updates auf einen vorhandenen Stack anwendet. Angenommen, Sie haben ein neues Docker-Image in Ihr Repository gepusht. Sie können einfach denselben Bereitstellungsbefehl ausführen, den Sie beim ersten Mal verwendet haben, und Ihr Schwarm lädt das neue Image herunter und stellt es bereit.

Natürlich möchten Sie möglicherweise nicht immer jeden Dienst in Ihrem Stack aktualisieren. Auch auf Serviceebene können wir Updates durchführen. Nehmen wir an, ich habe kürzlich das Image für meinen Webdienst aktualisiert. Ich kann diesen Befehl ausgeben, um alle meine Webcontainer zu aktualisieren:

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ demo_web

Ein zusätzlicher Vorteil dieses Befehls besteht darin, dass er ein fortlaufendes Update anwendet, wenn Sie dies in Ihrer ursprünglichen Konfiguration angegeben haben. Und selbst wenn Sie dies nicht getan haben, können Sie Flags an update übergeben, die es anweisen, ein rollierendes Update wie folgt durchzuführen:

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ --update-parallelism 1 --update-delay 30s \ demo_web

Dadurch wird jeweils ein Container aktualisiert, wobei zwischen den Aktualisierungen 30 Sekunden gewartet wird.

Skalieren von Diensten nach oben oder unten

Zwei Webcontainer zu haben ist großartig, aber wissen Sie, was besser ist? Zehn haben! Das Hoch- und Herunterskalieren von Diensten in einem Schwarm ist so einfach wie:

 docker service scale demo_web=10

Führen Sie diesen Befehl aus und überprüfen Sie die Ausgabe des docker service ps demo_web . Sie werden sehen, dass wir jetzt zehn Container haben, und acht davon wurden gerade erst gestartet. Wenn Sie interessiert sind, können Sie auch zur Webanwendung zurückkehren und die Seite einige Male aktualisieren, um zu sehen, dass Sie jetzt mehr als die ursprünglichen zwei Container-IDs erhalten.

Stacks und Dienste entfernen

Ihre Stacks und Services sind bereitgestellt und skaliert, großartig! Aber jetzt möchten Sie sie offline schalten. Dies kann mit dem entsprechenden rm Befehl erfolgen. Führen Sie den folgenden Befehl aus, um unseren Demo-Stack zu entfernen:

 docker stack rm demo

Oder, wenn Sie lieber nur einen einzelnen Dienst entfernen möchten, verwenden Sie einfach:

 docker service rm demo_web

Knoten entleeren

Erinnern Sie sich, als wir zuvor docker node ls haben, um die Knoten in unserem Schwarm zu überprüfen? Es lieferte eine Reihe von Informationen zu jedem Knoten, einschließlich seiner Verfügbarkeit . Standardmäßig sind Nodes Active , was bedeutet, dass sie für die Ausführung von Containern geeignet sind. Es kann jedoch vorkommen, dass Sie einen Knoten vorübergehend offline schalten müssen, um Wartungsarbeiten durchzuführen. Sicher, Sie könnten es einfach abschalten und der Schwarm würde sich erholen, aber es ist nett, Moby (dem Docker-Wal) ein wenig Bescheid zu geben.

Hier kommt das Draining von Knoten ins Spiel. Wenn Sie einen Knoten als Drain markieren, delegiert Docker Swarm alle darauf ausgeführten Container an andere Knoten und startet keine Container auf dem Knoten, bis Sie seine Verfügbarkeit wieder auf Active ändern.

Nehmen wir an, wir möchten node1 . Wir können laufen:

 docker node update --availability drain node1

Leicht! Wenn Sie bereit sind, es wieder zum Laufen zu bringen:

 docker node update --availability active node1

Einpacken

Wie wir gesehen haben, ermöglicht uns Docker in Verbindung mit dem Swarm-Modus, Anwendungen effizienter und zuverlässiger als je zuvor bereitzustellen. Es ist erwähnenswert, dass Docker Swarm keineswegs die einzige Container-Orchestrierungs-Engine da draußen ist. Tatsächlich ist es einer der jüngeren. Kubernetes gibt es schon länger und wird definitiv in mehr Produktionsanwendungen eingesetzt. Allerdings ist Swarm derjenige, der offiziell von Docker entwickelt wurde, und sie arbeiten jeden Tag daran, noch mehr Funktionen hinzuzufügen. Unabhängig davon, für welche Sie sich entscheiden, verwenden Sie weiterhin Container!