Podman Quadlet vs. Docker Compose für Linux-Dienste

Docker Compose und Podman Quadlet lösen überlappende Probleme, stammen jedoch aus unterschiedlichen Designzentren. Die Wahl zwischen ihnen hängt davon ab, ob Sie in Anwendungsstacks oder in Linux-Dienste denken.

Diese Unterscheidung ist für alle relevant, die Container auf einem Linux-Host betreiben – über einen einzigen Nachmittag des Experiments hinaus. Compose beschreibt Dienste, Netzwerke und Volumes in einer YAML-Datei und startet sie mit docker compose up. Quadlet beschreibt Container in systemd-ähnlichen Unit-Dateien und lässt den Systemdienst-Manager den Lebenszyklus übernehmen.

Beide Ansätze funktionieren für selbst gehostete Dienste, interne Tools und kleine Server. Die richtige Wahl hängt von Ihrem Betriebsmodell, der Vertrautheit des Teams und davon ab, ob Sie ein entwicklerfreundliches Stack-Format oder ein systemd-natives Dienstmodell bevorzugen. Dieser Vergleich deckt die praktischen Unterschiede ab: Dateiformate, Lebenszyklusverwaltung, Rootless-Container, Protokollierung, Updates, Netzwerke, Sicherheit und Migrationspfade. Er ist Teil von Entwickler-Tools: Der vollständige Leitfaden für moderne Entwicklungsworkflows.

Kurzempfehlung

Verwenden Sie Docker Compose, wenn:

• Sie den schnellsten Workflow für Multi-Container-Anwendungen wünschen.
• Sie bereits Docker Engine verwenden.
• Sie Stacks mit Entwicklern teilen.
• Sie eine vertraute compose.yaml für die lokale Entwicklung benötigen.
• Sie kleine Dienste mit Docker auf einem einzelnen Host bereitstellen.
• Sie bestehende Compose-Beispiele aus Projekten nutzen.

Verwenden Sie Podman Quadlet, wenn:

• Sie systemd-native Container-Dienste wünschen.
• Sie Rootless-Container bevorzugen.
• Sie keinen zentralen Docker-Daemon haben möchten.
• Sie langlebige Dienste auf einem Linux-Host betreiben.
• Sie systemctl, journalctl, Timer, Abhängigkeiten und Autostart wünschen.
• Sie einen selbst gehosteten oder Homelab-Server auf Basis von systemd aufbauen.
• Sie möchten, dass Container in das normale Linux-Dienstmodell passen.

Die praktische Regel lautet:

Docker Compose ist besser für Anwendungsstacks.
Podman Quadlet ist besser für Linux-Dienste.

Das ist kein Gesetz. Es ist ein nützlicher Standard.

Vergleichstabelle

Keines von beiden ist Kubernetes. Die meisten kleinen Dienste benötigen keinen Cluster. Sie benötigen eine langweilige, verständliche Möglichkeit, zu starten, zu stoppen, zu aktualisieren, zu protokollieren und sich von Fehlern zu erholen.

Wofür Docker Compose gut ist

Docker Compose ist ein Werkzeug zum Definieren und Ausführen von Multi-Container-Anwendungen. Eine typische Compose-Datei beschreibt Dienste, Images, Build-Kontexte, Ports, Volumes, Netzwerke, Umgebungsvariablen, Health-Checks, Abhängigkeiten und Profile.

services:
  web:
    image: nginx:stable
    ports:
      - "8080:80"
    restart: unless-stopped
    volumes:
      - ./html:/usr/share/nginx/html:ro

  redis:
    image: redis:7
    restart: unless-stopped

Ausführen:

docker compose up -d

Status prüfen:

docker compose ps

Logs lesen:

docker compose logs -f

Stoppen:

docker compose down

Compose ist direkt und produktiv. Es ist besonders gut, wenn die Denkeinheit „diese Anwendung besteht aus mehreren Containern“ ist. Für eine umfassende Referenz zu Compose-Befehlen und -Mustern siehe das Docker Compose Cheat-Sheet. Für Docker-Befehle jenseits von Compose – Images, Volumes, Netzwerke und Aufräumen – siehe das Docker Cheat-Sheet.

Wofür Podman Quadlet gut ist

