In diesem Artikel vergleichen wir Podman und Docker, um zu sehen, wie sie sich im Vergleich zueinander schlagen. Wir beginnen mit einem Überblick darüber, was die beiden Tools sind und warum du dich für das eine oder das andere entscheiden solltest. Dann gehen wir ins Detail, was jedes Tool einzigartig macht, bevor wir zu unserem Fazit kommen, welches Tool am besten für deine Bedürfnisse geeignet ist: Podman oder Docker!

Was ist Docker im Jahr 2023?

Docker ist ein langjähriger Akteur in der Container-Welt und existiert seit 2013. Wenn du die Branche schon eine Weile verfolgst, hast du sicherlich schon von Docker gehört oder es sogar selbst verwendet!

In den letzten Jahren hat sich das Unternehmen darauf konzentriert, die Entwicklererfahrung zu verbessern und sicherzustellen, dass Container in allen Phasen des Anwendungslebenszyklus effektiv von Entwicklern genutzt werden können. Es bietet auch eine umfangreiche Funktionssammlung für den Betrieb von Containern in der Produktion. Das Unternehmen hinter der Technologie, Docker Inc., hat auch einen fantastischen geschäftlichen Schwenk vollzogen und ist nun mit seinem abonnementbasierten Modell sehr profitabel. Sich auf Docker als kommerziell unterstütztes Produkt zu verlassen, könnte eine solide Entscheidung für die Zukunft sein.

Da Docker schon lange auf dem Markt ist, unterstützt es auch viele Funktionen, wie den Rootless-Modus (dazu später mehr). Dadurch ist es nicht mehr erforderlich, den Docker-Daemon mit Root-Rechten auf den Servern auszuführen. Das macht es für alle einfacher, da du Container verwenden kannst, ohne dich um privilegierten Zugriff oder die Sicherheitsprobleme kümmern zu müssen, die du als Root-Benutzer sonst hättest.

Docker bietet eine sehr umfassende Dokumentation zu nahezu jedem Thema, das bei der Arbeit mit Containern aufkommt.

Was ist das Besondere an Podman?

Podman ist eine relativ neue Container-Laufzeitumgebung, hat aber bereits Einzug in viele Standard-Software-Repositories für Linux erhalten. Du musst keine externen Quellen hinzufügen, um es auf deinem Host zu installieren. Es ist manchmal bereits bei einer frischen Installation verfügbar.

Podman läuft ohne Daemon und bietet eine Entwicklungserfahrung, die der von Docker sehr nahe kommt, d.h., die meisten Befehle in der Podman-CLI sind identisch mit denen der Docker-CLI. Podman Desktop, eine grafische Benutzeroberfläche für Podman, sieht ebenfalls fast genauso wie Docker Desktop aus.

Die Dokumentation von Podman ist ehrlich gesagt nicht so gut und lässt bestimmte Themen vollständig aus.

Die folgende Abbildung zeigt einen Graphen von Google Trends, der das wachsende Interesse an Podman in den letzten Jahren deutlich zeigt.

Podman ist ein von Red Hat gesponsertes Community-Projekt.

Was unterscheidet Podman von Docker?

Podman und Docker haben viele ähnliche Eigenschaften. Beide sind Tools zur Verwaltung von Containern unter Linux, die auf den gleichen Kernel-Funktionen (wie Namespaces und cgroups) aufbauen, die es ihnen ermöglichen, Prozesse voneinander isoliert auszuführen ('Sandboxing'). Die Benutzeroberfläche ist nahezu identisch, was einen einfachen und praktischen Wechsel zwischen den beiden ermöglicht. Du kannst sogar die meisten Container-Images, die du bereits hast, weiterhin verwenden (sofern sie mit dem OCI-Container-Image-Format kompatibel sind).

Lass uns einen genaueren Blick auf die Unterschiede zwischen Podman und Docker werfen.

Daemon – oder kein Daemon

Docker führt einen Daemon-Prozess ('docked') auf dem Host-System aus, der in der Regel mit Root-Rechten ausgestattet ist. Was macht der Daemon-Prozess in den Tiefen des Systems? Nun, im Grunde alles, was zur Verwaltung von Containern auf dem Host benötigt wird: Überwachung laufender Container-Instanzen, Verwaltung der Container-Images, Bereitstellung von Speichervolumes und vieles mehr. Er erstellt Container-Netzwerke auf Anfrage und kümmert sich um alle niedrigstufigen Container-Dinge, insbesondere containerd und runc. Der Daemon-Prozess erstellt eine API-Schnittstelle mit einem HTTP-Protokoll, um seine Funktionalität für alle Arten von Benutzeroberflächen zugänglich zu machen, einschließlich der Docker-Befehlszeile. Je nach Plattform wird die Docker-Schnittstelle über einen Unix-Socket, eine benannte Pipe oder einen TCP-Port (mit vielen Optionen, um sie sicher zu machen) realisiert. Der Docker-Daemon läuft mit sehr geringem Ressourcenverbrauch.

Kein Daemon mit Podman

