Docker ist tot!?! Podman – eine Alternative?

Maximilian Krone |
27. Mai 2022 |

docker-is-dead

Source: Fight icons created by smalllikeart – Flaticon

Container-Images, Docker und Kubernetes sind für Dich keine Fremdwörter und Du hast vielleicht schon vielerorts die Meldung vernommen, dass Docker tot sei? Du kannst Dir nicht genau erklären, woher diese Aussage kommt, oder hast Du das Thema vielleicht noch nicht ganz durchblickt? Dann wird Dir dieser Blogbeitrag dabei helfen.

Wie es zu der Aussage kommt, was für Hintergründe sie hat und was für mögliche Alternativen es gibt, möchte ich in diesem Blogbeitrag gerne einmal kurz mit meinen eigenen Eindrücken erläutern.

Dabei werde ich vor allem auf die Alternative Podman – welche ohne Hintergrunddienst (engl. Daemon) auskommt – inklusive ihrer Vor- und Nachteile gegenüber Docker eingehen. Zuerst wird dabei die OCI erklärt und im Anschluss, wie Podman im Groben funktioniert. Was Podman allerdings nicht ist und eine Auflistung der Vorteile gegenüber Docker folgt später.

Um es kurz vorwegzunehmen: Container-Images – vor allem nach dem OCI Standard – sind nicht tot und auch Docker hat nach wie vor seine Anwendungsgebiete und wird entsprechend nicht schnell aussterben. Der vorliegende Artikel zielt viel mehr auf die Lizensierungsveränderungen von Docker – insbesondere von Docker Desktop- ab und was für Konsequenzen sie nach sich zieht.

Warum ist Docker “tot”? Die Geschichte hinter Docker.

Anfänge der Container und Docker

Docker ist eine Open-Source Software, die vor allem der Isolierung von Applikationen mit Hilfe von Containervirtualisierung dient. Dies schafft sie u.a. durch den Einsatz von Linux-Techniken wie cgroups und namespaces, um Container zu realisieren. Genaueres dazu lässt sich auch in der offiziellen Dokumentation von Docker nachlesen.

Dabei ist Docker nicht, wie oft gedacht, der erste Ansatz in dieser Richtung gewesen. Die Isolierung von Anwendungen über Prozessisolierung – im Prinzip ist Containerisierung dies – geht weit in die Vergangenheit von Computern zurück. So können die ersten Ansätze bis zum chroot Systemaufruf (engl. syscall) der späten 1970er Jahre zurückverfolgt werden. Dieser Fortschritt war der Beginn der Prozessisolierung: der getrennte Dateizugriff für jeden Prozess.

Jedoch schaffte es die Docker Inc., am Anfang noch unter der Firmierung dotCloud, im März 2013 die Containerisierung auf ein neues Level zu heben. Sie ermöglichte es der breiten Öffentlichkeit die Containerisierung näher zu bringen, indem sie Docker als freie und quelloffene Software veröffentlichte. Vor allem die einfache, verständliche Nutzbarkeit, die hohe Verlässlichkeit und der extreme Mehrwert der Docker-Container führten in den darauffolgenden Jahren zum großen Erfolg und Aufleben der Containerisierung in der Welt der IT.

 

Aquisition Mirantis

mirantis

Im November 2019 erwarb dann Mirantis die Docker Inc. mitsamt der Docker-Suite. Kurz daraufhin kündigte Mirantis eine Anpassung des bestehenden Lizenzmodells an. So war die Standard-Nutzung von Docker inkl. Daemon, CLI und Docker Desktop bisher kostenfrei. Statt bisher freier Nutzung von Docker Desktop, ist diese Softwaresuite nun nach der Transitionsphase bis Ende Januar 2022 ab $5 pro Benutzer/Monat zu mieten, sofern es sich um eine professionelle Nutzung handelt. Ausgenommen davon sind seitdem nur noch Privatpersonen, Open-Source Communitys und kleine Unternehmen mit bis zu 250 Mitarbeitern oder 10 Millionen Dollar jährlichen Umsatz.

Zusätzlich dazu wurde in der zentralen Docker-Registry – dem DockerHub – ein Rate-Limit erstellt, sodass anonyme Nutzer nur 100 Images und authentifizierte freie Benutzer nur 200 Images innerhalb von sechs Stunden herunterladen können.

Diese Vorgänge hatten die Abkehr mehrerer größerer Hersteller und Plattformen zur Folge, da sie mit den plötzlich geänderten Lizenzbedingungen nicht einverstanden waren. Durch den Einsatz von Docker in beliebten Plattformen wie z.B. Kubernetes, zeigte dies die Gefahr der Abhängigkeit zur Docker Inc. Wenn dieses Unternehmen weiterhin ihr Lizenzmodell beliebig anpassen kann, so kann dies große Konsequenzen für alle Unternehmen und Plattformen zur Folge haben, die auf Docker setzen.

