Container und virtuelle Maschinen stellen Anwendungen in abgegrenzten Laufzeitumgebungen bereit. Der zentrale Unterschied liegt darin, wie sie Betriebssystemressourcen nutzen: Eine virtuelle Maschine enthält ein eigenes Gastbetriebssystem, während ein Container den Kernel des Hostsystems mitnutzt. Daraus ergeben sich Unterschiede bei Isolation, Ressourcenbedarf und Verwaltung.
Welche Technik passt, hängt von der Anwendung und den Anforderungen an Sicherheit und Betrieb ab. Für kleine Unternehmen ist es hilfreich, die jeweiligen Grenzen zu kennen, bevor eine Architektur festgelegt wird. Einen Überblick über Betriebsmodelle, Vorteile und Grenzen der Cloud gibt die Themenseite Cloud Computing.
Container versus virtuelle Maschinen: der grundlegende Unterschied
Eine virtuelle Maschine bildet einen eigenständigen Rechner innerhalb eines physischen Hosts ab. Ein Hypervisor teilt dessen Hardware-Ressourcen auf virtuelle Systeme auf. Jede VM kann ein eigenes Betriebssystem mit Kernel und Systemdiensten ausführen.
Ein Container kapselt dagegen einen Prozess oder eine Gruppe zusammengehöriger Prozesse. Er bringt die Anwendung und benötigte Bibliotheken mit, verwendet aber den Kernel des Hostbetriebssystems. Funktionen des Betriebssystems sorgen dafür, dass Prozesse voneinander getrennt sind und Ressourcen kontrolliert genutzt werden.
Das wirkt sich auf den Umfang der Laufzeitumgebung aus: Eine VM enthält ein vollständiges Gastbetriebssystem. Ein Container enthält typischerweise nur die Anwendung und ihre Abhängigkeiten. Das bedeutet nicht, dass Container grundsätzlich keine Betriebssystemkomponenten benötigen. Sie beziehen wichtige Funktionen vom Host.
Was eine virtuelle Maschine ausmacht
Der Hypervisor vermittelt zwischen den virtuellen Maschinen und der physischen Hardware. Je nach Umgebung läuft er direkt auf der Hardware oder als Anwendung innerhalb eines bestehenden Betriebssystems. Die VMs erhalten virtuelle Prozessoren, Arbeitsspeicher, Speicherlaufwerke und Netzwerkschnittstellen.
Da jede VM ein eigenes Gastbetriebssystem ausführt, lassen sich auf einem Host unterschiedliche Betriebssysteme betreiben, sofern die Plattform diese unterstützt. Das kann etwa dann nützlich sein, wenn eine Anwendung eine bestimmte Betriebssystemumgebung voraussetzt oder verschiedene Systemkonfigurationen getrennt gehalten werden sollen. In der Cloud werden virtuelle Maschinen häufig als virtuelle Server im Rahmen von IaaS bereitgestellt; welche Verantwortung dabei beim Anbieter liegt, erklärt der Beitrag zu IaaS, PaaS und SaaS.
Was einen Container ausmacht
Container nutzen Mechanismen des Hostsystems, um Prozesse und deren Sicht auf Ressourcen abzugrenzen. Dazu gehören beispielsweise getrennte Prozess- und Netzwerkbereiche sowie Beschränkungen für den Ressourcenverbrauch. Die genaue Umsetzung hängt von Betriebssystem und Containerplattform ab.
Ein Container-Image beschreibt die Dateien und Abhängigkeiten, aus denen ein Container gestartet werden kann. Images lassen sich versionieren und auf unterschiedlichen Systemen bereitstellen, solange die nötige Laufzeitumgebung vorhanden und die Plattform kompatibel ist. Das erleichtert es, Anwendungen in Entwicklungs-, Abnahme- und Betriebsumgebungen ähnlich auszuführen.
Isolation und Sicherheit
Beide Ansätze schaffen Grenzen zwischen Arbeitslasten, aber sie tun es auf unterschiedlichen Ebenen. Eine VM trennt Systeme mithilfe des Hypervisors und eines eigenen Gastbetriebssystems. Ein Container nutzt die Isolationsfunktionen des gemeinsamen Kernels.
Ein eigener Kernel pro VM kann eine zusätzliche Trennungsebene bieten. Das ist jedoch keine Garantie für Sicherheit: Auch Hypervisoren, Gastbetriebssysteme und Verwaltungsoberflächen müssen gepflegt und korrekt konfiguriert werden. Umgekehrt sind Container nicht automatisch unsicher. Ihre Sicherheit hängt unter anderem von der Containerplattform, den Berechtigungen, den verwendeten Images und der Konfiguration ab.
Bei Containern ist besonders wichtig, unnötige Zugriffsrechte zu vermeiden. Ein Prozess sollte nur auf Dateien, Geräte und Netzwerkfunktionen zugreifen können, die er tatsächlich benötigt. Auch ein Container mit weitreichenden Rechten kann Risiken für den Host mit sich bringen.
Für beide Technologien gehören regelmäßige Aktualisierungen und eine sorgfältige Verwaltung der Zugänge zum Betrieb. Eine klare Trennung von Anwendungen allein ersetzt keine Sicherheitsmaßnahmen. Entscheidend ist, welche Bedrohungen berücksichtigt werden und wie die gesamte Umgebung abgesichert ist.
Ressourcenbedarf und Geschwindigkeit
Container benötigen in der Regel weniger zusätzlichen Systemumfang als VMs, weil sie kein vollständiges Gastbetriebssystem mitbringen. Der Host muss dennoch Ressourcen für die Anwendung, die Container-Laufzeit und weitere Systemdienste bereitstellen. Wie viel benötigt wird, hängt von der konkreten Arbeitslast ab.
Eine VM beansprucht Ressourcen für ihr Gastbetriebssystem und die darin laufenden Anwendungen. Dafür bietet sie eine eigenständige Systemumgebung. Der tatsächliche Bedarf lässt sich nicht pauschal angeben: Eine schlank konfigurierte VM kann weniger benötigen als eine umfangreiche Container-Anwendung, und umgekehrt.
Container lassen sich oft zügig starten, weil nicht erst ein vollständiges Gastbetriebssystem hochfahren muss. Bei VMs gehören Start und Verwaltung des Gastbetriebssystems zum Ablauf. Für die Planung zählt aber nicht nur die Startzeit. Auch Speicherung, Überwachung, Aktualisierung und Wiederherstellung beeinflussen den Aufwand.
Verwaltung und Bereitstellung
Container eignen sich für Abläufe, in denen Anwendungen in klar beschriebenen Einheiten bereitgestellt und aktualisiert werden. Images können als Grundlage für mehrere gleichartige Laufzeitumgebungen dienen. Änderungen an der Anwendung und ihren Abhängigkeiten lassen sich dadurch nachvollziehbar zusammenfassen.
Das erleichtert die Bereitstellung, löst aber nicht alle Betriebsaufgaben. Verantwortliche müssen unter anderem Images verwalten, Sicherheitsaktualisierungen einplanen und festlegen, wie dauerhafte Daten gespeichert werden. Die Koordination vieler Container kann zusätzliche Plattformwerkzeuge und Fachwissen erfordern.
Bei virtuellen Maschinen wird meist ein vollständiges Betriebssystem verwaltet. Dazu zählen Systemaktualisierungen, Konfigurationen und die Überwachung der VM. Dieser zusätzliche Umfang kann sinnvoll sein, wenn eine Arbeitslast eine eigenständige Systemumgebung braucht. Er kann aber auch mehr Pflegeaufwand bedeuten, besonders wenn viele VMs betrieben werden.
Typische Einsatzfälle
Container können passen, wenn eine Anwendung samt Abhängigkeiten als Einheit bereitgestellt werden soll und das Hostbetriebssystem die nötige Umgebung unterstützt. Häufige Gründe sind:
- Anwendungen sollen in mehreren Umgebungen möglichst ähnlich laufen.
- Einzelne Dienste sollen getrennt entwickelt und bereitgestellt werden.
- Die Laufzeitumgebung soll sich über Images beschreiben und verwalten lassen.
- Ein Team möchte Anwendungen auf einer gemeinsamen Containerplattform betreiben.
Virtuelle Maschinen können geeignet sein, wenn ein eigener Kernel oder ein vollständiges Gastbetriebssystem erforderlich ist. Das kann beispielsweise für ältere Anwendungen, bestimmte Systemdienste oder voneinander stark getrennte Umgebungen relevant sein. Ebenso sind VMs eine Option, wenn auf einem physischen Host unterschiedliche Betriebssysteme betrieben werden müssen.
Diese Kriterien sind Orientierungspunkte, keine festen Regeln. Technische Abhängigkeiten, vorhandene Kenntnisse und Sicherheitsanforderungen entscheiden mit. Für manche Anwendungen kann auch eine Kombination sinnvoll sein: Container laufen dann innerhalb einer oder mehrerer virtueller Maschinen. So lassen sich die Vorteile beider Ebenen nutzen, allerdings wächst damit auch die Zahl der zu verwaltenden Komponenten.
Wer für einzelne, ereignisgesteuerte Aufgaben weder Container noch virtuelle Maschinen selbst verwalten möchte, kann auch auf Funktionsdienste zurückgreifen. Wie dieses Modell arbeitet und wo seine Grenzen liegen, beschreibt der Beitrag zu Serverless Computing.
Grenzen und häufige Missverständnisse
Container sind keine kleinen virtuellen Maschinen. Sie besitzen normalerweise kein eigenständiges Gastbetriebssystem und können deshalb nicht beliebige Betriebssysteme unabhängig vom Host ausführen. Die gemeinsame Nutzung des Kernels schränkt außerdem ein, welche Kombinationen von Host und Container technisch möglich sind.
Auch VMs sind nicht automatisch die bessere Wahl für Sicherheit oder Kompatibilität. Ein eigenes Betriebssystem schafft eine zusätzliche Grenze, bringt aber zugleich weitere Software mit, die konfiguriert und aktuell gehalten werden muss. Die passende Isolierung ergibt sich aus dem konkreten Risiko und der Architektur, nicht allein aus dem Namen der Technologie.
Ein weiterer Unterschied betrifft dauerhafte Daten. Container können so eingerichtet werden, dass Daten außerhalb des kurzlebigen Container-Dateisystems gespeichert werden. Ohne eine passende Speicherlösung können Änderungen jedoch verloren gehen, wenn ein Container ersetzt wird. VMs verwenden virtuelle Laufwerke, deren Daten unabhängig von einem einzelnen Prozess weiterbestehen können; auch hier braucht es eine passende Sicherungs- und Speicherstrategie.
Auswahl: Welche Fragen helfen bei der Entscheidung?
Statt nur auf den Ressourcenbedarf zu schauen, sollten Sie zuerst die Anforderungen der Anwendung klären:
- Benötigt sie einen bestimmten Kernel oder ein vollständiges Betriebssystem?
- Muss sie von anderen Arbeitslasten besonders stark getrennt sein?
- Welche Anforderungen gelten für dauerhafte Daten und deren Sicherung?
- Verfügt das Team über Erfahrung mit Containerplattformen, Hypervisoren oder beidem?
- Wie sollen Aktualisierungen, Zugriffsrechte und Überwachung organisiert werden?
Wenn eine Anwendung nur in einer bestimmten Systemumgebung läuft, kann eine VM die naheliegendere Grundlage sein. Ist eine portable, klar beschriebene Laufzeitumgebung wichtiger und sind die Betriebssystemanforderungen erfüllt, können Container besser passen. Bei gemischten Anforderungen ist eine Kombination möglich, sofern der zusätzliche Verwaltungsaufwand berücksichtigt wird. Steht die Entscheidung im Zuge eines Umzugs bestehender Systeme an, hilft eine strukturierte Bestandsaufnahme, wie sie der Beitrag Cloud-Migration planen beschreibt.
Container oder virtuelle Maschine: worauf es ankommt
Der Vergleich von Containern und virtuellen Maschinen dreht sich vor allem um die Grenze, an der isoliert wird. VMs kapseln ein vollständiges Betriebssystem, Container einzelne Anwendungen oder Prozesse unter einem gemeinsamen Kernel. Daraus folgen unterschiedliche Anforderungen an Kompatibilität, Ressourcen und Wartung.
Für den sicheren Betrieb zählen nicht nur technische Eigenschaften. Auch Rechtevergabe, Aktualisierungsprozesse, Datensicherung und die Zuständigkeiten im Team gehören zur Entscheidung. Eine passende Lösung ist diejenige, deren Anforderungen sich im Alltag zuverlässig erfüllen lassen.
Fazit
Container und virtuelle Maschinen isolieren Anwendungen auf unterschiedliche Weise. Container teilen den Kernel des Hosts und bündeln Anwendungen mit ihren Abhängigkeiten; VMs führen jeweils ein eigenes Gastbetriebssystem aus. Prüfen Sie Betriebssystemanforderungen, Sicherheitsgrenzen und Verwaltungsaufwand gemeinsam, um eine passende Grundlage für Ihre Arbeitslast zu bestimmen.
Häufige Fragen
Können Container ohne Internetverbindung betrieben werden?
Ja, wenn die benötigten Images und Abhängigkeiten bereits auf dem System verfügbar sind, kann ein Container grundsätzlich ohne laufende Internetverbindung starten. Für Aktualisierungen oder den Bezug neuer Images wird üblicherweise wieder eine Verbindung zu einer entsprechenden Quelle benötigt.
Überleben Container einen Neustart des Hostsystems?
Ein Neustart des Hosts beendet die laufenden Container zunächst. Ob sie danach automatisch erneut gestartet werden, hängt von der Konfiguration der Containerplattform ab. Dauerhafte Daten sollten getrennt vom kurzlebigen Container-Dateisystem gespeichert werden.
Eignen sich Container für Anwendungen mit grafischer Oberfläche?
Das ist grundsätzlich möglich, erfordert aber zusätzliche Konfiguration für die Darstellung und den Zugriff auf Grafikfunktionen. Der Aufwand hängt von Betriebssystem, Laufzeitumgebung und Anwendung ab. Container werden häufiger für Dienste ohne direkte grafische Oberfläche eingesetzt.