Warum es sich lohnt, einen Blick auf Podman zu werfen

In der Welt der Container gibt es zahlreiche Tools. Im Hinblick auf Container Engines ist Docker eindeutig das beliebteste Tool. Allerdings zieht nun auch Podman als Alternative immer mehr Aufmerksamkeit auf sich und könnte sich als gute Lösung für Ihre Projekte erweisen. In diesem Blogbeitrag werde ich erklären, was Podman ist und wie es sich von Docker unterscheidet. Zudem möchte ich Ihnen Informationen an die Hand geben, damit Sie entscheiden können, ob Sie Podman in Ihrer Umgebung verwenden können oder nicht.

Podman ist eine OCI-konforme (Open Container Initiative) Container Engine auf Open-Source-Basis (see GitHub). Die Engine wird von Red Hat angeboten und beinhaltet einige wesentliche Unterschiede zu Docker (wie bspw. eine Daemonless-Architektur und die Unterstützung von Rootless-Containern). Im Kern machen beide Tools allerdings dasselbe: Images und Container verwalten. Eines der Ziele von Podman ist es, eine Docker-kompatible API bereitzustellen. Somit sind nahezu alle CLI-Befehle (Command Line Interface) aus der Docker CLI auch in Podman verfügbar.

Im Ecosystem von Podman finden sich zudem zwei weitere Tools: Buildah und Skopeo. Buildah ist ein CLI-Tool zum Erstellen von Container-Images, und Skopeo ist ein CLI-Tool zum Ausführen von bestimmten Prozessen auf Images wie z. B. Push, Pull oder Inspect. Weitere Informationen zu diesen Tools und ihren Beziehungen zu Podman finden Sie in GitHub.

Der größte Unterschied zwischen Docker und Podman ist ihre Architektur. Docker läuft auf einer Client-Server-Architektur, während Podman auf einer Daemonless-Architektur aufbaut. Doch was bedeutet das? Bei der Arbeit mit Docker müssen Sie die Docker CLI verwenden, die mit einem Hintergrund-Daemon (dem Docker-Daemon) kommuniziert. Die Hauptlogik liegt im Daemon, der Images erstellt und Container ausführt. Dieser Daemon ist mit Root-Rechten ausgestattet. Die Podman-Architektur hingegen erlaubt es Ihnen, die Container unter dem Benutzer auszuführen, der den Container startet (fork/exec), und dieser Benutzer benötigt keine Root-Rechte. Da Podman über eine Daemonless-Architektur verfügt, kann jeder Benutzer, der Podman ausführt, nur seine eigenen Container sehen und ändern. Es gibt keinen gemeinsamen Daemon, mit dem das CLI-Tool kommuniziert.

Da Podman keinen Daemon nutzt, muss das Ausführen von Containern im Hintergrund unterstützt werden. Es bietet daher eine Integration mit systemd, wodurch die Steuerung von Containern über systemd-Units ermöglicht wird. Je nach Podman-Version können Sie diese Units entweder für bestehende Container generieren oder eigene Units generieren, die Container erstellen können (sofern im System keine Container vorhanden sind). Außerdem gibt es ein weiteres Integrationsmodell mit systemd, durch das systemd innerhalb eines Containers laufen kann. Weitere Informationen zu diesem Thema finden Sie im Red Hat-Blogbeitrag „Verbesserte systemd-Integration mit Podman 2.0“. Um den Daemonprozess zu steuern, verwendet Docker standardmäßig systemd.

Der zweite große Unterschied betrifft die Art und Weise wie Container ausgeführt werden. Mit Podman werden Container unter den jeweiligen Nutzerberechtigungen und nicht unter dem Daemon ausgeführt. An dieser Stelle kommt das Konzept von Rootless-Containern ins Spiel, denn ein solcher Container kann ohne Root-Rechte gestartet werden. Rootless-Container haben gegenüber Rootful-Containern einen riesigen Vorteil, da sie (wie Sie sich denken können) nicht unter dem Root-Account laufen. Sollte ein Angreifer in einen Container eindringen und aus diesem ausbrechen (Stichwort: Container Escape), hat dies den Vorteil, dass dieser Angreifer immer noch ein normaler Benutzer auf dem Host ist. Container, die von einem Benutzer gestartet werden, können nicht mehr Berechtigungen oder Funktionen haben als der Benutzer selbst. Dies stellt eine weitere natürliche Schutzebene dar. Für die Verwendung von Rootless-Containern sind zusätzliche Installationsschritte erforderlich (siehe GitHub), da Rootless-Container auf Benutzer-Namespaces und anderen Funktionen basieren, die ggf. zuerst installiert oder konfiguriert werden müssen. Docker implementiert zum Zeitpunkt der Erstellung dieses Artikels einen Rootless-Modus für den Docker-Daemon (siehe Docker-Dokumentation), wobei es sich dabei immer noch um einen experimentellen Modus handelt. Wenn Sie mehr über Rootless erfahren möchten, darüber wie es implementiert wird und welche Defizite es gibt, empfehle ich Ihnen die folgenden Blogbeiträge: „Defizite von Rootless Podman“ und „Der aktuelle Adaptions-Status von cgroup v2 in Containern“ (siehe Medium).

