# Docker Fundamentals: Die Architektur von Images & Containern

TL;DR / Management Summary Während LXC (Artikel 669) das Betriebssystem virtualisiert, virtualisiert Docker die Applikation. Docker ist heute der Industriestandard für portable Workloads. Ein Senior Admin versteht den Unterschied zwischen dem schreibgeschützten Image (dem Bauplan) und dem laufenden Container (der Instanz). Wir nutzen das Layer-Modell, um Speicherplatz zu sparen, und das Dockerfile, um die Infrastruktur exakt zu dokumentieren.

# 1. Das Docker-Modell

Vom Code zum Artefakt.

Docker trennt die Applikation von der Infrastruktur:

Dockerfile: Eine Textdatei mit Anweisungen (z.B. FROM debian, RUN apt install ...).
Image: Das Ergebnis des Build-Prozesses. Ein unveränderlicher (immutable) Snapshot der Applikation.
Container: Ein laufender Prozess am Host, der auf dem Image basiert und eine beschreibbare Ebene (Read-Write Layer) obenauf hat.

# 2. Deep Dive: Layer-Architektur

Speicherplatz sparen durch Stapeln.

Ein Docker-Image besteht aus mehreren Schichten (Layers).

Base Layer: (z.B. Debian OS).
Middleware Layer: (z.B. Python Runtime).
App Layer: (Ihr eigentlicher Code).

Vorteil: Wenn Sie 10 verschiedene Python-Apps haben, wird der Base- und Middleware-Layer nur einmal physisch auf der Festplatte Ihres Proxmox-Hosts gespeichert.

# 3. Container-Lebenszyklus

Erstellen, Laufen, Sterben.

Container sind flüchtig (Ephemeral).

Regel: Speichern Sie niemals Daten innerhalb des Containers! Alles, was erhalten bleiben muss (Datenbanken, Configs), gehört in Docker Volumes oder Bind-Mounts (Artikel 678).
Zustand: Ein Container sollte jederzeit gelöscht und neu gestartet werden können, ohne dass Informationen verloren gehen.

# 4. Day-2 Operations: Image-Hygiene

Den ‘Bloat’ vermeiden.

Große Images verlangsamen das Deployment und erhöhen die Angriffsfläche.

Aktion: Nutzen Sie Multi-Stage Builds.
- Stage 1: Kompiliere den Code (benötigt Build-Tools).
- Stage 2: Kopiere nur das fertige Binary in ein minimales Image (z.B. alpine).
Ergebnis: Ein 800 MB Image schrumpft auf 20 MB.

# 5. Troubleshooting & “War Stories”

Wenn der Wal strandet.

# Top 3 Fehlerbilder

Symptom: Container startet und beendet sich sofort wieder.
- Ursache: Der Hauptprozess (PID 1) wurde beendet (z.B. ein Dienst, der in den Hintergrund geht).
- Lösung: Docker-Container brauchen einen Prozess, der im Vordergrund bleibt (z.B. tail -f /dev/null oder der Webserver-Prozess selbst).
Symptom: Disk-Space am Host ist voll.
- Lösung: docker system prune löscht ungenutzte Layer und “Dangling” Images.
Symptom: “Network unreachable” aus dem Container heraus.
- Check: sysctl net.ipv4.ip_forward am Host prüfen (Artikel 707).

# “War Story”: Der “Volltext”-Container

Ein Admin betrieb einen Suchmaschinen-Container (Elasticsearch) ohne externes Volume. Das Ereignis: Er führte ein Update durch: docker rm my-search && docker run my-search:latest. Das Ergebnis: Der neue Container startete, aber alle indizierten Daten (1 TB) waren weg. Der Admin hatte vergessen, dass die Daten nur in der flüchtigen Schreib-Ebene des alten Containers lagen. Lehre: Verstehen Sie die Nicht-Persistenz von Containern. Ein Container ohne -v (Volume) Mapping ist ein Server ohne Langzeitgedächtnis.

# 6. Monitoring & Reporting

Container-Metriken.

# docker stats (Shell)

# Echtzeit-Übersicht aller Container
docker stats --no-stream

KPI: MEM USAGE / LIMIT. Achten Sie auf Memory-Leaks in Java- oder Node.js Containern.

# 7. Fazit & Empfehlung

Docker ist das Fundament für moderne Skalierbarkeit.

Empfehlung: Nutzen Sie Alpine Linux als Basis-Image für Ihre Container. Es ist sicher und winzig.
Wichtig: Verwenden Sie niemals den Tag :latest in Produktion. Fixieren Sie Ihre Versionen (z.B. :1.24.1), um unvorhersehbare Änderungen beim automatischen Neustart zu vermeiden.

# Anhang: Cheatsheet (Wichtige Befehle)

Aufgabe	Befehl
Image bauen	`docker build -t myapp:v1 .`
Container starten	`docker run -d --name myapp -p 80:80 myapp:v1`
Logs einsehen	`docker logs -f myapp`
In Container springen	`docker exec -it myapp sh`