Podman Compose ist kein Ersatz für Docker Compose, sondern dessen natürlicher Begleiter in einer daemonlosen Containerwelt. Es übersetzt dieselben deklarativen Compose-Dateien in Podman-Objekte — jedoch mit einem fundamentalen Unterschied: Wo Docker Compose „Container gruppiert“, erzeugt Podman Compose Pods, und zwar automatisch, deterministisch und im Sinne des Kubernetes-Modells. Damit wird Compose zu einem Werkzeug, mit dem komplexe lokale Stacks realistisch, strukturiert und ohne Orchestrator aufgesetzt werden können.
Compose bleibt im Kern eine YAML-basierte Beschreibungsform für Multi-Container-Anwendungen. Podman Compose folgt weitgehend der Docker-Compose-Spezifikation, allerdings mit Podman-spezifischer Semantik. Die vertraute Struktur bleibt erhalten:
services:
db:
image: postgres
app:
build: .
proxy:
image: nginxDer Unterschied liegt nicht im Format — sondern in der Interpretation.
Der wichtigste Unterschied zwischen Docker Compose und Podman Compose lautet:
Docker Compose erzeugt einzelne Container, die über ein Netz verbunden sind. Podman Compose erzeugt Pods, in denen Container gemeinsam laufen.
Jeder Compose-“Service” in einer Datei wird zu einem Container. Mehrere Services, die über dasselbe Netzwerk verbunden werden sollen, werden gruppiert. Podman Compose erstellt dafür eine Pod-Struktur, die dem Kubernetes-Modell ähnelt:
Pods werden automatisch nach dem Compose-Projekt benannt, inklusive Index für mehrere Instanzen.
Compose-Netzwerke sind traditionell virtuelle Bridges. Podman hingegen nutzt Netzwerke als eigenständige Objekte (Netavark), die — wenn sinnvoll — direkt an Pods gebunden werden. Ein Podman Compose Projekt erzeugt daher:
Es entsteht eine Netzwerkstruktur, die näher am Kubernetes-Modell liegt als an Docker.
Compose beschreibt Ports klassisch über:
ports:
- "8080:80"Docker ordnet Ports einzelnen Containern zu. Podman Compose weist Ports stattdessen dem Infrastrukturcontainer des Pods zu. Das heißt:
Dies macht Sidecars, Proxys, Exporter und Single-Host-Microservices erheblich einfacher zu betreiben.
Podman Compose unterstützt dieselben VOLUME-Deklarationen wie Docker Compose:
volumes:
data:
services:
db:
volumes:
- data:/var/lib/postgresql/dataDie Umsetzung ist jedoch Podman-spezifisch:
Das YAML bleibt identisch — die Runtime ändert sich.
Build-Sektionen funktionieren:
build:
context: .
dockerfile: ContainerfilePodman nutzt Buildah, wodurch Builds:
werden. Podman Compose ruft Buildah über Podman auf, ohne dass sich der Nutzer damit explizit befassen muss.
Podman Compose implementiert nahezu alle Standard-Compose-Felder:
environmentenv_filedepends_onhealthcheckconfigs und secrets (als lokale
Implementierungen)logging-KonfigurationDie Semantik bleibt identisch, die Ausführung erfolgt jedoch über Podman.
depends_on: keine Start-Order-GarantieDocker Compose garantiert Reihenfolgen. Podman Compose gibt diese Garantie nicht in derselben Form. Zwar versucht es, abhängige Services zuerst zu starten, aber:
Praktisch sind die Probleme geringer als bei Docker, aber das Verhalten ist im Detail anders.
Podman kann Compose-Projekte in Systemd-Units umwandeln:
podman generate systemd --new --filesDocker Compose muss dafür Wrapper-Skripte nutzen. Podman integriert sich dagegen nativ:
Damit wird Compose zu einer produktionsnahen Lösung auf Einzelhosts — etwas, das Docker Compose in dieser Form nie bieten konnte.
Podman Compose ist ein Werkzeug für:
Es ersetzt keinen Orchestrator. Es ersetzt kein Kubernetes. Aber es bildet Kubernetes-Pod-Strukturen lokal perfekt nach.
Wenn man die Komponenten zusammenführt, ergibt sich ein überraschend starkes Bild:
Podman Compose ist ein deklarativer Stack-Manager, der:
Damit ist Podman Compose eine realistische Plattform für viele Systeme, die ohne Orchestrator betrieben werden. Es fühlt sich wie ein „Mini-Kubernetes ohne Cluster“ an – nicht durch Zufall, sondern durch Design.