Podman Quadlet ist eine Möglichkeit, Podman-Container mithilfe von systemd-ähnlichen Dateien zu definieren. Anstatt einen vollständigen generierten systemd-Dienst von Hand zu schreiben, schreiben Sie eine deklarative Datei:

[Unit]
Description=Example web container
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/library/nginx:stable
PublishPort=8080:80
Volume=/opt/example/html:/usr/share/nginx/html:ro

[Service]
Restart=always

[Install]
WantedBy=multi-user.target

Speichern Sie sie als /etc/containers/systemd/example.container, laden Sie dann systemd neu:

sudo systemctl daemon-reload

Starten Sie es:

sudo systemctl enable --now example.service

Prüfen Sie es:

systemctl status example.service
journalctl -u example.service -f

Der Kernappell von Quadlet: Der Container wird zu einem normalen Linux-Dienst.

Der philosophische Unterschied

Docker Compose denkt in Stacks

Compose fragt: Welche Dienste machen diese Anwendung aus?

Ein Compose-Projekt lebt meist in der Nähe des Anwendungs-Codes:

myapp/
  compose.yaml
  .env
  app/
  db/

Sie starten das Projekt als Einheit:

docker compose up -d

Sie aktualisieren das Projekt als Einheit:

docker compose pull
docker compose up -d

Das ist einfach, sichtbar und portabel.

Podman Quadlet denkt in Diensten

Quadlet fragt: Welche Container soll dieser Linux-Host als Dienste ausführen?

Quadlet-Dateien leben in systemd-bezogenen Container-Pfaden:

/etc/containers/systemd/
~/.config/containers/systemd/

Sie verwalten generierte Dienste mit systemd:

systemctl status myapp.service
systemctl restart myapp.service
journalctl -u myapp.service -f

Das fühlt sich auf einem Linux-Server nativer an. Für allgemeine systemd-Dienstmuster siehe Beliebige Executable als Dienst in Linux ausführen.

Der wichtige Unterschied: Wer besitzt den Lebenszyklus?

Mit Docker Compose besitzt Compose den Anwendungslebenszyklus. Mit Quadlet besitzt systemd den Dienstlebenszyklus.

Dies beeinflusst Boot-Verhalten, Shutdown-Verhalten, Restart-Richtlinie, Abhängigkeitsreihenfolge, Logs, Health-Sichtbarkeit, User-Dienste, Updates, Integration mit Timern und Integration mit anderen Host-Diensten.

Wenn Sie systemd bereits verwenden, um alles andere auf dem Host zu verwalten, passt Quadlet gut hinein. Wenn Sie hauptsächlich in Anwendungsstacks denken, ist Compose meist komfortabler.

Docker Compose unter systemd im Vergleich zu Quadlet

Sie können Docker Compose als systemd-Dienst ausführen. Das ist oft ein gutes Muster. Beispiel systemd-Unit:

[Unit]
Description=MyApp Docker Compose stack
Requires=docker.service
After=docker.service network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/docker compose up -d --remove-orphans
ExecReload=/usr/bin/docker compose up -d --remove-orphans
ExecStop=/usr/bin/docker compose down
TimeoutStartSec=0
TimeoutStopSec=120

[Install]
WantedBy=multi-user.target

Das funktioniert gut. Aber es ist immer noch ein Wrapper um Compose. systemd startet den Compose-Befehl, während Docker und Compose die Container dahinter handhaben.

Mit Quadlet ist die Unit-Generierung direkt für Podman und systemd ausgelegt. Sie schreiben containerorientierte Unit-Dateien, und systemd verwaltet die generierten Dienste.

Die Unterscheidung ist subtil, aber wichtig:

Docker Compose unter systemd:
  systemd verwaltet einen Compose-Befehl.

Podman Quadlet:
  systemd verwaltet generierte Container-Dienste.

Für eine detaillierte Anleitung zu diesem Muster siehe Docker Compose als Linux-Dienst mit systemd ausführen.

Vergleich der Dateiformate

Docker Compose YAML

Compose verwendet YAML. Es ist kompakt, populär und einfach zu teilen. Es ist auch einrückungsempfindlich und kann unübersichtlich werden, wenn ein Stack groß wird.

services:
  app:
    image: ghcr.io/example/app:1.0.0
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      APP_ENV: production
    volumes:
      - app-data:/data

volumes:
  app-data:

