Podman: Linux-Container einfach gemacht, Teil 1

Das Container-Tool Podman, als Alternative zu Docker angepriesen, ist kürzlich in Version 1.0 erschienen. Gründe genug für einen tiefen Einblick: Von der Installation bis zum Einsatz.

Werkzeuge  –  9 Kommentare
Podman: Linux-Container einfach gemacht, Teil 1

(Bild: stock.xchng)

Red Hat hat das Container-Werkzeug Podman ursprünglich als Debugging-Tool für die auf Kubernetes spezialisierte Container-Engine CRI-O geplant, um Anwendungsentwicklern und Administratoren von Kubernetes-Clustern gewisse Aufgaben zu vereinfachen. Seitdem hat sich Podman jedoch zu einem umfangreichen Werkzeug für das Container-Management entwickelt. Entwickler können es in Linux-Distributionen, wie Fedora, Arch Linux und openSUSE Tumbleweed ohne weiteres aus den Hauptsoftwarequellen installieren.

Das Podman-Logo (Bild: Podman)

Erste Schritte

Die Podman-Entwickler bewerben ihr Werkzeug mit der Kompatibilität zu Docker, was sich auf der Kommandozeile in identischen Befehlen widerspiegelt und sowohl Nutzern als auch Programmen die Migration von Docker zu Podman vereinfachen soll. Unter der Haube unterscheiden sich die beiden Container-Tools jedoch stark.

Docker implementiert eine Client-Server-Architektur, wodurch bei der Ausführung eines Befehls der Docker-Client eine Nachricht an den Docker-Daemon sendet, der die Ausführung und das Management der Container wiederum an einen weiteren Server auslagert, nämlich an containerd. Diese Architektur birgt einige Sicherheitsrisiken, besonders wenn der Docker-Daemon als Systemadministrator (also als root) läuft. Um das zu umgehen, verzichtet Podman auf einen Daemon und setzt stattdessen auf ein klassisches Fork-Exec-Modell, das jeden Container zum Kindprozess von Podman macht. Das ermöglicht es zum Beispiel, Nutzeraktivitäten auf einem System nachzuvollziehen. Mit dem Docker-Daemon funktioniert das nicht, da er stets als gleicher Benutzer, in der Regel als root, ausgeführt wird.

Für das Management von Container-Images setzen Podman und die Geschwisterprojekte CRI-O, Buildah und Skopeo auf identische Bibliotheken zum Verwalten und Speichern der Container-Images, sodass sie diese miteinander teilen können. In Anlehnung an Dockers Kommandozeile, können Entwickler Container-Images mit dem pull-Kommando herunterladen. Zum Beispiel die neueste Version von Alpine Linux:

$ podman pull docker.io/library/alpine:latest
Trying to pull docker.io/library/alpine:latest...Getting image source signatures
Copying blob 6c40cc604d8e: 2.63 MiB / 2.63 MiB [============================] 1s
Copying config caf27325b298: 1.48 KiB / 1.48 KiB [==========================] 0s
Writing manifest to image destination
Storing signatures
caf27325b298a6730837023a8a342699c8b7b388b8d878966b064a1320043019

Das heruntergeladene Container-Image können Anwender nun verwenden, um mit podman run Container auszuführen oder um ein neues Image zu bauen. Für das Bauen von Images setzt Podman auf Buildah, das derselben Gruppe von Entwicklern wie Podman, CRI-O und Skopeo entspringt und auf das Bauen von Containern spezialisiert ist. Podman ruft jedoch nicht Buildah direkt auf, sondern verwendet Teile des Buildah-Quellcodes für das podman build-Kommando.