63 Image-Handling

Image-Handling ist eines der Kernthemen jeder Container-Engine und bei Podman besonders interessant, da es vollständig ohne zentralen Daemon funktioniert. Images sind nicht einfach „Container-Vorlagen“, sondern strukturierte, versionierte, transportable Artefakte, die Build-Prozesse, Supply Chains und Deployment-Pipelines miteinander verbinden. Wer Podman produktionsnah einsetzt, kommt deshalb nicht umhin, die Mechanik hinter Pull, Push, Caching, Layern und Signaturen zu verstehen. Die Arbeitsweise ist dabei an vielen Stellen Docker-kompatibel, aber durch den daemonlosen Ansatz transparenter und flexibler.

63.1 Image als transportable Laufzeitumgebung

Ein Container-Image ist eine Schichtung aus Filesystem-Layern und einem beschreibenden Manifest. Podman verwendet das OCI-Imageformat, das auch von Buildah, Skopeo, Docker und Kubernetes genutzt wird. Das bedeutet in der Praxis:

Images bestehen aus:

Mehrere Images können sich Layer teilen. Das spart Platz und verringert Pull-Zeiten.

63.2 Der Image-Store: container/storage

Podman speichert Images lokal über containers/storage, ein Storage-Treiber-System, das verschiedene Filesystemstrategien unterstützt:

Die Wahl des Treibers beeinflusst:

Diese Transparenz ist im Vergleich zu Docker deutlich höher: keine versteckte Daemon-Magie, sondern ein klarer, hostnaher Storage-Stack.

63.3 Pull-Strategien: Registries, Mirrors und Policies

Beim Image-Pull entscheidet Podman anhand von Regeln, woher ein Image bezogen wird. Diese Regeln sind in:

definiert. Im Gegensatz zu Docker ist das deutlich flexibler:

Beispielsweise kann eine Registry blockiert werden, um versehentliche Entwicklerschritte zu verhindern:

unqualified-search-registries = []

Dies zwingt den Nutzer zu expliziten Nennungen von registry/image:tag.

In Sicherheitskontexten ist das ein enormer Vorteil.

63.4 Tagging: Versionsmanagement für Images

Tags wirken trivial, sind aber der Schlüssel zur Steuerung von:

Ein gutes Tagging-Modell könnte so aussehen:

Podman verwaltet Tags wie Docker, aber transparenter: Ein Tag ist ein Zeiger auf ein Manifest, und Manifeste können wiederum Multiarch-Indexdateien sein.

63.5 Layer-Handling: Wiederverwendung statt Wiederaufbau

Layer-Caching ist eines der entscheidenden Optimierungsmerkmale. Podman nutzt denselben Mechanismus wie Buildah und Docker, allerdings ohne Daemon dazwischen — was die Diagnose erleichtert.

Klassisches Pattern:

Durch clevere Dockerfile/Containerfile-Struktur werden Layers wiederverwendbar.

Ein Diagnosewerkzeug ist:

podman history <image>

Das zeigt:

Für Architekten ein wichtiges Mittel zur Qualitätskontrolle.

63.6 Image-Manipulation: save, load, import, export

Podman erlaubt es, Images unabhängig von Registries zu bewegen:

podman save -o image.tar app:1.0
podman load -i image.tar

Damit lassen sich Images transportieren, ohne eine Registry zu nutzen — nützlich in:

Zusätzlich gibt es:

podman export   # exportiert Container-Filesystem
podman import   # erzeugt Images aus Tarballs

Export/Import erzeugen keine vollwertigen OCI-Schichten, sind aber als Debugwerkzeuge wertvoll.

63.7 Multiarch und Manifeste

Moderne Workflows setzen auf Multiarch-Images, z. B.:

Podman kann Manifeste direkt verwalten:

podman manifest create myimage
podman manifest add myimage docker://repo/app:amd64
podman manifest add myimage docker://repo/app:arm64

Damit entsteht ein Multiarch-Index, der automatisch die richtige Architektur für den Pull bereitstellt — eine Eigenschaft, die in heterogenen Systemlandschaften unverzichtbar wird.

63.8 Signierung und Verifizierung

Podman bringt einen besonders reifen Stack für Image-Sicherheit mit:

Durch containers-policy.json kann eine Organisation vorschreiben:

Docker kennt solche Mechanismen nur eingeschränkt oder als Add-on.

63.9 Garbage Collection und Pruning

Da Podman keinen Daemon hat, gibt es keinen Hidden State. Alle Images, Layer und Caches sind sichtbar.

Zur Bereinigung:

podman image prune
podman system prune

Im Gegensatz zu Docker werden Layers nicht „nebenbei“ gelöscht, sondern kontrolliert — was in produktionsnahen Systemen wichtig ist, da man Löschaktionen bewusst einplanen will.

63.10 Diagnosewerkzeuge: Inspect, Diff, History

Podman bietet detaillierte Einsicht in Images:

podman inspect <image>
podman diff <container>
podman history <image>

Damit lassen sich:

Gerade podman diff ist ein unterschätztes Werkzeug: Es zeigt präzise, wie sich ein laufender Container vom Image unterscheidet — relevant für Debugging, Sicherheit und State-Analyse.

63.11 Image-Handling mit Podman ist ein offenes System

Podman bildet Image-Verwaltung nicht als abgeschlossene Blackbox ab. Im Gegenteil: Es öffnet den Prozess, macht ihn verständlich und erweiterbar. Die Kombination aus Podman, Skopeo und Buildah ermöglicht einen modularen, transparenten Workflow:

Wer Container ernsthaft in die Produktionspipeline integriert, erhält damit ein Ökosystem, das fein steuerbar bleibt — ohne Monolith, ohne versteckte Daemons, ohne Abhängigkeit von proprietären Desktop-Werkzeugen.