Podman begann als schlanke Container-Engine: „Starte mir einen Container, und zwar ohne Daemon.“ Die ersten Versionen folgten konsequent diesem Minimalprinzip. Ein Prozess, ein Container, ein Conmon – mehr brauchte es nicht. Mit wachsender Verbreitung veränderten sich jedoch die Anforderungen. Anwender wollten:
Die folgenden Entwicklungsschritte zeigen, wie Podman sich erweitert hat, ohne dabei die Grundidee des daemonlosen Modells aufzugeben.
Der Kern von Podman besteht aus wenigen, gut definierten Komponenten:
containers/storage,
containers/image)Die Engine baut keine Images und enthält keine Orchestrierungslogik. Alles, was nicht zur unmittelbaren Containerlaufzeit gehört, wird ausgelagert.
Ein typischer Ablauf:
Diese Struktur macht Podman robust, nachvollziehbar und frei von Hintergrunddiensten, die Zustand verwalten müssten.
Der nächste große Schritt war die Einführung von Pods. Podman-Pods sind nicht identisch mit Kubernetes-Pods, auch wenn der Begriff bewusst übernommen wurde. Die Idee ist ähnlich, die Umsetzung jedoch lokal und deutlich einfacher.
Ein Podman-Pod ist eine Gruppe von Containern, die bestimmte Namespaces teilen:
Container innerhalb eines Pods können dadurch über
localhost miteinander sprechen und folgen derselben
grundlegenden Umgebung. Dieses Modell eignet sich für lokale
Multi-Container-Anwendungen, Testaufbauten oder Edge-Geräte, bei denen
mehrere eng gekoppelte Prozesse zusammengeführt werden sollen – ohne
Kubernetes oder separate Orchestrierungswerkzeuge.
Pods ersetzen keine Orchestrierung, aber sie reduzieren deren Notwendigkeit in vielen Anwendungsfällen.
Viele Teams arbeiten seit Jahren mit docker-compose. Ein
Umstieg auf Podman wäre unpraktisch, wenn bestehende Compose-Dateien neu
geschrieben werden müssten.
Die Lösung: Podman kann heute als Backend für Compose dienen.
Das funktioniert auf zwei Wegen:
Damit lassen sich bestehende Compose-Workflows weiterverwenden, ohne Änderungen an YAML-Dateien oder Deployment-Skripten. Compose und Pods verfolgen jedoch unterschiedliche Modelle:
Beide Konzepte existieren nebeneinander und bedienen unterschiedliche Anforderungen.
Lange Zeit war Podman ein reines Linux-Werkzeug. Entwickler unter macOS oder Windows benötigten Workarounds oder separate VMs. Mit Podman Machine änderte sich das grundlegend.
Podman Machine stellt eine minimal konfigurierte VM bereit, die Podman ausführt – ähnlich wie Docker Desktop, aber ohne proprietäre Komponenten. Es nutzt:
und liefert:
Damit lässt sich Podman auf allen wichtigen Plattformen konsistent einsetzen, ohne dass die zugrunde liegende Architektur verändert wird.
Ein Architekturmodell:
Das verhindert Umgebungsunterschiede und sorgt für reproduzierbares Verhalten unabhängig vom Hostbetriebssystem.
Aus diesen Entwicklungsschritten ergibt sich heute ein Werkzeugkasten, der verschiedene Ebenen abdeckt:
Podman ist damit nicht „größer“ geworden, sondern breiter – durch Ergänzungen, die jeweils klar abgegrenzt bleiben. Die Architektur ist nach wie vor modular: Jede Funktion erweitert den Anwendungsbereich, ohne die Grundmechanik der Engine zu verbiegen.