Storage-Mapping bezeichnet die Art und Weise, wie Daten zwischen Host und Container bzw. zwischen verschiedenen Containern verfügbar gemacht werden. In Podman ist dieser Bereich bewusst transparent gestaltet, weit näher am Linux-Unterbau als in Docker-Umgebungen, wo ein zentraler Daemon eine abstrahierende Rolle übernimmt. Storage-Mapping ist deshalb kein beiläufiger Aspekt, sondern ein zentrales Architekturthema: Es entscheidet darüber, wie persistent Daten sind, wie performant Write-Paths ausfallen und wie reproduzierbar ein Containerlaufzeitmodell tatsächlich wird.
Das wichtigste Designprinzip lautet: Container sind vergänglich, Storage nicht. Podman separiert diese beiden Aspekte deutlich:
Dieses Modell zwingt dazu, Datenpfade explizit zu gestalten statt implizite Daemon-Magie zu erwarten.
Podman nutzt containers/storage und layerbasierte
Filesysteme. Die wichtigsten Varianten:
Die Layerstruktur lässt sich inspizieren:
podman inspect <image>
podman history <image>Diese Einsicht ist ein Vorteil gegenüber Docker, wo der Daemon viel verschleiert.
Podman kennt drei Grundformen:
Jede hat spezifische Implikationen für Konsistenz, Performance und Rechteverwaltung.
Bind-Mounts spiegeln einen Host-Pfad in den Container:
-v /data/app:/srv/dataVorteile:
Nachteile:
Typische Stolperstelle: ein Container läuft rootless, das Host-Directory gehört UID 1000, der Container sieht jedoch 1000 → 100000 gemappt. Schreibzugriffe scheitern häufig.
Bind-Mounts sind mächtig, aber müssen mit Bedacht eingesetzt werden.
podman volume create appdata
podman run -v appdata:/var/lib/appMerkmale:
Podman speichert Named Volumes standardisiert unter:
/var/lib/containers/storage/volumes/<NAME>/Rootless entsprechend unter:
~/.local/share/containers/storage/volumes/<NAME>/Named Volumes sind ideale Produktionskandidaten ohne Orchestrator.
Sie entstehen automatisch:
-v /var/lib/appPodman erzeugt ein namenloses Volume.
Risiken:
Anonymous Volumes sind gut für temporäre Laufzeiten, aber nicht für produktive Deployments.
Der Umgang mit UID/GID ist ein Kernthema des Storage-Mappings und eine der häufigsten Fehlerquellen.
Beispiel:
chown 100000:100000 /data/appNur so kann ein rootless Container in dieses Verzeichnis schreiben.
Diese Details müssen bewusst berücksichtigt werden, besonders bei Bind-Mounts, Datenbanken, Caches oder Lockfiles.
Container in einem Pod teilen sich Namespaces — aber Storage teilen sie nur bei expliziten Mounts.
Strategien:
Ideal für Logs, Cache-Folder, temporäre Daten. Minimiert die Gefahr von Race Conditions.
Beispielsweise:
Wichtig: Locking und Transaktionen müssen sauber gestaltet sein.
Dieses Pattern ist robust und deutlich kontrollierter als Netzwerk-basierter Austausch.
Da Pods denselben Netzwerknamespace teilen, aber nicht denselben Storage, muss Storage explizit verbunden werden.
Ein Pod mit mehreren Containern sollte Volumes so definieren:
podman run --pod mypod -v data:/var/lib/app app
podman run --pod mypod -v data:/var/lib/app-sidecar backupJeder Mount ist unabhängig — kein implizites Sharing.
Podman Machine bringt eine zusätzliche Ebene ins Spiel: die VM-Schicht.
Der allgemeine Rat lautet:
Ein sinnvolles Modell ohne Orchestrator:
Dieses Schema ist einfach, aber stabil – und vermeidet die häufigsten Probleme rund um Rechte, Performance und Datenverlust.
Die eigentliche Besonderheit von Podman ist nicht ein bestimmtes Storage-Format, sondern die Tatsache, dass Storage-Mapping ein expliziter, sichtbarer, steuergerechter Teil der Architektur bleibt. Im Gegensatz zu vielen Daemon-designs wird hier nichts versteckt.
Storage wird bewusst gestaltet statt nebenbei „mitzutröpfeln“.