Container vs. VM

Bis Anfang der 2010er Jahre war Virtualisierung mit klassischen virtuellen Maschinen (VMs) der Standardweg, Anwendungen voneinander zu isolieren und Server effizient zu nutzen. Dann kam Docker und veränderte alles: statt jede Anwendung in einer komplett eigenen virtuellen Maschine mit eigenem Betriebssystem zu betreiben, packte man sie in einen Container – eine viel leichtere, schnellere Isolation. Heute sind beide Welten in fast jedem Rechenzentrum präsent: VMs als robuste Träger für ganze Betriebssysteme, Container als schlanke Verpackung einzelner Anwendungen. Wer Cloud-, Server- oder DevOps-Themen verstehen will, muss den Unterschied genau kennen – er taucht in der IHK-Prüfung garantiert auf.

Eine Analogie macht es greifbar: Stell dir vor, du betreibst ein Mietshaus. Eine VM ist wie eine eigene Wohnung im Haus – komplett mit eigener Küche, eigenem Bad, eigener Heizung. Jeder Mieter wohnt vollkommen unabhängig und merkt nichts von den anderen. Sehr robust, aber jede Wohnung braucht ihren eigenen Platz, ihre eigene Infrastruktur, eigenen Strom. Ein Container ist eher wie ein Zimmer im Studentenwohnheim – die Mieter teilen sich Küche, Bad und Heizung (den Kernel des Host-Betriebssystems), haben aber jeweils ihr eigenes abschließbares Zimmer mit eigenen Möbeln und Sachen. Viel platzsparender, viel günstiger – aber wenn die Heizung kaputtgeht, frieren alle.

1) Der Schichten-Vergleich – wo liegt der Unterschied?

Der zentrale Unterschied liegt darin, was beide Technologien nicht teilen und was sie teilen. VMs virtualisieren auf Hardware-Ebene und bringen jeweils ein komplettes Gastbetriebssystem mit. Container virtualisieren auf Betriebssystem-Ebene und teilen sich den Kernel des Host-Systems. Schau dir die Stacks im direkten Vergleich an:

2) Boot-Zeit – wie schnell ist „schnell"?

Eine VM startet wie ein normaler Computer: BIOS/UEFI, Kernel laden, Init-System hochfahren, Dienste starten. Das dauert Minuten. Ein Container hat das alles nicht – er startet einfach den eigentlichen Prozess (etwa nginx oder java -jar app.jar) im isolierten Namespace des Hosts. Das ist eine Frage von Sekunden, oft Millisekunden:

3) Ressourcenverbrauch – was kostet das wirklich?

Container sind nicht nur schneller, sondern auch deutlich genügsamer. Ein typischer leerer Linux-Container braucht wenige MB RAM, ein leerer Container mit Webserver vielleicht 30 MB. Eine vergleichbare VM braucht mit Linux-Kernel, Init-System und Diensten mindestens 256 MB, oft 512 MB oder mehr. Das hat direkte wirtschaftliche Folgen – auf derselben Hardware passt ein Vielfaches an Containern.

4) Isolation und Sicherheit – wo VMs noch punkten

VMs haben einen wichtigen Vorteil, der oft übersehen wird: stärkere Isolation. Eine VM hat einen eigenen Kernel – wenn ein Angreifer aus der VM ausbrechen will, muss er erst den Gastkernel kompromittieren und dann den Hypervisor angreifen. Container teilen sich den Host-Kernel: Eine Kernel-Lücke kann theoretisch zum „Container-Breakout" führen, bei dem ein bösartiger Prozess in einem Container Zugriff auf den Host bekommt.

Praktisch sind moderne Container-Runtimes mit zusätzlichen Sicherheitsmechanismen geschützt: Linux Namespaces (jeder Container sieht nur seine eigenen Prozesse, sein eigenes Netzwerk, sein eigenes Dateisystem), Cgroups (Ressourcenbegrenzung), Seccomp (welche Systemaufrufe ein Container machen darf), AppArmor/SELinux (Mandatory Access Control), und Tools wie gVisor oder Kata Containers, die zusätzliche Kernel-Schichten zwischen Container und Host einziehen. Trotzdem gilt: für hochsensible, mehrmandantenfähige Workloads sind VMs traditionell die sicherere Wahl, Container vor allem in vertrauenswürdigen Umgebungen. Mehr in der Lektion Sicherheit in Docker-Umgebungen.