Exemplarisch folgte dazu die Meldung des Kubernetes-Projekts, dass Docker bzw. dockershim ab Version 1.24 abgekündigt wird. Auch RedHat entschied sich mit RHEL 8 dazu. Aufgrund dieser Entscheidungen und auch der Abkehr von RedHat und Kubernetes von Docker gibt es einen immer größeren Teil von Entwicklern, die sich von Docker entfernen und nach Alternativen Ausschau halten. Einen interessanten Bericht zu der sinkenden Nutzung von Docker findet man hier.

Docker Desktop

Um die Tragweite des Ganzen zu verstehen, folgt hier eine Erklärung zu der Anwendung Docker Desktop.

Docker Desktop ist eine Software-Suite für Mac, Windows und mittlerweile auch Linux, mit der containerisierte Anwendungen mittels der Docker eigenen Werkzeuge erstellt werden können. Dabei umfasst Docker Desktop u.a. die Docker-Engine, die docker-cli, docker-compose und einen Credential-Helper.

Durch die Anpassung des Lizenzmodells darf Docker Desktop in der Gänze nur noch von den oben beschriebenen Ausnahmen verwendet werden, sofern Lizenzkosten vermieden werden sollen.

Was ist Podman?

podman

In der Szene tritt für viele Podman in die Fußstapfen von Docker als freie Software. Doch was genau Podman ist und dass es nicht nur einfach ein Ersatz ist, wird im Folgenden erläutert.

Podman ist ein quelloffenes und freies Container-Management-Tool für die Entwicklung, Verwaltung und Ausführung von OCI-Containern.

OCI-Images und -Runtime

OCI steht dabei für die Open Container Initiative und wurde 2015 von der Docker Inc. initiiert. Sie beschreiben zwei Spezifikationen: Die Runtime Spezifikation und die Image Spezifikation.

Jegliche Software kann die Spezifikationen implementieren und so OCI-kompatible Container-Images und Container-Runtimes schaffen, die untereinander kompatibel sind. Zusätzlich gibt es die sogenannten Container Runtime Interfaces (CRI), die auf den OCI-Runtimes aufsetzen und diese abstrahieren.

Beispielhafte Implementierungen der Container-Runtime-Interfaces sind dabei dockershim (OCI-Wrapper für die originale Implementierung der Docker-Engine, siehe dieser Artikel), containerd (neue Implementierung des Container Runtime Interfaces (CRI) von Docker) und cri-o (Implementierung des Kubernetes Container Runtime Interfaces).

Implementierungen der OCI-Images sind zum Beispiel in Docker, Buildah, kaniko und eben Podman zu finden. Die OCI-kompatiblen Container-Images können dann, wie eben beschrieben, auf einer CRI-kompatiblen Runtime (containerd, cri-o) ausgeführt werden, welche wiederum eine OCI-Runtime wie z.B. runc oder runsc aufruft. Runc bzw runsc starten dann den eigentlichen Container auf dem Client.

Dies mag auf den ersten Blick etwas verwirrend erscheinen, lässt sich aber anhand des Artikels von tutorialworks und der folgenden Abbildung verdeutlichen.

grafik-by-tutorial-works
The projects involved in running a container with Docker – Source: Tutorial Works

Was ist Podman nicht?

Dadurch, dass Podman – im Gegensatz zu Docker – keine Container Runtime, sondern nur eine Implementierung der OCI-Image-Spezifikation ist, kann Podman selbst keine Images starten. Es benötigt die genannte CRI-Container Runtime, welche wiederum die hardwarenahe OCI-Runtime wie z.B. runc oder runsc nutzt, um die eigentlichen Container zu starten.

Podman selbst kann also nur Verwaltungsaufgaben der Container inkl. Build übernehmen. Zum Ausführen der Images nutzt Podman dann z.B. das genannte containerd, welches wiederrum z.B. runc zum eigentlichen Starten des Containers ausführt.

Vorteile von Podman

