Compose-Dateien sind im Kern einfache deklarative Beschreibungen von Diensten. In der Praxis sind sie jedoch weit mehr: Sie sind ein Architekturartefakt, ein Dokument zur Wissensweitergabe und ein operativer Ankerpunkt für wiederholbare Deployments. Eine gut gestaltete Compose-Datei erkennt man daran, dass sie zwei Dinge gleichzeitig schafft: Sie ist verständlich für Menschen und präzise für Maschinen. Mit Podman Compose kommt ein weiterer Anspruch hinzu: Compose-Dateien sollten nicht nur Docker-kompatibel sein, sondern gleichzeitig optimal die Pod-Architektur und die daemonlosen Eigenschaften von Podman nutzen.
Eine Compose-Datei beschreibt nicht nur „welche Container sollen laufen?“, sondern:
Das Dokument wird damit zu einem Strukturplan der Anwendung. Es lohnt sich, diese Rolle ernst zu nehmen und nicht als bloße Startkonfiguration zu behandeln.
Eine übersichtliche Compose-Datei folgt einer klaren Struktur:
services)volumes,
networks)profiles)env_file, .env)Die Reihenfolge wirkt trivial, schafft aber Lesbarkeit. In der Praxis empfiehlt sich:
Ein Beispielausschnitt:
services:
api:
build: ./api
networks:
- internal
volumes:
- api_data:/var/lib/api
proxy:
image: nginx
networks:
- public
- internal
ports:
- "8080:80"
worker:
build: ./worker
networks:
- internal
volumes:
api_data:
networks:
public:
internal:Die Struktur kommuniziert bereits die Architektur: ein öffentlich zugänglicher Proxy, interne Services, eigenes Volume für persistente Daten.
Podman Compose erzeugt Pods — und zwar in der Regel einen Pod pro Projekt. Daraus entstehen sinnvolle Patterns, die man aktiv berücksichtigen sollte:
Das bedeutet:
API_URL=http://localhost:5000 ist oft ausreichendDarum gilt: Interne Ports niemals doppelt belegen.
Wenn zwei Services denselben Port erwarten, ist ein explizites Netzwerk statt eines Pods sinnvoller.
Der Infrastrukturcontainer verwaltet Ports. Die Compose-Datei sollte daher:
Ein häufiger Fehler ist:
serviceA:
ports:
- "8080:80"
serviceB:
ports:
- "8080:80"Bei Docker geht das — bei Podman Compose nicht, da beide Services im selben Pod laufen.
Compose macht es leicht, Netzwerke zu erzeugen — aber zu viele Netzwerke führen zu Unübersichtlichkeit. Best Practices:
Beispiel:
networks:
internal:
edge:Ein Podman-spezifischer Vorteil: Netzwerke werden zu first-class-Objekten, die deterministisch verwaltet werden. Dadurch lohnt es sich, sie bewusst zu modellieren.
Persistenz ist eines der am meisten unterschätzten Themen in Compose-Dateien. Gute Best Practices:
Bind mounts sind bequem, aber riskant. Named Volumes sind:
Statt:
volumes:
- data:/databesser:
volumes:
- api_data:/var/lib/apiDas wirkt trivial, aber verhindert Chaos nach Monaten oder Jahren.
Viele Compose-Dateien persistieren irrtümlich:
Best Practice: Volumes nur dort definieren, wo sie wirklich nötig sind.
Compose bietet mehrere Varianten, aber viele Projekte nutzen sie falsch.
.env-Pattern.env wird automatisch geladen und eignet sich für:
env_file für
teamübergreifende KonfigurationenEine getrennte Datei für komplexe Umgebungsvariablen erleichtert Wartbarkeit und Dokumentation.
Passwörter gehören:
.envEin Compose-Projekt ist ein Konfigurationsartefakt — kein Secret-Store.
Compose-Healthchecks sind sinnvoll, aber Podman Compose wertet die
Startbedingungen (depends_on.condition) nicht voll aus.
Deshalb:
Beispiel:
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:5000/health"]
interval: 10s
retries: 5Dies hilft bei Monitoring — nicht beim Start-Workflow.
Compose-Profile ermöglichen es, Umgebungen modular zu gestalten:
profiles:
- metricsServices können Profile zugewiesen bekommen:
services:
prometheus:
image: prom/prometheus
profiles: ["metrics"]Dadurch lassen sich:
gezielt aktivieren oder deaktivieren.
:1.4, nicht
:latest)Fehlt Versionspinning, wird jede Umgebung zu einem Glücksspiel.
Podman Compose ist kein Orchestrator — aber es lässt sich durch systemd zu einem stabilen Betriebssystemdienst erweitern:
podman generate systemd --new --filesDadurch entstehen:
Eine Compose-Datei kann damit als deklarative Basis für produktionsnahe Systeme dienen.
Viele Projekte missbrauchen Compose-Dateien als Ablage ungeordneter Optionen. Bessere Compose-Dateien folgen einem Gestaltungsprinzip:
So wird Compose zu einem tragfähigen Fundament — selbst im Podman-Kontext, der die Compose-Logik auf eine neue Ebene hebt.