Quadlet Unit-Dateien

Quadlet verwendet systemd-ähnliche Dateien. Sie sind wortreich, wenn Sie viele Dienste haben, aber lesbar, wenn Sie systemd bereits verstehen.

[Unit]
Description=Example app container
After=network-online.target
Wants=network-online.target

[Container]
Image=ghcr.io/example/app:1.0.0
PublishPort=8080:8080
Environment=APP_ENV=production
Volume=app-data.volume:/data

[Service]
Restart=always

[Install]
WantedBy=multi-user.target

Und eine Volume-Datei:

[Volume]
VolumeName=app-data

Gespeichert als app.container und app-data.volume im entsprechenden systemd-Container-Verzeichnis.

Abbildung von Docker Compose-Konzepten auf Quadlet

Die Migration ist konzeptionell einfach, aber nicht mechanisch. Compose beschreibt einen Stack. Quadlet beschreibt Dienste.

Rootless-Container

Rootless-Container sind einer der stärksten Gründe, Podman und Quadlet in Betracht zu ziehen.

Bei Docker fügen viele Benutzer sich der docker-Gruppe hinzu. Das ist bequem, aber der Zugriff auf den Docker-Daemon ist effektiv ein mächtiger Host-Zugriff. Auf einer persönlichen Workstation mag das akzeptabel sein. Auf Shared-Servern verdient es mehr Vorsicht.

Podman wurde mit Rootless-Nutzung als erstklassigem Workflow entworfen. Ein Rootless-Quadlet lebt unter dem Benutzerkonfigurationsverzeichnis:

~/.config/containers/systemd/whoami.container

Verwalten Sie es dann mit User-systemd:

systemctl --user daemon-reload
systemctl --user enable --now whoami.service
systemctl --user status whoami.service
journalctl --user -u whoami.service -f

Um den User-Dienst nach dem Abmelden weiterlaufen zu lassen:

sudo loginctl enable-linger "$USER"

Dies ist ein sauberes Modell für benutzereigene Dienste.

Rootless-Vergleich

Rootless ist keine Magie. Es hat Kompromisse bei Netzwerk, privilegiertem Verhalten und niedrigen Ports. Aber für langläufige, benutzereigene Dienste ist Quadlet ein sehr elegantes Modell.

Start- und Boot-Verhalten

Docker Compose

Compose erstellt per se keinen Boot-Dienst. Sie verlassen sich normalerweise auf Docker-Restart-Richtlinien, einen systemd-Wrapper um docker compose up -d, ein Deployment-Skript oder ein höherwertiges Werkzeug.

Beispiel Compose-Restart-Richtlinie:

services:
  app:
    image: example/app:stable
    restart: unless-stopped

Ein systemd-Wrapper gibt Ihnen einen Host-Level-Dienst. Das ist gut, aber es ist immer noch ein zusätzlicher Wrapper. Siehe Docker Compose als Linux-Dienst mit systemd ausführen für das vollständige Muster.

Podman Quadlet

Quadlet ist bereits systemd-orientiert. Aktivieren Sie beim Booten:

sudo systemctl enable myapp.service

Für Rootless:

systemctl --user enable myapp.service
sudo loginctl enable-linger "$USER"

Boot-Verhalten ist kein Add-on. Es ist das Modell.

Restart-Verhalten

Compose verwendet häufig restart: unless-stopped in YAML. Quadlet verwendet häufig systemd-Restart-Verhalten:

[Service]
Restart=always

Oder:

[Service]
Restart=on-failure

Dies verschiebt die Restart-Logik in den Dienstmanager. Die Präferenz: Verwenden Sie Compose/Docker-Restart-Richtlinien für Compose-Stacks, verwenden Sie systemd-Restart-Richtlinien für Quadlet und stapeln Sie nicht zu viele Supervisor. Behalten Sie einen klaren Besitzer des Restart-Verhaltens.

Vergleich der Protokollierung

Docker Compose Logs

docker compose logs -f
docker compose logs -f app

Das ist hervorragend für Entwickler.

Quadlet Logs

Quadlet-Dienste verwenden systemd-Logs:

journalctl -u app.service -f

Für Rootless-Units:

journalctl --user -u app.service -f

Sie können weiterhin Podman-Logs verwenden:

podman logs -f container-name

