Führen wir uns noch einmal das Endziel vor Augen: Eine Umgebung, in der das Deployment von Features in CoreMedia schnell und unkompliziert von statten gehen kann. Eine Grundvoraussetzung hierfür ist ein Cluster, welches Docker Container orchestrieren kann. Es gibt auf dem Markt einige Lösungen:
- Apache Mesos, bzw. DC/OS (eine erweiterte Produkt Variante von der Firma Mesosphere)
- Kubernetes (ursprünglich von Google entwickelt, jetzt Open Source)
- Docker Swarm
- Rancher
- Nomad (von HashiCorp, dem Hersteller von Terraform)
- Mantl
- etc.
All diese Tools (mehr oder weniger) managen eine Anzahl an Hardware Nodes und sorgen für das verteilen von Docker Containern auf diesen Hosts. Für unseren ShowCase haben wir uns für DC/OS (kurz für Data Center Operating System) von Mesosphere entschieden, weil es schnell und unkompliziert zu installieren und für den produktiven Einsatz im Unternehmensbreich geeignet ist. Docker Swarm ist von Docker Inc. (der Firma hinter Docker) selbst, ist aber relativ neu und noch instabil und aus unserer Sicht nicht für den Unternehmseinsatz im produktiven Bereich geeignet; ist aber mit Sicherheit sehr vielversprechend für die Zukunft. Kubernetes hat eine hohe Community Beteiligung und durchaus auch in Unternehmen im Einsatz. Wir werden Kubernetes in einer gesonderten Artikelserie evaluieren. Natürlich sind die Unterschiede sehr viel detaillreicher, wir wollen aber im Rahmen dieses Artikels nicht auf die Unterschiede eingehen, sondern unser Tools der Wahl genauer beleuchten.
Mesos behandelt alle Ressourcen aller Hardwarenodes im Cluster als einen einzelnen Computer. Für jeden Dienst der im Cluster verteilt werden soll wird eine Json Datei erstellt, welches deklarativ vorgibt wie viele CPU Ressourcen, RAM oder Disk Space dieser App zugewiesen werden soll. Ein Masternode übernimmt dabei die Rolle der Verteilung und Verwaltung. Angeschlossene Agents (vor Version 1 noch Slaves genannt) führen die Dienst dann aus. Dabei gibt jeder Agent Infromationen an den Master wieviele Ressourcen er noch zu Verfügung hat (Offers) und der Master entscheidet welcher Agent den Dienst ausführen soll. In produktiven Systemen sollten mindestens 3 Master Nodes installiert sein (maximal aber 5). Dies gewährleistet die Operationsfähigkeit des Clusters auch wenn ein Master ausfällt. Die ungerade Anzahl der Master ist ein Empfehlung aufgrund des verwendeten Algorithmus für die Clusterverwaltung. Es können beliebig viele Agents ins Cluster aufgenommen werden. Mesosphere hat Tests durchgeführt mit 50.000 Nodes.
Mesos alleine verwaltet im Grunde nur Ressourcen und ist für die Betriebsfähigkeit des Cluster verantwortlich. Für das Orchestrieren von Docker Containern brauchen wir ein sogenanntes Framework in Mesos. Frameworks sind Applikationen, die gegen die Mesos Api programmiert sind. Ein solches Framework ist Marathon – ein Container Orchestrierungstool oder auch Scheduler genannt. Dem entsprechend muss man in der Marathon App Definition (Json Datei) auch angeben von welchem Image der Container gestartet werden soll. Dabei können die Images in einem lokalen oder remote docker registry (wie docker hub oder quay.io liegen). In der Json Datei kann man ferner angeben wie viele Instanzen der jeweiligen App gestartet werden sollen, z.B. vier Delivery CAEs. Ein wichtiger Teil der Json Datei ist die HealthCheck Definition. Das ist ein zentraler Punkt für spätere Deployments mit Zero Downtime und Blue/Green Deployments oder Canary Releases. Der definierte Healtcheck gibt an, ob die Applikation erfolgreich gestartet ist und noch läuft. Ein Healtcheck kann z.B. auf das Vorhandensein einer Webressource prüfen (HTTP Response Code 200).
Die Healtchecks erfüllen auch einen anderen Zweck. In einem späteren Artikel dieser Serie werden wir sehen wie Dienste im Cluster automatisch neu gestartet werden, wenn sie ausfallen. Ebenso sind Healtchecks wichtiger Bestandteil des Blue/Green und Zero Downtime Deployments.
Was wir im Cluster noch installieren ist der Marathon Loadbalancer. Dahinter steckt ein HAProxy mit dynamischen Update der Konfigurationsdateien. Der HAProxy läuft auf dem öffentlich zugänglichen Server des Clusters und routet eingehende Verbindungen zu den entsprechenden Containern auf den private Agents. Dazu definiert man Serviceports, die auf Container-, bzw. Hostports der jeweiligen Nodes gemapped werden. Der HAProxy kann auch als SSL Terminator dienen mit einem geeigneten Zertifikat.
Sind Mesos, Marathon und HAProxy installiert (wie wir gesehen haben sind diese drei Tools in unter 15 Minuten installiert INKL. frischen Servern in der Cloud), kann mit nur einem Befehl eine Kette von CoreMedia Diensten in dem Cluster hochgefahren werden:
[bash]dcos marathon group add ./private-init-showcase.json[/bash]
Hier ein Auszug aus der Datei mit der Definiton für die Preview CAE,
Nach dem Absetzen des Befehles wird Mesos/Marathon die Ressourcen auf den entsprechenden Agents allockieren, Marathon wird die Images von der Docker Registry per Pull ziehen und die Container starten. Dabei haben wir zwei Applikationsgruppen definiert: Persistence und CMS. In der Persistance Gruppe haben wir eine Solr, den WFS und die MySql. Die Grupper CMS ist von der Gruppe Persistence abhängig und wird nur gestartet, wenn Persistance erfolgreich gestartet ist.
Am Ende werfen wir einen Blick auf das Dashboard von Marathon, in dem wir den Status des Clusters und deployten Services sehen können:
In unserer Demo dauert es bis zum funktionsfähigen CoreMedia Cluster ca. 25 Minuten. Dann haben wir Server in der Cloud neu instanziiert und die CoreMedia Infrastruktur aufgesetzt; alles automatisiert und auf Knopfdruck.
Wenn Sie mehr wissen möchten über die Container Technologie, DevOps, Agile Infrastrukturen im CoreMedia Umfeld dann melden Sich sich zu einem unverbindlichen WebEx Meeting an oder vereinbaren einen Termin bei Ihnen vor Ort. Wir führen Ihnen die Vorteile und enormen Zeitgewinne gerne live und in Farbe vor.