Im Folgenden werden die Vorteile von Podman gegenüber Docker kurz erläutert.

  • Nähe zu Docker.
    Trotz der teilweise erheblichen Unterschiede in der Implementierung von Podman zu Docker sind die gängigsten Befehle von Docker eins zu eins verwendbar. So funktionieren gängige Befehle wie login, build, pull, push, tag etc. genau wie vom Benutzer erwartet. Auch werden nach wie vor Dockerfiles zum Bauen der Container-Images verwendet. Dadurch wird einem ehemaligem Docker-Benutzer der Einstieg sehr erleichtert.
    Zusätzlich hilft diese Kompatibilität der Befehle einer nötigen Migration von Docker zu Podman. Zum Beispiel lassen sich so über das Setzen eines Aliases von podman auf Docker die meisten Skripte weiterverwenden.
  • Ressourcenbedarf und Einbettung in OS
    Podman wurde als schlanke und effiziente Lösung aufgebaut. Dadurch hat er insgesamt weniger Speicherbedarf, gilt als deutlich schneller und vergleichsweise effizient. Auch aus diesen Gründen ist Podman für einige Linux-Distributionen wie z.B. CoreOS von Fedora mittlerweile ein Standard geworden.
    Zusätzlich ist Podman mittlerweile in den Standard-Repositories von Ubuntu 22.04 LTS enthalten, siehe auch diesen > Blogbeitrag.
  • Pods
    Wie bereits erwähnt stellt Kubernetes mit Version 1.24 den Support für Docker ein. Dies hat zur Folge, dass dockershim als Runtime durch eine andere Container Runtime wie containerd oder cri-o ersetzt werden muss.Mit Podman hingegen soll die Zusammenarbeit weiter problemlos möglich sein. Podman unterstützt dabei sogar, wie man auch vom Namen ableiten kann, sogenannte Pods. Diese wurden ursprünglich von Kubernetes etabliert und können mehrere Container zusammenfassen, ähnlich einem Docker-compose.

 

schema-pod

Schematisches Konzept eines Pods

 

Es bietet sich damit an, Pods lokal mit Podman zu bauen und zu testen, bevor man diese in Kubernetes ausrollt. Alternativ wäre natürlich auch die Möglichkeit einer lokalen Minikube-Installation ein guter Weg, um seine Kubernetes Manifeste zu testen. Podman ist da allerdings schlanker und entsprechend performanter in kleinen Setups.

Mehr zu Pods in Podman kann man auch hier finden.

  • Rootless Modus
    Podman benötigt keine Root-Berechtigungen damit seine Befehle ausgeführt werden im Gegensatz zu Docker, welches vom Hintergrund-Prozess (Daemon) abhängig ist. Docker benötigt Root-Rechte oder erfordert, dass der Benutzer in der Docker-Gruppe ist. Sollte er es nicht sein und sollte kein sudo verwendet werden, wird eine entsprechende Fehlermeldung geworfen und es kann entsprechend nicht genutzt werden.
    Warum jenes überhaupt ein Problem sein mag, stellt man sich nun die Frage? Der Docker-Daemon benötigt – wie bereits erklärt – obligatorisch die Root-Rechte auf dem Server und erschafft dadurch ein potenzielles Sicherheitsrisiko. Sollte ein Angreifer in den Container eindringen, ergibt sich dadurch das Risiko, dass dieser auf den darunterliegenden Server ausbrechen kann, um dann weitere Services im Netzwerk zu infiltrieren.
  • Auditing
    Im Gegensatz zu Docker folgt Podman dem Fork-Exec-Modell. Das bedeutet, dass Änderungen im auditd-System aufgezeichnet werden. Das kann aus Compliance-Sicht ein Vorteil gegenüber Docker sein. Eine Ausnutzung des Audit-Modells in Docker gegenüber dem -Modell in Podman lässt sich dank des folgenden > Blogbeitrag nachvollziehen.

Limitierungen von Podman

Es gibt vor allem zwei Einschränkungen, die Podman mitbringt. Diese werden kurz nähergelegt.

  1. Linux basiert
    Podman läuft derzeit nur stabil auf Linux-basierten Systemen. Unter Windows oder MacOS wird es ein bisschen anspruchsvoller, wenn auch es mit Umwegen möglich ist.
    Unter Windows lässt sich Podman mittels WSL gut nutzen, unter MacOS lässt es sich direkt mit homebrew installieren. Allerdings sind diese Lösungen noch nicht hundertprozentig ausgereift und gelten noch als „In Entwicklung“. Mehr dazu lässt sich dem offiziellen > Podman-Blogbeitragentnehmen. Ich persönlich nutze Podman seit einiger Zeit mittels einer WSL 2 und der Ubuntu Distribution und bin grundlegend sehr zufrieden. Hier und da gibt es noch kleinere Kinderkrankheiten, diese sind aber in der Regel mittels Googlesuche schnell behebbar.
  2. Docker-Compose
    Podman selbst unterstützt Docker-Compose nicht, um mehrere Container lokal zu starten. Es gibt dafür zwei Alternativen.
    1. Zum einen gibt es bereits ein Projekt namens > Podman-Compose, das die Kernfunktionalitäten von Docker-Compose erfüllen soll, und zum anderen unterstützt Podman die oben beschriebenen Pods. Mit diesen lassen sich auch mehrere Container gleichzeitig starten und verwalten – dies sogar über einen Kubernetes-freundlicheren Weg.
    2. Eine weitere nützliche Alternative zu Docker-Compose ist zum Beispiel die Nutzung von > minikube oder auch > k3d. Mit diesen Werkzeugen lassen sich einfach und schnell lokale Kubernetes-Cluster ausrollen. Diese können dann zu Entwicklungszwecken benutzt werden, um lokal Kubernetes-Objekte wie z.B. Deployments, Services oder Pods zu implementieren und testen.

