Image Layer

Du siehst Layer beim docker pull:

Pulling ubuntu:
abc1234: Pulling fs layer (50 MB)
def5678: Pulling fs layer (10 MB)

Jeder Befehl im Dockerfile (RUN, COPY, ADD) erzeugt einen neuen Layer. Wenn du apt-get update ausführst, entsteht ein Layer mit den neuen Index-Dateien.

Praxisroutine

In der Praxis lernst du Image Layer, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Copy-on-Write (CoW) Strategie

Wenn du eine Datei /etc/hosts in Layer 3 änderst, die in Layer 1 schon da war: Docker kopiert die Datei von Layer 1 nach Layer 3 (Copy-Up) und speichert dort die Änderung. Layer 1 bleibt unberührt (Immutable). Der Container sieht nur die Version aus Layer 3. Das Bläht Images auf: Wenn du eine 1GB Datei in Layer 2 hinzufügst und in Layer 3 löschst, ist das Image immer noch 1GB groß (weil Layer 2 noch da ist). Die Datei ist nur "whiteout" (unsichtbar) im Layer 3.

2. Storage Drivers (Overlay2)

Wie funktioniert die Magie technisch? Der Storage Driver (heute fast immer overlay2) regelt das. Er nutzt Kernel-Features, um Verzeichnisse "übereinander" zu mounten (lowerdir, upperdir, merged). Ältere Treiber (aufs, devicemapper) hatten Performance-Probleme oder inode-Limits. Overlay2 ist extrem schnell (Page Cache Sharing), nutzt aber Inodes auf dem Host-Filesystem.

3. Layer Sharing & Deduplication

Wenn 100 Images auf ubuntu:20.04 basieren. Der Ubuntu-Layer wird nur einmal auf der Festplatte gespeichert (/var/lib/docker/overlay2). Alle 100 Container nutzen denselben Read-Only Layer. Das spart Gigabytes an Platz. Deshalb ist es schlau, in der Firma ein "Golden Base Image" zu standardisieren.

Whiteouts und Opaque Dirs im UnionFS

Wie "löscht" man eine Datei in einem Read-Only-System? Wenn du im Layer 3 ein RUN rm -rf /app/secrets ausführst, obwohl /app/secrets im Layer 1 lag, löscht Docker physisch nichts. Stattdessen erstellt Overlay2 eine spezielle Character-Device-Datei mit der Major/Minor-Nummer 0/0 namens .wh.secrets (Ein Whiteout). Das Dateisystem treibt bei jedem Read-Request eine Täuschung: Es ignoriert den alten Ordner, sobald es den .wh-Merkzettel über ihn findet. Das perfide: Extrahiert ein Hacker dein fertiges Image lokal per docker save image > tar.tar und entpackt dessen Layer einzeln, sieht er die Ursprungsdatei in der Tiefe ungefiltert. Dies macht rm zum Verbergen von Credentials fatal.

Buildkit und Inline-Cache

Früher (Legacy Docker Builder) basierte das Layer-Caching rein auf der Linearen SHA-Historie. Änderte man in Zeile 5 was, flogen alle Layer ab Zeile 6 in den Müll (Cache Invalidation). Modernes Buildkit (der Standard seit Docker 20) bricht die lineare Kette auf. Es analysiert einen Directed Acyclic Graph (DAG) aller Befehle aus Multi-Stage-Builds und baut Layer parallel. Mit dem Flag --cache-from kannst du einen existierenden Container aus der Registry als "Remote Cache" beim Bauen einbinden (oft in CI/CD). Eine unsaubere Layer-Struktur (kopieren von oft mutierenden package.json und src/ Code in einem Layer) bricht jedoch jeden Caching-Mechanismus, weshalb man Dependency-Schichten (installieren der Pip-Pakete) zwingend vor das eigentliche Code-Copying packen muss.

Squash und Flattening

Viele Devs wollten Layer-Overhead reduzieren und nutzten docker export gefolgt von docker import (oder das --squash arg beim Bauen). Ein "Squash" drückt alle 20 Layer deines Images in einen einzigen gigantischen Layer zusammen. Der gravierende Nachteil: Das Zerstört das Kern-Feature "Shared Layers". Zehn gesquashte Images, die sich zuvor 500MB Ubuntu-Base geteilt hätten, blockieren auf der SSD dann brutal 5 GB (10x das Ubuntu Base-Image), weil der Layer-Hash sich als isolierter Blob grundlegend geändert hat. Squashen ist nur noch für winzige Distroless/Scratch-Binaries in hochgradigen Edge-Szenarien nützlich.