Virtualisierung
Virtuelle Maschinen versus Container
Fortsetzung des Artikels von Teil 1
Docker und Kubernetes
Der Inbegriff einer Container-Lösung ist die Open-Source-Software Docker. Wer mehrere Container auf einem Host betreibt, muss diese managen. Dazu eignet sich die Orchestrierungslösung Kubernetes. Diese Werkzeuge haben sich durchgesetzt und automatisieren viele Aspekte für das Bereitstellen und Betreiben von Containern. Dazu gibt es wichtige Features für Hochverfügbarkeit, Loadbalancing (Lastverteilung), API (Schnittstellen), Autoscaling (automatisches Skalieren) oder Scheduling (Terminierung).
Gutes Management ist besonders für die sogenannten Microservices wichtig: Eine Anwendung lässt sich in kleine Bestandteile zerlegen, die jeweils in einem separaten Container parallel laufen. Solch eine kleine Einheit nennt sich Microservice, sie bildet nur einen Teilausschnitt der gesamten Softwareumgebung ab, zum Beispiel Authentifizierung, Speicherzugriff, Eingabe, Ausgabe oder Funktionen einer App. Das Umsetzen einer Microservice-Architektur ist jedoch nicht zwingend an die Container-Technologie geknüpft. Es funktioniert grundsätzlich auch mit VMs, dabei ist aber zu beachten, dass das Starten und Austauschen einer VM länger dauert als bei Containern.
Schnelles und portables (Entwickler-)Werkzeug
Die Microservices helfen Software-Entwicklern, schrittweise und schneller den Quellcode für eine Anwendung zu erstellen und zu kompilieren. Sie können fehlerhafte Microservices zügig korrigieren oder komplett neu schreiben und den betreffenden Container austauschen. Die Entwickler liefern ihren kompilierten Quellcode als Container-Image aus. Das Container-Image ist die Datenbasis, um die Instanz-Container abzuleiten – was auch mehrfach funktioniert. Die Entwickler packen alles für den Container-Betrieb inklusive Netzwerkkonfiguration und möglicher Anbindung an externe Systeme in das Container-Image. Ein Administrator erzeugt den oder die Container aus dem Image, indem dann die App(s) zu Testzwecken oder in einem Produktivsystem laufen. Der Effekt: Eine Anwendung wird extrem portabel. Wenn man das Container-Image im Netzwerk bereitstellt, können Zugriffsberechtigte schnell den Container auf ihrem Laptop, im Rechenzentrum oder in der Cloud starten, und zwar ohne die zum Teil aufwendige administrative Einrichtung der nötigen Umgebung.
Normalerweise ist ein Container bei nahezu jedem Cloud-Anbieter lauffähig. Er benötigt Betriebssystem und Middleware, die Cloud-Anbieter standardisiert vorhalten. Eine VM lässt sich hingegen nicht so ohne weiteres von Cloud A nach B verschieben, wenn diese unterschiedliche Hypervisor verwenden.
Die Software-Entwicklung mit Containern, die in der Public Cloud gehostet werden, ist aus zwei Gründen bereits Standard: Container bilden die Arbeitsweise der Entwickler ab, die diese Systeme zudem leicht selbst verwalten können. VMs verursachen mehr Verwaltungsaufwand, den man in der Cloud mit heterogenen Werkzeugen meistern muss. Allerdings ist ihr Cloud-Betrieb im Vergleich zu anderen Technologien verhältnismäßig günstig. Auch bringt eine virtuelle Maschine mehr Sicherheit, viel Flexibilität hinsichtlich Funktionsvielfalt und Freiheitsgraden mit.
Der bewährte Parallelbetrieb
Die Container- und VM-Technologien ergänzen sich. Üblich ist, beide zu kombinieren. Ein Beispiel: Auf einem Bare-Metal-Server betreibt ein Unternehmen mehrere VMs. In einer oder mehreren dieser VMs läuft eine Container-Umgebung. Kaum jemand wird noch einen Container direkt auf einem physischen Server laufen lassen. Auch in der Cloud erfolgt die Ressourcen-Bereitstellung fast ausschließlich über VMs, in denen sich dann Container betreiben lassen. Es ist daher eher die Regel, dass VMs und Container parallel zum Einsatz kommen.
Typisch ist, dass eine App in einem Container läuft, der normalerweise statusfrei ist. Ein Container sollte keine Daten enthalten, die verloren gehen würden, wenn man den Container durch einen anderen ersetzt. Deshalb wird die Datenhaltung so eingerichtet, dass die Daten extern auf einem Speicher oder einer Datenbank abgelegt sind. Der Parallelbetrieb funktioniert dann beispielhaft so: Während sich die Datenbank zur Datenhaltung in einer VM befindet, greift die App aus einem Container auf sie zu.
In einem weiteren gängigen Szenario löst eine VM einen Container ab. So hat sich in der Praxis durchaus bewährt, eine Testumgebung auf Containerbasis zu betreiben. Ist die App fertig, wird sie für den Produktivbetrieb über eine VM bereitgestellt, weil diese stark isoliert und sicherer ist.
Mit dem Schnellstarter klein anfangen
Container werden VMs so schnell nicht komplett ersetzen – aber an ihnen kommt man künftig nicht vorbei. Container stellen für viele Szenarien eine effiziente und einfache Methode dar, Leistung bereitzustellen, agil Software zu entwickeln, Self Services aufzusetzen und individuelle Nutzeranforderungen zu bedienen. Sobald Anwendungen nicht statusbehaftet sind, spielen Container ihre Vorteile aus. Diese liegen im Schnellstart, in der effektiven Nutzung von Microservices und dem leichten Austausch, sobald eine bessere App-Version verfügbar ist. VMs bleiben für Anwendungen, die das lange Speichern von Daten erfordern, vorerst voll im Spiel – allein oder zusammen mit Containern. Außerdem stellen sie für Unternehmen, die Anwendungen und Services in die Public Cloud verlagern, zunächst das ideale Betriebsmodell dar. Sie steuern ihre VMs wie gewohnt, nur dass diese dann in der Public Cloud laufen. Über die Zeit findet dann sinnvollerweise eine Transformation statt – weg vom reinen VM-Betrieb hin zur Nutzung von Plattform-as-a-Service-Diensten (PaaS), wie beispielsweise Container-Umgebungen. VMs sind zudem die etabliertere Virtualisierungstechnologie, weshalb Container-Neueinsteiger mit kleinen Projekten starten sollten.
Haiko Hertes ist Azure Cloud Architect bei SoftwareOne, Microsoft Most Valuable Professional (MVP) und Microsoft Certified Trainer (MCT)
- Virtuelle Maschinen versus Container
- Docker und Kubernetes
Lesen Sie mehr zum Thema