Für Serveroperationen ist die journalctl-Integration ein großer Vorteil. Ihre Container passen in denselben Log-Workflow wie andere Linux-Dienste.

Updates

Aktualisieren von Docker Compose

Ein häufiger Update-Flow:

cd /opt/myapp
docker compose pull
docker compose up -d --remove-orphans
docker image prune -f

Einfach in ein Skript zu wrappen:

#!/usr/bin/env bash
set -euo pipefail

cd /opt/myapp

docker compose config --quiet
docker compose pull
docker compose up -d --remove-orphans
docker image prune -f
docker compose ps

Aktualisieren von Podman Quadlet

Ein vereinfachter manueller Flow:

sudo podman pull ghcr.io/example/app:1.0.1
sudo systemctl restart app.service

Oder für Rootless:

podman pull ghcr.io/example/app:1.0.1
systemctl --user restart app.service

Podman kann Auto-Update-Workflows unterstützen, wenn Container mit den richtigen Labels und Image-Richtlinien konfiguriert sind. Quadlets Vorteil ist nicht, dass Updates immer einfacher sind. Der Vorteil ist, dass Updates dienstmanager-nativ sind.

Philosophie von Auto-Updates

Auto-Updates sind bequem. Sie sind auch ein Risiko. Für geringrisiko-Homelab-Dienste können automatische Container-Updates in Ordnung sein. Für Datenbanken, zustandsbehaftete Apps oder Geschäftsdienste ist der bevorzugte Flow:

1. Backup erstellen.
2. Pull ausführen.
3. Neuerstellen oder Neustart.
4. Health prüfen.
5. Später prune.

Compose macht dies explizit. Quadlet und Podman können es systemd-nativ machen. Kein Werkzeug entfernt die Notwendigkeit eines Rollback-Plans.

Volumes und persistente Daten

Compose Volumes

Compose unterstützt benannte Volumes:

services:
  db:
    image: postgres:16
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Und Bind-Mounts:

services:
  app:
    image: example/app
    volumes:
      - ./config:/config:ro
      - ./data:/data

Quadlet Volumes

Quadlet kann Bind-Mounts verwenden:

[Container]
Volume=/opt/app/config:/config:ro
Volume=/opt/app/data:/data

Oder eine .volume-Datei:

[Volume]
VolumeName=app-data

Dann referenzieren Sie sie:

[Container]
Volume=app-data.volume:/data

Compose ist kompakter für Storage auf Stack-Ebene. Quadlet ist stärker mit unabhängig verwalteten Dienst-Units ausgerichtet.

Secrets und Umgebungsdateien

Compose

Compose verwendet oft env_file oder environment in YAML. Für einen kleinen privaten Dienst ist .env üblich. Für ernste Systeme behandeln Sie .env als sensibel und halten Sie es aus Git fern.

Quadlet

Quadlet kann verwenden:

[Container]
Environment=APP_ENV=production
EnvironmentFile=/opt/app/app.env

Berechtigungen einschränken:

chmod 600 /opt/app/app.env

Weder Compose noch Quadlet sind an sich ein vollständiges Secret-Management-System. Verwechseln Sie „nicht in der Kommandozeile“ nicht mit „sicher“.

Netzwerke

Compose Networking

Compose erstellt ein Standardprojekt-Netzwerk und gibt Diensten DNS-Namen basierend auf Dienstnamen:

services:
  app:
    image: example/app
    depends_on:
      - db

  db:
    image: postgres:16

Die App kann die Datenbank normalerweise bei db erreichen. Multi-Container-App-Netzwerke fühlen sich natürlich an. Dies ist eine der stärksten Funktionen von Compose.

Quadlet Networking

Quadlet kann Netzwerke separat mit .network-Dateien definieren oder Podman-Netzwerkoptionen verwenden:

[Network]
NetworkName=appnet

Container-Datei:

[Container]
Image=example/app:stable
Network=appnet.network

Das ist expliziter und systemd-ähnlich. Für ein oder zwei Container ist es in Ordnung. Für einen großen App-Stack ist Compose oft einfacher zu lesen.

Pods

Podman hat ein natives Pod-Konzept. Das ist relevant, wenn Sie das Kubernetes-Denkmuster mögen, bei dem mehrere Container einen Network-Namespace und eine Lebenszyklusgrenze teilen. Quadlet unterstützt .pod-Dateien:

[Pod]
PodName=myapp
PublishPort=8080:8080

Ein Container kann diesem Pod beitreten:

[Container]
Image=ghcr.io/example/app:stable
Pod=myapp.pod

Compose hat nicht dasselbe Pod-Modell. Es hat Dienste auf Netzwerken. Für die meisten einfachen Web-Apps reichen Compose-Netzwerke aus. Für Podman-User, die pod-ähnliche Gruppierung mögen, ist Quadlet eine bessere Übereinstimmung.

Build-Workflows

Compose ist meist besser, wenn Sie Images als Teil des lokalen Anwendungs-Workflows bauen:

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:8080"

Dann:

docker compose up --build

Das ist extrem bequem für die Entwicklung. Quadlet ist meist besser, wenn Sie bereits gebaute Images als Dienste ausführen. Bauen Sie Images separat mit Podman:

podman build -t localhost/myapp:latest .

Dann referenzieren Sie das Image:

[Container]
Image=localhost/myapp:latest

Wenn Ihr Workflow „Code bearbeiten, neu bauen, Stack neu starten“ ist, gewinnt Compose. Wenn Ihr Workflow „ein bekanntes Image als Linux-Dienst bereitstellen“ ist, gewinnt Quadlet.

Portabilität

Compose-Dateien sind weit verbreitet. Viele Open-Source-Projekte bieten eine compose.yaml oder docker-compose.yml an. Wenn ein Projekt sagt „starte dies mit Docker Compose“, können Sie normalerweise schnell mit docker compose up -d starten. Das ist ein großer praktischer Vorteil.

Quadlet ist portabel über Systeme, die Podman, systemd und kompatible Quadlet-Unterstützung haben. Das ist ein engeres Ziel, aber ein sehr gutes für moderne Linux-Server. Quadlet ist nicht das beste Format, um eine Anwendung mit jedem möglichen Entwickler zu teilen. Es ist ein gutes Format, um zu beschreiben, wie ein spezifischer Linux-Host einen containerisierten Dienst ausführen soll.

Developer Experience

Docker Compose gewinnt meist bei der Developer Experience. Mehr Beispiele, mehr Tutorials, mehr Projektvorlagen, einfachere lokale Builds, einfacher One-File-Stack, vertrautes docker compose up und starke Passform für Dev-Abhängigkeiten. Ein Entwickler kann dies schnell lesen:

services:
  db:
    image: postgres:16
  redis:
    image: redis:7
  app:
    build: .

Quadlet kann ähnliche Dinge tun, aber es ist mehr operations-shape. Für die lokale Entwicklung würde ich selten mit Quadlet beginnen, es sei denn, die Anwendung selbst bezieht sich speziell auf Podman oder systemd.

Operations Experience

Quadlet gewinnt oft bei der Operations Experience auf einem Linux-Host. Gründe:

• Native systemctl
• Native journalctl
• Rootless User-Dienste
• systemd-Abhängigkeiten
• systemd-Timer
• systemd-Restart-Verhalten
• Kein zentraler Docker-Daemon
• Bessere Passform mit Host-Dienstverwaltung

Ein Server-Admin kann über Folgendes argumentieren:

systemctl status app.service
journalctl -u app.service -f
systemctl restart app.service

Das ist der normale Linux-Dienst-Workflow.

Sicherheitsmodell

Docker Compose Sicherheitsnotizen

Docker Compose kommuniziert normalerweise mit dem Docker-Daemon. Bei einer normalen Linux-Docker-Installation ist der Zugriff auf den Docker-Socket mächtig. Ein Benutzer, der Docker steuern kann, kann oft Host-Pfade mounten, privilegierte Container ausführen oder anderweitig breite Host-Kontrolle erlangen. Für Installationsoptionen einschließlich Rootless-Docker auf Ubuntu siehe Installieren Sie Docker auf Ubuntu.

Praktischer Rat:

• Exponieren Sie /var/run/docker.sock nicht sorglos.
• Behandeln Sie die docker-Gruppe als privilegiert.
• Vermeiden Sie privilegierte Container.
• Vermeiden Sie Host-Mounts, es sei denn, sie sind benötigt.
• Halten Sie Secrets aus Git fern.
• Verwenden Sie explizite Image-Tags für wichtige Dienste.
• Überprüfen Sie veröffentlichte Ports.

