Container-Images sind primär für Registries gedacht, doch reale
Workflows lassen sich nicht auf Pull und Push reduzieren.
Entwicklungsumgebungen ohne Netz, Air-Gap-Cluster, isolierte Testzonen,
Archivierungsprozesse oder manuelle Debugging-Szenarien benötigen
direkte Kontrolle über das Image als Datei. Podman bietet dafür vier
Werkzeuge, die sich auf zwei Achsen unterscheiden: Images
vs. Container und Transport vs. Reproduktion. Die Befehle
save, load, export und
import sind dabei mehr als nur Dateikonvertierungshelfer –
sie definieren, wie ein Container-Artefakt außerhalb einer Registry
transportiert, verändert oder archiviert wird.
Um die vier Operationen richtig einzuordnen, muss man verstehen, dass Podman zwei grundverschiedene Formen von Containerdaten kennt:
Diese Formen sind nicht austauschbar, sondern folgen unterschiedlichen semantischen Regeln. Ein Image besitzt ein Manifest, Layer, Metadaten und History-Informationen. Ein RootFS hingegen ist ein flatten Snapshot ohne Metadaten.
Der Unterschied ist zentral: wer ein Image reproduzierbar übertragen will, nutzt Image-Mechanismen. Wer nur den Zustand eines Containers sichern oder portieren möchte, arbeitet mit RootFS-Prozessen.
Die semantische Einordnung der vier Funktionen lässt sich prägnant darstellen:
Image-basierte Operationen sind verlustfrei. RootFS-basierte Operationen verlieren Metadaten, sind aber nützlich für Debugging oder Air-Gap-Migrationen.
podman save erstellt ein Komplettabbild eines Images
inklusive aller Layer und Metadaten. Die resultierende Datei ist
typically ein OCI-konformes Tarball. Entscheidend ist: save
erzeugt eine wiederherstellbare Repräsentation, die exakt dem
Original entspricht.
Typische Einsatzfelder:
Die exportierte Datei enthält:
Kurz: alles, was für ein reproduzierbares Wiederherstellen notwendig ist.
Im Unterschied dazu transportieren viele Anwender Bilder per
docker save, was nominell ähnlich funktioniert – doch
Podman orientiert sich stärker am OCI-Standard und vermeidet versteckte
Abhängigkeiten.
podman load importiert ein zuvor gespeichertes Image
wieder in den lokalen Storage. Podman übernimmt Layer-Deduplizierung:
existiert ein Layer bereits lokal, wird er nicht erneut gespeichert.
Dadurch bleiben die Dateien klein, und der Storage wächst nicht
unnötig.
Ein praktisches Detail: load erzeugt automatisch die in
der Archivdatei enthaltenen Tags. Das bedeutet, dass ein in einer
Registry verwendetes Tag-Layout direkt wiederhergestellt wird, ohne
zusätzliche CLI-Aufrufe.
Für CI-Pipelines ist dies der entscheidende Mechanismus, wenn Images ohne Registry-Interaktion übertragen werden sollen.
podman export arbeitet nicht auf Image-Ebene, sondern
auf Container-Ebene. Das ist ein fundamentaler Unterschied. Exportiert
wird ausschließlich das RootFS des Containers – der aktuelle Zustand
inklusive aller Änderungen, aber ohne Layer, Manifest,
Metadaten oder History.
Dieses Verfahren ist ideal für:
Doch Achtung: export ist semantisch destruktiv. Die
resultierende Datei ist nicht direkt ein konsumierbares Image. Wer sie
in ein Image verwandeln will, benötigt podman import.
Ein häufiger Irrtum: Teams glauben, dass export eine
portable Form eines Images erzeugt. Tatsächlich werden alle
Image-Metadaten verworfen – einschließlich Entrypoints, Env-Variablen,
Labels oder History.
podman import nimmt ein RootFS-Tar und erzeugt daraus
ein neues Image. Da dabei sämtliche Metadaten verloren gingen, erhält
das neue Image minimale Default-Einstellungen. Wichtige Parametrisierung
(wie Entrypoint oder Labels) muss mit Flags rekonstruiert werden.
Dieses Verfahren eignet sich, wenn man bewusst „flache“ Images erzeugen möchte, z. B. für:
Ein Import-basiertes Image ist leerer, einfacher und damit oft transparenter. Es ist gewissermaßen ein „resetter“ übermäßig komplexer Layerbäume.
Viele Fehlerbilder entstehen dadurch, dass Anwender
save/load und export/import verwechseln. Zwei
typische Szenarien:
→ tatsächlich mit export ein RootFS erzeugt → nach
Import fehlen Entrypoint, User, Labels, Env → Deployment schlägt
fehl
→ tatsächlich ein komplettes OCI-Archiv über save →
unnötig große Datei, unnötige Layer, unnötige Historie
Eine klare mentale Schablone hilft: save/load ist ein exakter Roundtrip export/import ist ein destruktiver Transformationsprozess
In vielen Branchen – Industrie, Behörden, Medizin – sind Air-Gap-Cluster der Normalfall. Dort stehen Pulls aus Public Registries nicht zur Verfügung. Die Übertragung erfolgt über:
Hier ist save/load der korrekte Transportmechanismus.
Teams bauen Images im Internetbereich, signieren sie, archivieren sie
als OCI-Tarball und transferieren diese kontrolliert in den geschützten
Bereich. Dort werden sie mit load wiederhergestellt und
anschließend gegen eine interne Registry gepusht.
Dieses Verfahren schafft eine überprüfbare, auditierbare Lieferkette.
Manchmal reicht ein Registry-Push nicht aus, weil man das Image tatsächlich inspizieren oder modifizieren muss:
Für solche Zwecke dienen die Tar-Archive aus save oder
export als direkte Arbeitsobjekte. Entwickler können sie
auspacken, mit Tools analysieren und wieder packen – allerdings ist das
fehleranfällig und sollte nur für Debugging oder Forschung genutzt
werden.
Ein häufiges Muster im Debugging:
podman export eines Containerspodman import als neues ImageSo lassen sich schwer zu reproduzierende Fehler isolieren oder minimalistische Testimages erzeugen.
Images, die mehrere Plattformen unterstützen, bestehen aus mehreren
architekturspezifischen Images plus Manifest. podman save
kann diese Manifestliste vollständig exportieren.
podman load rekonstruiert sie entsprechend.
Bei RootFS-Prozessen existiert dieses Konzept nicht. Ein exportierter Container ist immer eindimensional. Das spielt im Debugging keine Rolle, im Produktionsbetrieb jedoch schon.