Podman versus Docker – was bringt die Zukunft in der „Container-Welt“?
Offizieller RedHat-Support für Docker wurde eingestellt – Podman dafür als Alternative gepusht
In unserem Fall war vor allem die Einstellung des Docker-Supports durch RedHat der Auslöser, uns im Rahmen eines komplexes Portal-Projektes für einen Kunden aus der Bundesverwaltung einmal Podman, ein vielversprechendes neues System für das Management von Containern und Pods, genauer unter die Lupe zu nehmen. Dabei sollte für unser aktuelles gemeinsames Portal-Projekt vor allem geprüft und evaluiert werden, ob Podman sich für Produktivbetrieb einer skalierbaren Anwendung eignet, in einer Umgebung, wo auf absehbare Zeit keine klassische Cloudlösung als Orchestrierungsplattform (Kubernetes, Openshift etc.) zur Verfügung stehen wird. Für uns als Software-Dienstleister stellte sich zudem die übergeordnete Frage, unter welchen Bedingungen/Anforderungen Podman grundsätzlich als Alternative zu Docker in Betracht gezogen werden kann.
Podman – vollständiger und unkomplizierter 1:1-Ersatz für Docker?
Podman kommt aus dem Hause RedHat und wird damit beworben, dass man Docker damit 1:1 ersetzen kann, was wohl auch die Einstellung des Supports von Docker erklärt. Die Dokumentation geht gar soweit, einen Austausch von Docker durch Podman zu empfehlen:
$ alias docker=podman
Das wirft einige Fragen auf: Ist dies wirklich so? Und kann das (im Gegensatz zu Docker) Pods unterstützende neue Tool unter Umständen sogar als Ergänzung oder Ersatz zum „großen Bruder“ Kubernetes/Openshift verwendet werden? In der Evaluation sollte es weniger darum gehen, die neue Technologie aus der Perspektive der Softwareentwicklung zu betrachten, sondern vor allem die Vor- und Nachteile von Podman aus Operations-Sicht beim Kunden als Betreiber des Systems zu beleuchten. Schauen wir uns das Ganze doch einmal genauer an.
Worin unterscheidet sich Podman denn nun tatsächlich von Docker?
Tatsächlich ist es so, dass es aus Sicht des Kunden als Betreiber eines Systems auf RedHat drei wesentliche Unterscheidungsmerkmale gegenüber Docker gibt. Diese sind:
- Podman verzichtet auf einen „Daemon“ Prozess, der alle laufenden Container verwaltet, zugunsten eines gewöhnlichen Fork-Exec-Modells, das sich technisch besser in das Linux-Ökosystem integrieren lässt (Beispiel: Installieren von Podman-Containern als systemd-Services).
- Podman erlaubt von Haus aus die Ausführung ohne root-Privilegien. Die Container werden als normale Kindprozesse in der aktuellen Benutzersitzung gestartet, wohingegen ein unzureichend gesicherter Docker Daemon mit seinen Root-Privilegien ein großes Risiko darstellen kann.
- Podman bietet, im Gegensatz zu Docker, nicht nur die Unterstützung von Containern, sondern auch Pods, wie sie in Kubernetes/Openshift angeboten werden.
Zusammen mit der vom Hersteller versprochenen Möglichkeit der reibungslosen 1:1-Ablösung von Docker sieht dies nach einem ziemlich attraktiven Gesamtpaket aus. Doch wie fällt die Bewertung nach eingehender Prüfung aus?
Alles super oder was? Das Stärken- und Schwächen-Profil von Podman
Als nächsten Schritt erstellten wir ein Stärken-Schwächen-Profil, bei dem folgende Fragen beantwortet wurden: Was sind die wichtigsten Vorteile beim Einsatz von Podman? Und gibt es vielleicht auch Schwächen, die einen Einsatz erschweren oder nur unter bestimmten Bedingungen möglich machen?
Aus unserer Sicht ist der größte Vorteil, den ein Einsatz von Podman gegenüber Docker verspricht, die höhere Sicherheit durch den Verzicht auf einen Daemon mit Root-Privilegien. Erwähnt sei in diesem Kontext allerdings, dass die neueste Version von Docker ebenfalls über Umwege einen Rootless-Betrieb unterstützt. Zudem erlaubt die Kompatibilität mit den Images aus Docker-Umgebungen grundsätzlich eine einfache Migration unserer Anwendung in eine Podman-Umgebung.
Demgegenüber stehen allerdings mehrere Aspekte von Podman, die wir als nachteilig bewerten:
- Erschwerte Automatisierbarkeit ohne einen via Netzwerk verfügbaren Daemon, der das Erstellen und Verwalten von Containern von einem Remote Host erlaubt. Zwar verfügen neueste Podman-Versionen über ein Tool, das eine Docker-kompatible REST-API anbietet, dieses ist jedoch nur zum vorübergehenden Einsatz gedacht und unterstützt zum Beispiel noch keine Authentifizierung oder TLS.
- Hohe Fehleranfälligkeit: Im Rahmen der Prüfung in unserem konkreten Projekt hat sich Podman leider als (noch) nicht vollständig zuverlässig erwiesen. So schlugen Standardoperationen wie das Anlegen, Starten und Stoppen von Container immer wieder ohne erkennbare Gründe fehl, um im nächsten Anlauf dann wieder zu funktionieren. Insbesondere beim Networking begegneten wir häufig Problemen (Portkonflikte, DNS etc.).
- Die vollständige und unkomplizierte 1:1-Ablösung von Docker ist (zumindest momentan) nicht möglich. An der „Oberfläche“ herrscht tatsächlich weitestgehend die versprochene Kompatibilität – gräbt man aber tiefer und geht ins Detail, ist festzustellen, dass zum Beispiel keine Logging Treiber unterstützt werden, oder nur manche Requests der Docker-Client-Bibliotheken in unseren Automatisierungstools von der Podman REST-API verstanden werden.
Abschließendes Fazit
Aus technischer Sicht verfügt Podman über eine große Schnittmenge mit Docker, weshalb der Einsatz auch diesbezüglich im konkreten Projekt absolut möglich wäre. Aus unserer Sicht ist der Podman-Einsatz im Produktivbetrieb derzeit, zumindest im vorliegenden Projekt-Setting, allerdings (noch) nicht wünschenswert. Die wesentlichen Gründe hierfür sind:
- (Noch) etwas unreifer Gesamteindruck, durch häufige spontane Fehler, Warnungen und andere Betriebsprobleme, insbesondere im rootless-Betrieb.
- Die (bislang) zu geringe Verbreitung von Podman als Standalone-Werkzeug außerhalb der Openshift-Umgebung, wodurch bei Problemen nur wenige Informationen in öffentlichen Quellen zur Verfügung stehen.
Aus betrieblicher Sicht könnte der Podman-Einsatz in einem Projekt mit der Linux Distribution von RedHat dennoch notwendig werden, insbesondere durch Betriebsrichtlinien, die die Verwendung von Software aus offiziellen Redhat-Paketquellen vorschreiben. Nach unserer Evaluation gehen wir davon aus, unsere Softwarelösung mit überschaubarem Aufwand auf Podman portieren zu können. Podman-spezifische Probleme müssten zunächst allerdings in Zusammenarbeit mit dem Redhat-Support erörtert und gegebenenfalls gelöst werden, was unseren Erfahrungen bei der Zusammenarbeit mit RedHat nach, unproblematisch sein dürfte.
Grundsätzlich ist Podman aus unserer Sicht, eine etwas größere Produktreife und geringere Fehleranfälligkeit vorausgesetzt, für den Produktiveinsatz in verschiedenen Projekt-Szenarien eine vielversprechende zukünftige Alternative. Wir sind sehr gespannt und werden die weiteren Entwicklungen rund um Podman sehr aufmerksam beobachten.
