Container 2.0: Auf dem Weg von stateless zu stateful

Lesezeit
2 Minuten
Bis jetzt gelesen

Container 2.0: Auf dem Weg von stateless zu stateful

11.10.2017 - 14:00
Veröffentlicht in:
Durch klar definierte Laufzeitumgebungen weisen Container eine hohe Portabilität auf und sind unabhängig von darunterliegenden Systemen. Noch sind sie überwiegend stateless und so im Aufbau und Betrieb relativ unkompliziert. Es kündigt sich jedoch eine Trendwende an: Unternehmen möchten verstärkt Anwendungen in Containern nutzen, die statusbehaftet, also stateful, sind. Einsatzszenarien sind etwa Big-Data-Verfahren oder ein einfacheres Verschieben von Anwendungen in die Public Cloud. Der Fachartikel schildert die Herausforderungen.
Im Gegensatz zu einer virtuellen Maschine sind Container komplett unabhängig von darunterliegenden Systemen. Ihre Vorteile beziehen sie daraus, dass sie nicht zustandsbehaftet – also stateless – sind. Sie sind ideal für den Einsatz von Microservices. Diese kleinen Dienste übernehmen in der Regel nur ein bis zwei Aufgaben und sind daher sehr überschaubar. Mit ein paar Zeilen Code in einen Container verpackt, sind sie schnell deployed. Stateless-Container lassen sich durch vorgefertigte Images in kürzester Zeit neu erstellen oder wegwerfen. Sie sind immutable und die DevOps-Teams müssen sich keine Gedanken um die darin befindlichen Daten machen.

Sie lassen sich beliebig zwischen verschiedenen Cloud-Umgebungen, Bare-Metal-Servern oder Rechenzentren verschieben – im Hinblick auf Hybrid- und Multi-Cloud-Szenarien ein ideales Gesamtpaket. Doch genau dieses hohe Bereitstellungstempo sowie den geringen Overhead für benötigte Ressourcen und Management, wollen immer mehr IT-Abteilungen auch für Stateful-Container. Für diese hat vor einem Jahr Florian Leibert, CEO von Mesosphere, den Begriff "Container 2.0" geprägt und das Thema in den Fokus der Container-Community gerückt.

Logische Weiterentwicklung des Containereinsatzes
Der Einsatz von Container 2.0 ist in der Tat ein logischer Schluss. Im Grunde hat Docker die Möglichkeit, persistente Daten abzulegen, bereits von Anfang an mitgebracht. Seitdem haben aber vor allem die pflegeleichteren Container 1.0 das Geschehen dominiert. Allerdings ist es in der heutigen IT-Landschaft so, dass die ein oder andere Anwendung von längerfristig vorgehaltenen Daten abhängig ist. So sind etwa Datenbanken per se stateful. Diese in Container zu packen, ist also nicht ganz einfach.

Viele der bekannten Container-Orchestrierungs-Engines haben nach und nach Features für das Ablegen von persistenten Daten in einen Storage eingeführt. Kubernetes veröffentlichte mit Version 1.5 die StatefulSets (vorher PetSets) zum Verwalten von zustandsbehafteten containerisierten Anwendungen. Mesosphere bietet Funktionen für persistenten Storage seit Marathon Version 1.0. Im Kern sollte es mit Container 2.0 möglich sein, Datenbanken zusätzlich mit in einen Docker-Container aufzunehmen. Dieses Szenario ist speziell für Multi-Cloud-Umgebungen interessant, da auf diese Weise Datenbanken schneller bereitstehen und es einfacher ist, die darin befindlichen Daten in verschiedene Speicher zu verteilen und schneller zu skalieren.

Hürde Skalierbarkeit
Die Skalierbarkeit von Stateful-Containern ist nicht ganz trivial. Bezogen auf das Beispiel der Datenbanken: Sind gerade erst neue Daten eingepflegt, ist es im Vergleich zum Handling der Container 1.0 nicht möglich, diese einfach zu löschen und neu bereitzustellen. DevOps-Teams müssen genau hinschauen, wie die Container aufgebaut und geclustert sind. Da es sich bei einem Großteil von Stateful-Containern um Datenbanken oder Message Queues handelt, müssen diese oft längerfristig verfügbar sein. Wichtige Daten sollten nicht verloren gehen. Es ist daher sinnvoll, Datenbanken hochverfügbar bereitzustellen, etwa MongoDB als Replica Set oder MySQL als Galera Cluster.

