Warum ich von Docker zu Podman gewechselt bin

 (codesmash.dev)
14 Punkte von GN⁺ 2025-09-06 | 8 Kommentare | Auf WhatsApp teilen
  • Bei Docker werden aufgrund der Architektur mit einem Hintergrund-Daemon (dockerd) seit Langem immer wieder Sicherheitslücken und unnötiger Ressourcenverbrauch kritisiert
  • Podman setzt auf eine daemonlose Architektur, sodass Container direkt mit Benutzerrechten ausgeführt werden, was die Angriffsfläche verkleinert und die Stabilität erhöht
  • Durch die Unterstützung von Systemd-Integration, Kubernetes-freundlichem Design und getrennten Tools nach Unix-Philosophie wie Buildah/Skopeo steigt die betriebliche Effizienz
  • Dank der hohen Kompatibilität zur Docker-CLI funktionieren die meisten bestehenden Workflows schon mit alias docker=podman unverändert weiter
  • Auch in realen Betriebsumgebungen werden Sicherheit und Ressourcenmanagement einfacher, und bei neuen Projekten wird Podman zu einer vernünftigeren und zukunftsorientierten Wahl

Grenzen von Docker und Sicherheitsprobleme

  • Docker basiert auf einer Struktur, bei der der dockerd-Daemon ständig mit Root-Rechten läuft
    • Wird eine Schwachstelle im Daemon gefunden, kann der gesamte Host gefährdet sein
  • Beispiele wichtiger Sicherheitsvorfälle
    • 2019: runC-Container-Escape (CVE-2019-5736)
    • 2022: Linux-Dirty-Pipe-Schwachstelle, cgroups-v1-Escape
    • 2024: runC „Leaky Vessels“, BuildKit-Schwachstelle
    • 2024: Cryptojacking-Kampagne über exponierte Docker-APIs
  • Die Wiederholung solcher Vorfälle macht das grundsätzliche Risiko einer daemonbasierten Architektur deutlich

Podmans daemonlose Architektur

  • Podman verwendet keinen Hintergrund-Daemon
    • Beim Ausführen von podman run läuft der Container als direkter Kindprozess des aufrufenden Befehls
    • Im rootless-Modus ausgeführt bedeutet Root im Container auf dem Host nur normale Benutzerrechte
  • Vorteile
    • Höhere Sicherheit: Im Fall eines Container-Escapes ist der Schaden begrenzter
    • Mehr Stabilität: Wenn ein Container abstürzt, bleiben andere unbeeinflusst
    • Effizientere Ressourcennutzung: Kein unnötiger ständig laufender Daemon, dadurch geringerer Speicherverbrauch

Besondere Funktionen von Podman

  • Systemd-Integration
    • Mit podman generate systemd lassen sich systemd-Unit-Dateien automatisch erzeugen
    • Dienste können mit den Standardbefehlen von systemctl verwaltet werden
  • Kubernetes-Freundlichkeit
    • Das Pod-Konzept ist standardmäßig integriert und erleichtert die Entwicklung von Multi-Container-Apps
    • Mit podman generate kube lassen sich direkt Kubernetes-YAML-Dateien erzeugen
  • Unix-Philosophie
    • Podman konzentriert sich auf die Ausführung von Containern, für Image-Builds dient Buildah, für Registry-Verwaltung Skopeo
    • So lassen sich für jeden Zweck optimal angepasste Tools nutzen

Umstieg und Kompatibilität

  • Der Wechsel von Docker zu Podman erfolgt nahezu ohne Unterbrechung
    • Die CLI ist kompatibel, sodass sich statt docker einfach podman verwenden lässt
    • Vorhandene Dockerfiles funktionieren unverändert weiter
  • Unterschiede
    • Im rootless-Modus ist das Binden an Ports unter 1024 nicht möglich → ein Reverse Proxy wird empfohlen
    • Volumeberechtigungen müssen verwaltet werden
    • Tools, die vom Docker-Socket abhängen, können den Docker-API-kompatiblen Modus von Podman verwenden

Einsatz in der Praxis und Vorteile

  • Nach dem Einsatz von Podman in Betriebsumgebungen
    • sinkt der Aufwand für Sicherheitsprüfungen, rootless-Sicherheit ist standardmäßig vorhanden
    • werden Ressourcennutzungsmuster einfacher und besser vorhersehbar
  • Docker ist weiterhin populär, aber für neue Projekte oder wenn es Freiheit bei der Technologiewahl gibt, ist Podman oft besser geeignet
    • Natürliche Integration in Linux-Verwaltungsmechanismen
    • Auf Kubernetes ausgerichtete Architektur
    • Eine sicherere und vernünftigere Umgebung für die Container-Ausführung

