Podman vs. Docker: Auf dem Papier besser, in der Praxis abgehängt

Auf dem Papier erfüllt Podman jede Anforderung für die Zukunft der Containerisierung: rootless Container, kein Hintergrund-Daemon, der Ressourcen frisst, und engere Integration mit systemd für alle, denen Kontrolle auf Systemebene wichtig ist. Es ist sicher, es ist Open Source, und es wurde mit modernen Prinzipien im Hinterkopf entworfen. Warum also beherrscht Docker, das ältere, schwerfälligere und wohl chaotischere Geschwisterchen, immer noch die Container-Welt?

Wer sich je getraut hat, Podman in einem Entwicklerforum zu erwähnen, kennt die Antwort in einer Variante von: „Ja, Podman ist cool, aber Docker funktioniert einfach." Genau darin steckt das ganze Problem.

Der First-Mover-Vorteil ist nicht nur Marketing

Docker kam 2013 mit Vollgas auf den Markt und war mehr als ein neues Tool. Es prägte, wie Menschen über Container dachten. Die Branche übernahm es rasend schnell, ganze Plattformen wurden darum herum gebaut, und Tutorials, Dokumentation, CI/CD-Workflows und Orchestrierungstools entstanden mit Docker im Kopf. Noch heute sagen Leute beiläufig „Docker-Container", so wie sie zu Taschentüchern „Kleenex" sagen.

Als Podman 2019 erschien, hatte sich Docker längst in die Fundamente unzähliger Systeme eingegraben. Dieser sechsjährige Vorsprung war nicht bloß Zeit, er war Verwurzelung, und die lässt sich nicht durch gute Absichten und bessere Standardeinstellungen ersetzen.

Die Kompatibilitätsillusion

Eines von Podmans ursprünglichen Verkaufsargumenten war die Docker-Kompatibilität. Theoretisch könnten Sie docker einfach als Alias auf podman legen und weitermachen. In der Praxis klappt das nur halb.

Rückmeldungen aus dem Alltag zeichnen ein anderes Bild. Podman kann viele Dockerfiles und Compose-Konfigurationen ausführen, doch Nutzer stoßen immer wieder auf Randfälle, die den Wechsel alles andere als nahtlos machen. Ein frustrierter Nutzer sagte: „Ich hab's versucht, Podman erwies sich als deutlich problematischer und weniger stabil. Vielleicht in ein paar Jahren." Ein anderer ergänzte: „Es gibt leichte Abweichungen, nicht viel, aber genug, um es lästig zu machen."

Welche Abweichungen? Zum Beispiel:

• Podman Compose ist ein komplett eigenständiges Projekt neben Docker Compose und nicht immer aktuell oder voll kompatibel
• Probleme rund um Container-Startreihenfolge, Netzwerkverhalten, Restart-Richtlinien
• Integrationsprobleme mit GPUs oder alternativen Storage-Pfaden

Sobald man auch nur leicht vom ausgetretenen Pfad abweicht, landet man wieder im Gebiet von „debug alles selbst".

Dokumentation: Docker ist der Standard

Eine der größten unsichtbaren Kräfte, die Docker an der Spitze halten, ist die Dokumentation. Wenn fast jede GitHub-README, jeder Entwickler-Blog und jede Open-Source-App sagt, man solle „diese Docker-Compose-Datei ausführen", folgt man dem Weg des geringsten Widerstands. Dockers Reife bedeutet eine Fülle an Ressourcen, von Blogposts über Stack-Overflow-Antworten bis zu YouTube-Tutorials, die genau Ihr Problem schon gelöst haben.

Podman fühlt sich dagegen immer noch wie der Neue in der Schule an. Selbst wenn es einwandfrei funktioniert, heißt der Mangel an eingebauter Dokumentation mehr Googeln, mehr Rätselraten und mehr Trial-and-Error. Ein Nutzer sagte es unverblümt: „Die meisten Anleitungen sind für Docker geschrieben. Wenn man das nutzt, was alle anderen auch nutzen, ist es leichter, Hilfe zu bekommen."

Compose vs. Quadlets: die Kluft im Workflow

