Programmierung · DevOps · Container

Docker vs Podman: welche Container-Engine, und wann?

Kurze Antwort: Docker und Podman erledigen dieselbe Kernaufgabe — Container bauen und ausführen — und nutzen dasselbe Image-Format, sodass ein mit dem einen gebautes Image auf dem anderen läuft. Der Hauptunterschied ist die Architektur: Docker führt Container über einen langlebigen zentralen Daemon (dockerd) aus, der typischerweise als root läuft, während Podman daemonlos und rootless by design ist und jeden Container als gewöhnlichen Kindprozess startet. Ihre Befehlszeilen sind nahe genug, dass alias docker=podman den Großteil des Alltags abdeckt. Wähle Podman, wenn du keinen root-Daemon und eine enge systemd-Integration willst; bleib bei Docker, wenn du auf Docker Desktop, einen ausgereiften Compose-Workflow oder ein größeres Ökosystem angewiesen bist.

Wenn du mit einem der beiden neu bist, hilft es, zuerst zu verstehen, was Docker und Container sind. Dieser Leitfaden setzt das voraus und konzentriert sich darauf, wie sich die beiden Engines unterscheiden.

Architektur: mit Daemon vs daemonlos

Docker nutzt ein Client-Server-Modell. Der docker-Befehl, den du eingibst, ist ein Client, der mit einem Hintergrunddienst spricht, dem Docker-Daemon (dockerd), der deine Container tatsächlich erstellt und ausführt. Dieser Daemon läuft dauerhaft und in der Standardkonfiguration als root. Das ist bequem — ein Dienst verwaltet alles — aber es ist auch ein einzelner privilegierter Prozess, dem alle Container auf dem Host gehören.

Podman geht einen anderen Weg. Es gibt keinen zentralen Daemon: Wenn du einen Container startest, forkt und exect Podman ihn direkt als Kindprozess deiner Shell, mit denselben Linux-Primitiven (Namespaces, cgroups). Jeder Container ist nur ein normaler Prozessbaum. Dieses daemonlose Modell bedeutet, dass es keinen ständig laufenden root-Dienst zum Kompromittieren gibt und ein Absturz in einem Container nicht durch einen gemeinsamen Daemon läuft.

Rootless-Container und Sicherheit

Dieser Architekturunterschied führt zum Sicherheitsunterschied, der den meisten am wichtigsten ist. Podman wurde dafür gebaut, rootless zu laufen — ein unprivilegierter Benutzer kann Container ohne root bauen und ausführen, indem User-Namespaces die Container-UIDs auf den Host abbilden. Docker kann ebenfalls rootless laufen und unterstützt das seit Jahren, aber seine Standardinstallation dreht sich weiter um den root-Daemon, sodass Rootless ein optionaler Modus statt die Grundlage ist.

Kein root-Daemon zu haben verkleinert die Angriffsfläche: Es gibt keinen privilegierten Hintergrunddienst, den ein Container-Ausbruch ins Visier nehmen könnte, um den Host zu übernehmen. Für Mehrbenutzer-Server und CI-Runner ist diese „kein root-Daemon“-Eigenschaft ein echter, konkreter Grund, zu Podman zu wechseln. Es ist keine Magie — Container brauchen weiterhin sorgfältige Konfiguration — aber die Standardhaltung ist konservativer.

Gleiche Images, nahezu identische CLI

Das ist der Teil, der den Wechsel schmerzlos macht: Beide Werkzeuge folgen den OCI-Standards (Open Container Initiative) für Images und Laufzeit. Ein mit Docker gebautes Image läuft unter Podman und umgekehrt, und beide ziehen aus denselben Registries (Docker Hub, GitHub Container Registry, Quay und weitere). Es gibt kein nur-Docker- oder nur-Podman-Image-Format.

Die Befehlszeilen sind bewusst ähnlich. podman run, podman build, podman ps und podman pull spiegeln ihre Docker-Pendants mit denselben gängigen Flags. Viele setzen einfach einen Alias:

alias docker=podman

und behalten ihre Gewohnheiten. Dockerfiles funktionieren unter Podman ebenfalls unverändert. Die CLI ist nicht in jedem Sonderfall zu 100 % identisch, aber für das tägliche Bauen und Ausführen ist sie nahe genug, dass das Muskelgedächtnis übertragbar ist.

Pods: Podmans Kubernetes-artige Gruppierung

