Ein Softwarecontainer ist eine standardisierte, ausführbare Einheit: Sie enthält den Anwendungscode und die Abhängigkeiten, die diese Anwendung zum Ausführen benötigt. Ein Container ist damit kein bloßer Ordner, sondern läuft als abgegrenzter Prozess auf einem Hostsystem. Das erleichtert es, dieselbe Anwendung in Entwicklung, Test und Betrieb mit einer vergleichbaren Laufzeitumgebung bereitzustellen.
Wer eine Webanwendung ausliefert, braucht mehr als ihren Quellcode: etwa eine Laufzeit, Bibliotheken, Konfiguration und einen definierten Startbefehl. Ein Containerimage beschreibt dieses Paket; wenn eine Containerlaufzeit es startet, entsteht daraus ein Container. Die Docker-Erklärung zu Containern beschreibt Images entsprechend als eigenständige, ausführbare Softwarepakete mit Code, Laufzeit und weiteren benötigten Bestandteilen.
Container ersetzen nicht zwangsläufig andere Betriebsformen. Sie sind eine Art, Anwendungen zu verpacken und auszuführen. Für die Umgebung darunter braucht es weiterhin ein Betriebssystem, eine Containerlaufzeit sowie Entscheidungen über Netzwerk, Speicher, Zugriffe und Überwachung.
Ein Image wird üblicherweise aus nachvollziehbaren Schritten gebaut. Es enthält Anwendungsdateien und Angaben dazu, wie der Prozess gestartet werden soll. Die Containerlaufzeit verwendet dieses Image und startet den Prozess mit einer abgegrenzten Sicht auf Ressourcen wie Dateisystem, Prozesse und Netzwerk. Mehrere Container können auf demselben Rechner laufen und nutzen dabei den Kernel des Hostbetriebssystems gemeinsam.
Diese gemeinsame Grundlage unterscheidet Container von vielen virtuellen Maschinen. Eine virtuelle Maschine bildet eine vollständige Maschine auf virtualisierter Hardware nach und bringt in der Regel ein eigenes Gastbetriebssystem mit. Container isolieren Anwendungen anders und sind daher kein gleichwertiger Ersatz für jede VM-Anforderung. Welche Form der Abgrenzung angemessen ist, hängt etwa von Betriebssystem, Sicherheitsmodell und Arbeitslast ab.
Ein Team betreibt einen kleinen Dienst, der Rechnungsdaten entgegennimmt. Statt auf jedem Server einzeln eine passende Programmiersprache und Bibliotheken einzurichten, erstellt das Team ein Image mit dem Dienst und dessen Laufzeit. Der Testserver und der Produktivserver können daraus jeweils einen Container starten. Das schafft noch keine fehlerfreie Auslieferung: Zugangsdaten, Datenbanken, Datensicherung und die Erreichbarkeit des Dienstes müssen weiterhin separat geplant und betrieben werden.
Container eignen sich besonders, wenn Anwendungen wiederholbar gebaut und in verschiedenen Umgebungen ausgeführt werden sollen. Häufig werden einzelne Dienste, Hintergrundaufgaben oder Entwicklungsumgebungen in Container gepackt. Auch bei Cloud Computing und Plattformen mit mehreren Diensten sind sie verbreitet, weil sich Images versionieren und gezielt ausrollen lassen.
Bei einer größeren Zahl von Containern kommt oft eine Verwaltungsplattform hinzu. Kubernetes ist laut seiner Dokumentation eine erweiterbare Open-Source-Plattform zur Verwaltung containerisierter Arbeitslasten und Dienste. Es ist jedoch nicht mit dem Container selbst gleichzusetzen: Kubernetes kann Container-Workloads verwalten, baut aber weder automatisch eine Anwendung noch ersetzt es jede Betriebsentscheidung.
„Im Container läuft es überall“ ist eine nützliche Vereinfachung, aber keine Garantie. Image und Anwendung müssen zur Zielarchitektur, zur Containerlaufzeit und zu den benötigten externen Diensten passen. Persistente Daten gehören nicht automatisch dauerhaft in den Container: Wird ein Container ersetzt, können Daten im beschreibbaren Container-Dateisystem verloren gehen, wenn kein passender Speicher vorgesehen ist.
Auch die Isolation ist kein Freibrief. Ein Container teilt sich zumindest Teile der Grundlage mit dem Host. Deshalb bleiben gepflegte Images, begrenzte Rechte, aktuelle Abhängigkeiten und ein bewusstes Sicherheitskonzept wichtig. Containerisierung kann Abläufe vereinheitlichen, sie nimmt Betriebsteams aber nicht die Verantwortung für Konfiguration, Beobachtbarkeit und Wiederherstellung ab.
Ein Containerimage ist die unveränderte Vorlage; ein Container ist die daraus laufende Instanz. Eine virtuelle Maschine enthält dagegen typischerweise ein vollständiges Gastbetriebssystem auf virtualisierter Hardware. Von Software as a Service unterscheidet sich ein Container ebenfalls: SaaS beschreibt ein Bezugs- und Betriebsmodell für Software, ein Container eine technische Verpackungs- und Laufzeitform.