Zusammenfassung des FastAPI-Migrationsleitfadens

  • Vorhandene Dockerfiles können unverändert weiterverwendet werden
  • Einfacher Ersatz durch podman build und podman run
  • Mit podman generate systemd als systemd-Dienst registrierbar
  • Unterstützung für Multi-Service-Umgebungen wie Datenbanken durch die Nutzung von Pods
  • Docker-Compose-Workflows können mit podman-compose oder durch Konvertierung mit kompose abgedeckt werden

Verwandte Beiträge

8 Kommentare

 
shortstories 2025-09-09

Hier steht zwar, dass eine Umstellung ohne Downtime möglich ist, aber in der tatsächlichen Produktionsumgebung gab es ziemlich viele merkwürdige Dinge. Auf dem Mac wird zum Beispiel in der Standardeinstellung zstd-Komprimierung verwendet, sodass die gebauten Images die Registry ziemlich stark belasten oder übermäßig beanspruchen.
 
codemasterkimc 2025-09-08

Docker, Podman, alles dasselbe....

securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL

securityContext:
runAsNonRoot: true
runAsUser: UID
 
koxel 2025-09-08

In der Praxis ist die Docker-Kompatibilität nicht besonders gut, daher ist die Nutzbarkeit nicht so toll...
Ich bin wegen Rootless zu Podman gewechselt und dann wieder zu Docker zurückgekehrt.
Wie andere schon gesagt haben: Wenn man es mit Kubernetes nutzen will, kann man auch einfach containerd verwenden.
 
click 2025-09-08

Wenn Docker Compose nicht gut funktioniert und der Vorteil in der guten Kubernetes-Kompatibilität liegt, frage ich mich, ob man dann nicht einfach direkt Kubernetes verwenden sollte.
Ich wollte es auch ausprobieren, aber da es nicht auf Anhieb lief und Port-Mappings unter 1024 auch nicht direkt möglich waren, nutze ich stattdessen einfach eine Kombination aus k3s und nerdctl zum Bauen von Images.
 
ndrgrd 2025-09-07

Ich möchte zwar schon länger irgendwann wechseln, aber als ich es früher ausprobiert habe, liefen im Gegensatz zu dem, was Entwickler oft sagen, zu viele docker compose-Projekte einfach nicht richtig ...
 
afewgoodman 2025-09-07

Docker unterstützt doch keine Netzwerke.
 
devsepnine 2025-09-07

Soweit ich weiß, werden ähnlich wie bei Docker auch Netzwerkfunktionen unterstützt.
Gibt es denn noch Dinge, die noch nicht richtig funktionieren?
 
