Docker 1.12 Swarm mode – Migration eines bestehenden Docker Swarms

Vor knapp einem Monat hat Docker einige neue Features angekündigt, die mit der Docker Engine Version 1.12 erscheinen. Zwar ist diese Version bislang noch im Beta- bzw. Release-Candidate-Status, aber aufgrund der doch recht umfassenden Änderungen lohnt es sich dennoch, sich vor offizieller Freigabe damit zu beschäftigen. Vorweg sei erwähnt, dass die Änderungen doch einschneidender sind, als die minimale Erhöhung der Versionsnummer vermuten lässt. Die neuen Features zur Einrichtung eines Docker Swarms, aber auch zur Erstellung von Services und darauf basierenden Skalierung und Orchestrierung lassen eher den Schluss zu, dass es sich um völlig neue Tools handelt, als um die Erweiterung eines vorhandenen. Glücklicherweise lassen sich die bisherigen Konfigurationen bislang auch weiterhin verwenden, aber vermutlich wird es nur eine Frage der Zeit sein, bis z.B. die Images für den Swarm Agent nicht mehr gewartet werden und der Umstieg auf den neuen Swarm mode unumgänglich erscheint.

Dieser Artikel beschäftigt sich daher auch nur mit einem Teil der neuen Features, und zwar lautete das Ziel, einen bestehenden Docker Swarm, der mittels docker-machine eingerichtet wurde, in einen neuen Docker Swarm umzuwandeln. Dabei handelte es sich jedoch eher um einen Abriss mit anschließendem Neubau, dazu später mehr. Die Voraussetzungen waren wie folgt – ein Docker Swarm auf mehreren VMs in einem privaten Netzwerk, somit waren alle Ports untereinander freigeschaltet, es mussten keine Änderungen an einer Firewall oder ähnliches durchgeführt werden. Wenn der Swarm z.B. bei AWS EC2 betrieben wird, müsste ein weiterer Port zur Kommunikation freigegeben werden (TCP 2377), während die Ports für Consul (8500. 8300-8302) nicht mehr benötigt werden.

Der Docker Swarm wurde ursprünglich mit docker-machine und SSH per generic Treiber eingerichtet. Der User hat dabei alle Rechte, docker auf den jeweiligen Nodes auszuführen, falls noch nicht geschehen, sollte der User der Gruppe „docker“ hinzugefügt werden, z.B.:


Die Liste der beteiligten Docker Hosts liest sich wie folgt:


Als Client wird die VM „connewitz“ eingesetzt, d.h. dort ist docker-machine installiert, alle weiteren Aktionen werden von dieser VM ausgeführt. Beim bisherigen Swarm war dieser Docker Host tatsächlich nicht Bestandteil des Swarms, sondern diente nur als Client zu administrativen Zwecken. Auf der VM namens „lausen“ ist hingegen Consul installiert, somit ist diese Maschine zwar Voraussetzung für den Betrieb des Swarms, aber der Host ist nicht im Swarm mit eingebunden.

Weiterhin wurden die noch unterschiedlichen Versionen der Docker-Engine zunächst aktualisiert, so dass nach dem Update einheitlich die Version 1.11.2 eingerichtet war.

Da die bisherige Swarm-Installation nicht mehr benötigt wurde, sind die Docker-Container für swarm-agent, swarm-agent-master und consul heruntergefahren und gelöscht worden. Somit wurde der vorherige Swarm letztlich gelöscht.


Entfernen der swarm-Container auf dem Master:


Ebenfalls wurde auf den anderen Docker-Hosts, die nicht Master waren, der jeweilige swarm-agent abgeschaltet und gelöscht, z.B.:


Nachdem somit alle Container entfernt worden waren, die letztlich die Infrastruktur eines Swarm bilden, wurde der Versuch, den Swarm anzusprechen, folglich mit einer Fehlermeldung quittiert:


Ein paar Restbestände gibt es dennoch – und zwar aufgrund der vorherigen Einrichtung mittels docker-machine. Da bei der Einrichtung durch docker-machine die ursprüngliche Konfiguration in einem config.json-File gespeichert wurde (z.B. .docker/machine/machines/miltitz/config.json), wird auch bei Ausführen von docker-machine ls der bisherige Swarm nach wie vor angezeigt. Das soll hier aber nicht weiter stören.

