Eines steht fest: Container sind zwar alles andere als einfach zu betreiben, aber die Vorteile überwiegen und der Trend zur Containerisierung wird weiter anhalten. [...]
Die IT-Abteilungen müssen sich jetzt darauf vorbereiten, den Schritt zu Container-Umgebungen in den nächsten Jahren zu vollziehen.“ So lautet die deutliche Ansage von Marc Kleff, Director Solutions Engineering beim Datenspeicher-Spezialisten NetApp. Langfristig rechnet er damit, dass Container den Großteil der Anwendungen abdecken.
Die sogenannte Containerisierung gilt als einer der bedeutendsten Umbrüche in der IT-Welt: gekapselte Anwendungen, die unabhängig voneinander ausgeführt werden – ganz egal wo sie sich gerade befinden. Das erleichtert vor allem den IT-Abteilungen die Arbeit ungemein. So stehen Unternehmen in Sachen Digitalisierung momentan unter einem enormen Erfolgsdruck, der vor allem die Anforderungen an die IT-Abteilungen hochschraubt. Mit Containern lassen sich neue Anwendungen und Dienste schnell und flexibel zur Verfügung stellen.
Doch trotz aller Vorteile der Container-Technologie, zum Standard gehören sie in den Unternehmen bislang nicht. Stephan Michard, Senior Systems Engineer bei Dell Technologies, bestätigt dies: „Unsere Gespräche mit Unternehmen zeigen, dass viele noch nicht in der Lage sind, Container-Applikationen zu betreiben.“
Die Containerisierung spielt derzeit vor allem in der Planung von neuen Software-Systemen eine große Rolle, so die Erfahrung von Simon Fleischer, Teamleiter Software Engineering bei der IT-Beratung Consol. Architekten und DevOps-Ingenieure würden ihren Einsatz häufig in der Konzeptionsphase erwägen. Allerdings müssten Container nicht in jeder Umgebung die beste Wahl sein und oft sei es wirtschaftlich nicht sinnvoll, jedes Altsystem in Container umzuziehen. „Man kann also sagen, dass Container längst ‚angekommen‘ und reif für den Produktiveinsatz sind. Von einer flächendeckenden Durchdringung zu sprechen, wäre jedoch übertrieben.“ Aber: „Viele Unternehmen nutzen bereits Container und wissen es gar nicht, denn viele Produkte aus dem Bereich Software as a Service setzen im Hintergrund auf Containern auf.“
Zu einem ähnlichen Ergebnis kommt die aktuelle Studie „Container in der IT und ihr Potenzial in deutschen Unternehmen“ des IT-Dienstleisters Cronon und der Analysten von Techconsult: Für 38 Prozent der Unternehmen, die Container im Einsatz haben oder dies planen, stellt das mangelnde Know-how über die Technologie ein Hemmnis dar und erschwert die Implementierung, „weshalb in solchen Fällen eher auf altbewährte und sogar veraltete Konzepte zurückgegriffen wird“. Die Vorteile von Containern haben die Unternehmen aber erkannt: 78 Prozent halten es für wahrscheinlich, dass Container-Technologie künftig ein fester Bestandteil ihrer IT-Landschaft sein wird.
De-facto-Standard Kubernetes
„Technisch gesehen sind Container eine logische Weiterentwicklung diverser Innovationen im Linux-Kernel wie Cgroups oder Namespaces über das letzte Jahrzehnt. Dazu kommt die Etablierung von Kubernetes und einem ganzen Ökosystem von Projekten“, so Björn Brundert, Principal Solution Engineer Application Platforms beim Cloud- und Virtualisierungs-Spezialisten VMware. Bei Kubernetes handelt es sich um ein ursprünglich von Google entwickeltes und inzwischen als Open Source zur Verfügung stehendes Tool zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen. Kubernetes hat sich mittlerweile als Standard für die Verwaltung von Containern etabliert.
Während Kubernetes und Containerisierung große Vorteile mit sich bringen können, braucht deren Realisierung, wie es bei jeder neuen Technologie der Fall ist, jedoch ihre Zeit. Der technische Reifegrad, das Ökosystem an Tools und nicht zuletzt auch das vorhandene Wissen, zum Beispiel bei den Entwicklern, sind hier nur einige Faktoren. Kubernetes ist zwar eine komplexe Software, die es Nutzern einfacher macht, verteilte Systeme zu bauen – „aber nicht jede Anwendung eignet sich hierfür beziehungsweise die Verwendung kommt erst in einem neueren Release von Kubernetes infrage“, schränkt Björn Brundert ein.
Mit zentralen Updates alle drei Monate schaffe Kubernetes jedoch zunehmend neue Möglichkeiten und decke neue Anwendungsfälle ab.
Auch laut Marc Kleff von NetApp hat sich Kubernetes als Quasi-Standard im Bereich der Container erfolgreich durchgesetzt: „Die Lösung ist komplex, bietet aber auch einen sehr großen Mehrwert und eine hohe Entwicklungsgeschwindigkeit. Da viele Alternativen nicht mithalten konnten, wurden sie bereits von Kubernetes verdrängt.“
Dabei ist Kubernetes allerdings kein Allheilmittel und schon gar keine eierlegende Wollmilchsau: Zwar nimmt Kubernetes den DevOps-Teams die meiste Arbeit ab, wenn es um Orchestrierung und Management geht, aber einen kompletten Überblick erhält man erst durch ein vernünftiges Monitoring. Hierfür eignen sich zum Beispiel die Tools Prometheus und Grafana. Letztlich erfordert ein erfolgreiches Container-Management aber ein ganzes Potpourri unterschiedlicher Tools, zum Beispiel für den sicheren Zugriff auf Datenbanken oder andere Unternehmens-Services.
Früher war vor allem das Container-Verwaltungs-Tool Docker beliebt. Auch wenn dessen Bedeutung schwindet, so ist es in den Unternehmen doch weiterhin vertreten: „Gerade beim Evaluieren neuer Software und solange es sich nicht um eine reine Microsoft-Umgebung handelt, gehört Docker für Entwickler zum Standard“, berichtet Frank Haumann. Er ist Partner beim Cloud-Dienstleister Red Reply. Vermehrt sehe er Docker in produktiven Umgebungen und bei Kunden, die versierter im Umgang mit der CI/CD-Pipeline (Continuous Integration and Continuous Delivery) sind. Doch je größer die Installationen seien, desto häufiger treffe man auf das Container-Management-Framework Kubernetes, „das sich verstärkt zum Standard entwickelt und ältere Frameworks wie Cloud Foundry, Apache Mesos oder Docker Swarm ablöst“. Haumann unterstreicht: „Ohne Kubernetes sind Lösungen mit mehreren Hundert Containern nicht mehr wirtschaftlich und sicher zu betreiben.“ Kubernetes bringe aber auch eine Komplexität mit sich, die Operations-Teams vor Herausforderungen stelle. Aus diesem Grund wanderten viele Kubernetes-Installationen als Managed Kubernetes in Private oder Public Clouds.
Container versus VMs
Häufig hört man, dass Container sogar virtuelle Maschinen (Virtual Machines, VMs) obsolet machen. Virtualisierung und Container zu vergleichen ähnelt jedoch dem sprichwörtlichen Vergleich von Äpfeln und Birnen. VMs stellen (virtualisierte) Hardware bereit. „Das eröffnet Unternehmen ab ‚Oberkante Hardware ‘ alle Freiheiten, zum Beispiel bei der Wahl des Betriebssystems“, erklärt Thomas Franz. Er leitet den Technologiebeirat beim IT-Dienstleister Adesso. Container-Umgebungen hingegen arbeiteten auf einem Betriebssystem, das für eine bestimmte Hardware-Architektur konzipiert sei. Diese unterschiedlichen Freiheitsgrade hätten Folgen, positive wie negative. Deswegen, so Franz weiter, könne ein Container nicht automatisch auf jeder Hardware-Architektur oder jedem Betriebssystem betrieben werden. Dieser Nachteil spiele in der Praxis jedoch seltener eine Rolle, „da häufig einheitliche Betriebssysteme und Hardware-Architekturen genutzt werden“. Für Projekte im IoT-Umfeld sei dies allerdings schon relevanter. So sei ein Container zum Beispiel für einen Intel-basierten Server nicht ohne Weiteres auf einem Raspberry Pi einsetzbar.
Viele Anwendungen, die früher in virtuellen Maschinen liefen, lassen sich grundsätzlich in einen Container verschieben. Wenn man aber irgendwelche existierenden Applikationen ohne eine Anpassung in Containern betreibt, dann fügt das diesen Applikationen erst einmal keine neuen Funktionen hinzu. Anders ausgedrückt: „Eine nicht skalierbare Single-Instance-Applikation ist auch nach der Containerisierung keine cloudnative Scale-Out-Applikation.“ Es gibt laut Björn Brundert von VMware diverse Applikationen, die sich für eine einfache Umwandlung in einen Container eignen. Die technische Komplexität müsse aber teilweise sehr individuell betrachtet werden. Als Beispiel nennt er Anwendungen, die etwa über keine integrierten Backup-Mechanismen verfügen und daher von externen Backup-Tools abhängig sind. Weitere Fragen seien, ob eine Applikation überhaupt auf dem Betriebssystem unterstützt werde, das der Container-Runtime zugrunde liegt. Oder wie werden Updates an der Applikation gemacht, nachdem sie containerisiert wurde? All diese und noch etliche andere Themen müssten auf jeden Fall berücksichtigt werden, soll eine Migration erfolgreich sein.
IT-Abteilungen sollten also die beiden Technologien – sprich virtuelle Maschinen auf der einen und Container auf der anderen Seite – nicht gegeneinander ausspielen: Es sei kein Oder, sondern ein Und, wie Stephan Michard von Dell betont. „Beide Technologien stellen verschiedene Möglichkeiten der Virtualisierung dar und haben ihre jeweilige Berechtigung und ihre Vorzüge – je nach den Anforderungen, die an eine Applikation gestellt werden.“ Für virtuelle Maschinen existierten bewährte Management- und Orchestrierungs-Tools, und so lange es keine extremen Anforderungen an eine hohe Skalierbarkeit oder sehr kurze Entwicklungszyklen gebe, ließen sich Applikationen auch gut über virtuelle Maschinen bereitstellen.
Felix Grundmann zufolge, Head of Product Management beim Provider Ionos, gibt es durchaus auch Gründe, virtuelle Maschinen gegenüber Containern vorzuziehen. Dies sei der Fall, wenn man beispielsweise einen Custom-Kernel betreiben, das Gast-Betriebssystem wählen oder eine bestimmte Hardware simulieren wolle. Hinzu komme die bessere Isolierung und Sicherheit, aber auch die Möglichkeit, Workloads ohne Ausfallzeit „live“ zu migrieren. „Vermutlich lassen sich nahezu alle Anwendungen umbauen, um in Containern zu laufen“, ergänzt er. Aber: „Technisch gibt es noch Gründe, dass dies nicht immer sinnvoll sein muss.“
Microservices
Doch wie sehen Anwendungen in Containern eigentlich aus? Im Zusammenhang mit Containern ist häufig von Microservices die Rede. Darunter versteht man Dienste, die jeweils eine kleine Aufgabe erfüllen. Die Microservices lassen sich über Schnittstellen so miteinander verbinden, dass sich daraus eine beliebig komplexe Software ergibt. Darüber hinaus sind die einzelnen Funktionsblöcke je nach Nutzung und Auslastung unabhängig voneinander skalierbar. Die beiden Haupteigenschaften von Microservices sind dabei Spezialisierung und Eigenständigkeit. So beschränkt sich jeder Dienst auf die Lösung eines bestimmten Problems – und arbeitet dabei eigenständig: Jeder dieser kleinen Dienste lässt sich bereitstellen, betreiben und skalieren, ohne die Funktionsfähigkeit anderer Services zu beeinträchtigen.
Aus technischer Sicht besteht jedoch zwischen Microservices und Containern kein direkter Zusammenhang. So lassen sich auch komplette monolithische Applikationen mit Hilfe von Containern betreiben. Doch gerade in Anbetracht einer möglichen Skalierung beziehungsweise einer effizienten Nutzung der IT-Infrastruktur ist das manchmal nicht unbedingt sinnvoll.
Ähnlich sieht es Wolfgang Kurz, CEO beim IT-Dienstleister Indevis: „Natürlich kann man auch größere Blöcke in Container packen. Allerdings verfehlt man dann etwas den ursprünglichen Gedanken, für jeden Task einen Container zu haben, der dann im Idealfall ‚stateless‘ ist und im Bedarfsfall einfach häufiger gestartet wird.“ Wolle man beispielsweise eine große SQL-Datenbank in einem Container betreiben, dann stelle sich die Frage, warum sie in einem Container laufen sollte. „In klassischen Infrastrukturen hat man das Thema des persistenten hochverfügbaren Storage mit hohem I/O, funktionierendem Cluster und Backup-Konzept seit vielen Jahren im Einsatz.“ Wenn man so etwas in einem Container machen wolle, dann sei man schnell im experimentellen Bereich oder müsse sehr viel Know-how selbst aufbauen. Das sei nur für sehr große Firmen oder Cloud-Anbieter sinnvoll.
In einigen Fällen kann es dennoch ratsam sein, auch ganze Applikationen in Container zu packen. Laut Simon Fleischer von Consol hat es sich insbesondere während der Entwicklungsphase bewährt, lokale Dienste wie etwa Datenbanken oder Queue-Server in Containern zu starten, „da auf diese Weise sehr einfach identische Umgebungen für alle Kollegen im Entwicklungsteam erstellt werden können“.
Knackpunkt Sicherheit
Trotz aller Vorteile – Unternehmen treibt beim Einsatz von Containern vor allem das Thema Sicherheit um. Laut der eingangs erwähnten Studie gaben 38 Prozent der IT-Verantwortlichen an, dass Sicherheitsbedenken ein Grund dafür sind, keine Container im Unternehmen einzusetzen. Und die Bedenken haben auch ihre Berechtigung: Der sichere Betrieb von Container-Workloads ist nicht trivial.
In den Anfangszeiten der Containerisierung liefen diese oft mit Root-Rechten. Dadurch konnte ein Angreifer, der die Sicherheitsmechanismen des Host-Betriebssystems überwand und Zugriff auf die Hardware hatte, gegebenenfalls auch auf die Container zugreifen. Heutzutage liegen laut Marc Kleff von NetApp die Hürden hingegen deutlich höher, da viele Lösungen auf den Root-Zugriff verzichten – „System und Container bleiben getrennt, obwohl diese Trennung nicht so weit wie bei einer Server-Virtualisierung reicht.“ Im Allgemeinen gilt, so Kleff: „Wo aus Sicherheitsgründen eine dedizierte Hardware-Trennung eingeführt wurde, wird man diese jetzt nicht durch einen Mischbetrieb mehrerer Container auf einem Host ersetzen.“
Dass die Sicherheit ein großes Thema ist, das noch längst nicht gelöst ist, betont auch Wolfgang Kurz von Indevis. Ein gängiges Problem sei etwa der Übergriff in Speicherbereiche des Nachbarn. Das gelte unter anderem auch für Teile des Betriebssystems. „Durch den Einsatz von Containern wird es also keinesfalls sicherer, zumal viele Technologien zum Schutz von Containern noch in den Kinderschuhen stecken.“ Auch wenn alle etablierten Firmen Angebote zum Schutz von Container-Lösungen im Angebot hätten, so seien das oft aus der Virtual-Machine-Welt übertragene Ansätze, die nur teilweise funktionierten. Daher seine Warnung: „Viele Online-Repositories, von denen viele Anwender ihre Container beziehen, sind veraltet und haben eklatante bekannte Sicherheitslücken. Hier muss man im Grunde täglich die Container neu bauen. Solch eine Build Pipeline hat aber nicht jeder im Einsatz, auch wenn sie notwendig wäre.“
Vor allem im DevOps-Bereich ist die Sicherheit von Containern ein Thema: Das Operations-Teams hat die Aufgabe, Sicherheitslücken in Produktivumgebungen zu finden. Dabei ist es in der Praxis aber häufig schon schwierig, Komponenten und Abhängigkeiten in Container-Images zu überblicken. „Der Überblick über Komponenten und Abhängigkeiten in Container-Images gelingt dort, wo die enge Verbindung von Dev und Ops in einer DevOps-Kultur gelebt wird“, betont Marc Kleff. Die Operations-Teams dürften nicht nur auf das Resultat blicken, „sondern müssen bereits im Code-Repository und beim Quellcode ansetzen. Hier werden die Abhängigkeiten und Komponenten definiert. Dafür können Unternehmen auf fertige Lösungen zurückgreifen.“ GitHub werde beispielsweise automatisch auf Sicherheitslücken in solchen Abhängigkeiten gescannt und der Anwender benachrichtigt.
Von der Cloud Native Computing Foundation – einem Projekt der Linux Foundation, um Cloud-Computing, Microservices und Containervirtualisierung zu fördern – gibt es eine Reihe von empfohlenen Vorgehensweisen, an denen sich Unternehmen orientieren können. Sinnvoll ist es zum Beispiel, jeweils aktuelle Software-Stände der Container-Engine und des Orchestrierungssystems einzusetzen oder sensible Work-loads voneinander zu separieren. Das lässt sich umsetzen, indem man etwa Applikationen in getrennten Clustern betreibt.
Bei der Verwendung von Container-Basis-Images sollte man darauf achten, aus welcher Quelle diese stammen. Hier ist es unter Umständen angebracht, entweder einen Anwendungskatalog mit signierten Basis-Images zu verwenden oder auch Container-Images in regelmäßigen Abständen neu zu erstellen. Weitere wichtige Aspekte für einen sicheren Betrieb von Container-Workloads sind das Netzwerk-Design und der Einsatz von Monitoring- und Logging-Systemen.
Patchen
Container haben auch Auswirkungen auf den Patch-Prozess. So sind Container typischerweise „immutable“. Das bedeutet: Sie werden nicht kontinuierlich gepflegt, sondern einfach durch neue Container ersetzt. Das erfordert in vielen Fällen neue Software-Build- und -Release-Routinen. „Das bringt bei komplexen Systemen – insbesondere in monolithischen Strukturen – viel Aufwand mit sich, dessen Nutzen sich erst später einstellt und häufig auch nicht vorweg quantifizieren lässt“, berichtet Ionos-Produktmanager Felix Grundmann. Bei Containern patcht man also keine Live-Container, sondern die Images in ihrer Container-Registry. „Auf diese Weise kann das vollständig gepatchte Container-Image als eine Einheit ausgerollt oder zurückgerollt werden, sodass der Patch-Rollout-Prozess mit seinem – offensichtlich sehr häufigen – Code-Rollout-Prozess identisch wird, komplett mit Überwachung, Canarying und Tests“, erklärt Stefan Schäfer, Head of Global Product Marketing beim Hosting-Spezialisten OVHcloud. So werde ein Patch unter Verwendung des normalen Prozesses auf vorhersehbare Weise ausgerollt. Eine Alternative – wenn auch weniger vorteilhaft, da sie nach einem unvorhersehbaren Zeitplan eintritt – sei es, den Rollout ad hoc erfolgen zu lassen. „Wenn ein Container dann das nächste Mal stirbt, dreht Kubernetes einen weiteren Container auf, um dies auszugleichen, und alle Patches, die man angewendet hat, werden auf die Infrastruktur ausgerollt.“ Abhängig von der Lebensdauer der Container sollten diese innerhalb weniger Tage vollständig gepatcht sein.
Container as a Service
Die Sache mit den Containern klingt also nicht nur kompliziert – sie ist es auch. Die Integration von Container-Technologien stellt viele, vor allem kleinere Unternehmen vor Herausforderungen. Die Implementierung und das Management von Containern erfordern entsprechend qualifiziertes IT-Personal, das sich vor allem bei dem einen oder anderen Mittelständler erst einmal einarbeiten muss. Hinzu kommt: Viele IT-Abteilungen sind wie erwähnt bereits durch die zahlreichen Anforderungen in Zuge der Digitalisierung ausreichend ausgelastet.
Die Nutzung von Container-Diensten, Container as a Service (CaaS), ist daher eine gute Alternative zum Aufbau einer eigenen Container-Plattform. Die Cloud-Angebote stellen die notwendige Infrastruktur und Management-Tools wie Docker oder Kubernetes bereit. „Container-as-a-Service-Angebote sind prädestiniert für den schnellen Einstieg, weil Unternehmen damit innerhalb kurzer Zeit mit Container-Applikationen bei Public-Cloud-Providern starten können“, meint Stephan Michard von Dell. Michael Armstrong, Projektleiter beim Hosting-Unternehmen Centron, bestätigt das: „Wir können aus Erfahrung sagen: Dieser Bereich wird immer wichtiger. Wir verzeichnen eine konstant steigende Nachfrage nach Container-as-a-Service-Lösungen – und das ist nur logisch: Die Apps und Services des Kunden sind innerhalb weniger Sekunden verfügbar. Gleichzeitig muss er weder Fachkräfte für Einrichtung und Betrieb vorhalten noch in eine neue IT-Infrastruktur investieren.
“Für NetApp-Engineer Marc Kleff hat der Einsatz von Container as a Service vor allem praktische Gründe: „Wir erleben den Trend, dass Unternehmen in den Bereichen auf Services zurückgreifen, in denen sie durch einen eigenen Betrieb keinen unmittelbaren Mehrwert schaffen.“ Den Mehrwert erbrächten meistens die Applikationen, während die Infrastruktur lediglich ein Mittel zum Zweck sei. „Container-Plattformen als Infrastruktur-Ebene zählen deshalb zu den Anwendungsfällen, die ‚as a Service‘ konsumiert werden können.
“Für Simon Fleischer sind Container as a Service „sicherlich Teil der Zukunft“, aktuell komme es aber noch stark auf den Anwendungsfall an. „Es ist sehr charmant, dass man einfach einen Container bereitstellt und dieser beliebig skaliert werden kann, allerdings fehlt hier in manchen Bereichen noch die Kontrolle.“ Konkret bedeute dies, dass man sich etwa bei erhöhten Sicherheitsanforderungen zunächst besser selbst um das Container-Management kümmern sollte. Auch im Sinne der Multi-Cloud gebe es noch Verbesserungspotenzial, da sich die APIs der Anbieter stark unterschieden.
Fazit & Ausblick
Eines steht fest: Container sind zwar alles andere als einfach zu betreiben, aber die Vorteile überwiegen und der Trend zur Containerisierung wird weiter anhalten. Doch was kommt als Nächstes? Dell-Engineer Stephan Michard zitiert dazu Mark Twain: „Voraussagen soll man unbedingt vermeiden, besonders solche über die Zukunft.“ Container-Lösungen würden mittel- bis langfristig sicher eine bedeutendere Rolle als bisher einnehmen – einen genauen Anteil vorherzusagen, hält Michard jedoch für schwer möglich.
Für Thomas Franz von Adesso werden sich Container als innovative Technologie etablieren, die viele weitere Entwicklungen beflügelt, „beispielsweise Microservice-Architekturen, Automatisierung von Software-Delivery- und Betriebsprozessen oder ein Homogenisieren dieser Prozesse“. Container sind ihm zufolge inzwischen ein anerkanntes Werkzeug in der IT: „Unternehmen nutzen sie standardmäßig, wenn es um den vereinheitlichten Transport, das Management oder den Betrieb von Software geht.“ Dies zeige etwa das Angebot von Plattformen für das Orchestrieren und das Management von Containern.
Nach Einschätzung von Indevis-CEO Wolfgang Kurz ist auch für die klassische Virtual Machine noch lange kein Ende in Sicht. Es würde noch immer eine Vielzahl physischer Server betrieben. „Gerade wenn es um sehr hohe Performance geht, ist die Hardware-Nähe immer noch entscheidend.“ Der Kosten-Nutzen-Aufwand, um sämtliche Applikationen in Richtung Container zu entwickeln, stehe oft in keinem Verhältnis.
*Konstantin Pfliegl ist Redakteur bei der Zeitschrift com! professional und schreibt auch für die Internet World Business, Telecom Handel und die Schweizer Computerworld. Er hat rund 20 Jahre Erfahrung als Redakteur für verschiedene Print- und Online-Medien. Er arbeitete als Redakteur unter anderem für die Fachpublikationen tecChannel und Internet Professionell sowie freiberuflich unter anderem regelmäßig für FOCUS Online.
Be the first to comment