Containerisierung

Was ist Containerisierung?

Containerisierung bezeichnet das Bündeln einer Anwendung mit allen benötigten Bibliotheken, Konfigurationen und Abhängigkeiten in einer standardisierten, isolierten Einheit, dem Container. Dieser Container läuft unabhängig von der darunterliegenden Umgebung auf jedem System gleich, vom Entwicklungsrechner bis zum Rechenzentrum. Anders als virtuelle Maschinen teilen sich Container den Kernel des Betriebssystems und starten dadurch schneller und ressourcenschonender.

Der Begriff stammt aus der Logistik. Der Frachtcontainer hat den Welthandel verändert, weil er ein einheitliches Maß geschaffen hat, das jeder Kran, jedes Schiff und jeder LKW verarbeiten kann, unabhängig vom Inhalt. Containerisierung in der Software folgt derselben Logik. Die Betriebsumgebung muss nicht mehr wissen, was in der Anwendung steckt, sie muss nur das Container-Format beherrschen.

Wie unterscheidet sich ein Container von einer virtuellen Maschine?

Eine virtuelle Maschine bildet einen vollständigen Rechner nach, samt eigenem Betriebssystem. Ein Container verzichtet darauf und nutzt den Kernel des Hosts mit. Daraus ergeben sich die praktischen Unterschiede, die für Betriebsentscheidungen relevant sind:

• Startzeit: Container starten in Sekunden oder Bruchteilen davon, virtuelle Maschinen benötigen den kompletten Bootvorgang eines Betriebssystems.
• Ressourcenbedarf: Auf derselben Hardware laufen deutlich mehr Container als virtuelle Maschinen, weil das Betriebssystem nicht mehrfach vorgehalten wird.
• Isolationstiefe: Virtuelle Maschinen trennen strikter, da sie eigene Kernel verwenden. Container isolieren auf Prozessebene, was bei besonders hohen Schutzanforderungen bewusst abzuwägen ist.

Beide Ansätze schließen sich nicht aus. In der Praxis laufen Container häufig innerhalb virtueller Maschinen, um die Isolation der Virtualisierung mit der Handhabbarkeit der Containerisierung zu verbinden.

Welche Vorteile bietet Containerisierung?

Für Entscheider zählt weniger die Technik als das, was sie im Betrieb verändert.

• Reproduzierbarkeit: Die Anwendung verhält sich in Test, Abnahme und Produktion gleich, weil sie überall dasselbe Paket ist. Der klassische Streitpunkt, dass etwas nur auf einem bestimmten System funktioniert, verliert an Grundlage.
• Portabilität: Ein Container läuft auf eigener Hardware, in einer europäischen Cloud oder beim Rechenzentrumsdienstleister, ohne dass die Anwendung neu gebaut werden muss. Das reduziert die Bindung an einen einzelnen Anbieter, siehe dazu auch Vendor Lock-in.
• Skalierbarkeit: Lastspitzen lassen sich abfangen, indem zusätzliche Instanzen desselben Containers gestartet werden.
• Sauberer Lebenszyklus: Aktualisierungen erfolgen als Austausch des gesamten Containers statt als Eingriff in ein laufendes System. Ein Rückfall auf die vorherige Version bleibt jederzeit möglich.

Containerisierung in der Praxis

Das verbreitetste Format stammt von Docker, das sich als De-facto-Standard etabliert hat. Wie sich der Einsatz konkret rechnet und worauf beim Betrieb zu achten ist, behandelt die Kompetenzseite zu Docker Containern im Unternehmen.

Sobald mehr als eine Handvoll Container im Spiel ist, stellt sich die Frage der Orchestrierung, also der automatisierten Verteilung, Überwachung und Erneuerung. Diese Aufgabe übernimmt in den meisten Umgebungen Kubernetes. Für kleinere Installationen ist der Aufwand einer vollwertigen Orchestrierung allerdings oft nicht gerechtfertigt.

Wann sich Containerisierung lohnt, und wann nicht

Containerisierung ist kein Selbstzweck. Sie zahlt sich vor allem dort aus, wo mehrere Umgebungen betrieben werden, wo häufig ausgeliefert wird oder wo eine Anwendung langfristig unabhängig von einer bestimmten Plattform bleiben soll. Bei der Modernisierung bestehender Systeme ist sie ein pragmatischer Zwischenschritt, weil eine Anwendung containerisiert werden kann, ohne sie neu zu schreiben.

