Virtuelle Maschine oder Container – in der Vorlesung klang das gleich, im Praktikum ist es das überhaupt nicht

Gute Frage, und die Antwort ist tatsächlich ein sauberer Einzeiler, den du dir merken kannst: Eine VM virtualisiert die Hardware, ein Container virtualisiert das Betriebssystem. Alles andere folgt daraus.

Virtuelle Maschine: Auf der echten Hardware läuft ein Hypervisor, der so tut, als gäbe es mehrere vollständige Rechner. Jede VM bekommt virtuelle CPU, virtuellen Arbeitsspeicher, virtuelle Festplatte und Netzwerkkarte – und darauf installierst du ein komplettes Gastbetriebssystem mit eigenem Kernel. Deine 8 GB und die Bootzeit sind genau das: Du startest einen ganzen Rechner, nur eben in Software.

Für die Klausur die übliche Unterteilung:

• Typ 1 (bare metal): Hypervisor läuft direkt auf der Hardware – Rechenzentrumsbetrieb, performanter
• Typ 2 (hosted): Hypervisor läuft als Programm in einem normalen Betriebssystem – das ist das, was du auf dem Laptop machst

Container: Hier gibt es kein zweites Betriebssystem. Alle Container auf einem Host teilen sich denselben Kernel und sind im Kern nur besonders gut abgeschottete Prozesse. Diese Abschottung leistet der Kernel selbst über zwei Mechanismen: Namespaces sorgen dafür, dass ein Container nur seine eigenen Prozesse, sein eigenes Dateisystem und sein eigenes Netzwerk sieht, und cgroups begrenzen, wie viel CPU und Arbeitsspeicher er verbrauchen darf.

Damit ist auch beantwortet, was ihm fehlt: das eigene Betriebssystem. Im Image stecken nur deine Anwendung, ihre Bibliotheken und ein paar Systemdateien – kein Kernel und nicht die vielen Dienste, die eine vollwertige Installation mitbringt. Daher MB statt GB und Sekunden statt Minuten, weil eben kein Bootvorgang stattfindet, sondern nur ein Prozess gestartet wird.

Zwei Begriffe, die gern verwechselt werden: Ein Image ist die unveränderliche Vorlage, ein Container die laufende Instanz davon – wie Klasse und Objekt in der objektorientierten Programmierung. Aus einem Image kannst du beliebig viele Container starten. Beschrieben wird das Image in einer Build-Datei (Basis-Image, Abhängigkeiten, Anwendung, Startbefehl), es besteht aus aufeinander aufbauenden Schichten und wird über eine Registry verteilt. Gemeinsame Schichten liegen auf dem Host nur einmal – noch ein Grund für den kleinen Fußabdruck.

Daniel hat das Technische abgedeckt, ich nehme den Beurteilungsteil – der bringt in der Klausur die Punkte, weil dort das „es kommt darauf an“ hingehört.

Container sind die bessere Wahl, wenn:

• die Anwendung zustandslos ist und du sie einfach mehrfach starten willst (Webdienste, Schnittstellen)
• du viele kleine Dienste betreibst (Microservices)
• du eine Build- und Auslieferungspipeline hast und bei jeder Änderung neu ausrollst
• Entwicklung, Test und Produktion identisch sein sollen – das Image, das getestet wurde, ist exakt das, was produktiv läuft. Damit stirbt das berühmte „Bei mir lief es doch“
• Dichte zählt: Auf einem Host laufen problemlos Dutzende Container, aber nur eine Handvoll VMs

Eine VM brauchst du weiterhin, wenn:

• ein anderes Betriebssystem nötig ist – ein Linux-Host kann keine Windows-Prozesse ausführen, dafür muss ein eigener Kernel her
• die Isolation stark sein muss, etwa bei fremden Mandanten auf derselben Hardware. Geteilter Kernel heißt: Eine Kernel-Lücke betrifft potenziell alle Container des Hosts – das ist die größere Angriffsfläche
• Altsoftware läuft, die eine bestimmte Systemumgebung erwartet, oder du eigene Kernel-Module bzw. spezielle Treiber brauchst
• zertifizierte, abgeschottete Umgebungen regulatorisch gefordert sind

Wichtig fürs Verständnis: In der Praxis ist das kein Entweder-oder. In der Cloud laufen Container fast immer innerhalb von VMs – die VM liefert die harte Trennung zwischen Kunden, der Container die schnelle Auslieferung der Anwendung. Schreib diesen Satz in die Klausur, dann ist der Beurteilungsteil beantwortet.

Noch drei Stolpersteine aus der Praxis:

1. Container sind vergänglich. Alles, was im Container geschrieben wird, ist beim Neustart weg. Daten gehören in Volumes oder in eine externe Datenbank. Eine Datenbank im Container ohne Volume ist ein garantierter Datenverlust.
2. Sicherheit ist Arbeit. Nicht als root im Container laufen, nur Images aus vertrauenswürdiger Quelle mit festem Versions-Tag, regelmäßig neu bauen. Ein Image ist eine Momentaufnahme – nach drei Monaten stecken bekannte Lücken darin, auch wenn scheinbar nichts passiert ist.
3. Betriebskomplexität. Bei drei Containern reicht die Kommandozeile, ab ein paar Dutzend brauchst du Orchestrierung – und die kostet Know-how. Die eingesparten Serverkosten holt der Betriebsaufwand schnell wieder rein. Das ist die betriebswirtschaftliche Seite der Antwort, die in einer WiInf-Klausur gern gesehen wird.