Podman vs. Docker – wo liegt die Zukunft der Container-Welt?

Da der offizielle Support für das beliebte Container-Management-Tool Docker in Red Hat Enterprise Linux 8 (RHLE 8) eingestellt wurde, müssen sich Administratorinnen und Administratoren auf eine neue Option einstellen. Podman, ebenfalls von Red Hat, gilt als direkter Nachfolger und kann durch den Verzicht auf einen zentralen Daemon und Root-Privilegien gewichtige Sicherheitsbedenken des Vorgängers entkräften. Ansonsten ähneln sich beide Tools, wobei Podman noch mit einigen Bugs zu kämpfen hat.

Docker, eine der beliebtesten und verbreitetsten Container-Lösungen, erhält keinen offiziellen Support mehr in Red Hat Enterprise Linux 8. Herausgeber Red Hat liefert die Lösung des Problems allerdings direkt mit: Podman. Die CRI-O-Umgebung wird von Red Hat als gleichwertige 1:1-Lösung beworben, sodass sich Docker-Fans eigentlich keine Sorgen machen müssten. Ob aber Podman Docker wirklich ohne Einschränkungen ersetzen kann, steht auf einem anderen Blatt. Um diese Frage beantworten zu können, lohnt es sich, zunächst beide Container-Technologien unter die Lupe zu nehmen.

Seit Docker 2013 als Open-Source-Software veröffentlicht wurde, erfreut sich die Technologie großer Beliebtheit. Als leichte und zugleich praktikable sowie verlässliche Lösung für die Anwendungsentwicklung ermöglicht Docker Nutzerinnen und Nutzern eine freiere Herangehensweise. Durch das Image als Abbild eines Containers lassen sich Pakete leicht als Daten transportieren und installieren. Ein einzelnes Docker-Image kann dabei eine unbegrenzte Anzahl von Containern kreieren, um z. B. OpenStack-Clouds zu realisieren. Docker ist dabei mit Ausnahme einiger weniger Schnittstellen zu Betriebssystem oder Hardware komplett isoliert. Die Container selbst enthalten lediglich jene Informationen, die wirklich benötigt werden, und sind dadurch vergleichsweise schlank.

An die Stelle Dockers soll nun Podman treten – zumindest nach dem Willen von Red Hat Linux. Podman ist als Pod-Manager für die Erstellung und Weiterverarbeitung von Containern gedacht und mit der OCI-Container-Spezifikation kompatibel. Im Gegensatz zu Docker kommt Podman ohne Root-Rechte aus und soll daher im Vergleich sicherer sein. Podman baut auf Docker auf und war ursprünglich als Debugging-Tool geplant, bevor es zur Alternative bzw. zum Nachfolger der älteren Management-Tools wurde. Um die Umstellung zu erleichtern, ist es möglich, Befehle aus Docker in Podman zu verwenden. Das allein macht Podman allerdings noch nicht zu einem ebenbürtigen Nachfolger.

Genau das ist aber die entscheidende Frage. Da in RHEL 8 der Support für Docker eingestellt wurde, müssen viele Nutzerinnen und Nutzer sich neu orientieren und eine vergleichbar gute Alternative finden. Während Red Hat Linux in Podman diese Option sieht, sind viele Entwicklerinnen und Entwickler unschlüssig oder sogar ablehnend. Um den Zweikampf Docker vs. Podman angemessen bewerten zu können, lohnt sich ein Blick auf die Stärken und Schwächen des Herausforderers.

Der größte Vorteil, den Podman auch gegenüber Docker bietet, ist der Verzicht auf einen zentralen Daemon und die Root-Rechte. Dadurch ist nicht nur ein schnellerer Start möglich – unter dem Sicherheitsaspekt ist diese Änderung ebenfalls begrüßenswert. Das Host-System ist geschützt und Prozesse mit Root-Rechten können nicht länger auf den Kernel zugreifen. Auch die Kompatibilität mit Docker ist für Podman ein großer Vorteil. Die Migration lässt sich vergleichsweise einfach durchführen, und auch die einzelnen Arbeitsschritte sind für Administratorinnen und Administratoren, die das alte Management gewohnt sind, weitestgehend intuitiv.

Darüber hinaus ist es mit Podman möglich, beliebte Container-Registrierungen wie Docker Hub oder Quay.io zu verwenden. Auch YAML-Dateien für Kubernetes können erstellt werden. Podman benötigt insgesamt weniger Speicherplatz, gilt als extrem schnell und vergleichsweise effizient. Mittlerweile ist Podman daher die Default-Lösung für viele Linux-Distributionen wie Fedora CoreOS.

So sehr Red Hat auch von Podman überzeugt ist, fehlerfrei ist die Container-Engine nicht. Insbesondere einige Kinderkrankheiten und Bugs sorgen dafür, dass viele Administratorinnen und Administratoren noch nicht vollends von Podman überzeugt sind und andere Alternativen zu Docker suchen oder Hybridlösungen wie Kata Containers bevorzugen.

Fehler beim Umgang mit Containern sind häufiger zu beobachten. Ohne einen Daemon im Netzwerk sind die Erstellung und das Management der Container über einen Remote Host schwierig. Auch wenn Podman hier erste Lösungsvorschläge anbietet, sind diese Probleme nicht behoben. Das gilt auch für die versprochene Kompatibilität von Podman und Docker. Noch werden nicht alle Requests vom neueren Tool verstanden.