Zurückhaltung ist angebracht, wenn eine einzelne, selten geänderte Anwendung auf einem festen Server läuft und niemand im Team Erfahrung mit dem Betrieb von Containern hat. Dann verlagert Containerisierung den Aufwand lediglich, statt ihn zu senken. Die entscheidende Frage lautet nicht, ob die Technik verfügbar ist, sondern ob die Organisation den laufenden Betrieb tragen kann.

Sicherheit und Betrieb containerisierter Anwendungen

Container erben die Schwachstellen dessen, was in ihnen steckt. Ein veraltetes Basis-Image bringt seine Sicherheitslücken in jede daraus erzeugte Instanz. Für regulierte Bereiche ergeben sich daraus konkrete Pflichten, etwa ein nachvollziehbarer Nachweis der verwendeten Komponenten, regelmäßige Aktualisierung der Basis-Images und ein geregelter Umgang mit Zugriffsrechten.

Weil Container den Kernel des Hosts mitnutzen, ist die Trennung schwächer als bei virtuellen Maschinen. Wo besonders schutzbedürftige Verfahren betrieben werden, gehört diese Eigenschaft in die Risikobetrachtung. Auch die Frage, wo die Container tatsächlich laufen, berührt die digitale Souveränität einer Organisation.

Der laufende Betrieb, von der Überwachung über das Einspielen von Aktualisierungen bis zur Wiederherstellung im Störungsfall, unterscheidet sich in der Verantwortung nicht von klassischer Infrastruktur. TenMedia übernimmt diese Aufgaben im Rahmen von Softwarebetrieb und Wartung.

Häufige Missverständnisse

Rund um Containerisierung halten sich einige Annahmen, die in Projektgesprächen regelmäßig für falsche Erwartungen sorgen.

• Container sind nicht automatisch sicherer. Sie kapseln eine Anwendung, beheben aber keine Schwachstelle in ihr. Sicherheit entsteht durch gepflegte Basis-Images, eingeschränkte Rechte und einen geregelten Aktualisierungsprozess.
• Containerisierung ist keine Modernisierung. Eine alte Anwendung im Container bleibt eine alte Anwendung. Der Container erleichtert Betrieb und Umzug, ersetzt aber keine fachliche Überarbeitung.
• Container brauchen nicht zwingend Kubernetes. Für wenige Anwendungen genügen einfachere Werkzeuge. Eine vollständige Orchestrierung lohnt sich erst, wenn Umfang und Änderungsfrequenz sie rechtfertigen.
• Container sind nicht zustandslos, nur weil sie so gedacht sind. Datenbanken und Dateiablagen benötigen weiterhin dauerhaften Speicher und ein Sicherungskonzept.

Containerisierung und regulatorische Anforderungen

In regulierten Umgebungen verschiebt Containerisierung die Nachweispflichten, sie hebt sie nicht auf. Wer Software für Behörden oder Betreiber kritischer Infrastrukturen betreibt, muss weiterhin belegen können, welche Komponenten im Einsatz sind, wie schnell Sicherheitsaktualisierungen eingespielt werden und wie der Betrieb nach einer Störung wieder anläuft.

Containerisierung kann diese Nachweise erleichtern, weil der Inhalt eines Containers explizit beschrieben ist und sich maschinell auswerten lässt. Vorausgesetzt, die Images werden gepflegt und nicht über Jahre unverändert weiterverwendet. Genau dieser Punkt entscheidet darüber, ob Containerisierung die Sicherheitslage verbessert oder verschlechtert.

Einordnung

Containerisierung ist heute weniger eine Innovation als eine Grundannahme moderner Softwareentwicklung. Ihr Nutzen liegt weniger in der Technik selbst als in der Vereinheitlichung, die sie erzwingt. Wer Anwendungen containerisiert, muss deren Abhängigkeiten benennen, ihre Konfiguration dokumentieren und ihren Lebenszyklus definieren. Diese Klarheit ist der eigentliche Gewinn, und sie bleibt auch dann bestehen, wenn die darunterliegende Plattform eines Tages gewechselt wird.