von Redaktion IT-A…
Lesezeit
2 Minuten
Seite 2 - Container 2.0: Auf dem Weg von stateless zu stateful
Containerisierung von Bestandsapplikationen
Gerade Unternehmen, die die Containerisierung ihrer bestehenden Anwendungen angehen wollen, sollten sich über Container 2.0 Gedanken machen. Aufgrund der Anwendungshistorie sind sehr wahrscheinlich persistente Daten involviert. Da stellt sich die Frage, ob es für Unternehmen nicht empfehlenswert ist, direkt mit Container 2.0 zu starten, und neue Services dann als Stateless-Container umzusetzen. Wie so oft lautet darauf die Antwort: jein. Es kommt oft auf die Art der Anwendung an. Bei der neuen Anwendungsentwicklung haben Stateless-Container und -Microservices klar die Nase vorn.
Geht es beispielsweise um ein Redesign einer Webshop-Plattform, ist es in der Tat einfacher, den bestehenden Monolithen in kleine Services zu zerschneiden und, wenn erforderlich, einen Stateful-Service separat daneben zu stellen. Auf diese Weise erhalten Unternehmen leicht zu handhabende Microservices in Stateless-Containern und behandeln lediglich den einen zustandsbehafteten Dienst gesondert. Hier bietet sich also eine Kombination aus beidem an. Generell steht hinter Container 2.0 das Ziel, abhängige Daten direkt mit in die Container zu packen. Mittlerweile bieten Software-Hersteller, wie etwa Oracle für seine Datenbank, ihre Services bereits containerisiert mit zustandsbehafteten Daten an. Das reduziert den Aufwand für die IT-Abteilungen. Der Trend geht verstärkt in die Richtung, Business-Software in dieser Form anzubieten, sodass sich die Frage, ob Container 1.0 oder 2.0, gar nicht mehr grundlegend stellt.
Container-Orchestrierung wird kritischer
Wie ihre zustandslosen Verwandten gilt es ebenso, Stateful-Container im Betrieb zuverlässig zu orchestrieren. Dafür gibt es die bereits erwähnten Orchestrierungs-Engines verschiedener Hersteller. Zu den Platzhirschen zählt hier etwa Kubernetes. Sein StatefulSet ist dafür ausgelegt, Stateful-Applikationen im Cluster vorzuhalten. Alternativ funktionieren ebenso Features von Docker Compose. Sie erlauben es, Stateful-Applikationen wie MongoDB, MariaDB oder Elasticsearch, die Daten in großen Mengen abspeichern, in Containern laufen zu lassen.
Prinzipiell unterscheiden sich die Anforderungen an die Orchestrierung zwischen den beiden Container-Typen deutlich, denn es gilt immer zu überlegen: Was passiert, wenn der Stateful-Container verschwindet? Zustandslose Container sind immutable. Daher ist es einfach, diese nach Bedarf zu skalieren. Bei Stateful-Containern funktioniert dies nicht: Beim Löschen gehen die Daten verloren. Handelt es sich dabei lediglich um einen Zwischenspeicher, etwa bei einer Cassandra-Datenbank, die lediglich als Cache fungiert, entsteht kein größerer Schaden. Kritischer sieht es aus, wenn es um wichtige Daten etwa aus einer MongoDB geht.
Über Docker sind für Container 2.0 Health Checks automatisiert möglich. Sie führen bei Bedarf einen Restart aus. Ohne Docker müssten IT-Administratoren direkt auf das System gehen und diese manuell neustarten. Für Datenbanken ist es empfehlenswert, diese von Grund auf als Replica Set aufzubauen. Dafür sollte etwa ein MongoDB Replica Set mit einem Loadbalancer wie HAProxy bereitgestellt sein. Fällt dann ein Node aus, übernimmt einer der anderen. Ebenfalls sollte jeder Primary Node und Secondary Node mit einem Health Check auf Port 27017 ausgestattet sein. Auf diese Weise ist die Datenbank hochverfügbar.
Wenn anschließend die primäre MongoDB ausfällt, übernehmen die anderen Replicas und bestimmen einen neuen Primary Node. Über einen Container Orchestrator ist es möglich, den ausgefallenen Container via Health Check neu aufzubauen. Dieser fügt sich dann selbständig wieder in den Cluster ein und dient als Secondary Node. Während dieses Vorgangs ist der Cluster durchgehend für die Applikation erreichbar. Es kommt also zu keinem Betriebsausfall der Anwendung. Ein weiterer Vorteil: Dieses Setup ist auf Self-healing ausgelegt. IT-Administratoren müssten erst dann eingreifen, wenn der ausgefallene Replica nicht mehr startet und er die Ursache dafür genauer untersuchen muss.
Fazit
Stateful-Container erfordern im Aufbau und Betrieb eine erhöhe Aufmerksamkeit. Ihr Einsatz ist vor allem in DevOps-Teams sehr sinnvoll, da sowohl Entwicklung als auch Betrieb gemeinsam abschätzen müssen, welche Abhängigkeiten sich durch zustandsbehaftete Anwendungen ergeben und was daraus für das Handling dieser Container resultiert. Selbst wenn die grundlegenden Funktionen für Aufbau und Betrieb von Container 2.0 von Docker schon früh gegeben waren, handelt es sich hierbei um ein noch junges Konzept. Viele Unternehmen starten gerade erst mit den einfacheren und wesentlich unkritischeren Containern 1.0. In Hinblick auf die erhofften Vorteile, ist davon auszugehen, dass die Container-Community aus Herstellern und Anwendern in naher Zukunft weitere Technologien und Best Practices für Stateful-Container entwickeln wird. Damit sollte dann absehbar der Automatisierungsgrad steigen und das Handling wird vereinfacht.
Seite 1: Logische Weiterentwicklung des Containereinsatzes
Seite 2: Container-Orchestrierung wird kritischer
ln/Michael Vogeler, Systemadministrator im Bereich Application and Database Services bei Nexinto.
Gerade Unternehmen, die die Containerisierung ihrer bestehenden Anwendungen angehen wollen, sollten sich über Container 2.0 Gedanken machen. Aufgrund der Anwendungshistorie sind sehr wahrscheinlich persistente Daten involviert. Da stellt sich die Frage, ob es für Unternehmen nicht empfehlenswert ist, direkt mit Container 2.0 zu starten, und neue Services dann als Stateless-Container umzusetzen. Wie so oft lautet darauf die Antwort: jein. Es kommt oft auf die Art der Anwendung an. Bei der neuen Anwendungsentwicklung haben Stateless-Container und -Microservices klar die Nase vorn.
Geht es beispielsweise um ein Redesign einer Webshop-Plattform, ist es in der Tat einfacher, den bestehenden Monolithen in kleine Services zu zerschneiden und, wenn erforderlich, einen Stateful-Service separat daneben zu stellen. Auf diese Weise erhalten Unternehmen leicht zu handhabende Microservices in Stateless-Containern und behandeln lediglich den einen zustandsbehafteten Dienst gesondert. Hier bietet sich also eine Kombination aus beidem an. Generell steht hinter Container 2.0 das Ziel, abhängige Daten direkt mit in die Container zu packen. Mittlerweile bieten Software-Hersteller, wie etwa Oracle für seine Datenbank, ihre Services bereits containerisiert mit zustandsbehafteten Daten an. Das reduziert den Aufwand für die IT-Abteilungen. Der Trend geht verstärkt in die Richtung, Business-Software in dieser Form anzubieten, sodass sich die Frage, ob Container 1.0 oder 2.0, gar nicht mehr grundlegend stellt.
Container-Orchestrierung wird kritischer
Wie ihre zustandslosen Verwandten gilt es ebenso, Stateful-Container im Betrieb zuverlässig zu orchestrieren. Dafür gibt es die bereits erwähnten Orchestrierungs-Engines verschiedener Hersteller. Zu den Platzhirschen zählt hier etwa Kubernetes. Sein StatefulSet ist dafür ausgelegt, Stateful-Applikationen im Cluster vorzuhalten. Alternativ funktionieren ebenso Features von Docker Compose. Sie erlauben es, Stateful-Applikationen wie MongoDB, MariaDB oder Elasticsearch, die Daten in großen Mengen abspeichern, in Containern laufen zu lassen.
Prinzipiell unterscheiden sich die Anforderungen an die Orchestrierung zwischen den beiden Container-Typen deutlich, denn es gilt immer zu überlegen: Was passiert, wenn der Stateful-Container verschwindet? Zustandslose Container sind immutable. Daher ist es einfach, diese nach Bedarf zu skalieren. Bei Stateful-Containern funktioniert dies nicht: Beim Löschen gehen die Daten verloren. Handelt es sich dabei lediglich um einen Zwischenspeicher, etwa bei einer Cassandra-Datenbank, die lediglich als Cache fungiert, entsteht kein größerer Schaden. Kritischer sieht es aus, wenn es um wichtige Daten etwa aus einer MongoDB geht.
Über Docker sind für Container 2.0 Health Checks automatisiert möglich. Sie führen bei Bedarf einen Restart aus. Ohne Docker müssten IT-Administratoren direkt auf das System gehen und diese manuell neustarten. Für Datenbanken ist es empfehlenswert, diese von Grund auf als Replica Set aufzubauen. Dafür sollte etwa ein MongoDB Replica Set mit einem Loadbalancer wie HAProxy bereitgestellt sein. Fällt dann ein Node aus, übernimmt einer der anderen. Ebenfalls sollte jeder Primary Node und Secondary Node mit einem Health Check auf Port 27017 ausgestattet sein. Auf diese Weise ist die Datenbank hochverfügbar.
Wenn anschließend die primäre MongoDB ausfällt, übernehmen die anderen Replicas und bestimmen einen neuen Primary Node. Über einen Container Orchestrator ist es möglich, den ausgefallenen Container via Health Check neu aufzubauen. Dieser fügt sich dann selbständig wieder in den Cluster ein und dient als Secondary Node. Während dieses Vorgangs ist der Cluster durchgehend für die Applikation erreichbar. Es kommt also zu keinem Betriebsausfall der Anwendung. Ein weiterer Vorteil: Dieses Setup ist auf Self-healing ausgelegt. IT-Administratoren müssten erst dann eingreifen, wenn der ausgefallene Replica nicht mehr startet und er die Ursache dafür genauer untersuchen muss.
Fazit
Stateful-Container erfordern im Aufbau und Betrieb eine erhöhe Aufmerksamkeit. Ihr Einsatz ist vor allem in DevOps-Teams sehr sinnvoll, da sowohl Entwicklung als auch Betrieb gemeinsam abschätzen müssen, welche Abhängigkeiten sich durch zustandsbehaftete Anwendungen ergeben und was daraus für das Handling dieser Container resultiert. Selbst wenn die grundlegenden Funktionen für Aufbau und Betrieb von Container 2.0 von Docker schon früh gegeben waren, handelt es sich hierbei um ein noch junges Konzept. Viele Unternehmen starten gerade erst mit den einfacheren und wesentlich unkritischeren Containern 1.0. In Hinblick auf die erhofften Vorteile, ist davon auszugehen, dass die Container-Community aus Herstellern und Anwendern in naher Zukunft weitere Technologien und Best Practices für Stateful-Container entwickeln wird. Damit sollte dann absehbar der Automatisierungsgrad steigen und das Handling wird vereinfacht.
Seite 1: Logische Weiterentwicklung des Containereinsatzes
Seite 2: Container-Orchestrierung wird kritischer
| << Vorherige Seite | Seite 2 von 2 |
ln/Michael Vogeler, Systemadministrator im Bereich Application and Database Services bei Nexinto.