Anschließend wude das Update auf die für den Swarm mode notwendige Version 1.12 der Docker-Engine durchgeführt. Diese ist noch im Beta-Stadium für Windows und Mac, unter Ubuntu liegt sie aktuell als Release-Candidate vor. Bei der Erstellung dieses Artikels war v1.12.0-rc4 aktuell.

Bei Ubuntu liegt die Version 1.12.0-rc4 im „experimental“-Repository vor, insofern ist zunächst die Datei mit den Ubuntu-Paketquellen zu ändern. Auf allen Hosts wurde daher in die Datei /etc/apt/sources.list.d/docker.list folgendes eingetragen, d.h. die Angabe von „main“ durch „experimental“ ersetzt:


Anschließend wurde die Docker-Engine mit den üblichen Kommandos auf den neuesten Stand gebracht:


Bei einigen der VMs gab es jedoch Konflikte beim Upgrade, da die Konfiguration unter /etc/default/docker überschrieben werden sollte. Das lag zum Teil auch in der Historie begründet, denn einige der VMs sind von einer älteren Ubuntu-Version upgraded worden, andere waren etwas neuer und direkt mit Ubuntu 16.04 und einer neueren Docker-Version eingerichtet. Bei den neueren Maschinen war die Konfiguration in der Datei /etc/systemd/system/docker.service gespeichert, während die älteren die Datei  /etc/default/docker benutzen. Da die Optionen relativ schnell wieder hergestellt werden konnten, wurde im Konfliktfall die „Version des Paket-Betreuers“ installiert.

Das darauf folgende Update war erfolgreich, wie der Blick auf docker info verriet:


Die übrigen Maschinen wurden analog updated, bzw. wurde die Möglichkeit genutzt, sich von der Client-Maschine (d.h. diejenige mit docker-machine) auf den anderen VMs einzuloggen, etwa:


Nach der erfolgreichen Update-Prozedur war jedoch der direkte Zugriff auf die Docker-Engine vom Client aus nicht mehr möglich:


Eigentlich war dies auch logisch, denn die bisherigen Optionen wurden überschrieben, so dass die Docker-Engine nur noch in der Default-Einstellung auf dem lokalen Socket verfügbar war. Die bisherigen Opeionsn fehlen somit, diese waren::


Die einzelnen Docker-Hosts sollten jedoch weiterhin per API, insofern auf dem Port 2376 erreichbar sein. Da der neue Swarm jedoch Consul nicht mehr verwendet, wurden die entsprechenden Angaben entfernt, so dass die Optionen nur noch wie folgt lauteten:


Nachdem die Optionen entsprechend erweitert wurden, war auch die Docker-Engine mit ihrer API wieder verfügbar:


Auf den neueren VMs wurden erst gar keine Konflikte beim Update-Prozess genannt, dabei bliebt die Frage, wo die Konfiguration der Docker-Engine stattfindet. Eine Antwort lieferte systemctl:


Hierbei wurde /etc/systemd/system/docker.service genutzt, auch darin wurden die Consul-spezifischen Optionen entfernt. Auf einer der VMs wurde diese Änderung zunächst nicht durchgeführt, d.h. dort waren die Parameter für Consul (--cluster-store=consul://192.168.10.64:8500 --cluster-advertise=eth0:2376) noch vorhanden. Beim späteren Einrichten der Swarm Nodes wurde daraufhin eine Fehlermeldung ausgegeben:


Somit wird auch klar, dass der bisherige Swarm nicht mit dem neuen Swarm mode kompatibel ist, insofern heißt es entweder – oder.

Nachdem alle Vorbereitungen abgeschlossen waren, sieht die Liste der Docker-Maschinen wie folgt aus:

Der neue Docker Swarm mode

Da die VMs auf insgesamt drei physischen Maschinen verteilt sind, soll auf jedem der Server ein Docker Swarm Manager eingerichtet werden. Den Anfang macht „connewitz“, d.h. die VM, die bislang nur als Client diente. Weitere Hinweise, Parameter etc. befinden sich natürlich in der offiziellen Docker-Dokumentation.

Vorweg sei erwähnt, dass die Einrichtung eines Docker Swarm mit der neuen Version wesentlich einfacher geworden ist. Zwar konnte auch docker-machine einige Komplexität verbergen, indem die für den Swarm-Betrieb notwendigen Parameter übernommen und die Container eingerichtet wurden, aber all dies ist nun nicht mehr notwendig. Ebenfalls lässt sich der neue Docker Swarm mode sehr einfach auf bestehenden Docker Hosts installieren – und noch dazu durchaus sicher, denn die Komplexität bzgl. Zertifikat-Einrichtung und -verwaltung wird genauso von der Docker-Engine selbst übernommen wie die Speicherung der eigentlichen Konfiguration, ein externer Speicher wie Consul oder etcd ist nicht mehr notwendig.

Die Architektur lässt sich wie folgt darstellen:

Quelle und Copyright: https://blog.docker.com/2016/06/docker-1-12-built-in-orchestration/ Quelle und Copyright: https://blog.docker.com/2016/06/docker-1-12-built-in-orchestration/

 

Die Initialisierung auf einem der gewünschten Master (hier: connewitz) geschieht wie folgt:


Das war es auch schon! Weitere Nodes, ob Manager oder nicht, können mit den angegebenen Kommandos und Parametern hinzugefügt werden.

Noch ein kurzer Test:


Zeit für einen weiteren Swarm Manager, dieser soll auf „tondi“ installiert werden. In einigen Tutorials und Blog-Einträgen werden diese Schritte ebenfalls beschrieben. Doch entweder es wird sich direkt auf den jeweiligen Docker Hosts eingeloggt, oder docker-machine wird mit dem ssh-Kommando aufgerufen, wie in diesem Beispiel. Da jedoch alle Docker-Kommandos auch per API – und somit per Docker-Client verfügbar sind, müsste es auch anders gehen, schließlich funktioniert die Docker-Engine ja wie zuvor:


Insofern – wenn normale Kommandos funktionieren, wieso nicht auch die swarm-Konfiguration?

Genau dies ist auch der Fall, somit werden alle weiteren Nodes bzw. Manager wiederum von der Client-Maschine eingerichtet:


Genau wie gewünscht wurde der neue Swarm Manager eingerichtet, aus Sicherheitsgründen ist jedoch noch eine Bestätigung auf dem bisherigen bzw. ersten Manager notwendig:


Perfekt! Auch das will geprüft werden:


Wie erwartet ist der Host „tondi“ nun als Manager eingerichtet, wobei der aktuelle „Leader“ nach wie vor „connewitz“ ist. Um im Fehlerfall ein eindeutiges Quorum (Docker nutzt den Raft-Algorithmus zur Herstellung von Konsens der Manager-Nodes untereinander) zu erhalten, empfiehlt sich die Nutzung einer ungeraden Anzahl von Manager Nodes, so dass zumindest der Ausfall eines Managers problemlos verkraftet wird. Das Hinzufügen eines weiteren Swarm Managers geschieht analog:


Auch diese Kommandos wurden nur vom „Client“ aus ausgeführt, das Einloggen in weitere VMs ist nicht notwendig. Wie erwartet besteht der Swarm nun aus drei Nodes, die allesamt als Manager fungieren:


Alle weiteren Nodes werden als Worker hinzugefügt, etwa die VM „lausen“:


Das Ergebnis ist dieser Swarm Cluster:


Dabei können alle Kommandos zur Verwaltung des Clusters auch von den aktuell nicht aktiven Manager Nodes ausgeführt werden. Zur Verdeutlichung:


Der Versuch, die Liste der Nodes von einem Worker aus zu erreichen, endet hingegen wie erwartet in einer Fehlermeldung:


Jedoch können auch Nodes, die als Worker fungieren, nachträglich als Manager eingerichtet werden.

So viel für heute! Der neue Docker Swarm läuft, nun gilt es, alle weiteren Features zu entdecken, insbesondere die neuen Services und deren Erstellung sowie Skalierung. Immerhin laufen die bisherigen Docker-Container nach wie vor, sofern sie nicht Features des „alten “ Docker Swarm voraussetzen.

Ähnliche Beiträge

Tags:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.