Docker 1.12 Swarm mode – Shortcuts

Seit den ersten Tests und dem Aufbau eines Docker Swarm Clusters unter Docker 1.12 mit dem so genannten Swarm mode habe ich mich weiter mit den neuen Features von Docker 1.12 beschäftigt. Bevor ich jedoch zu einem ausführlicheren Beitrag über Docker Services in der Praxis komme, möchte ich zunächst einige Themen erläutern, die mir beim weiteren Ausprobieren aufgefallen sind. 

Node-Rollen ändern – Worker zu Manager

Ein weiterer zu Testzwecken aufgebauter Swarm sieht wie folgt aus:


Dabei fällt zunächst auf, dass „schwerin.mushaake.org“ einen FQDN (fully qualified domain name) als Hostname hat, während die anderen nur die Kurzbezeichnung tragen. Das liegt daran, dass der Hostname auf „schwerin“ im Unterschied zu den anderen Nodes in der Datei /etc/hostname mit Domain angegeben ist – warum auch immer.

Nun sind in diesem Cluster zwei Manager Nodes enthalten – und zwar „waren“ und „rostock“. Diesen sollte ein dritter Manager hinzu gefügt werden, was mit dem Kommando „docker node promote <hostname>“ möglich sein sollte:


Das Ergebnis war jedoch ernüchternd:


Der Node „chemnitz“ war offensichtlich noch kein Manager, was auch ein Test bestätigte:


Eine weitere Fehlermeldung war nicht zu erkennen, und während sich die genannten Nodes problemlos als Worker hinzufügen ließen, war die Ernennung zum Manager nicht möglich.

Woran das lag, hatte sich mir zunächst nicht erschlossen. Daher wollte ich das Verhalten auf einem anderen Swarm verifizieren. Dabei handelt es sich um denjenigen aus dem letzten Artikel, mehrere VMs auf drei physischen Servern in einem privaten Netzwerk:


Einer der Worker sollte zum Manager ernannt werden:


Das Ergebnis:


Interessanterweise hatte es diesmal problemlos funktioniert! Also untersuchte ich die Firewall-Einstellungen auf dem betreffenden Node des ersten Swarms, tatsächlich gab es dort eine Ubuntu-ufw-Firewall, jedoch waren die Ports für den Swarm eigentlich freigeschaltet. Eigentlich. Da jedoch der Node „chemnitz“ in einem vollkommen anderen Netzwerk, d.h. bei einem anderen Provider steht als die beiden Manager-Nodes „waren“ und „rostock“, vermute ich an dieser Stelle eine mögliche Ursache. Denn der Node „schwerin“ konnte wiederum zum Manager ernannt werden:

Docker Services

Docker beschreibt die in der Version 1.12 neu hinzu gekommenen Services als „replizierte, verteilte, lastverteilte Prozesse in einem Swarm von Docker Engines“ (“ replicated, distributed, load balanced process on a swarm of Engines“). Letztlich handelt es sich dabei um eine neue Art, Container zu starten, zu verteilen und zu verwalten. Die bisherige Art und Weise funktioniert zwar nach wie vor, ist aber teilweise eingeschränkt. Während es im bisherigen Swarm möglich war, einen Container auch auf einem Host per „docker run...“ zu starten und dabei ein im Swarm angelegtes Overlay-Network zu nutzen, ist dies im neuen Swarm nicht mehr möglich. die Overlay-Networks beziehen sich hier nur noch auf dem Swarm und können nur mit den Services verwendet werden. Da die Beispiele zu den Services bislang eher sagen wir mal sehr beispielhaft sind, habe ich versucht, mich anhand einer realen Anwendung dem Thema zu nähern. Dazu verweise ich (schon wieder) auf den nächsten Artikel. Ein sehr, sehr simples Beispiel ist der Start eines „ping“-Kommandos innerhalb eines Containers. Anstatt diesen einzelnen Container per „docker run...“ zu starten, wird er als Service deklariert:


An dieser Stelle steht naturgemäß die Frage nach dem „Warum?“. Was ist der Zweck dieser neuen Art? Docker selbst nennt wiederum einige Argumente – Services sind selbstheilend, belastbar, beinhalten ein internes Load-Balancing, repliziert (verteilt oder „global“, d.h. auf jedem Node laufend) und werden deklarativ definiert, d.h. der gewünschte Status wird angegeben, Docker kümmert sich um die Einhaltung. Tatsächlich klingt dies nach einigen großartigen Features – und das sind sie auch, vorausgesetzt, die Anwendung ist dementsprechend darauf ausgelegt.

Im Beispiel wurde der Service einmal gestartet und läuft auf dem Node „pirita“. Durch Constraints ist es auch möglich, die Nodes näher zu spezifizieren, auf denen der Service laufen soll.

Sollen z.B. zehn Container laufen, lässt sich der Service einfach skalieren:


Wie zu erkennen ist, sind zum Zeitpunkt des Aufrufs der Service-Liste erst drei Container gestartet worden. Das liegt daran, dass die meisten Nodes das zugrunde liegende Image noch nicht heruntergeladen hatten. Das Herunterladen geschieht automatisch, so dass wenig später das Kommando zu diesem und somit gewünschten Ergebnis führt:


Eine Übersicht der jeweiligen Container erhält man mit dem „docker service tasks <servicename>„-Kommando. Das erste Beispiel zeigt den Status kurz nach dem Aufruf des scale-Befehlt, im zweiten sind bereits alle notwendigen Images heruntergeladen und die Container gestartet worden:


Die umgekehrte Richtung geht natürlich auch:


Hier wurden alle Container bis auf die Nr. 2 beendet, Docker sorgt für die Einhaltung der Vereinbarung, denn es soll nur genau ein Task laufen. An dieser Stelle wird auch klar, dass die jeweiligen Tasks und somit zugrunde liegenden Images für derartige Aktionen ausgelegt sein müssen. Docker gewährleistet hier die Einhaltung der Deklaration, aber es ist nicht festgelegt, in welcher Reihenfolge die Container gestartet werden bzw. dass der zuerst gestartet auch derjenige ist, der beim Herunterskalieren übrig bleibt.

Der Service kann genauso einfach wieder beendet werden:


Zwar liegt die praktische Anwendung eines solchen Beispiels in weiter Ferne, aber ich wollte dennoch zur leichteren Nachvollziehbarkeit die Kommandos in dieser Form erläutern.

Docker Swarm Visualizer

Ein sehr nettes Tool, was im Vorstellungs-Video von Docker 1.12 verwendet wurde, ist der Docker Swarm Visualizer. Damit lassen sich die neuen Docker Services in einem Swarm übersichtlich anzeigen. Die Aktualisierung geschieht nahezu in Echtzeit, somit können Änderungen in der Anzahl und Verteilung sehr gut nachvollzogen werden.

docker_swarm_visualizer

Der Start ist denkbar einfach, hier wurde auf einem der Manager Nodes folgendes Kommando verwendet:


Weitere Hinweise finden sich auf der Github-Seite, auf jeden Fall lohnt sich das Ausprobieren!

Fazit

Docker 1.12 mit dem neuen Swarm mode bietet etliche neue Features, die jedoch erst einmal ausprobiert und beherrscht werden müssen. Bei den Services war ich anfangs eher skeptisch bzw. nach den ersten Versuchen ernüchtert, später jedoch umso begeisterter. Dazu später mehr…

 

Ähnliche Beiträge

Tags:

Schreibe einen Kommentar

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