Wenn Docker Compose das gemütliche kleine Haus ist, in dem Sie seit Jahren leben, dann sind Podmans Quadlets die umweltfreundliche, modulare Fertighütte im Wald: interessant, innovativ, aber man weiß noch nicht recht, wie man darin lebt.

Mit Compose definieren Sie Dienste, Volumes, Netzwerke und Abhängigkeiten in einer einzigen YAML-Datei. Das ist aufgeräumt, lesbar und dokumentiert sich selbst. Selbst bei Solo-Projekten bleiben Entwickler oft bei Compose, nur um sich lange Docker-Befehle nicht merken zu müssen.

Podman setzt dagegen stark auf systemd-Integration. Quadlets sind systemd-Unit-Dateien, die Container und Pods so definieren, dass sie zu erstklassigen Bürgern Ihres Systems werden. Für den Betrieb ist das großartig, für Entwickler, die einfach schnell etwas hochziehen und mit dem Coden anfangen wollen, ist es schwer zu verkaufen. Ein Nutzer witzelte: „Quadlet-Dateien zu schreiben ist ein Albtraum. Man braucht eine Datei pro Container, Volume, Netzwerk und Pod … alle im selben Verzeichnis. Compose funktioniert einfach."

Podman ist für Ops gebaut, Docker für Devs

Hier steckt vermutlich der Kern des Ganzen. Docker ist dev-first und übernimmt die Kontrolle. Es richtet Networking, Logging und Container-Lifecycle ein, betreibt einen Daemon auf Root-Ebene und sagt: „Keine Sorge, ich kümmere mich darum." Für Entwickler, die sich nicht mit Firewalls oder Systemrichtlinien herumschlagen wollen, ist das ein Gewinn.

Podman ist ops-first und respektiert die Host-Umgebung. Es überschreibt keine Systemeinstellungen, integriert sich hervorragend mit SELinux und systemd und ist darauf ausgelegt, sich einzufügen statt zu dominieren. Für Gelegenheitsnutzer ist genau das das Problem. Entwickler suchen selten nach Integration mit Enterprise-Sicherheitsprotokollen, sie wollen reibungslose Container-Starts, einfache Befehle und minimale Konfiguration.

Wer nicht auf Fedora, Arch oder RHEL arbeitet, wo Podman vorinstalliert und voll unterstützt ist, kämpft auch mit Installation und Aktualisierung. Auf Debian-basierten Systemen ist Podman in den Hauptrepos oft veraltet, und für neuere Versionen muss man durch einige Reifen springen. Bei Docker fügt man ein Repo hinzu, und es geht los.

Stabilität vor Ideologie

Ideologisch erfüllt Podman viele Wünsche. Es ist daemonless, es ist rootless, und es vermeidet die Sicherheitsfallen, die Docker aus seinen frühen Wildwest-Tagen geerbt hat. Wenn Ihnen Systemsicherheit und Ressourcenisolation wirklich wichtig sind, ist Podman überzeugend.

Die meisten Nutzer haben es in ihrem Homelab aber nicht mit nationaler Sicherheit oder regulatorischer Compliance zu tun. Sie betreiben Nextcloud, Plex oder Home Assistant. Sie wollen keine SELinux-Richtlinien perfektionieren, sie wollen einen Film streamen, ohne dass er auf halber Strecke abstürzt. Ein Nutzer fasste es so zusammen: „Docker ist bombenfest, und ich hab keinen Grund gefunden zu wechseln."

Fazit

In mancher Hinsicht ist Podman objektiv besser, mit sichereren Standardeinstellungen, Systemintegration und einer modernen Architektur. Die reale Welt läuft aber nicht allein auf Specs, sie läuft auf Support, Stabilität und Einfachheit.

Aktuell gewinnt Docker also weiterhin standardmäßig, weil die Leute es kennen, weil es funktioniert und weil „gut genug" für die meisten mehr als genug ist.

Wenn Podman Docker wirklich entthronen will, reichen theoretische Vorteile nicht. Es braucht:

• Reibungslosere Kompatibilität
• Bessere Dokumentation
• Breitere Community-Unterstützung
• Mehr Zeit

Im Moment reicht es nicht, auf dem Papier „besser" zu sein, jedenfalls nicht, solange Docker seit über einem Jahrzehnt das lange Spiel spielt und dabei gewinnt.