Podman ist nach dem Pod benannt — einem Konzept, das es von Kubernetes übernimmt. Ein Pod ist eine Gruppe von Containern, die Ressourcen wie einen Netzwerk-Namespace teilen, sodass sie über localhost miteinander reden können, als wären sie auf derselben Maschine. Podman kann diese Pods direkt erstellen und verwalten, was die lokale Entwicklung näher daran bringt, wie Dinge in einem Kubernetes-Cluster laufen. Docker hat kein natives „Pod“-Primitiv im selben Sinne; Multi-Container-Aufbauten werden stattdessen mit Compose-Netzwerken zusammengestellt.

systemd-Integration

Da Podman-Container gewöhnliche Kindprozesse statt Kinder eines Daemons sind, fügen sie sich natürlich in systemd ein, den Dienstmanager von Linux. Historisch konntest du podman generate systemd ausführen, um eine Unit-Datei pro Container zu erzeugen; der aktuelle, empfohlene Ansatz ist Quadlet, mit dem du Container in deklarativen Dateien im Unit-Stil beschreibst, die systemd direkt verwaltet — sie beim Booten starten, bei Fehlern neu starten und wie jeden anderen Dienst verfolgen. Für Server, die ohnehin alles über systemd betreiben, ist das eine saubere Möglichkeit, Container ohne zusätzlichen Daemon unter denselben Supervisor zu stellen.

Compose: docker compose vs podman

Viele Projekte verlassen sich auf Compose, um mehrere Container aus einer YAML-Datei hochzufahren. Docker liefert docker compose (das Compose-v2-Plugin) als erstklassiges, gut gepflegtes Werkzeug. Podman unterstützt Compose-Workflows ebenfalls: Es kann mit dem separaten Werkzeug podman-compose arbeiten, und Podman stellt zudem einen Socket bereit, mit dem das Standard-Compose-Tooling reden kann, sodass bestehende compose.yaml-Dateien oft mit wenig oder keiner Änderung laufen. In der Praxis ist Dockers Compose-Erfahrung die ausgereiftere und ausgefeiltere der beiden, was ein Grund ist, warum Teams mit intensiver Compose-Nutzung manchmal bei Docker bleiben.

Docker-Desktop-Lizenz vs Podmans Open-Source-Modell

Unter Windows und macOS wird Docker meist über Docker Desktop genutzt. Docker Desktop ist kostenlos für private Nutzung, Bildung und kleine Unternehmen, erfordert aber für größere Organisationen (über der von Docker veröffentlichten Größenschwelle) ein kostenpflichtiges Abonnement. Diese Lizenzänderung ist für größere Firmen eine echte Budget- und Compliance-Frage.

Podman ist vollständig Open Source und kostenlos, ohne Lizenz pro Arbeitsplatz. Sein Desktop-Begleiter, Podman Desktop, ist ebenfalls Open Source. Für Organisationen, die eine kommerzielle Desktop-Lizenz vermeiden wollen — oder einfach einen durchgehenden Open-Source-Stack bevorzugen — zählt dieser Unterschied genauso wie jeder technische.

Welches solltest du also nutzen?

Kriterium	Docker	Podman
Architektur	Zentraler Daemon (dockerd)	Daemonlos (fork/exec pro Container)
Rootless	Unterstützt, optional	Rootless by design (Standard)
Image-Format	OCI	OCI — austauschbar mit Docker
CLI	Referenz-CLI	Nahezu identisch (alias docker=podman)
Pods	Kein natives Pod-Primitiv	Native Pods (Kubernetes-Stil)
systemd	Läuft unter dem Daemon	Native Units via Quadlet
Compose	docker compose (ausgereift)	podman-compose / Compose via Socket
Desktop-Lizenz	Docker Desktop kostenpflichtig für große Orgs	Open Source, kostenlos (Podman Desktop)

Es gibt keinen universellen Sieger. Wähle Podman, wenn du keinen root-Daemon, rootless Container als Standard, eine native systemd/Quadlet-Verwaltung oder die Vermeidung der Docker-Desktop-Lizenz willst. Bleib bei Docker, wenn du auf Docker Desktop, einen ausgereiften Compose-Workflow oder die Breite seines Ökosystems und seiner Dokumentation angewiesen bist. Da beide OCI sprechen, kannst du sie auch mischen — mit dem einen bauen, mit dem anderen ausführen — oder Podman ausprobieren, ohne deine bestehenden Images und Dockerfiles wegzuwerfen. Und wenn du später viele Container über mehrere Maschinen orchestrieren musst, ist das eine Aufgabe für Kubernetes, das über beiden steht.