Quadlet Sicherheitsnotizen

Podman Quadlet paart sich gut mit Rootless-Containern und User-systemd-Diensten. Dies kann das Risiko reduzieren, insbesondere auf Shared-Hosts oder persönlichen Servern, wo Dienste keinen Root-Daemon benötigen sollten.

Praktischer Rat:

• Beziehen Sie Rootless-Dienste vor, wenn sie passen.
• Verwenden Sie User-Units für benutzereigene Dienste.
• Verwenden Sie System-Units nur, wenn Host-Level-Berechtigungen benötigt werden.
• Vermeiden Sie unnötige privilegierte Container.
• Halten Sie Umgebungsdateien abgesperrt.
• Denken Sie sorgfältig über Bind-Mounts nach.

Rootless bedeutet nicht risikofrei. Es bedeutet, dass der Standard-Blast-Radius kleiner sein kann.

Performance

Für die meisten Webdienste, internen Tools und selbst gehosteten Apps ist Performance nicht der entscheidende Faktor. Die Hauptunterschiede sind operativ, nicht rohe Geschwindigkeit. Wählen Sie basierend auf Lebenszyklusmodell, Sicherheitsmodell, Host-Integration, Team-Vertrautheit, Update-Prozess, Netzwerkbedürfnissen und Debugging-Workflow.

Wenn Sie zwischen Compose und Quadlet allein wegen Performance wählen, optimieren Sie wahrscheinlich die falsche Schicht.

Ausfallmodi

Docker Compose Ausfallmodi

Häufige Probleme:

• Docker-Daemon läuft nicht
• Compose-Plugin fehlt
• Falsches Projektverzeichnis
• .env nicht wie erwartet geladen
• Alte docker-compose-Binäre versehentlich verwendet
• Container nicht nach Konfigurationsänderungen neu erstellt
• Waisencontainer nach Dienstumbenennung zurückgelassen
• Volumes mit down -v gelöscht
• Docker-Logs füllen die Festplatte
• Docker-Socket-Berechtigungsfehler

Beste Fixes:

docker compose config
docker compose ps
docker compose logs -f
docker compose up -d --remove-orphans

Podman Quadlet Ausfallmodi

Häufige Probleme:

• Unit-Datei im falschen Verzeichnis
• Vergessen systemctl daemon-reload
• Verwendung von System-Units, wenn User-Units beabsichtigt waren
• Vergessen loginctl enable-linger für Rootless-Dienste
• Image-Pull dauert länger als systemd-Start-Timeout
• cgroup v2 nicht verfügbar
• SELinux-Labels oder Volume-Berechtigungen
• Dienstname unterscheidet sich von Dateierwartungen
• Netzwerk- oder Volume-Unit nicht korrekt aktiviert oder referenziert

Beste Fixes:

systemctl status app.service
journalctl -u app.service -f
systemctl daemon-reload
podman ps -a
podman logs container-name

Für Rootless:

systemctl --user status app.service
journalctl --user -u app.service -f

Migrationsbeispiel: Compose zu Quadlet

Starten Sie mit diesem Compose-Dienst:

services:
  whoami:
    image: traefik/whoami:v1.10
    restart: unless-stopped
    ports:
      - "8080:80"
    environment:
      WHOAMI_NAME: compose-demo

Ausführen mit Compose:

docker compose up -d

Ein grobes Quadlet-Äquivalent:

[Unit]
Description=Whoami demo container
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/traefik/whoami:v1.10
PublishPort=8080:80
Environment=WHOAMI_NAME=quadlet-demo

[Service]
Restart=always

[Install]
WantedBy=multi-user.target

Speichern als /etc/containers/systemd/whoami.container, dann:

sudo systemctl daemon-reload
sudo systemctl enable --now whoami.service
sudo systemctl status whoami.service

Das Beispiel ist einfach, weil es ein Container ist. Ein größerer Compose-Stack mit Datenbanken, Netzwerken, Volumes und Build-Schritten benötigt eine sorgfältigere Übersetzung.

Migrationscheckliste

Bevor Sie von Compose zu Quadlet wechseln, fragen Sie:

[ ] Ist dieser Stack wirklich eine Reihe von langläufigen Host-Diensten?
[ ] Sind die Images bereits gebaut und veröffentlicht?
[ ] Brauche ich Rootless-Dienste?
[ ] Möchte ich systemd-Abhängigkeiten und Timer?
[ ] Sind Volumes und Bind-Mounts klar verstanden?
[ ] Sind Ports dokumentiert?
[ ] Werden Secrets außerhalb von Git gehandhabt?
[ ] Gibt es einen Backup- und Restore-Prozess?
[ ] Kann ich Logs durch journalctl überwachen?
[ ] Habe ich einen Rollback-Pfad?

Wenn die meisten Antworten ja sind, kann Quadlet eine gute Passform sein. Wenn der Stack mostly für die lokale Entwicklung ist, ist Compose wahrscheinlich immer noch besser.

Wann bei Docker Compose bleiben

Bleiben Sie bei Compose, wenn:

• Das Projekt bereits eine gute Compose-Datei liefert.
• Sie den einfachsten Onboarding-Pfad benötigen.
• Entwickler denselben Stack lokal ausführen.
• Sie Images während der Entwicklung bauen.
• Sie eine YAML-Datei für Dienste, Volumes und Netzwerke wünschen.
• Sie maximale Tutorial- und Community-Kompatibilität wünschen.
• Ihr aktueller systemd-Wrapper gut funktioniert.

Es gibt keinen Preis für das Mигrieren eines funktionierenden Compose-Stacks zu Quadlet nur, weil Quadlet theoretisch sauberer ist. Wenn Compose für Ihren Use-Case langweilig und zuverlässig ist, behalten Sie es.

Wann zu Podman Quadlet wechseln

Wechseln Sie zu Quadlet, wenn:

• Der Stack wirklich ein Host-Dienst ist.
• Sie Rootless-Dienstverwaltung wünschen.
• Sie Podman gegenüber Docker bevorzugen.
• Sie möchten, dass systemd den Lebenszyklus besitzt.
• Sie journalctl-Logs wünschen.
• Sie Dienstabhängigkeiten wünschen.
• Sie User-Dienste wünschen, die nach dem Abmelden überleben.
• Sie weniger Docker-Daemon-Exposition wünschen.
• Sie einen Selbst-Hosting-Host um systemd herum aufbauen.

Quadlet ist nicht „Compose, aber besser“. Es ist ein anderes Designzentrum.

Empfohlene Muster

Muster 1: Lokale Entwicklung

Verwenden Sie Docker Compose. Schnell, vertraut, portabel, einfach neu zu bauen, einfach für Teams.

Muster 2: Single-Host Self-Hosting

Verwenden Sie entweder. Wählen Sie Compose, wenn das Projekt bereits eine Compose-Datei bereitstellt. Wählen Sie Quadlet, wenn Sie systemd-native Dienstverwaltung wünschen. Compose gibt ein besseres App-Bundle; Quadlet gibt einen besseren Linux-Dienst.

Muster 3: Benutzereigener Rootless-Dienst

Verwenden Sie Podman Quadlet. Rootless-Workflow, User-Level-Dienstverwaltung, kein zentraler Docker-Daemon.

~/.config/containers/systemd/app.container
systemctl --user enable --now app.service
loginctl enable-linger

Muster 4: Produktionsähnlicher Single-Server

Verwenden Sie Docker Compose mit einem disziplinierten systemd-Wrapper, oder verwenden Sie Quadlet, wenn Ihr Team mit Podman vertraut ist. Wählen Sie nicht basierend auf Mode. Wählen Sie basierend darauf, wer es um 2 Uhr morgens betreiben wird.

Muster 5: Multi-Node-Plattform

Verwenden Sie keines als finale Orchestrierungsschicht. Erwägen Sie Kubernetes, Nomad, Swarm oder eine verwaltete Plattform. Compose und Quadlet sind exzellente Single-Host-Tools. Sie sind keine Cluster-Scheduler.

Praktischer Entscheidungsbaum

Ist dies hauptsächlich für die lokale Entwicklung?
  ja:
    verwenden Sie Docker Compose
  nein:
    weiter

Bietet das Projekt bereits eine gepflegte compose.yaml?
  ja:
    verwenden Sie Docker Compose, es sei denn, Sie haben einen starken Grund zur Migration
  nein:
    weiter