Für ein Urteil, ob nun der jahrelang beliebte Quasi-Standard oder der Herausforderer im Duell Podman vs. Docker triumphiert, ist der direkte Vergleich beider Engines entscheidend. Worin unterscheiden sich also die beiden Management-Systeme?

Anders als Docker verzichtet Podman auf einen zentralen Daemon für die Entwicklung, Verwaltung und Ausführung von OCI-Containern. Stattdessen basiert Podman auf dem Konzept der Kubernetes Pods. Hierbei schließen sich mehrere Container innerhalb eines gemeinsamen Linux-Namensraums zusammen. Dies schafft flexible Konfigurations- und Kombinationsmöglichkeiten. Docker bietet diese Möglichkeit nicht ohne zusätzlich Konfiguration über docker-compose an.

In diesem Zusammenhang ist auch einer der größten Kritikpunkte an Docker zu sehen. Dessen Daemon benötigt nämlich obligatorisch die Root-Berechtigung und erschafft dadurch ein potenzielles Sicherheitsrisiko. So haben Container über Docker grundsätzlich die Möglichkeit, auszubrechen und auch auf dem Host zu wirken. Dies kann unter Umständen zu großen Schäden auf dem Kernel führen, wenn z. B. ein falsch konfigurierter Container Zugriff auf den Host erhält. Podman löst dieses Problem, indem Container ohne Root-Privilegien gestartet werden können. Was unter Sicherheitsaspekten begrüßenswert ist, bedingt allerdings auch zwangsläufig, dass Administratorinnen und Administratoren keine Befehle ausführen können, die Root-Rechte auf dem Host voraussetzen.

Im Duell Kubernetes vs. Docker gibt es viele Unterschiede zwischen den beiden Schwergewichten, bei der Containerorchestrierung arbeiteten die Tools allerdings gut zusammen. Das wird sich mit Kubernetes 1.24 wohl ändern, da Kubernetes den Support für Docker einstellt. Mit Podman soll die Zusammenarbeit allerdings weiter problemlos möglich sein. Der Name des neueren Systems deutet bereits an, dass Podman (im Gegensatz zu Docker) zusätzlich auch Pods unterstützt, die von Kubernetes etabliert wurden.

Anders als Docker folgt Podman einer Aktion nach dem Fork-Exec-Modell und zeichnet Änderungen im auditd-System auf. Das sieht bei Docker anders aus, da hier keine Aufzeichnung erfolgt.

Dieser Unterschied wird mit der Zeit sicherlich kleiner und kleiner werden. Aktuell ist es allerdings durchaus noch so, dass die Dokumentation für Docker der für Podman weit überlegen ist. Bereits seit 2013 hat sich der „Oldie“ mehr oder weniger zum Standard entwickelt und verfügt dementsprechend über eine riesige Community, die Administratoren bei jedem Problem mit Rat und Tat zur Seite steht. Hier kann der fünf Jahre jüngere Nachfolger noch nicht mithalten. In Zukunft werden sich die beiden Tools in dieser Hinsicht wohl angleichen.

Zwar ist das Design von Docker und Podman sehr unterschiedlich, in der täglichen Arbeit fällt das allerdings nur wenig ins Gewicht. Wer Docker kennt, wird sich sehr wahrscheinlich auch mit Podman zurechtfinden, gerade auch, da viele Befehle bekannt sind und einfach übernommen werden können.

Genau das macht die Migration von Docker zu Podman auch vergleichsweise einfach. Nicht nur sind die Befehle wie „pull“, „push“, „build“, „run“, „commit“ u. a. größtenteils identisch, auch die Images von Docker sind kompatibel mit Podman. Dies war ein erklärtes Ziel der Entwickler. Bevor Sie den Wechsel vollziehen, sollten Sie unbedingt sicherstellen, dass Docker gestoppt wurde. Dann installieren Sie Podman oder greifen auf die vorinstallierte Software in einigen Linux-Versionen zurück. Sie müssen danach „Dockerfile“ und docker-compose.yml in „Containerfile“ und container-compose.yml umbenennen. Wichtig außerdem: Podman speichert seine Container und Images an einem anderen Platz als der prominente Vorgänger.

Podman vs. Docker ist ein ungleicher Kampf, da das ältere Tool zwar einen gewissen Vorsprung hat, von Red Hat allerdings nicht mehr unterstützt wird. Dafür gibt es durchaus gute Gründe, die vor allem im Bereich der Sicherheit zu finden sind. Hier hatte Docker lange Zeit großen Nachholbedarf, und die Mängel wurden bei Podman behoben. Der Verzicht auf einen zentralen Daemon und der daraus resultierende bessere Schutz könnten so früher oder später auch skeptische Administratoren überzeugen. Fehlerfrei ist dabei allerdings auch Podman nicht, kleinere Probleme müssen nach wie vor gelöst werden. Gelingt dies, gewinnt der Herausforderer Podman gegen Docker knapp.

Viele überzeugte Docker-Enthusiasten und -Enthusiastinnen werden früher oder später eventuell noch wechseln oder sich neu orientieren und z. B. auf eine Kubernetes-Alternative zurückgreifen, mit der Docker noch genutzt werden kann. Durch die große Ähnlichkeit der beiden Container-Lösungen und das Bestreben von Red Hat Linux, Podman als Nachfolger zu etablieren, wird allerdings auch ein Wechsel sehr wahrscheinlich funktionieren.