GN⁺ 2025-09-06
Hacker-News-Kommentar
  • 2001/2002 musste ich eine WiFi-Hotspot-Box aufbauen. Damals war ich OpenBSD-Fan und wollte eine in Python geschriebene Distribution so schlank wie möglich halten. Ich wollte unnötiges Kopieren von Dateien und Abhängigkeitsprobleme vermeiden und habe mich deshalb für chroot und das Jail-Konzept entschieden. Mein Deployment-Code führte Software außerhalb der Jail-Umgebung aus und überwachte mit ptrace, welche Dateien der Prozess öffnete. Aus dieser Ausgabe habe ich eine Abhängigkeitsliste extrahiert und sie paketiert. Das Ergebnis war klein, unveränderlich und sicherer. Als Docker auftauchte, fühlte ich mich an diese frühere Methode erinnert, und ich frage mich, ob es ein ähnliches Tool gibt, das die Dateinutzung von Docker-Containern überwacht, um Deployments zu verkleinern
    • Die beste CI/CD-Pipeline, die ich je benutzt habe, war ein Django-Freelancer-Deployment. Ein Git-Post-Receive-Hook automatisierte bei jedem git push den Build statischer Dateien und den Neustart von httpd. Man musste nur git push live master ausführen, und schon war deployed. Ich habe viel Docker genutzt, aber das war das einfachste Deployment überhaupt. Ich verstehe die Vorteile von Docker, aber HTTP unter Ubuntu oder OpenBSD einzurichten ist auch nicht besonders schwer. Ich frage mich, ob die Docker-eigene Reproduzierbarkeit den zusätzlichen Verwaltungsaufwand wirklich wert ist
    • Das erste Google-Suchergebnis ist slimtoolkit/slim mit 22k Stars
    • In OpenWrt gibt es ein Tool namens ujail. Wenn man ihm eine ELF-Binärdatei gibt, analysiert es die benötigten Bibliotheksabhängigkeiten und mountet in tmpfs nur die notwendigen Dateien schreibgeschützt
      Link zum relevanten Code
  • Podman ist für mich wirklich eine hervorragende Erfahrung. Docker fand ich schwierig und voller Fallstricke, aber Podman steht ihm in nichts nach. Vor allem muss man sich in meiner Firma keine Sorgen um Lizenzen machen. Eine absolute Win-win-Situation
    • Mich würde interessieren, ob Lizenzen in der Firma wirklich ein Thema waren. Die kostenpflichtige Lizenzpolitik von Docker Desktop ist vernünftig. Unter 250 Mitarbeitenden oder unter 10 Millionen US-Dollar Umsatz ist es kostenlos. Selbst wenn die Lizenz 90 US-Dollar pro Jahr kostet, ist das bei US-Entwicklergehältern weniger als ein Mittagessen. Außerdem kann man das offiziell unterstützte Tool auf allen Betriebssystemen nutzen
    • Eigentlich muss sich die Firma um Lizenzen nicht groß kümmern. Docker Engine ist vollständig Open Source und kostenlos. Nur Docker Desktop braucht in Unternehmen eine separate Lizenz. Die meisten Funktionen lassen sich aber auch mit Docker Engine nutzen
    • Podman ist viel besser als Docker. Man muss sich keine Gedanken über Benutzer-/Gruppenrechte oder Sicherheitsprobleme durch Root-Prozesse machen. Außerdem muss man keine Daten an einen Daemon schicken
    • Auf einigen PCs entfernt der Windows-Uninstaller von Podman nicht alle Komponenten sauber, sodass beim erneuten Ausführen Fehler auftreten. Selbst wenn man die Services manuell löscht, bleiben Probleme bestehen. Das ist ziemlich oft ein ärgerlicher Störfaktor
  • Ich mag Podman sehr, aber es funktioniert nicht immer mit allen Containern. Große Container wie GitLab hängen zum Beispiel oft von der komplexen Geschichte und den Eigenheiten von Docker ab, weshalb es unter Podman häufig Fehler gibt. Selbst gebaute Images laufen meiner Erfahrung nach meistens gut unter Podman. Problematische Container umgehe ich, indem ich eine Incus-VM starte und sie darin ausführe. Sowohl Podman als auch Docker sind bei der GPU-Anbindung inkonsistent, was unbequem ist. Trotzdem halte ich Podman für die bessere Wahl. Vor allem rootless ist ein großer Vorteil
    • Ich vermute, die meisten Probleme kommen von Images, die PID 1 als Root starten. Podman ist standardmäßig rootless, daher treten solche Probleme auf. Wenn man auch root-basierte Images ohne Docker nutzen will, kann man Podman getrennt in rootful- und rootless-Modi betreiben und mit dem Flag --connection die gewünschte Umgebung angeben. Bei Bedarf kann Podman auch automatisch eine VM erzeugen und nutzen dafür lima. Podman Desktop hat außerdem eine Docker-Kompatibilitätsschicht, die Kompatibilitätsprobleme abmildert
    • Dass manche Container unter Podman nicht funktionieren, dürfte überhaupt erst die Motivation für den Blogpost gewesen sein. Wenn die Nutzerbasis groß genug wird, etabliert sich vermutlich die Praxis, vor dem Veröffentlichen auch Podman-Umgebungen zu testen
    • Wir betreiben sowohl GitLab-Server als auch Runner komplett unter Podman. Persönlich würde ich die Runner lieber auf k8s umstellen, aber aktuell funktioniert es mit Traefik gut
    • Ich nutze viele buildx-bezogene Funktionen. Oberflächlich sieht es so aus, als ginge das auch mit Podman, aber in der Praxis klappt es nicht gut
  • Das größte Problem ist für mich die Podman-Unterstützung unter Ubuntu. Die standardmäßig mitgelieferte Podman-Version ist viel zu alt, um direkt nutzbar zu sein. Ich verwende Podman v5, GitHub Actions nutzt v3 und meine Kollegen verwenden Docker. Dadurch entsteht die Komplexität, dass meine Skripte mit altem Podman, aktuellem Podman und Docker gleichermaßen funktionieren müssen
    • Es gibt kein vertrauenswürdiges Repository für .deb-Builds. Es gibt keine offiziellen .deb-Pakete, und was ich gefunden habe, ist entweder veraltet oder wird künftig nicht mehr gepflegt. Dann bleibt die Frage, warum Podman die Installation nicht einfacher macht. Ich denke, RedHat will keine Entwicklungsressourcen darauf verwenden, die Produkte der Konkurrenz zu unterstützen. Verständlich, aber außerhalb des RedHat-Ökosystems fühlt man sich wie ein Nutzer zweiter Klasse
    • Ich halte das für das größte Problem. Die geringere Bekanntheit gegenüber Docker ist auch ein Thema, aber Versionsinkompatibilitäten sind viel eher der Hauptgrund dafür, dass Podman eine Nische bleibt. Distributionen wie Ubuntu liefern oft ältere Software aus, und das muss eigentlich vom Maintainer gelöst werden, aber von Podman selbst kommt da wenig aktiver Einsatz. Deshalb habe ich sogar meinen Homeserver auf eine RedHat-nahe Distribution umgestellt, nur um aktuelles Podman zu bekommen
    • Dass es keine dauerhaft gepflegten offiziellen Upstream-.deb-Pakete gibt, verhindert bei uns den internen Einsatz von Podman. Da wirkt Docker beneidenswert, weil das offizielle .deb-Repository gut gepflegt ist
    • Das ist einer der Gründe, warum ich Ubuntu/Debian nicht nutze: Updates kommen viel zu langsam. Man könnte es zwar über Flatpak nutzen, aber bei solcher Software wäre es schön, wenn sie einfach standardmäßig verfügbar wäre
    • Podman ist Open Source, daher können Distributionen wie Ubuntu es selbst paketieren und aktualisieren. Ich kann auch verstehen, dass RedHat nicht besonders motiviert ist, das Packaging konkurrierender Softwareumgebungen direkt zu unterstützen
  • Ich habe vor Kurzem wegen der Arbeit ein Podman-Setup durchlaufen, und es war eine der schlimmsten Erfahrungen überhaupt. Rootless Podman + SELinux + normaler Benutzer im Container ist wirklich die Hölle
    • Klar, wenn man sich unbedingt quälen will, kann man mit allem Probleme haben, aber in der Praxis funktioniert das meiste gut. Ich betreibe auf RHEL10-Maschinen mit aktiviertem SELinux mehrere Services als rootless Container hinter einem nginx-Reverse-Proxy, etwa Forgejo, Runner und uptime-kuma, und das läuft problemlos
    • Ich habe noch nie einen Vorteil von rootless gespürt. Wenn eine Maschine nur eine einzige Sicherheitsdomäne hat, kann man genauso gut als Root laufen lassen, und wenn nicht, sollte man ohnehin echte Isolation wie Firecracker- oder Kata-VMs nutzen. Rootless bedeutet viel Mühe bei fraglichem Nutzen
    • Ich hatte in der Firma dieselbe Situation, aber wenn man die Podman-spezifische Vorgehensweise nutzt und die Doku liest, ist es brauchbar. Entscheidend ist, die Dokumentation für aktuelle Versionen zu lesen
    • Ich nutze auf Fedora seit über 7 Jahren ausschließlich Podman
    • Unsere Organisation ist komplett von Docker auf Podman migriert. Es gab unterwegs etwas Reibung, aber das SysDev-Team konnte alles solide lösen
  • Es heißt oft, wenn ein Docker-Compose-Workflow zu komplex wird, solle man ihn direkt in Kubernetes-YAML umwandeln. Meiner Erfahrung nach ist K8s-YAML aber viel komplexer als docker compose. Und nicht jeder nutzt Kubernetes
    • Ich sehe das anders. K8s-YAML ist in seiner Komplexität ähnlich wie docker compose oder manchmal sogar einfacher. Es ist nur extrem ausführlich. Eine Compose-Datei mit 100 Zeilen kann sich in 20 YAML-Dateien mit je 50 Zeilen aufteilen. Es wäre schön, wenn kubectl eine Art Sugar-Funktion zum gegenseitigen Umwandeln von einfachen und komplexen YAMLs hätte
    • Wenn man docker compose in k8s yaml umwandelt, funktioniert ein LLM als Zwischenschicht erstaunlich gut. Übrigens kann auch Podman k8s yaml erzeugen, wodurch ein natürlicher Migrationspfad entsteht
    • Ich kann keine Compose-Dateien schreiben, aber k8s yaml kann ich schreiben. Deshalb wirkt compose auf mich sogar "komplexer"
  • Der im Artikel erwähnte Befehl podman generate systemd ist inzwischen deprecated. Als Alternative gibt es Podman Quadlets, die ähnlich wie eine docker-compose.yaml in einer systemd-Unit-Datei definiert werden
    • Es ist logisch, Compose/Orchestrierung an systemd zu übergeben. Es gibt keine Client-Server-Architektur wie bei Docker, sondern echte User-Prozesse, daher ist das eine naheliegende Entscheidung
    • Das Problem ist, dass es dazu fast keine Dokumentation gibt
  • Es ist schwierig, Container mit mehreren UIDs auf einen einzelnen Host-Benutzer abzubilden. Standardmäßig wird Root im Container auf den ausführenden Benutzer des Hosts gemappt, aber in letzter Zeit verwenden viele Apps im Container Nicht-Root-Benutzer wie www-data oder Benutzer 1000. Diese werden auf dem Host auf sekundäre IDs gemappt, wodurch bei Volume-Mounts Dateibesitzer verwaisen und große Verwirrung entsteht. Es fehlt eine einfache Option, alle UIDs auf einen einzelnen Benutzer zu mappen, und bestehende Optionen wie crun-uidmap oder userns funktionieren nicht gut. Ich zweifle am praktischen Nutzen dieser sekundären ID-Zuordnungen
    • Wenn ich es richtig verstehe, ist das eine Einschränkung von Linux-Namespaces. Damit Tools wie Docker oder Podman solche Zuordnungen unterstützen können, braucht es Linux-Unterstützung. 1:1-UID-Mapping ist deshalb nötig, weil sonst Benutzer 1000 und 0 im Container auf denselben Host-Benutzer gemappt würden und die Dateibesitzerinformationen durcheinandergeraten
    • Man könnte auch idmapped Mounts in Betracht ziehen. Sie lösen allerdings nur das Remapping im Dateisystem und nicht bei Kernel-Aufrufen
    • Es wäre schön, wenn man im Container einfach als "man selbst" laufen könnte, sodass das auch in Logs bei den Besitzern so auftaucht
    • Mit der Option ignore_chown_errors kann man Root auf die Benutzer-ID mappen und das ohne zusätzliche Mapping-Konfiguration relativ einfach umsetzen
  • Ich habe mehrmals versucht, auf Podman zu migrieren, bin aber an verschiedenen Stellen gescheitert. Erstens war die Performance von Podman auf meinem kleinen VPS deutlich schlechter als die von Docker, Details lasse ich aus. Zweitens ist das Entwicklungsökosystem noch nicht vollständig nachgezogen. Viele Tools hängen vom Docker-Socket ab, und unter Podman funktionieren sie wegen Berechtigungsproblemen oder API-Inkompatibilitäten nicht gut. Podman ist kein perfekter Drop-in-Ersatz
    • Langsames Netzwerk bei rootless Podman kann an slirp4netns liegen. pasta ist ein schnellerer Ansatz. Docker richtet standardmäßig über einen privilegierten Daemon das Netzwerk ein, also sollte es keinen Performance-Unterschied geben, wenn man Podman als Root nutzt
    • SELinux-Berechtigungsfehler mit Podman und Quadlet sind weiterhin ein ständiges Ärgernis. Oft ist es einfacher, gleich einen Pod mit Host-weiten Rechten zu bauen, nur die nötigen /dev-Geräte zu mounten und sehr eingeschränkte Programme in ein isoliertes Netzwerk zu stellen
    • Interessanterweise war Podman auf meinen ressourcenschwachen Systemen bei Performance und Ressourcenverbrauch Docker deutlich überlegen. Das scheint am Unterschied zwischen crun und runc zu liegen. Außerdem ist Podman leichtergewichtig, weil kein Daemon läuft
  • Ich habe sowohl Docker als auch Podman aufgegeben und bin zu FreeBSD Jails gewechselt
    • Mehr Informationen und Verwaltungs-Tools gibt es hier,
      hier,
      hier,
      und hier
    • Kann man in einer FreeBSD-Jail sofort MS SQL Server oder Tausende Docker-Container ausführen? Die Entscheidung für FreeBSD hat einen hohen Preis, etwa eingeschränkte Kompatibilität. Das ist auch der Grund, warum Jails nie wirklich Mainstream geworden sind
    • Das Setup scheint ziemlich aufwendig zu sein, und ich frage mich, ob es für FreeBSD etwas wie containerd gibt
    • FreeBSD Jails sind eine distributionsspezifische Besonderheit
    • Ich frage mich, was der Unterschied zwischen einer VM auf einem Linux-Host und einer FreeBSD-Jail ist