MacOS: Alternative Lima

lima-logo

 

Neben Podman gibt es noch eine weitere erwähnenswerte Alternative: Lima.

Lima – abgekürzt für Linux virtual machines – wird in dem Kontext vor allem als Alternative für MacOS genutzt und wird mit QEMU (ein Hypervisor), containerd und nerdctl ausgeliefert.

Somit nutzt Lima im Hintergrund QEMU zur Virtualisierung, containerd als Container Runtime und nerdctl als Docker-kompatible CLI für containerd. Lima ähnelt dem Windows Subsystem für Linux (WSL) in der Version 2.

Für unsere Mac-Nutzer somit auf jeden Fall einen Blick wert.

Ausblick Unikernel

Eine weitere Möglichkeit von Docker-Containern zu wechseln sind die sogenannten Unikernels. Diese werden der Vollständigkeit halber hier kurz erwähnt, auch wenn sie derzeit keine Bedeutung im Kubernetes-Kontext haben. Ein interessanter Blogbeitrag zu dem Thema kann man auf Hackernoon finden. Es handelt sich um ein interessantes Konstrukt, welches ggf. eines Tages in die Welt von Kubernetes Einzug finden wird, wenn Container durch Unikernel ersetzt werden können. Derzeit wäre die Nutzung von Unikerneln meiner Meinung nach noch nicht umsetzbar.

unikernels

Zusammenfassung

Zu guter Letzt möchte ich noch eine Zusammenfassung der Nutzung von Docker und Podman in der fme AG geben, um unsere Sichtweise zu untermauern.

Viele von uns haben jahrelang die Docker-Suite genutzt – einige nutzen sie weiterhin in laufenden Projekten, einige sind bereits zu anderen Alternativen gewechselt.

Es gibt – wie immer – kein Schwarz und Weiß, sondern viele Grautöne dazwischen. Entsprechend sind nach wie vor zahlreiche Anwendungsgebiete für Docker Desktop vorhanden und es sind auch einige Kunden gewillt die damit einhergehenden Lizenzkosten zu übernehmen.

Allerdings gibt es auch viele Gegenstimmen dazu – sowohl in der Community, als auch bei unseren Kunden. Die plötzliche Änderung eines Lizenzmodells wird dort sehr kritisch betrachtet und trägt dazu bei, dass von dieser Software Abstand genommen wird.

Wir sind dazu übergegangen in neuen Projekten Podman, Lima oder ähnliche freie Software zu verwenden, da wir unabhängig von Herstellern und Lizenzzwängen bleiben wollen. Open-Source und freie Software ist meiner Meinung nach ein wichtiger Grundpfeiler von erfolgreichen und zukunftsträchtigen IT-Projekten. Selbst Microsoft hat dies in den letzten Jahren verstanden und gelebt, indem sie viel in die Cross-Plattform-Kompatiblität mit Produkten wie .NET Core und WSL investiert haben.

Dank aktiver Entwicklercommunity und der Unterstützung von RedHat, dem Kubernetes-Projekt und vielen weiteren Organisationen und Personen, entwickelt sich Podman zu einer ernstzunehmenden Alternative für die professionelle Entwicklung von OCI-Images.

Meine Prognose: Auf lange Sicht wird Docker an Bedeutung verlieren und Open Source Projekte wie Podman, Lima etc. werden den Platz der ehemals bedeutensten Container-Suite einnehmen.

Auch aus diesem Grund bin ich Pro-Podman und im direkten Duell zwischen Docker und Podman geht der Sieg– meiner Meinung nach – an Podman und den Gedanken an freie Software.

 

×
Haben wir Ihr Interesse geweckt? Dann schreiben Sie uns gerne an.
JETZT KONTAKT AUFNEHMEN

Folgen Sie uns auf unseren Social Media Accounts, um keinen neuen Blogartikel zu verpassen.

linkedin     xing     facebook     twitter

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert