Die hybride Cloud mit Docker Swarm und Ansible, Teil 1

Inhaltsverzeichnis

Zeitgemäße Applikationen kommen nicht mehr mit nur einem Server auf einem Betriebssystem aus: Ein Docker-Orchestrierungstool wie Docker Swarm kann helfen, die Container über Server- und Betriebssystemgrenzen hinweg im Griff zu behalten. Das DevOps-Tool Ansible übernimmt im Sinne von "Infrastructure-as-Code" die komplette Initialisierung des Docker Swarm.

Der Artikel "Docker-Windows-Container mit Ansible managen" zeigte, dass aktuelle DevOps-Tools wie Ansible gut für das Managen von Windows-Servern geeignet sind, obwohl sie ursprünglich aus dem Unix-Umfeld stammen. Anwendungen, die eine Windows-Umgebung benötigen, können mit nativen Docker-Windows-Containern ebenfalls in den Genuss der Vorteile von Docker kommen.

In der Praxis betreiben selbst entschiedene Verfechtern eines Betriebssystems meist trotzdem Instanzen des anderen, sei es nun Linux oder Windows. Beispielsweise läuft ein für Linux geschriebener Nginx am besten auf Linux, wohingegen eine Anwendung, die eine für Windows-C kompilierte Bibliothek benötigt, einen nativen Windows-Container gut vertragen kann. Oft führt das zu der Anforderung, dass ein Docker-Orchestrierungswerkzeug ein hybrides System aus nativen Windows- und Linux-Containern unterstützt, die jeweils auf Windows- und Linux-Servern laufen. Idealerweise fügen die Tools alle "beweglichen Teile" zu einem Ganzen zusammen, beispielsweise indem ein einziger Befehl alle notwendigen Schritte automatisiert laufen lässt. Denn am Ende generiert die Applikation erst in ihrer Gesamtheit den vollen Geschäftswert.

Docker Swarm

Der Orchestrierung von Docker-Containern über Servergrenzen hinweg widmet sich mittlerweile zahlreiche Werkzeuge. Zwei populäre Vertreter sind Kubernetes und Docker Swarm. Ersteres kann sich aktuell vor Popularität kaum retten und bietet vor allem in großen Installationen viele Vorteile. Trotzdem fokussiert sich der vorliegende Artikel auf den "neuen" Docker Swarm mode, der minimal Docker 1.12.0 voraussetzt und direkt in die Docker-Engine integriert ist (nicht zu verwechseln ist er mit dem älteren Stand-Alone Docker Swarm).

Dem Fokus auf Docker Swarm liegt eine Empfehlung zugrunde: Häufig gibt es den Eindruck, dass die Nutzung von Kubernetes nach der Docker-Einführung Pflicht ist. Allerdings können ein paar Schritte vorab dem Lern- und Projekterfolg zuträglich sein können. Nach dem Start mit Docker sollten Entwickler zuerst Docker Compose in Betracht ziehen. Vor allem in Zusammenarbeit mit einem guten Provisionierungswerkzeug wie Ansible lassen sich damit viele Anforderungen abbilden – unter anderem erleichtern die Docker Compose Services das Skalieren von Containern, und die Datei docker-compose.yml ermöglicht das Ausführen der gesamten Applikation mit dem Befehl docker-compose up.

Sobald sich Docker-Container auf mehrere Server verteilen, ist die Nutzung von Docker Swarm mode sinnvoll. Da Swarm auf den bekannten Docker-Konzepten aufbaut, gelingt der Start schnell. Selbst das praktische docker-compose.yml findet bei einem Docker Stack (die Bezeichnung einer aus mehreren Containern bestehenden Anwendung in Docker Swarm) weitere Verwendung. Sollten noch weitergehende Anforderungen auftauchen, die Docker Swarm nicht mehr abdeckt, ist der Einsatz von Kubernetes sinnvoll. Erst dann lohnt es sich, die anspruchsvolle Lernkurve von Kubernetes zu bezwingen, denn es ist äußerst komplex und kann teilweise gerade erlernte Docker-Konzepte ersetzen. Besonders nach einer hart erkämpften Docker-Einführung inklusive der nicht zu unterschätzenden Dockerisierung von Legacy-Anwendungen kann es zu langen Gesichtern führen, wenn Kubernetes alles über den Haufen wirft.

Nicht zuletzt ist der Aufbau eines hybriden Docker-Container-Clusters mit nativen Windows- und Linux-Containern mit den aktuell für jedermann verfügbaren Versionen des Windows Server 2016 (siehe dazu den Artikel "Docker-Windows- Container mit Ansible managen" nicht sinnvoll mit Kubernetes umsetzbar. Die Kubernetes-Unterstützung des aktuellen Windows Server 2016 ist noch zu rudimentär. Nur für Kunden, die im Rahmen des Zusatz-Lizenzpakets Software Assurance für Volumenlizenzierung in den Genuss der neuen halbjährlichen Updates von Windows Server 2016 kommen, könnte sich das bald ändern. Die halbjährlichen Updates verteilt Microsoft über den sogenannten Semi-annual Channel. Die Aktualisierung auf Version 1709 bringt die benötigten Networking-Features für einen Kubernetes-Betrieb mit. Allen anderen steht für hybride Cluster mit nativen Windows- und Linux-Containern zurzeit ausschließlich Docker Swarm zur Verfügung.

Windows Vagrant Box mit Packer

Egal für welche Lösung man sich entscheidet: Ein vollständig nachvollziehbares und automatisiertes Setup sollte das Ziel sein. Denn gerade bei neuen Technologien wie den nativen Docker-Windows-Containern kann es immer mal wieder zu unvorhergesehenen Problemen kommen. Wenn jedoch einfach alles wieder automatisiert bereitstellbar ist, sind Fehler leichter zu beheben.

Für eine solche Vorgehensweise ist der Einsatz eines der zahlreichen "Infrastructure-as-Code"-Werkzeuge von Nöten. Im Artikel zu Docker-Windows-Containern hat sich das Tool Vagrant bewährt. Es kann nicht nur einzelne Maschinen verwalten, denn mit dem Vagrant-Multi-Machine-Setup lassen sich mehrere virtuelle Maschinen mit dem einfachen Kommando vagrant up hochfahren. Das Vorgehen hat den Vorteil, dass das entstehende Setup überall lokal nachvollziehbar und danach leicht auf das jeweilige Deployment-Szenario zu adaptieren ist – sei es eine On-Premise-Installation oder einer der zahlreichen Cloud-Provider.

Für das Aufsetzen eines hybriden Clusters benötigt man neben einer Linux Vagrant Box eine entsprechende mit Windows Server 2016. Da es keine offizielle Vagrant Box für den Docker-Windows-Container-Betrieb von Microsoft gibt, ist sie selbst zu erstellen. Wie das geht zeigt der Artikel "Docker-Windows-Container mit Ansible managen". Das dort verwendete Setup mit Packer.io lässt sich nahezu vollständig wiederverwenden. Es gilt nur einen kleinen Unterschied im Vagrantfile-Template von Packer abzubilden. Im Vorartikel ist direkt eine konkrete Virtual-Box-Instanz sowie ein passendes Port-Forwarding konfiguriert. Beides führt aber bei mehreren Windows-Servern zu Problemen, denn es kann immer nur eine Virtual-Box-Instanz mit dem gleichen Namen geben, und es lässt sich nur ein bestimmter Port an einen Host binden. Ein eigenes Vagrantfile-Template kann das Dilemma jedoch elegant umgehen. Das vagrantfile-windows_2016- multimachine.template, das das aus dem Vorartikel bekannte GitHub-Repository ansible-windows-dockerspringboot bereithält, fällt im Vergleich etwas kleiner aus:

Vagrant.configure("2") do |config|
  config.vm.box = "windows_2016_docker_multi"
  config.vm.guest = :windows

  config.windows.halt_timeout = 15

  # Configure Vagrant to use WinRM instead of SSH
  config.vm.communicator = "winrm"

  # Configure WinRM Connectivity
  config.winrm.username = "vagrant"
  config.winrm.password = "vagrant"
end 

Um Packer ein anderes Vagrantfile-Template unterschieben zu können, ist eine Anpassung der Packer-Konfigurationsdatei erforderlich, was in der Datei windows_server_2016_docker.json geschieht, die nun das Mitgeben eines Vagrantfile-Template-Namens mit dem Parameter template_url sowie zusätzlich die Definition des Namens der Vagrant Box von außen per box_output_prefix unterstützt. Jetzt lassen sich die für das vorliegende Setup benötigten Windows-Server-Vagrant-Boxen erzeugen.

Dazu ist das GitHub-Repository ansible-windows-dockerspringboot zu klonen und der folgende Packer-Befehl innerhalb des Ordners step0-packer-windows-vagrantbox auszuführen. Wichtig ist nur, dass aktuelle Packer- sowie Virtual-Box-Versionen installiert sind.

packer build -var iso_url=14393.0.161119
1705.RS1_REFRESH_SERVER_EVAL_X64FRE_EN-US.ISO -var
iso_checksum=70721288bbcdfe3239d8f8c0fae55f1f -var 
template_url=vagrantfile-windows_2016-multimachine.template -var
box_output_prefix=windows_2016_docker_multimachine
windows_server_2016_docker.json

Die Befehlsausführung kann sich etwas in die Länge ziehen. Danach sollte die Vagrant-Box windows_2016_docker_multimachine_virtualbox.box im Verzeichnis step0-packer-windowsvagrantbox vorliegen. Das sollte man danach der lokalen Vagrant-Installation bekannt machen:

vagrant box add --name windows_2016_multimachine
windows_2016_docker_multimachine_virtualbox.box

Hybride Cloud in der Hosentasche

Jetzt lässt sich das Vagrant-Multi-Machine-Setup aufbauen. Dazu liegt im Verzeichnis step4-windowslinux- multimachine-vagrant-docker-swarm-setup das Vagrantfile bereit. Es beschreibt die Grundstruktur der lokalen Cloud-Infrastruktur. Zu Gunsten der Lesbarkeit sind die Details etwas gekürzt:

Vagrant.configure("2") do |config|

    # One Master / Manager Node with Linux
    config.vm.define "masterlinux" do |masterlinux|
        masterlinux.vm.box = "ubuntu/trusty64"
        ...
    end

    # One Worker Node with Linux
    config.vm.define "workerlinux" do |workerlinux|
        workerlinux.vm.box = "ubuntu/trusty64"
        ...
    end

    # One Master / Manager Node with Windows Server 2016
    config.vm.define "masterwindows" do |masterwindows|
        masterwindows.vm.box = "windows_2016_multimachine"
        ...
    end

    # One Worker Node with Windows Server 2016
    config.vm.define "workerwindows" do |workerwindows|
        workerwindows.vm.box = "windows_2016_multimachine"
        ...
    end
end   


  # One Worker Node with Linux
  config.vm.define "workerlinux" do |workerlinux|
      workerlinux.vm.box = "ubuntu/trusty64"
      workerlinux.vm.hostname = "workerlinux01"
      workerlinux.ssh.insert_key = false
      workerlinux.vm.network "forwarded_port", guest: 22,
       host: 2232, host_ip: "127.0.0.1", id: "ssh"

      workerlinux.vm.network "private_network", ip: "172.16.2.11"

      workerlinux.vm.provider :virtualbox do |virtualbox|
          virtualbox.name = "WorkerLinuxUbuntu"
          virtualbox.gui = true
          virtualbox.memory = 2048
          virtualbox.cpus = 2
          virtualbox.customize ["modifyvm", :id, "--ioapic", "on"]
          virtualbox.customize ["modifyvm", :id, "--vram", "16"]
      end
  end

Grundsätzlich entsprechen die Konfigurationsparameter denen einer einzelnen Maschine, beispielsweise der Parameter box, der auf die zu nutzende Vagrant Box verweist. Interessanter ist die Netzwerkkonfiguration: Da später Ansible den hybriden Cluster provisioniert, muss der jeweilige Port der Maschine im Cluster bekannt sein. Dazu setzt man ihn mit dem Schlüsselwort "forwarded_port". Ohne den Konfigurationsparameter ist das Vagrant-eigene Port-Correction-Feature aktiv und weist zufällig einen anderen Port zu, denn auf dem Host-System kann ein Port nur einmalig belegt sein. Mit der expliziten Konfiguration ist sichergestellt, dass sich Ansible immer auf den konfigurierten Port verlassen kann und es zu keinen bösen Überaschungen kommt.

Dem Parameter id kommt eine besondere Rolle zu, denn Vagrant definiert standardmäßig Ports für SSH beziehungsweise WinRM, die es zu überschreiben gilt. Das klappt mit id: "ssh" für Linux- und id: "winrm-ssl" für Windows-Boxen.

Die Kommunikation zwischen Maschinen

Ein weiterer interessanter Punkt eines Vagrant-Multi-Machine-Setups stellt die Netzwerkkonfiguration dar, denn alle Maschinen im Cluster sollten miteinander kommunizieren können. Zusätzlich muss der Host für eine spätere Provisionierung mit den Cluster-Nodes reden können. Dafür bietet sich das sogenannte Host-only Networking von VirtualBox an (eine gute Gegenüberstellung aller Netzwerkmodi von VirtualBox bietet ein Blogbeitrag von Werner Fischer und Thomas Krenn. Host-only Networking kann man einfach mit der Private Networks Configuration in Vagrant aktivieren. Zusätzlich sollte man gleich eine statische IP-Adresse vergeben, die sich für den späteren Zugriff per Ansible anbietet. All das konfiguriert eine einzige Zeile innerhalb der jeweiligen Vagrant-Box-Defintion:

masterlinux.vm.network "private_network", ip: "172.16.2.10" 

Dasselbe gilt für die Windows-Boxen. Im Hintergrund veranlasst Vagrant Virtual Box ein neues und separates Netzwerk zu erstellen (meist mit einem Namen wie "vboxnet2") und legt in jeder Maschine des Clusters eine virtuelle Netzwerkkarte mit der passenden IP an. Das ist alles, mit einer kleinen Ausnahme für die Windows-Server, der sich ein Folgeschritt widmet.

Ansible braucht Zugriff auf die Hosentaschen-Cloud

Wenn Entwickler sich dem Thema Provisionierung von Vagrant-Boxen nähern, fällt der Blick auf Vagrants Ansible-Provisioner. Damit konfiguriert man innerhalb der einzelnen Vagrantfiles das direkte Ausführen von Ansible Playbooks wie folgt:

config.vm.provision "ansible"
    do |ansible| ansible.playbook = "playbook.yml" 
end

Das war aber nicht beabsichtigt! Denn der Artikel sollte aufzeigen, wie man mit Ansible einen vollständigen Docker-Swarm-Cluster hochziehen kann. Dabei ist vor allem die Generierung und der Austausch von sogenannten Join-Tokens zwischen den Vagrant-Boxen notwendig. Wären die Ansible-Skripte in ebenso viele Playbooks aufgeteilt wie der Cluster an Nodes bereithält, wäre ein Austausch der Join-Tokens nicht möglich. Zusätzlich wäre das angestrebte Hochfahren der gesamten Applikation mit einem Ansible-Befehl in weite Ferne gerückt. Denn das war ja das gesetzte Ziel: Die Anwendung als Ganzes zu managen, ohne beachten zu müssen, dass sie verteilt innerhalb eines hybriden Clusters aus Windows- und Linux-Maschinen läuft.

Deshalb muss es ein zentrales Ansible Playbook geben, das alle Maschinen bändigen kann. Ansible bietet an, mehr als einen Server zu managen. Allerdings gilt es einen Fallstrick zu beachten! Verwendet man denselben Host mehrfach in unterschiedlichen Inventory-Gruppen, versucht Ansible, alle Konfigurationen für die jeweiligen Gruppen zu mergen. Das sollte man vermeiden. Es ist keine gute Idee, folgende Konfiguration umsetzen:

[masterwindows] 
127.0.0.1 
[masterlinux]  
127.0.0.1
[workerwindows]   
127.0.0.1  

Das Problem tritt vor allem lokal auf, denn dort haben alle Maschinen die gleiche IP. Besser ist es, unterschiedliche Alias-Namen für die jeweiligen Vagrant-Boxen zu vergeben. Verlässt man im späteren Projektverlauf die lokale Entwicklungsumgebung, sind die unterschiedlichen IP-Adressen eventuell nutzbar. Ist unter MacOS/Linux die Datei etc/hosts beziehungsweise unter Windows die Datei C:\Windows\system32\drivers\etc\hosts entsprechend erweitert, ist die Vergabe von lokalen Aliasnamen schnell erledigt. Dazu ist lediglich die Übernahme der folgenden Einträge in die jeweilige hosts-Datei erforderlich:

127.0.0.1 masterlinux01
127.0.0.1 workerlinux01 
127.0.0.1 masterwindows01
127.0.0.1 workerwindows01  

Der kleine manuelle Schritt ist meistens zu verschmerzen, lässt sich aber automatisieren. Beispielsweise kann das Vagrant-Plugin vagrant-hostmanager die Einträge automatisch anhand der im Vagrantfile definierten config.vm.hostname-Einträge konfigurieren. Allerdings wird die Eingabe des Root- beziehungsweise Administratorkennworts bei jeder Ausführung des Befehls vagrant up notwendig, was zu wiederholten manuellen Eingaben führt. Eine andere Alternative könnte die Nutzung der statischen IP-Adressen der Vagrant-Boxen sein. Es hat sich herausgestellt, dass sprechende Alias-Namen wie masterlinux01 oder workerwindows01 bei der späteren Ausführung der Ansible-Skripte hilfreich sein können, da folglich immer klar ist, was auf welcher Instanz gerade passiert. Gerade am Anfang kann das zu einem schnelleren Verständnis der benötigten Schritte beitragen und das Debugging vereinfachen, sollte etwas nicht funktionieren.

Mit der Konfiguration steht alles bereit, die "Cloud in der Hosentasche" direkt lokal auszuprobieren. Das Vagrant-Multi-Machine-Setup mit hybridem Cluster aus Windows- und Linux-Maschinen ist vollständig konfiguriert und fährt mit dem Kommandozeilenbefehl vagrant up hoch.

Einzige Voraussetzung: Lokal sollten noch 8 GB RAM verfügbar sein, denn jede der vier Vagrant-Boxen ist auf 2048 MB konfiguriert. Ein unbedarftes vagrant upkann problematisch sein, sollte nicht genug Arbeitsspeicher frei sein. Die Konfiguration lässt sich in der Datei Vagrantfile angepassen. Falls der heißgelaufene Laptop eine Pause braucht, reicht der simple Kommandozeilenbefehl vagrant halt, der alle Maschinen des Clusters herunterfährt.

Ansible marsch!

Jetzt ist alles bis auf eine kleine Hürde für die Arbeit von Ansible bereit,denn es soll ja am Ende ein Ansible Playbook den gesamten Docker-Swarm-Cluster initialisieren können. Das heißt, dass ein und dasselbe Ansible Playbook in der Lage sein muss, Windows- und Linux-Maschinen provisionieren zu können.

Das gleichzeitige Managen von Windows und Linux innerhalb des selben Playbook erfordert eine Konfigurationsmöglichkeit für die Art der Anbindung an die jeweilige Maschine. Denn Linux-Maschinen sind über SSH anzusprechen, Windows-Maschinen dagegen besser über WinRM. Der hierfür benötigte Konfigurationsparameter heißt ansible_connection. Das Provisionieren von beiden Betriebssystemen innerhalb des gleichen Ansible Playbook ist praktisch undokumentiert, funktioniert aber mitansible_connection.

Am besten zeigt das das Beispielprojekt des Artikels, das ein entsprechendes Hostsfile enthält:

[masterwindows]
masterwindows01

[masterlinux]
masterlinux01

[workerwindows]
workerwindows01

[workerlinux]
workerlinux01

[linux:children]
masterlinux
workerlinux

[windows:children]
masterwindows
workerwindows

Die ersten vier Definitionen ordnen einfach die Alias-Namen der Vagrant-Boxen passend zu den vier Kategorien innerhalb eines hybriden "Mixed-OS"-Clusters zu. Wie angedeutet sind das Manager- beziehungsweise Master-Nodes (masterwindows und masterlinux) sowie Worker-Nodes (workerwindows und workerlinux) mit Windows und Linux. Die letzten zwei Einträge im Hostsfile nutzen das "Group of Groups"-Feature von Ansible. Da alle Maschinen der Gruppen masterlinux und workerlinux auf Linux basieren, sind sie mit dem Suffix :children der Supergruppe linux zugeordnet. Dasselbe gilt für die Supergruppe windows. Dadurch ergibt sich die Struktur der Ansible-Gruppenvariablen.

Die Datei all.yml enthält als oberstes Element die Konfigurationsparameter, die für alle Maschinen im Cluster gelten sollen – egal, ob es sich um Windows- oder Linux-Boxen handelt. Da Nutzername und Passwort üblicherweise bei allen Vagrant-Boxen gleich sind, sind sie in der all.yml definiert:

ansible_user: vagrant
ansible_password: vagrant 

Die nächste Ebene der Gruppenstruktur fächert sich in windows.yml und linux.yml auf. Darin zieht das Schlüsselwort ansible_connection den erwähnten Joker und konfiguriert damit beide Verbindungstypen. Die linux.yml kommt simpel daher: ansible_connection: ssh.

Neben der Protokolldefinition durch ansible_connection nutzt man innerhalb der windows.yml noch eine zusätzliche Konfigurationsoption für die WinRM-Verbindung. Das ist notwendig, um Self-Signed-Zertifikate zu verwenden, die das Ansible-Konfigurationsskript standardmäßig generiert:

ansible_connection:winrm
ansible_winrm_server_cert_validation: ignore 

Die letzte Zutat für den erfolgreichen Aufruf aller Maschinen des Clusters durch Ansible ist die korrekte Portkonfiguration. Konkret nutzt man das Schlüsselwort ansible_connection, wie die Datei workerwindows.yml zeigt: ansible_port: 55996

Die Konfiguration muss für jede Maschine im Cluster vorliegen. Es zeigt sich die Notwendigkeit, den Port explizit im Vagrantfile festzulegen. Wie im Abschnitt "Vagrant ermöglicht die hybride Cloud in der Hosentasche" beschrieben, wird das über die Konfigurationsoption forwarded_port gelöst, die die betriebssystemspezifische id enthalten muss, bei der workerwindows-Maschine entsprechend:

workerwindows.vm.network "forwarded_port", guest: 5986, 
host: 55996, host_ip: "127.0.0.1", id: "winrm-ssl" 

Nun steht alles bereit, um aus einem Ansible Playbook heraus gleichzeitig Windows- und Linux-Boxen zu provisionieren. Sobald alle Maschinen des Clusters nach der Eingabe des Befehls vagrant up hochfahren, kann Ansible die Verbindung testen. Dazu muss man einfach im Ordner step4-windows-linux-multimachine-vagrant-docker-swarm-setup den folgenden Befehl ausführen, der die Verbindung zur Windows-Worker-Maschine workerwindows mit Hilfe des Ansible-Moduls win_ping testet: ansible workerwindows -i hostsfile -m win_ping

Ist alles korrekt konfiguriert, sollte auf das ping ein pong folgen:

workerwindows01 | SUCCESS => {
   "changed": false,
   "failed": false,
   "ping": "pong" 
 }     

Die Verbindung zu einem Linux-Node lässt sich nahezu identisch mit dem Ansible-Modul ping testen:ansible masterlinux -i hostsfile -m ping

Nur im Fall des ersten Zugriffs auf einen der Linux-Knoten sollte man ihn durch zwei weitere Befehle ergänzen. Denn Ansible möchte dieen gern zu den eigenen "known hosts" hinzufügen. Wie die Dokumentation vorschlägt, könnte das wie folgt aussehen:

export ANSIBLE_HOST_KEY_CHECKING=False            
ansible masterlinux -i hostsfile -m ping   
unset ANSIBLE_HOST_KEY_CHECKING

Mit der Installation des Programms sshpass lässt sich für Testzwecke das Generieren entsprechender Keys umgehen. Auf dem Mac geschieht das mit brew install https://raw.githubusercontent.com/kadwanev/bigboybrew/master/Library/Formula/sshpass.rb. Der Verbindungstest der Linux-Maschinen per Ansible sollte eine Erfolgsmeldung liefern, damit den Folgeschritten nichts mehr im Wege steht.

Zwischenfazit

Packer hat eine universell einsetzbare Vagrant Box mit Windows Server 2016 bereitgestellt. Darauf aufbauend ermöglicht das Vagrant-Multi-Machine-Setup die Konfiguration mehrerer Maschinen mit Windows und Linux – sozusagen die "Cloud in der Hosentasche". Alle Maschinen sind so konfiguriert, dass sie sich gegenseitig im Netzwerk erreichen können und für den Host ansprechbar sind. Der Zugriff von Ansible auf alle Maschinen ist mit dem Schlüsselwort ansible_connection möglich. Durch eine intelligente Gruppenstruktur innerhalb des Hostsfile ist die Provisionierung eines hybriden Clusters aus Windows- und Linux-Maschinen durchführbar. Der Verbindungsaufbau per Ansible zu allen Cluster-Nodes funktioniert. Und das alles aus demselben Ansible Playbook heraus.

Damit steht die Basis, um einen hybriden Docker Swarm mit Ansible im zweiten Teil des Artikels zu initialisieren und ein späteres Applikations-Deployment vorzubereiten. Dazu gehört unter anderem eine Docker-Swarm-Registry und eine vernünftige Docker-Swarm-Management-Oberfläche.

Jonas Hecht
führte die Überzeugung, dass Softwarearchitektur und Hands-on-Entwicklung zusammengehören, zu codecentric. Tiefgreifende Erfahrungen in allen Bereichen der Softwareentwicklung großer Unternehmen treffen bei ihm auf eine Leidenschaft für neue Technologien. (bbo)