5) Portabilität – das Schiffscontainer-Versprechen

Der Name „Container" kommt nicht von ungefähr: Genauso wie ein See-Container mit standardisierten Maßen auf jedes Schiff, jeden Lkw und jeden Bahnwaggon passt, läuft ein Docker-Container auf jedem System mit kompatibler Runtime. Das Container-Image enthält die Anwendung samt allen Abhängigkeiten (Bibliotheken, Konfiguration, Laufzeitumgebung). Ein einmal gebauter Container läuft auf:

• dem Laptop des Entwicklers (Docker Desktop unter Windows, macOS, Linux)
• dem Test-Server des QA-Teams
• dem Produktions-Cluster (Kubernetes, OpenShift)
• jedem Cloud-Anbieter (AWS ECS, Azure Container Apps, GCP Cloud Run)

Damit endgültig der berühmte Entwicklerspruch „aber bei mir lief es!" – wenn das Container-Image lokal läuft, läuft es überall. Diese Portabilität ist einer der wichtigsten Gründe für den Erfolg von Docker.

6) Wann VM, wann Container?

In der Praxis sind Container und VMs keine konkurrierenden Technologien – sie ergänzen sich. Selbst Container laufen oft in VMs, vor allem in der Cloud: Eine EC2-Instanz hostet eine Kubernetes-Node, auf der Container laufen. So bekommt man die Isolation der VM und die Effizienz der Container. Welche Technologie für welchen Zweck:

7) Die Geschichte und der Marktdurchbruch

Container sind keine neue Erfindung: Schon Anfang der 2000er gab es FreeBSD Jails, Solaris Zones und – ab 2008 – Linux LXC. Diese Technologien waren mächtig, aber kompliziert zu bedienen. 2013 veröffentlichte Solomon Hykes Docker, das die bestehende Linux-Container-Technik mit einer einfachen Befehlszeile (docker run, docker build), einem standardisierten Image-Format und einer öffentlichen Registry (Docker Hub) zugänglich machte. Das war der Durchbruch – innerhalb von zwei Jahren wurde Docker zum Industriestandard.

Heute ist „Docker" oft Synonym für „Container", obwohl es genaugenommen nur eine bestimmte Implementierung ist. Die meisten Produktions-Cluster nutzen heute containerd als Runtime und Kubernetes als Orchestrierung. Docker bleibt aber das wichtigste Werkzeug für Entwickler und ist nach wie vor der Einstiegspunkt für die Container-Welt.

Zusammenfassung

VMs virtualisieren auf Hardware-Ebene mit eigenem Gastbetriebssystem pro VM, Container virtualisieren auf OS-Ebene und teilen den Host-Kernel. Schichten: VMs brauchen Hypervisor + Guest-OS pro Instanz; Container brauchen nur die Runtime und die App-Binaries. Startzeit: VMs starten in Minuten, Container in Sekunden bis Millisekunden. Ressourcen: Auf demselben Server laufen Hunderte Container statt Dutzender VMs. Isolation: VMs sind robuster isoliert (eigener Kernel), Container teilen den Host-Kernel und brauchen zusätzliche Schutzmechanismen (Namespaces, Cgroups, Seccomp). Portabilität: Container laufen identisch auf Laptop, Server und Cloud. Praxis: Container und VMs schließen sich nicht aus – oft laufen Container auf VMs. VMs eignen sich für klassische, stateful, langlebige Workloads und Multi-Tenancy mit hoher Isolation; Container für Microservices, CI/CD, schnelles Skalieren, Dev/Test-Umgebungen.

Verwandte Lektionen: Docker-Architektur · Was ist Virtualisierung? · Hypervisor Typ 1 vs. Typ 2 · und mehrWeitere relevante LektionenDocker Images & ContainerDockerfile schreibenSicherheit in Docker-UmgebungenCloud-Grundbegriffe (IaaS/PaaS/SaaS)Cloud-SkalierbarkeitLinux-GrundkommandosCloud als Megatrend