Container verstehen: Image, Container und VM

Worum es geht

Elias ist im 2. Lehrjahr als Informatiker Applikationsentwicklung bei der Transbox Logistik AG in Härkingen. Das Entwicklungsteam betreut die Rampenbuchung: eine Spring-Boot-Webanwendung mit PostgreSQL, über die Speditionen ein Zeitfenster an einer der Laderampen buchen. Klingt einfach, aber im Alltag knirscht es:

• Lea arbeitet mit Java 21 und PostgreSQL 16, Marco noch mit Java 17 und PostgreSQL 14. Ein Datumsfehler tritt nur bei Marco auf.
• Ein neuer Lernender braucht einen halben Tag, bis die Anwendung auf seinem Laptop läuft. Die Anleitung im Wiki ist zwei Jahre alt.
• Auf dem Testserver läuft «irgendeine» Version. Wer sie wann installiert hat, weiss niemand genau.

Der Satz, den alle kennen: «Bei mir läuft es.» Das Problem ist selten der Code, sondern die Umgebung: Java-Version, Datenbankversion, Betriebssystem, Umgebungsvariablen, installierte Bibliotheken. Container lösen genau dieses Problem. Du beschreibst die komplette Laufzeitumgebung einmal, baust daraus ein Paket, und dieses Paket startet auf jedem Laptop, auf dem Testserver und in der Cloud gleich.

In dieser Lektion verstehst du, was Images und Container sind, worin sie sich von virtuellen Maschinen unterscheiden und wann du welche Technik wählst. Am Schluss startest du eine PostgreSQL-Datenbank in wenigen Sekunden, ohne sie zu installieren.

Image und Container: Vorlage und laufendes Exemplar

Denk an einen Schiffscontainer. Der Kran im Hafen weiss nicht, ob Bananen oder Laptops drin sind. Er kennt nur die genormte Box mit den genormten Ecken. Genau diese Idee übernimmt Docker für Software: Was in der Box steckt, ist deine Sache. Wie die Box gestartet, gestoppt und verschoben wird, ist überall gleich.

Zwei Begriffe musst du sauber auseinanderhalten:

• Ein Image ist eine unveränderliche Vorlage. Es enthält ein minimales Dateisystem (z.B. die Dateien eines schlanken Linux), die Laufzeit (z.B. Java), deine Anwendung und Metadaten wie den Startbefehl. Ein Image wird gebaut und danach nicht mehr verändert.
• Ein Container ist ein laufendes (oder gestopptes) Exemplar eines Images. Er bekommt eine eigene, dünne beschreibbare Schicht obendrauf, eigene Prozesse, ein eigenes Netzwerk-Interface und einen eigenen Namen.

Aus der objektorientierten Programmierung kennst du das Muster: Image verhält sich zu Container wie Klasse zu Objekt. Aus einer Klasse erzeugst du beliebig viele Objekte mit eigenem Zustand. Aus einem Image startest du beliebig viele Container, und jeder hat seine eigene beschreibbare Schicht.

Daraus folgt eine wichtige Denkweise: Container sind wegwerfbar. Du reparierst keinen Container von Hand, sondern baust ein neues Image und startest einen neuen Container. Daten, die bleiben sollen (z.B. die Buchungen in der Datenbank), legst du ausserhalb des Containers ab. Wie das geht, lernst du in Lektion 8.

Container und virtuelle Maschine im Vergleich

Bisher läuft der Testserver der Rampenbuchung als virtuelle Maschine (VM). Ein Hypervisor wie Hyper-V oder VMware simuliert dort einen kompletten Rechner, und darin läuft ein vollständiges Gastbetriebssystem mit eigenem Kernel. Drei Anwendungen in drei VMs bedeuten drei komplette Betriebssysteme, die alle booten, gepatcht und überwacht werden müssen.

Ein Container funktioniert anders. Er bringt kein eigenes Betriebssystem mit Kernel mit, sondern nur die Dateien, die die Anwendung braucht. Alle Container auf einem Host teilen sich den Kernel des Hosts. Der Linux-Kernel sorgt mit zwei Mechanismen dafür, dass sie sich trotzdem nicht in die Quere kommen:

• Namespaces isolieren, was ein Prozess sieht: eigene Prozessliste, eigenes Netzwerk, eigenes Dateisystem, eigener Hostname. Ein Prozess im Container sieht nur «seine» Welt.
• Control Groups (cgroups) begrenzen, wie viel er verbrauchen darf: CPU, Arbeitsspeicher, Ein- und Ausgabe.

Ein Container ist also im Kern ein ganz normaler Prozess auf dem Host, nur gut abgeschirmt. Deshalb startet er in Sekunden statt Minuten: Es muss kein Betriebssystem booten.

Die Zahlen sind Richtwerte. Elias hat für die Rampenbuchung gemessen: Der Container startet in etwa 2 Sekunden und braucht rund 150 MB RAM, die bisherige Test-VM braucht 2 Minuten zum Booten und 2 GB RAM.

Wann Container, wann VM, wann PaaS?

Container sind kein Allheilmittel. Im Teammeeting will die Teamleiterin wissen, ob man jetzt alles in Container packen soll. Elias argumentiert mit drei Fragen:

1. Ist es unsere eigene Anwendung, die wir oft neu ausliefern? Dann passen Container sehr gut. Die Rampenbuchung bekommt alle zwei Wochen ein Release, und jede Version soll in Test und Produktion identisch laufen.
2. Braucht die Software ein eigenes Betriebssystem oder eine grafische Installation? Das alte ERP-System läuft nur auf einem bestimmten Windows Server, wird mit einem Setup-Assistenten installiert, und die Lizenz ist an die Maschine gebunden. Das bleibt auf seiner VM.
3. Wollen wir uns um die Plattform überhaupt kümmern? Für eine einfache Webanwendung ohne Spezialbedarf kann ein PaaS-Angebot (Platform as a Service, z.B. ein App-Service in der Cloud) besser sein: Du lädst nur den Code oder das Image hoch, Betrieb, Patches und Skalierung übernimmt der Anbieter. Dafür hast du weniger Kontrolle.

Schritt für Schritt: Die erste Datenbank in drei Sekunden

Elias will dem Team zeigen, wie schnell das geht. Du kannst die Schritte selbst nachmachen. Voraussetzung: Docker Desktop (unter Windows mit WSL 2) oder Podman ist installiert.

Schritt 1: Prüfen, ob Docker läuft.

docker version

Du siehst einen Block «Client» und einen Block «Server». Fehlt der Server-Teil, läuft die Docker Engine nicht. Starte dann Docker Desktop.

Schritt 2: PostgreSQL als Container starten.

docker run -d --name testdb -e POSTGRES_PASSWORD=nurlokal -p 5432:5432 postgres:17

Die Teile bedeuten:

Beim ersten Mal lädt Docker das Image aus der Registry Docker Hub herunter (Pulling from library/postgres). Danach liegt es lokal und der nächste Start dauert nur noch Sekunden.

Schritt 3: Prüfen, ob der Container läuft.

docker ps

CONTAINER ID   IMAGE         COMMAND                  STATUS         PORTS                    NAMES
3c1f9a7e2b44   postgres:17   "docker-entrypoint.s…"   Up 4 seconds   0.0.0.0:5432->5432/tcp   testdb

Schritt 4: In die Logs schauen.

docker logs testdb

Die letzte Zeile lautet sinngemäss «database system is ready to accept connections». Die Datenbank ist bereit.

Schritt 5: Im Container einen Befehl ausführen.

docker exec -it testdb psql -U postgres -c "SELECT version();"

docker exec startet einen zusätzlichen Prozess im laufenden Container. Hier ist es der PostgreSQL-Client psql, der schon im Image enthalten ist. Auf deinem Laptop musst du nichts installieren.

Schritt 6: Ein zweiter, unabhängiger Container aus demselben Image.

docker run -d --name testdb2 -e POSTGRES_PASSWORD=nurlokal -p 5433:5432 postgres:17

Das Image wird nicht noch einmal geladen. Der zweite Container hat seine eigene beschreibbare Schicht und damit eine eigene, leere Datenbank. Weil Port 5432 auf dem Laptop schon belegt ist, leitest du hier Port 5433 weiter.

Schritt 7: Aufräumen.

docker stop testdb testdb2
docker rm testdb testdb2

stop beendet die Container, rm löscht sie samt beschreibbarer Schicht. Das Image postgres:17 bleibt lokal liegen (docker image ls).

Typische Fehler

• Image und Container verwechseln. «Ich habe im Image eine Datei geändert» geht nicht. Du hast sie im Container geändert, und mit dem Container ist sie weg. Dauerhafte Änderungen gehören ins Dockerfile (Lektion 3).
• Den Container wie eine kleine VM behandeln. SSH-Server einbauen, mehrere Dienste in einen Container packen, von Hand Pakete nachinstallieren: Das macht Container schwer nachvollziehbar. Faustregel: ein Dienst pro Container.
• docker run zweimal mit demselben Namen. Die Meldung «The container name "/testdb" is already in use» heisst: Der Container existiert schon (vielleicht gestoppt). Starte ihn mit docker start testdb oder lösche ihn zuerst.
• Kein Tag angeben. docker run postgres bedeutet postgres:latest. Morgen kann das eine neue Hauptversion sein. Gib immer eine Version an, z.B. postgres:17.
• Container für eine Sicherheitsgrenze wie bei VMs halten. Container teilen sich den Kernel. Eine Lücke im Kernel betrifft alle Container auf dem Host. Für stark getrennte Kunden oder heikle Software ist eine VM als zusätzliche Schicht sinnvoll.

Zusammenfassung

• Container lösen das Problem «bei mir läuft es», indem sie die ganze Laufzeitumgebung mitliefern.
• Image = schreibgeschützte Vorlage, Container = laufende Instanz mit eigener beschreibbarer Schicht (wie Klasse und Objekt).
• Container teilen sich den Kernel des Hosts und werden mit Namespaces und cgroups isoliert. Deshalb starten sie in Sekunden und sind klein.
• VMs bringen ein ganzes Gastbetriebssystem mit: stärkere Isolation, aber langsamer und schwerer.
• Eigene, häufig ausgelieferte Anwendungen passen in Container, Fremdsoftware mit eigenem OS auf eine VM, einfache Webanwendungen ohne Betriebsaufwand oft auf PaaS.
• Die ersten Befehle: docker run, docker ps, docker logs, docker exec, docker stop, docker rm.