Podman verzichtet dagegen auf den Daemon-Prozess ('daemonlose Container-Engine'). Das Container-Management erfolgt direkt vom Client aus. Daher erlaubt das Aufrufen von Podman mit einem anderen Benutzer als root nur die Operationen, die dieser Benutzer ausführen darf. Dies beschränkt natürlich die Möglichkeiten des Benutzers – aber auch die von Eindringlingen, die einen Container von innen übernehmen könnten.

Aus Sicherheitssicht ist das 'rootless'-Phänomen also eine ziemlich gute Idee. Und doch könnte es irgendwann schnell zu Ende gehen. Darauf werden wir im nächsten Abschnitt genauer eingehen.

Podman für die Produktion - etwas komplizierter

Ein entscheidenderer Nachteil des Verzichts auf einen Daemon-Prozess wird deutlich, wenn versucht wird, Podman für Produktions-Workloads zu verwenden. Mit Docker kannst du beispielsweise einfach eine 'Restart-Policy' für Container angeben und sicherstellen, dass sie im Falle eines Absturzes neu gestartet werden. Podman führt keinen Prozessmonitor aus und muss diese Aufgabe daher an eine andere Stelle delegieren: Hier kommt unser guter alter Freund systemd ins Spiel. Obwohl systemd sehr verbreitet ist und wahrscheinlich von den meisten Systemadministratoren gut verstanden wird, handelt es sich dennoch um eine sehr komplexe zusätzliche Lösung, die mit eigenen Kosten verbunden ist. Podman unterstützt den Benutzer, indem es die systemd-Einheiten generiert (die Konfiguration, um systemd mitzuteilen, wie ein Prozess überwacht und verwaltet werden soll), aber dies ist ein völlig anderes Ökosystem. Wenn du von Docker kommst, kann dies eine gewisse Einarbeitungszeit erfordern, um alles mit dem gewünschten Verhalten zum Laufen zu bringen. Ein weiterer Pluspunkt für systemd ist jedoch, dass eine Einheit genauso gut mit verringerten Benutzerrechten ausgeführt werden kann.

Ob Docker oder Podman - wenn die Produktionsbereitstellungen ernst genommen werden sollen, muss letztendlich irgendwo ein Daemon-Prozess involviert sein. Und natürlich gibt es einen Dienstprozess (Daemon), wenn du die Podman REST API verwenden möchtest..

Rootful und rootless

Eine sehr nützliche (und manchmal unterschätzte) Funktion von Docker sind Overlay-Netzwerke. Diese ähneln 'echten' (virtuellen) Netzwerken auf einer Host-Maschine. Docker-Netzwerke ermöglichen alle Arten von komplexen Verbindungstopologien mit Routen, NATs und IP-Pools usw. Das ist besonders nützlich in Situationen, in denen eine bestimmte Produktionsumgebung erreicht und verschiedene Dienste, die eine Anwendung ausmachen, lose gekoppelt werden sollen. Tatsächlich läuft jeder Container in seinem eigenen Namespace im Linux-Kernel, sodass es möglich ist, Ressourcenbeschränkungen für jeden Container, Netzwerkeinstellungen usw. festzulegen. Einer der grundlegenden Gedanken bei der Aufteilung des Linux-Kernels in mehrere Räume war die Prozesssicherheit. Im Moment ist dies größtenteils nur mit Root-Rechten möglich. Dennoch ist Sandboxing mit Namespaces auch mit nicht privilegierten Benutzern möglich.

Wie es in der Realität aussieht

Wichtige Funktionen verschwinden, wenn Docker im Rootless-Modus ausgeführt wird, und das gilt auch für Podman. Ich habe herausgefunden, dass es eine Option gibt, Podman rootful auszuführen, um diese Fähigkeiten, insbesondere ein ordentliches Netzwerk, zu erhalten.

In der Praxis hat das Podman-Entwicklungsteam eine meiner bescheidenen Meinung nach fragwürdige Lösung für das fehlende Networking geschaffen, indem es das Konzept des 'Pods' als Alternative eingeführt hat.

Mit Podman kannst du mehrere Container in einem Pod kompilieren. 'Pod' ist der Name für eine höherstufige Organisation von Kernel-Namespaces. Alle Container, die denselben Pod teilen, befinden sich tatsächlich im selben Kernel-Namespace(s). Am wichtigsten ist, dass sie denselben Netzwerk-Namespace teilen. Dadurch können die Container-Prozesse über TCP-Sockets miteinander kommunizieren. Du kannst beispielsweise einen Prozess auf Port localhost:8000 und einen anderen Prozess auf localhost:8001 ausführen. Beide Prozesse können über den TCP-Socket auf localhost miteinander kommunizieren. Dies wäre nicht möglich für zwei separate 'podman run ...' (oder mit 'docker run ...'), da sie standardmäßig voneinander getrennt sind. Die Verwendung des Pod-Konzepts beseitigt letztendlich die Notwendigkeit für Networking vollständig und somit auch die Notwendigkeit für eine rootful-Betrieb.

