Agile Infrastruktur und Continuous Delivery in CoreMedia – Cluster Scheduler – Teil4

Let’s think again about the end goal: An environment in which the deployment of features in CoreMedia can be quick and easy. A basic requirement for this is a cluster that can orchestrate Docker containers. There are several solutions on the market:

• Apache Mesos, or DC/OS (an extended product variant from Mesosphere)
• Kubernetes (originally developed by Google, now open source)
• DockerSwarm
• rancher
• Nomad (from HashiCorp, the maker of Terraform)
• Mantle
• etc.

All of these tools (more or less) manage a number of hardware nodes and ensure that Docker containers are distributed across these hosts. For our showcase, we chose DC/OS (short for Data Center Operating System) from Mesosphere because it is quick and easy to install and suitable for productive use in the corporate sector. Docker Swarm is from Docker Inc. (the company behind Docker) itself, but is relatively new and still unstable and, in our view, not suitable for corporate use in the productive sector; but is certainly very promising for the future. Kubernetes has a high level of community participation and is also used in companies. We will evaluate Kubernetes in a separate series of articles. Of course, the differences are much more detailed, but we do not want to go into the differences in this article, but rather take a closer look at our tool of choice.

Mesos treats all resources of all hardware nodes in the cluster as a single computer. For each service to be distributed in the cluster, a JSON file is created which declaratively specifies how many CPU resources, RAM or disk space should be allocated to this app. A master node takes on the role of distribution and administration. Connected agents (known as slaves before version 1) then execute the service. Each agent gives the master information about how many resources it still has available (offers) and the master decides which agent should execute the service. In productive systems, at least 3 master nodes should be installed (but a maximum of 5). This ensures that the cluster can operate even if a master fails. The odd number of masters is a recommendation due to the algorithm used for cluster management. Any number of agents can be added to the cluster. Mesosphere has carried out tests with 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.