Eine Nebenbemerkung an dieser Stelle zu einem anderen Sicherheitsthema – Image Signing: Aktuell unterstützt Podman die einfache Signatur, während Docker die Content Trust-Funktion bietet, die auf The Update Framework basiert (weitere Informationen hierzu finden Sie in dieser GitHub-Ausgabe).

Viele Entwickler verwenden bei ihren Projekten Docker Compose, um mehrere Container gleichzeitig auf ihrer Entwicklungs-Engine zu nutzen. Zum jetzigen Zeitpunkt wird Docker Compose in Podman nicht unterstützt. Momentan wird zwar am Aufbau eines Docker Compose-Äquivalents gearbeitet (siehe GitHub), allerdings nicht vom Podman-Team. Das Podman-Team betrachtet Kubernetes als den „De-facto-Standard für die Container-Orchestrierung“ (siehe GitHub), daher unterstützen sie das Pods-Konzept, nicht aber Docker Compose. Es ist möglich, ein Docker Compose-ähnliches Verhalten mit Pods zu erzeugen, obgleich die Konvertierung zwischen den beiden einige Anstrengungen erfordert. Bitte beachten Sie aber, dass Pods konzeptionell nicht wie Docker Compose sind und eine 1:1-Übersetzung möglicherweise nicht zu 100% funktioniert. Wenn Sie mehr darüber erfahren möchten, finden Sie in einem Red Hat-Blogbeitrag Informationen dazu, wie man von Docker Compose zu Pods wechselt.

Ein weiteres wichtiges Thema aus der Entwicklungsperspektive ist die Integration in Entwicklungs-Tools. Docker ist deutlich besser in eine Vielzahl von Tools integriert. Da Podman eine kompatible API bereitstellt, sollte ein Wechsel möglich sein. Allerdings muss dies individuell getestet werden.

Podman ist ein vielversprechender Kandidat, wenn Sie erhöhte Sicherheitsanforderungen in Bezug auf Laufzeitrechte haben oder wenn Sie ein Projekt von Grund auf neu aufsetzen können. Wenn Sie von Anfang an Pods verwenden, können Sie später immer noch zu Kubernetes wechseln. Denken Sie daran, dass Podman an sich auf Linux-Konzepten basiert und keine Unterstützung für Windows-Container bietet. Ihre Entwickler benötigen daher Kenntnisse in Linux.

Wenn Sie an einem Projekt arbeiten, das von den Docker-Spezifikationen abhängig ist (wie Docker Compose), lohnt sich die Verwendung von Podman im Allgemeinen nicht, da die Migration einigen Aufwand und Änderungen in der Entwicklungsumgebung erfordert.

Je nach Projektziel kann es sinnvoll sein, die beiden Tools miteinander zu kombinieren. Wenn Sie erhöhte Sicherheitsanforderungen in der Produktionsumgebung haben, können Sie Docker weiter auf den Entwicklungs-Engines verwenden und in den Laufzeitumgebungen (dev, int, prod usw.) zu Podman wechseln. Diese Kombination ist möglich, da beide Tools OCI-konform sind und Podman Dockerfiles und Image-Spezifikationen unterstützt. Solche Kombinationen müssen aber sorgfältig geprüft werden, da sie Kenntnisse in beiden Tools erfordern.

Podman wächst und seine Entwickler binden ständig neue Funktionalitäten ein. Erst kürzlich wurde eine RESTful-API hinzugefügt, die die Fernsteuerung von Podman ermöglicht. Bisher stand zur Fernsteuerung nur eine varlink-API zur Verfügung. Geplant sind weitere Verbesserungen an der RESTful-API und an der Rootless-Funktion. Darüber hinaus werden die Entwickler eine Integration mit CRI-O aufbauen.