Möchten Sie rootless langläufige Dienste, die von systemd verwaltet werden?
  ja:
    verwenden Sie Podman Quadlet
  nein:
    weiter

Möchten Sie die einfachste Multi-Container-App-Definition?
  ja:
    verwenden Sie Docker Compose
  nein:
    weiter

Möchten Sie, dass Container sich wie normale Linux-Dienste verhalten?
  ja:
    verwenden Sie Podman Quadlet
  nein:
    verwenden Sie Docker Compose

Befehle im direkten Vergleich

Häufige Missverständnisse

“Quadlet ersetzt Docker Compose”

Nicht genau. Quadlet ersetzt einige Compose-Use-Cases, insbesondere langläufige Linux-Dienste. Es ersetzt Compose nicht als einfachstes Anwendungs-Stack-Format für Entwickler.

“Docker Compose ist nicht produktionsreif”

Zu breit. Compose kann für kleine Produktionssysteme völlig vernünftig sein, wenn Sie Backups, Updates, Protokollierung, Restart-Verhalten und Host-Sicherheit verstehen. Das Problem ist nicht Compose. Das Problem ist, so zu tun, als hätte eine Single-Host-Compose-Bereitstellung dieselben Eigenschaften wie ein Cluster-Orchestrator.

“Podman ist nur Docker ohne Daemon”

Zu einfach. Podman hat Docker-kompatible Befehle, aber sein Designzentrum ist anders: Daemonlose Operation, Rootless-Workflows, Pods und Linux-Integration.

“Rootless bedeutet sicher”

Nein. Rootless reduziert einige Risiken. Es macht schlechte Images, exponierte Secrets, unsichere Bind-Mounts oder verletzliche Apps nicht sicher.

“systemd ist zu schwer für Container”

systemd ist bereits der Dienstmanager auf den meisten mainstream Linux-Servern. Es zu verwenden, um langläufige Container zu verwalten, ist nicht seltsam. Es ist oft die langweilige und richtige Sache zu tun.

Finale Empfehlung

Verwenden Sie Docker Compose, wenn der Anwendungsstack das Hauptaugenmerk ist. Verwenden Sie Podman Quadlet, wenn der Linux-Dienst das Hauptaugenmerk ist.

Diese Unterscheidung ist nützlicher, als zu diskutieren, welches Werkzeug besser ist. Für Entwickler-Workflows ist Compose schwer zu schlagen. Es ist populär, lesbar, portabel und wird von unzähligen Projekten unterstützt. Für langläufige Linux-Dienste ist Quadlet still exzellent. Es lässt Container sich wie native systemd-Dienste anfühlen, funktioniert natürlich mit Rootless-Podman und passt zum Betriebsmodell eines ernsthaften Linux-Hosts.

Die bevorzugte Aufteilung:

Lokale Entwicklung: Docker Compose
Portabile App-Beispiele: Docker Compose
Kleine selbst gehostete Stacks: Docker Compose oder Quadlet
Rootless User-Dienste: Podman Quadlet
Langläufige Host-Dienste: Podman Quadlet
Multi-Node-Orchestrierung: keines; verwenden Sie einen echten Orchestrator

Migrieren Sie nicht nur, um modern zu sein. Migrieren Sie, wenn das Lebenszyklusmodell besser ist. Compose ist ein großartiges Stack-Tool. Quadlet ist ein großartiges Dienst-Tool. Die intelligente Wahl ist, jedes dort zu verwenden, wo sein Denkmodell zur Aufgabe passt.

Referenzen

• Podman Quadlet Dokumentation — offizielle Podman Quadlet-Referenz
• Docker Compose Dokumentation — offizielle Docker Compose-Referenz
• Docker Compose als Linux-Dienst mit systemd ausführen — detaillierte Compose-as-systemd-Anleitung auf dieser Seite
• Docker Compose Cheat-Sheet — Referenz für Compose-Befehle und -Muster
• Docker Cheat-Sheet — Referenz für Docker-Befehle
• Installieren Sie Docker auf Ubuntu — Docker-Installationsleitfaden mit Rootless-Alternativen
• Beliebige Executable als Dienst in Linux ausführen — allgemeine systemd-Dienstmuster
• Entwickler-Tools: Der vollständige Leitfaden für moderne Entwicklungsworkflows — Cluster-Startseite