‫Eines der großen Versprechen von Containern ist, dass wir unsere Apps einfach bereitstellen können, als ob wir ein Plattformdienst wären, wissen
‫Sie, wie Heroku oder so. Wir können das auf jeder Hardware tun, ob
‫auf unserer Hardware, bei einem Cloud-Anbieter, ob virtuell oder physisch. Mit Docker können unsere Apps gleich ausgeführt werden, unabhängig davon, ob
‫es sich um Amazon, Azure, DigitalOcean, Linode, Rackspace, Google Cloud oder was auch immer handelt. Wie können wir ohne all diese Plattformfunktionen
‫auf einfache Weise Dutzende, Hunderte oder sogar Tausende von Containern auf vielen Servern
‫oder Instanzen bereitstellen und warten? Oder Knoten oder Tröpfchen oder was auch immer.
‫Das bringt einige wirklich neue Probleme mit sich, die für kleine Organisationen bisher keine Probleme waren.
‫Wir alle kennen Netflix und große Organisationen wie dieses, die sich auf Tausende und Abertausende von Knoten und
‫Zehntausende von Knoten skalieren lassen, und sie haben viele Ingenieure.
‫Aber wenn Sie nur ein paar Leute in Ihrem Team haben, oder wenn Sie nur ein Einzelentwickler sind, wie nehmen
‫Sie Ihre Container und skalieren sie und bewältigen ihren gesamten Lebenszyklus? Von der Bereitstellung über den Start
‫bis zum Neustart, von der Neuerstellung bis zum Löschen und Aktualisieren.
‫Wir fangen an, Fragen zu stellen, wie genau Docker das macht oder macht es das überhaupt?
‫Einige der Fragen, die wir uns stellen, lauten: Wie skalieren wir? Wie skalieren wir? Wie stellen wir sicher,
‫dass unsere Container neu starten, wenn sie ausfallen?
‫Wie ersetzen wir diese Container, wenn wir tatsächlich ein Update für sie haben? Heutzutage wird dies als blaugrünes Deployment
‫bezeichnet. Dies bedeutet, dass Sie keine Ausfallzeit haben und die Server aus dem Pool
‫nehmen, um neue Server einzuspielen. Am Ende steht Ihnen immer etwas zur
‫Verfügung, sodass Sie beim Aktualisieren nie wirklich außer Betrieb sind. Woher wissen wir, ob wir Dutzende von Knoten oder nur drei Knoten haben,
‫an denen wir diese Container gestartet haben? Auf welchem Knoten befindet sich unser Container? Wie kommunizieren wir über
‫diese verschiedenen Knoten oder Server mit unserem Netzwerk in den Containern?
‫Wie können wir in Bezug auf die Sicherheit sicherstellen, dass unsere Container nur auf den Maschinen ausgeführt
‫werden, auf denen sie ausgeführt werden sollen?
‫Wie speichern wir die privaten Informationen, die wir für unsere Container benötigen, z. B. Geheimnisse
‫oder Passwörter, nachdem wir die Dinge im Handumdrehen verschieben und dynamisch bereitstellen?
‫Dies bringt uns zu einer wichtigen Entwicklung im Bereich dessen, was Docker zu lösen versucht.
‫Wenn Leute mit mir reden und denken, Docker sei nur eine Container-Laufzeit, erwähne ich nur
‫den Swarm-Modus, eine brandneue Funktion aus dem Jahr 2016, die jahrelanges Verständnis für die Anforderungen von Containern und die Art
‫und Weise, wie sie tatsächlich live ausgeführt werden, zusammenbringt in Produktion.
‫Swarm ist also im Grunde genommen eine Server-Cluster-Lösung, die verschiedene Betriebssysteme oder Hosts oder Knoten,
‫oder wie auch
‫immer Sie sie nennen möchten, zu einer einzigen verwaltbaren Einheit zusammenbringt, in der Sie dann den
‫Lebenszyklus Ihrer Container orchestrieren können. Um ganz klar zu sein, wir sprechen nicht über Swarm,
‫den ich Swarm Classic nenne, der vor 1 eine Add-On-Komponente für Docker war. 12 kamen heraus. Es war wirklich ein Container, der in
‫Docker ausgeführt wurde, der
‫wirklich nur Ihre Docker-Ausführungsbefehle aufnahm und sie auf mehreren Servern wiederholte.
‫Es hat ein paar Probleme gelöst, aber es war nicht wirklich so groß, dass wir wirklich 80% der Fälle lösen mussten, in denen
‫es darum ging, wie Sie Ihre Container betreiben.
‫Im Sommer 2016
‫kündigte Docker auf der dockercon 2016 das Swarm Kit an, ein Set von Bibliotheken oder ein Toolkit, das sich auf
‫eine ganze Reihe neuer Swarm-Funktionen bezieht.
‫Dann haben sie das direkt in den Docker-Server gesteckt. Während des gesamten Kurses standen Ihnen die Funktionen
‫in der CLI und auf Ihrem Server zur Verfügung.
‫Jetzt können wir endlich in sie eintauchen.
‫Im Januar 2017, 1. 13 sind erschienen, und da Swarm Mode
‫2016 neu war, werden sie es in den kommenden Jahren weiter verbessern.
‫Im Januar haben sie zusätzliche Funktionen hinzugefügt, die Stacks and Secrets genannt werden, sowie andere
‫Boni, über die wir später sprechen werden. Es ist wichtig zu beachten, dass Swarm nicht standardmäßig aktiviert ist.
‫Tatsächlich konnten Sie auf Ihrem Computer die hier aufgeführten Befehle derzeit nicht verwenden. Das würde einen Fehler
‫auslösen, da Swarm aktiviert sein muss.
‫Dies war eines der Entwurfsziele: Keiner der Swarm-Codes würde sich auf den
‫vorhandenen Docker-Daemon auswirken, und alle Tools und Systeme, die bereits auf Docker angewiesen waren,
‫oder sie hatten möglicherweise eine eigene Orchestrierung auf Docker funktionieren weiterhin und werden nicht von
‫Swarm
‫gestört, der jetzt Teil von Docker ist. Einige wirklich grundlegende Konzepte, bevor wir anfangen, darin zu tauchen, ist,
‫dass diese blauen Kästchen, die Sie oben sehen, das sind, was wir Manager-Knoten nennen, und sie haben
‫tatsächlich eine lokale Datenbank, die als Raft-Datenbank bekannt ist.
‫Es speichert ihre Konfiguration und gibt ihnen alle Informationen, die sie benötigen, um die Autorität in einem
‫Schwarm zu haben.
‫Wir haben hier also drei verschiedene Manager, die alle zum Schwarm hinzugefügt wurden,
‫und alle behalten eine Kopie dieser Datenbank und verschlüsseln ihren Datenverkehr, um die Integrität sicherzustellen und das Vertrauen zu
‫garantieren, dass sie diesen Schwarm sicher verwalten können .
‫Unten im Grünen haben wir tatsächlich Notizen von Arbeitern. Jetzt können Sie im Konzept von Swarm sehen,
‫wir haben jetzt Manager und Arbeiter.
‫Jede dieser Komponenten ist eine virtuelle Maschine oder ein physischer Host, auf dem eine Linux- oder
‫Windows-Serververteilung ausgeführt wird.
‫Dies zeigt, wie sie tatsächlich alle über das kommunizieren, was wir Control Plane nennen. Auf diese Weise
‫werden Befehle um den Schwarm gesendet und nehmen an Aktionen teil. In einer etwas komplizierteren Ansicht haben wir
‫diese von mir erwähnte Raft-Konsensus-Datenbank, die zwischen allen Knoten erneut repliziert wird.
‫Sie erteilen den Arbeitern Befehle.
‫Die Manager selbst können auch Arbeiter sein. Natürlich können Sie Mitarbeiter und Manager in
‫zwei verschiedene Rollen herabstufen und befördern.
‫Wenn Sie an einen Manager denken, denken Sie in der Regel an einen Mitarbeiter mit Berechtigungen zur Steuerung des Schwarms.
‫Die einzige Voraussetzung für jeden dieser Server ist, dass er
‫denselben Docker ausführt, den Sie bereits verwenden. Mit diesem Konzept eines Schwarms und diesen Managern haben wir jetzt neue
‫Konzepte, wie unsere Container aussehen.
‫Mit dem Docker-Befehl run konnten wir also nur einen Container bereitstellen.
‫Es würde nur einen Container erstellen.
‫Es war immer auf jedem Computer, mit dem die Docker CLI sprach.
‫Das ist normalerweise Ihr lokaler Computer oder möglicherweise ein Server, an dem sie angemeldet sind. Dieser Docker-Befehl hatte
‫keine Konzepte zum Skalieren oder Hochskalieren.
‫Wir brauchten also neue Befehle, um damit umzugehen.
‫Von dort kommt der Docker-Dienstbefehl. In einem Schwarm ersetzt es
‫den Docker-Befehl run und ermöglicht es uns, unserem Container zusätzliche Funktionen hinzuzufügen, wenn wir ihn ausführen, z.
‫B. Replikate, um uns mitzuteilen, wie viele davon ausgeführt werden sollen.
‫Diese werden als Aufgaben bezeichnet.
‫Ein einzelner Dienst kann mehrere Aufgaben haben, und jede dieser Aufgaben startet einen Container.
‫In diesem Beispiel haben wir einen Dienst mit dem Docker-Dienst create erstellt, um einen Nginx-Dienst mit dem Nginx-Image zu starten,
‫wie wir es bereits mehrmals getan haben.
‫Aber wir haben gesagt, dass wir drei Repliken möchten.
‫Es wird also die Manager-Knoten verwenden, um zu entscheiden, wo diese im Schwarm platziert werden sollen. Standardmäßig wird versucht, sie zu
‫verteilen.
‫Jeder Knoten würde eine eigene Kopie des Nginx-Containers erhalten, bis zu den drei Replikaten, von denen wir sagten,
‫dass sie benötigt werden.
‫Dies ist ein schnelles und grundlegendes Verständnis dafür, wie die Manager arbeiten und was sie im Hintergrund tun.
‫Alle diese Funktionen sind neu.
‫Es geht nicht nur darum, Ihren Befehl auf einer API auszuführen, wie wir es bei
‫einem Docker-Ausführungsbefehl kennen.
‫Tatsächlich gibt es hier eine völlig neue Swarm-API, die eine Reihe von Hintergrunddiensten wie den Scheduler und den Dispatcher sowie den
‫Allokator und den Orchestrator enthält, die dabei helfen, Entscheidungen darüber zu treffen, was die Mitarbeiter zu
‫einem bestimmten Zeitpunkt ausführen sollen.
‫Deshalb melden sich die Arbeiter ständig bei den Managern und bitten um neue Arbeit.
‫Die Manager verteilen ständig neue Arbeit und bewerten, was Sie ihnen gesagt haben, gegen das, was
‫sie tatsächlich tun.
‫Wenn dann ein Abgleich stattfinden soll, werden diese Änderungen vorgenommen, z. B., dass Sie
‫drei weitere Wiederholungsaufgaben in diesem Service ausführen sollen.
‫Der Orchestrator wird das also erkennen und den Arbeitern Befehle erteilen und so weiter.
‫Mit diesem Swarm-Modus erhalten wir eine Reihe von Funktionen, mit denen wir bereits vorhandene Docker-Fähigkeiten nutzen können,
‫um unsere Container zuverlässig im Internet bereitzustellen und viele Probleme zu lösen Probleme,
‫die wir haben würden, wenn wir in Produktion
‫gehen.