57 Kompatibilität zu docker-compose

Die Popularität von docker-compose macht seine Kompatibilität zu einem entscheidenden Faktor für jede alternative Container-Engine. Podman adressiert dieses Bedürfnis bewusst: Der Großteil der Compose-Spezifikation wird unterstützt, und die Semantik der docker-compose.yaml bleibt weitgehend erhalten. Gleichzeitig gibt es fundamentale Unterschiede im Ausführungsmodell — insbesondere, weil Podman Compose nicht auf einen Daemon setzt und Compose-Services intern zu Pods gruppiert. Damit ist Podman Compose ähnlich, aber eben nicht gleich. Für Architekten ist es wichtig zu verstehen, wo die Grenzen liegen und welche Teile der bekannten Compose-Logik unverändert genutzt werden können.

57.1 Grundsatz: Podman Compose nutzt dieselbe YAML-Syntax

Podman Compose akzeptiert die gleichen YAML-Definitionen wie docker-compose. Die meisten Felder funktionieren identisch:

services, networks, volumes
environment, env_file
build und dockerfile
ports
depends_on
secrets, configs (eingeschränkt)
healthcheck
restart

Für viele Workflows bedeutet das: eine bestehende docker-compose.yaml lässt sich direkt mit Podman Compose starten, ohne Anpassungen.

In der Praxis heißt das: Kompatibilität im Format ja, Gleichheit im Verhalten nein.

57.2 Unterschiedliche Interpretationen der Compose-Felder

Compose war ursprünglich ein Docker-spezifisches Werkzeug. Podman nutzt dieselben Felder, interpretiert sie aber in einem anderen Kontext: daemonlos, pod-basiert, systemnah.

Einige Beispiele:

ports werden an den Infrastrukturcontainer des Pods statt an den Container gebunden
networks erzeugen Netavark-Netzwerke, die Pods zugeordnet werden
restart: wird nicht von einem Daemon kontrolliert, sondern später von systemd (falls generiert)
depends_on garantiert keine Startreihenfolge im klassischen Docker-Sinne

Die YAML bleibt identisch, die Semantik ändert sich teilweise.

57.3 Compose-Features, die vollständig kompatibel sind

57.3.1 Build-Sektionen

build: wird durch Podman/Buildah exakt so interpretiert wie durch Docker.

57.3.2 Environment Handling

Alle Varianten funktionieren:

environment:
  - KEY=value
  - OTHER=${ENVVAR}

57.3.3 Named Volumes und Bind Mounts

Die Syntax ist identisch, nur die Implementierung liegt in Podman Storage statt im Docker Daemon.

57.3.4 Netzwerke

Compose-Netzwerke werden zu Podman-Netzwerken übersetzt. Routing, Isolation und DNS entsprechen Podman-Semantik, aber die YAML funktioniert wie gewohnt.

57.3.5 Logging

Logging-Angaben werden akzeptiert, aber Podman nutzt keine Docker-spezifischen Logtreiber. Standard ist journald oder console, abhängig von der Umgebung.

57.4 Bereiche, in denen Podman Compose bewusst abweicht

57.4.1 1. Keine Daemon-abhängige Restart-Policy

Docker Compose delegiert Restart-Mechaniken an den Docker Daemon.

Podman Compose kann nur:

gar nicht neu starten
über systemd neu starten (bei systemd-Generierung)

Ein Beispiel:

restart: always

funktioniert bei docker-compose unmittelbar. Bei Podman Compose wird es erst mit podman generate systemd relevant.

Das ist kein Bug — es ist das Grundprinzip einer daemonlosen Engine.

57.4.2 2. Keine vollständige Unterstützung des Compose v2 Featuresets

Podman Compose implementiert den Compose-Standard größtenteils, aber nicht vollständig:

keine Swarm-Funktionen
keine GPU-spezifischen Felder
eingeschränkte Unterstützung komplexer deploy:-Blöcke
eingeschränkte Interpretation von secrets: und configs:

deploy: ist besonders relevant: bei Docker Swarm wird es aktiv genutzt, bei docker-compose ignoriert — und bei Podman Compose ist es weitgehend wirkungslos.

57.4.3 3. Multi-Container-Services werden zu Pods gruppiert

Ein Compose-Projekt erzeugt mindestens einen Pod. Services werden nicht wie bei Docker nebeneinander gestellt, sondern gruppiert:

services:
  app:
  proxy:
  db:

→ Docker: drei Container in einem Netzwerk → Podman: ein Pod, drei Container, ein Netzwerknamespace

Das Verhalten bleibt funktional ähnlich, aber die Laufzeitstruktur ist fundamental anders.

57.4.4 4. `depends_on` ist nicht identisch

Docker Compose:

garantiert Startreihenfolge (v2)
berücksichtigt Gesundheitschecks (mit condition:)

Podman Compose:

startet Container schnell, ohne strikte Reihenfolge
ignoriert Gesundheitscheck-Bedingungen
setzt eher auf Selbstheilung innerhalb des Pods

Für robuste Anwendungen spielt das selten eine Rolle, aber bei race conditions zwischen DB & App sollte man es bewusst berücksichtigen (z. B. über Wait-for-Skripte).

57.5 Bereiche, die oft fälschlich als „inkompatibel“ angesehen werden

57.5.1 Port-Mapping

Compose-Syntax ist identisch:

ports:
  - "8080:80"

Der Unterschied liegt nicht im YAML, sondern darin, dass die Ports an den Pod gebunden werden. Das führt manchmal zu Missverständnissen:

Docker: jeder Container hat eigene Ports
Podman: ein Pod hat Ports, Container darin teilen sich diese

Doch funktional bleibt die Freigabe identisch.

57.5.2 Netzwerk-Isolation

Compose-Netzwerke werden sauber umgesetzt — nur mit Netavark statt mit Docker Bridges. Die meisten docker-compose Netzwerktopologien funktionieren sofort und unverändert.

57.6 Wann ist Podman Compose ein Drop-In Replacement?

lokale Entwicklungsumgebungen, bei denen docker-compose YAMLs genutzt werden
CI/CD-Pipelines ohne Docker Daemon
Testumgebungen, die Pod-Strukturen benötigen
Multi-Container-Anwendungen auf einem Einzelhost
rootless Container-Workflows

Die Kompatibilität reicht für 90 % aller realen Projekte.

57.7 Wann wird es holprig?

bei Projekten, die Compose für Orchestierungsfunktionen missbrauchen (z. B. komplexe deploy:-Abschnitte)
bei GPU-basierten Anwendungen
bei Tools, die direkt mit Docker-Sockets kommunizieren
bei Szenarien, die hart auf Docker’s Logging- oder Networking-Interna zugreifen

Für die meisten Architekturen ist das kein Problem — aber bei tiefer Integration in Docker-spezifische Infrastruktur sollte man genauer hinsehen.

57.8 Ein praktischer Entscheidungsleitfaden

Wenn die Compose-Datei:

Services beschreibt
Ports freigibt
Volumes mountet
Build-Angaben enthält
Netzwerke definiert

→ Podman Compose funktioniert nahezu identisch.