Begriff

Docker Image

Containerization Docker S1

2 Quellen 1 Lernpfad 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Wenn du einen Container starten willst, brauchst du eine Vorlage. Diese Vorlage ist das Docker Image. Es ist wie ein Schnappschuss (Snapshot) von einem kompletten Computer. Darin ist:

Das Betriebssystem (Linux Alpine, Ubuntu).
Die Tools (Python, Node.js).
Dein Code (app.py). Der Clou: Ein Image ist unveränderlich (Immutable). Wenn du es einmal gebaut hast, ändert es sich nie wieder (außer du baust eine neue Version v2). Wenn du 10 Container aus einem Image startest, sind alle 10 beim Start exakt gleich.

Merksatz: Ein schreibgeschütztes Template, das alle notwendigen Dateien (Code, Libraries, Dependencies, OS) enthält, um einen Container auszuführen. Es besteht aus übereinanderliegenden Layern.

Du bekommst Images aus dem Internet (Docker Hub): docker pull nginx:latest (Lädt das Image herunter). docker images (Zeigt alle Images auf deiner Festplatte). docker run nginx (Macht aus dem toten Image einen lebenden Container). docker rmi nginx (Löscht das Image, um Platz zu sparen).

Praxisroutine

In der Praxis lernst du Docker Image, 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. Layers & UnionFS

Ein Image ist keine einzelne Datei (wie .iso). Es ist ein Stapel von Layern (Schichten).

Layer 1: Ubuntu Base (100 MB).
Layer 2: Python installiert (50 MB).
Layer 3: Dein Code (1 MB). Docker nutzt ein Union Filesystem (Overlay2). Wenn du Layer 3 liest, schaut Docker durch alle Schichten hindurch. Wenn du eine Datei in Layer 1 löschst? Docker markiert sie im oberen Layer als "gelöscht" (Whiteout File .wh.file), aber im unteren Layer ist sie physikalisch noch da. Das bläht Images auf, wenn man nicht aufpasst!

2. Manifest & Digest (SHA256)

Tags (:latest) sind gefährlich (Mutable). Heute zeigt es auf v1, morgen auf v2. Produktions-Systeme nutzen den Digest (Hash). nginx@sha256:854c32.... Dieser Hash ist kryptografisch eindeutig. Er wird aus dem Manifest berechnet (einer JSON-Datei, die die Liste aller Layer-Hashes enthält). Wenn sich ein Bit in einem Layer ändert, ändert sich der Digest.

3. Scratch Images & Distroless

Profis nutzen keine vollen OS-Images (Ubuntu/Debian). Sie nutzen:

Alpine: Winzig (5 MB), aber nutzt musl statt glibc (Kompatibilitätsprobleme).
Distroless (Google): Enthält nur deine App und Laufzeitumgebung. Keine Shell (/bin/sh), kein ls, kein apt. Mega sicher, weil Angreifer nichts tun können, selbst wenn sie reinkommen.
Scratch: Leeres Image. Perfekt für Go/Rust Binaries (FROM scratch). 0 Overhead.

1. UnionFS (OverlayFS2) Architektur

Ein Docker Image ist keine monolithische 2-Gigabyte .iso Datei. Es ist eine abstrakte Illusion des Dateisystems. Auf der SSD (Solid State Drive) deines Hosts (in /var/lib/docker/overlay2/) existiert ein gigantischer Ordner mit Hash-Namen. Jedes Kommando (RUN apt-get install curl) im Dockerfile erzeugt einen neuen Hash-Ordner (Layer), in dem nur die Differenz (das kleine Binary von curl) liegt. Startest du den Container, nimmt das OverlayFS alle Dutzend RO-Layer (Read-Only) und stülpt sie (wie durchsichtige Folien auf einem Overheadprojektor) optisch übereinander in einen Mountpoint. Dem Container wird vorgegaukelt, ein einzelnes, flaches C:\ Laufwerk vor sich zu haben.

2. Copy-on-Write (CoW) und UpperDir

Wenn das Image zu 100% Read-Only ist, wie kann deine App beim Laufen dann eine Logdatei in /var/log schreiben? Der laufende Container bekommt von Docker einen hauchdünnen, unsichtbaren R/W-Layer (UpperDir) ganz oben auf den Folienstapel gelegt. Hier greift Copy-on-Write (CoW): Möchtest du im Container eine fette 100 MB Datei aus dem Basis-Image leicht verändern, blockiert Docker das. Docker kopiert die 100 MB Datei blitzschnell unsichtbar vom RO-Layer buchstäblich hoch in den UpperDir-Layer, und dort modifizierst du sie. Die Basisdatei bleibt für immer unberührt. Das Kopieren kostet kurz extrem viel I/O Performance, schützt aber das Original-Image.

3. OCI (Open Container Initiative) Format

Früher war ein Image das propritär verschlossene Eigentum von "Docker Inc.". Heute unterliegen Images dem offenen Standard OCI. Dort ist exakt definiert (JSON-Schema), wie das Image-Manifest aufgebaut ist. Das ist der entscheidende Punkt, warum moderne Runtimes in Kubernetes wie containerd oder CRI-O (als Docker-Konkurrenz) ein normales "Docker Image" starten können, ohne dass du auch nur noch eine einzige Zeile Docker-Source-Code auf deinem Server installiert hast. Das Image ist universell portabel zwischen den IT-Konzernwelten geworden.

Quick-Check

Was ist "Squashing"?
Das Zusammenfügen vieler kleiner Layer zu einem großen. Vorteil: Kleinere Gesamtgröße (gelöschte Dateien fliegen wirklich raus). Nachteil: Docker kann Layer nicht mehr wiederverwenden (schlechtes Caching beim Pull/Push).
Warum keine Passwörter im Image?
Weil jeder, der docker history tippt oder das Image entpackt (docker save), die Datei im Klartext sehen kann. Auch wenn du sie im nächsten Layer löschst! (Siehe Whiteout Files).
Was ist OCI?
Open Container Initiative. Ein Standard, damit Docker-Images auch in anderen Runtimes (Podman, Kubernetes CRI-O) laufen. Ein "Docker Image" ist heute eigentlich ein "OCI Image".