Der Podman "Infra Container"

Übrigens: Jedes Podman-Pod erhält einen speziellen Container namens "Infra-Container". Er tut nichts weiter, als einzuschlafen, sobald das Pod erstellt ist. Alle Attribute, die das Pod definieren, werden tatsächlich diesem speziellen Container zugewiesen, einschließlich Port-Bindungen, Kernel-Namespaces, Ressourcenbeschränkungen usw. Sobald das Pod erstellt ist, können diese Attribute nie wieder geändert werden. Angenommen, du erstellst ein neues Pod und fügst später einen Container hinzu, der einen neuen Port mit dem Host bindet - Podman wird dazu nicht in der Lage sein. Du musst das gesamte Pod mit der neuen Port-Bindung (oder anderen Attributen) neu erstellen.

Privilegien vs. Fähigkeiten

Jeden Prozess mit herabgesetzten Rechten auszuführen, bringt erhebliche Einschränkungen mit sich. Das macht Sinn, besonders um zu verhindern, dass ausgenutzte Containerprozesse Systemänderungen vornehmen oder auf andere Prozesse zugreifen können. Das Herabsetzen der Ausführungsrechte ist generell vorzuziehen, und ich nehme dieses Thema sehr ernst. Allerdings führt der Tausch des Sandbox-Mechanismus zugunsten fehlender Netzwerkfähigkeiten eine weitere Klasse von Systemanfälligkeiten ein.

Podman-Pods und Kubernetes

Das Podman-Team behauptet, dass die Arbeit mit Podman-Pods den Übergang zu Kubernetes viel einfacher macht. Tatsächlich kannst du mit Podman ein Pod erstellen (alle Container, die du benötigst, hinzufügen; bestimmte Attribute festlegen) und automatisch eine gültige Kubernetes YAML-Datei daraus generieren. Und ja, die technische Grundlage ist die gleiche. Aber trotzdem, wer hat nach diesem Feature gefragt?

Der monolithische Pod

Ich habe dieses Tutorial gefunden, das vorschlägt, einen Webserver, einen Anwendungsserver und die Datenbank in einen Podman-Pod zu packen. Das wäre praktisch, wenn ich dies mit Podman auf einem Serverhost betreiben wollte. Aber hier ist der Punkt. Wer mit Erfahrung in Kubernetes würde jemals eine solche Pod-Definition in einer Kubernetes-Umgebung anwenden? Ich erhalte einen monolithischen Pod, der alles enthält, was eine Anwendung ausmacht. Was ist mit Skalierbarkeit, Ausfallsicherheit und natürlich Sicherheit? Eine ernsthafte Kubernetes-Bereitstellung verwendet abstrakte Arbeitslastdefinitionen, die in "Deployments", "StatefulSets" und anderen höheren Kubernetes-Objekten deklariert sind. Ich habe dieses Muster noch nie in der realen Welt gesehen (was nicht bedeutet, dass es nicht existiert). Die Verwendung von nackten Pods scheint für Kubernetes überhaupt kein praktischer Ansatz zu sein. Wenn es jedoch verwendet wird, um echte Kubernetes-Strukturbereitstellungsmuster wie Sidecars oder Adapter zu konstruieren, wäre ich sehr glücklich.

Ungerechtfertigte Versprechungen

Daher finde ich dieses Feature irreführend, insbesondere in Bezug auf die Kommunikation und Dokumentation von Podman. Nein, ich kann keinen Podman-Pod auf einem lokalen Rechner definieren und ihn so einfach in die Produktionsumgebung von Kubernetes migrieren. In Kubernetes verwenden wir starke Netzwerkmechanismen wie Lastenausgleicher, IP-Routing, Netzwerkrichtlinien und damit lose Kopplung.

Fazit

Ich hoffe, dieser Artikel hat dir ein besseres Verständnis für die Unterschiede zwischen Podman und Docker gegeben. Wie du sehen kannst, gibt es viele Ähnlichkeiten zwischen den beiden Tools, aber sie haben auch einige wesentliche Unterschiede, die je nach Anwendungsfall die eine Option geeigneter machen könnten als die andere. Obwohl Podman sich noch in einem frühen Entwicklungsstadium befindet, hat es bereits Anzeichen dafür gezeigt, eine würdige Alternative zu Docker zu sein, indem es eine einfachere Benutzererfahrung bietet und gleichzeitig die Kompatibilität mit vorhandenen Images aus anderen Registern wie Docker Hub oder Google Container Registry (GCR) beibehält. Ich bin gespannt, wie sich diese Tools im Laufe der Zeit weiterentwickeln, während sie beide neue Funktionen hinzufügen. Schau dir auch Podman Desktop an. Ich bin mir nicht sicher, ob Podman auch den Weg der Entwicklererfahrung („DX“) wie Docker geht oder ob sie versuchen, Produktionsserver zu betreiben. Lass mich wissen, was du denkst.

Fühle dich frei, folge mir auf LinkedIn oder trete unserem Discord bei.