Darüber hinaus sind Mechanismen zu berücksichtigen, die auslösen, wenn etwas mit der Datenbank passiert. Überprüfen etwa Container Health Checks bestimmte TCP- oder UDP-Ports? Ist dies der Fall und der Port nicht mehr erreichbar, lösen sie eine Neuskalierung aus. Ein Beispiel: MySQL lauscht auf dem Port 3306. Fällt die Datenbank auf diesem Port aus, bekommt der Health Check keine Antwort zurück. Dann erfolgt die Löschung des Containers. Anschließend beginnt der Aufbau eines neuen Containers, der die MySQL-Datenbank wieder startet. Listing 1 stellt ein detaillierteres Beispiel für eine Stateful-Datenbank auf einem Prometheus-Server dar. Prometheus ist hier stateful mit Health Check auf Port 9090 bereitgestellt. Fällt dieser Server auf dem Port aus, wird er neu aufgebaut. Die Daten liegen persistent auf einem NFS-Server.

In Docker-Container verpackte Stateful-Anwendungen sind nur eine Möglichkeit der Skalierung. Derzeit setzt sich die Community unter anderem mit Skalierung im Storage-Bereich auseinander. Dort ist die Entwicklung aktuell stark im Fluss und noch hat sich kein Best Practice herauskristallisiert. Dieses wird aber sicherlich in naher Zukunft der Fall sein, denn Stateless-Container eignen sich ebenso für Big-Data-Szenarien. Für diese sind verteilte Storages besonders relevant. Ein Beispiel wäre in diesem Szenario der Einsatz von Elasticsearch zum Verarbeiten großer Datenmengen. Diese Anwendung ist heute bereits ebenfalls als Stateful-Container ausführbar. In Listing 2 finden Sie ein Beispiel für einen containerisierten Elasticsearch-Cluster.

Seite 1: Logische Weiterentwicklung des Containereinsatzes
Seite 2: Container-Orchestrierung wird kritischer


Seite 1 von 2 Nächste Seite >>


ln/Michael Vogeler, Systemadministrator im Bereich Application and Database Services bei Nexinto.

Ähnliche Beiträge

Azure mit lokalen Netzen verbinden (3)

Azure bietet vielfältige Möglichkeiten, um Ressourcen in der Cloud mit lokalen Netzwerken zu verbinden. Dazu gehören auch Sicherheitsmechanismen und Loadbalancer, die den Datenverkehr zwischen Cloud und lokalem Rechenzentrum nicht nur zur Verfügung stellen, sondern absichern und hochverfügbar konfigurieren. IT-Administrator zeigt die Wege auf, um die Cloudumgebung mit dem lokalen Netzwerk zu verbinden. Im dritten und letzten Teil der Workshopserie zeigen wir, wie Sie virtuelle Firewalls hochziehen.

Azure mit lokalen Netzen verbinden (2)

Azure bietet vielfältige Möglichkeiten, um Ressourcen in der Cloud mit lokalen Netzwerken zu verbinden. Dazu gehören auch Sicherheitsmechanismen und Loadbalancer, die den Datenverkehr zwischen Cloud und lokalem Rechenzentrum nicht nur zur Verfügung stellen, sondern absichern und hochverfügbar konfigurieren. IT-Administrator zeigt die Wege auf, um die Cloudumgebung mit dem lokalen Netzwerk zu verbinden. Im zweiten Teil binden wir den Connection Broker an und erklären, was es mit dem Cloud Witness auf sich hat.

Azure mit lokalen Netzen verbinden (1)

Azure bietet vielfältige Möglichkeiten, um Ressourcen in der Cloud mit lokalen Netzwerken zu verbinden. Dazu gehören auch Sicherheitsmechanismen und Loadbalancer, die den Datenverkehr zwischen Cloud und lokalem Rechenzentrum nicht nur zur Verfügung stellen, sondern absichern und hochverfügbar konfigurieren. IT-Administrator zeigt die Wege auf, um die Cloudumgebung mit dem lokalen Netzwerk zu verbinden. Im ersten Teil der Workshopserie schildern wir das Prinzip virtueller Netzwerke.