Docker/Buch/06 Interna/Podman-Interna

Podman-Interna

Bei der Anwendung sieht Podman aus wie Docker, und tatsächlich funktioniert in vielen Fällen alias docker=podman, also der simple Austausch des docker -Kommandos durch podman

Hinter den Kulissen ist Podman aber vollkommen anders organisiert

In diesem Abschnitt gehen wir daher auf einige Details der Implementierung von Podman ein Um zu begreifen, wie sich Podman von Docker unterscheidet, müssen Sie zuerst die Grundidee bei der Implementierung von Docker verstehen: Dabei hat docker primär die Aufgabe, mit den beiden Hintergrundprozessen dockerd und containerd zu kommunizieren

Diese erledigen die eigentliche Arbeit, verwalten also die Containerund

Image-Dateisysteme, führen Container aus usw Fundamental anders sieht die Arbeitsweise von Podman aus: Das Kommando podman kümmert sich direkt um das Image-Management und die Container-Ausführung

Es gibt keinen im Hintergrund laufenden Dämon
Das Kommando podman erledigt somit selbst alle Aufgaben, für die im Docker-Universum dockerd bzw
containerd zuständig sind
podman greift natürlich auch auf andere Programme und Bibliotheken zurück –

aber eben nicht auf einen zentralen Dämon

Die Podman-Entwickler sehen darin den größten Vorteil ihrer Architektur: Es gibt damit keinen Single Point of Failure

Die in der Dokumentation beschriebenen Sicherheitsvorteile von Podman im Vergleich zu Docker klingen zwar plausibel, es ist aber zu früh, um darüber ein endgültiges Urteil zu fällen

Unklar ist auch, wie weit die Sicherheit von Podman von SELinux abhängt
Dann wären nämlich alle Distributionen ohne SELinux (speziell Debian und

Ubuntu) sicherheitstechnisch benachteiligt

Red Hat hat mit Udica auf jeden Fall ein eigenes Werkzeug entwickelt, das beim Festlegen von SELinux-Regeln für Container jeder Art (inklusive Podman) hilft:

https://www.redhat.com/en/blog/generate-selinux-policiescontainers-with-udica Zu guter Letzt stößt der viel beworbene Betrieb von Containern ohne root-Rechte in der Praxis manchmal an die Grenzen des technisch Möglichen: In diesem Abschnitt werden wir Ihnen zeigen, dass auch Podman im root-Modus ausgeführt werden kann, um technische Einschränkungen zu überwinden

Container-Registries Unter Docker stellt sich die Frage nach der Image-Herkunft nicht: Das Kommando docker lädt Images automatisch aus dem weltweit größten öffentlichen Container- Angebot herunter, nämlich dem Docker Hub

Bei Podman ist die Situation anders:

Dort entscheidet die Datei /etc/containers/registries.conf, von welchen Quellen (Registries) die Container heruntergeladen werden Bei den meisten Distributionen enthält registries.conf nach der Installation bereits sinnvolle Defaulteinstellungen

Die folgenden Zeilen zeigen die unter Fedora gültige

Konfiguration:

Datei / etc / container s / registrie s

conf ( Fedora )

unqualified - search -registri e s = [" registry .fedorapr o j e ct

org " ,

" registry .access

redhat
com " ,

" docker

io " , " quay
io "]

Wenn Sie podman run name ausführen, ohne dem Projektnamen explizit eine Registry voranzustellen, fragt das Kommando, welche der vier obigen Quellen Sie verwenden möchten

In aller Regel ist docker.io (also der Docker Hub) die richtige Wahl
Die anderen drei Registries sind dem Red-Hat-Kosmos zuzuordnen und enthalten fast ausschließlich Images zu Red-Hat-nahen Projekten
Letzten Endes ist es also so, dass

Sie zwar mit Podman eine alternative Container-Implementierung verwenden, aber weiterhin auf den Docker Hub als zentrale Image-Quelle angewiesen sind Ergänzend zu registries.conf ordnet die Datei 000-shortnames.conf wichtige Repositories der richtigen Registry zu

Wenn Sie also podman run node ausführen, weiß podman, dass es das Image aus dem Docker Hub herunterladen soll, und verzichtet auf die Nachfrage

Datei / etc / container s / registrie s

conf
d /000 -shortnam es
conf

[ aliases ]

" almalinu x "          = "docker

io / library /almalinu x "

" almalinux - minimal " = "docker

io / library /almalinux - minimal "

" amazonli n u x " = "public

ecr
aws / amazonli nu x / amazonli nu x "

" archlinu x " = "docker

io / library /archlinu x "

" busybox " = "docker

io / library /busybox "

" centos " = "quay

io / centos / centos "

" node " = "docker

io / library /node "

" oracleli n u x " =

" container - registry

oracle .com / os / oracleli n u x "

" php " = "docker

io / library /php "

" python " = "docker

io / library /python "

" rust " = "docker

io / library /rust "

" ubuntu " = "docker

io / library /ubuntu "

Rootless Podman versus Rootful Podman Normalerweise wird das Kommando podman ohne root-Rechte ausgeführt, d

h., Rootless Podman ist der Normalfall
Wenn Sie Ports kleiner als 1024 nutzen oder auf

Kompatibilitätsprobleme stoßen, können Sie Podman aber auch ganz unkompliziert rootful (was für ein Wort!) verwenden

Dazu stellen Sie dem podman-Kommando einfach sudo voran
Fertig!

sudo podman run -d --rm -p 80:80 --name mywebser ve r httpd sudo podman stop mywebserv e r

Beachten Sie aber, dass Podman unter Linux für Container, Images usw

unterschiedliche Verzeichnisse verwendet, je nachdem, ob podman mit oder ohne sudo ausgeführt wird
Ein bereits in Rootless Podman genutztes Image muss ein zweites Mal heruntergeladen werden, wenn Sie es rootful ausführen möchten
podman ps zeigt alle

Container an, die rootless laufen, sudo docker ps dagegen die, die rootful gestartet wurden Rootless und Rootful Podman sind also vollständig voneinander getrennt

In der

Regel werden Sie – der Podman-Philosophie folgend – anfänglich versuchen, ohne root-Rechte auszukommen

Stoßen Sie dabei auf eine unüberwindbare Grenze, heißt es: »Zurück an den Start.« Sie müssen alle podman-Kommandos neuerlich ausführen und Ihr Setup neu einrichten, diesmal eben mit vorangestelltem sudo und entsprechend mit root-Rechten

Rootful Docker unter Windows und macOS Wir behandeln in diesem Buch Podman eigentlich nur im Linux-Kontext und gehen auf die Nutzung von Podman unter Windows und macOS nicht ein

Aber an dieser

Stelle müssen wir doch eine kleine Ausnahme machen

Podman unter Windows und macOS setzt wie bei Docker eine virtuelle Maschine bzw
WSL-Instanz voraus

Wenn Sie möchten, dass Container in dieser virtuellen Maschine mit root-Rechten ausgeführt werden, hilft sudo podman nicht weiter

Stattdessen müssen Sie mit podman machine den root-Modus aktivieren:

podman machine set --rootful Um zurück in den Standardmodus zu wechseln, setzen Sie rootful auf false: podman machine set --rootful=false Weitere Optionen dieses Kommandos sind hier dokumentiert: https://docs.podman.io/en/latest/markdown/podman-machine-set.1.html

Socket-Datei Docker verwendet eine Socket-Datei zur Kommunikation zwischen dem Kommando docker und dem im Hintergrund laufenden Docker-Dämon

Prinzipbedingt ist diese

Datei in Podman überflüssig

Aus Gründen der Kompatibilität mit Docker ist es aber auch unter Podman möglich, eine Socket-Datei einzurichten

Das ist beispielsweise zweckmäßig, wenn Sie Portainer zur Podman-Administration verwenden wollen
In der Vergangenheit ermöglichte die Socket-Datei auch, Podman mit dem veralteten Script docker-compose zu kombinieren
Das ist heute aber nicht mehr relevant: Einerseits gibt es mit podman-compose eine gute Alternative zu docker-compose, die keine Socket-Datei benö- tigt; zum anderen ist das früher eigenständige Script docker-compose mittlerweile ein integrativer Bestandteil des docker -Kommandos und kann nicht mehr extra installiert werden

Wenn Sie also ein Docker-kompatibles Tool zusammen mit Podman einsetzen möchten, können Sie die Socket-Datei mit einem der folgenden Kommandos aktivieren:

systemctl --user enable --now podman .socket (Rootless Podman ) sudo systemct l enable --now podman

socket (Rootful Podman )

Wenn Sie später die automatische Aktivierung der Socket-Datei wieder abstellen wollen, führen Sie eines der beiden folgenden Kommandos aus:

systemctl --user disable --now podman

socket (Rootless Podman )

sudo systemct l disable --now podman

socket (Rootful Podman )

Hintergrundinformationen zu Sockets sind hier zusammengefasst: https://github.com/containers/podman/blob/main/docs/tutorials/socket_ activation.md

Speicherort für Container und Images Wenn das Kommando podman mit gewöhnlichen Benutzerrechten ausgeführt wird, dann werden auch Images, Container usw

im Benutzeraccount gespeichert
Dabei wird das folgende Verzeichnis verwendet:

/ home / <accountname >/

local / share / containe r s

Sollten Sie podman mit root-Rechten ausführen, kommt OCI-konform das Verzeichnis /var/lib/containers zum Einsatz

Dieses Verzeichnis erfüllt also dieselbe Funktion wie /var/lib/docker

Subordinate UIDs/GIDs Podman verwendet genauso wie Rootless Docker UIDs und GIDs jenseits von 100.000 – also Nummern, die im normalen Linux-Betrieb üblicherweise ungenutzt sind

Subordinate UIDs/GIDs basieren auf einem Kernel-Mechanismus, der Benutzern die Kontrolle über einen Bereich von UIDs/GIDs gibt
Für die Zuordnung der

UIDs und GIDs zu einem bestimmten Benutzer sind die Dateien /etc/subuid und /etc/subgid zuständig (siehe auch Abschnitt 2.5, »Rootless Docker«)

Netzwerkeinbindung Container laufen in einem privaten Netzwerk, standardmäßig mit IPv4-Adressen der Art 10.0.2.*

Im Unterschied zu Docker stehen Podman-Containern standardmäßig

IPv4 und IPv6 zur Verfügung Wenn manuell oder durch podman-compose eigene Netzwerke für Container-Gruppen gebildet werden, landen die dazugehörigen Konfigurationsdateien im folgenden Verzeichnis:

local / share / container s / storage / networks

Hintergrundinformationen zur Konzeption der Netzwerkeinbindung von Podman- Containern können Sie hier nachlesen: https://www.redhat.com/sysadmin/container-networking-podman https://github.com/containers/podman/blob/main/docs/tutorials/ basic_networking.md

Kein ping Wie bei Rootless Docker führt auch in durch Podman ausgeführten Containern ping zu einer Fehlermeldung

Zum Testen müssen Sie ping zuerst installieren, z
B
mit dnf install iputils-ping oder mit apt update und apt install iputils-ping

Den von ping ausgelösten Fehler operation not permitted verhindern Sie, indem Sie dem Host-Rechner die Ausführung von ping für den von Podman reservierten UID- Bereich (siehe /etc/subuid) erlauben:

root # sysctl -w " net

ipv4
ping_gro u p _r a n g e =0 2000000"

Damit diese Änderung dauerhaft gilt, müssen Sie die Einstellung für ping_group_ range in /etc/sysctl.conf einbauen

Diesen Tipp und einige weitere Anleitungen zur

Behebung häufiger Probleme können Sie hier nachlesen: https://github.com/containers/podman/blob/master/troubleshooting.md

Immer noch kein ping! Selbst wenn Sie das obige sysctl-Kommando ausgeführt haben, liefert das ping- Kommando bei manchen Containern (z

B
Debian) weiterhin den Fehler operation not permitted
Bei anderen Containern (Fedora) funktioniert ping dagegen

Die Ursache dieses zweiten Problems besteht darin, dass das ping-Kommando je nach Linux-Distribution unterschiedlich eingerichtet ist

Damit ping aus dem Container heraus funktioniert, benötigt das ping-Kommando das Recht, Netzwerkfunktionen zu nutzen
Deswegen müssen Sie in hartnäckigen Fällen im Container zuerst setcap cap_net_raw+p /usr/bin/ping ausführen
Danach funktioniert ping – jetzt wirklich!

Pods Haben Sie sich schon gefragt, woher der Name »Podman« kommt? Es handelt sich dabei um eine Kurzform von Pod Manager

Demnach ist podman ein Kommando zum

Verwalten von Pods

Was aber sind Pods? Der durch Kubernetes geprägte Begriff Pods

(siehe Kapitel 20, »Kubernetes«) bezeichnet eine Gruppe zusammengehöriger Container Das folgende Beispiel zeigt, wie Sie den Pod mypod mit einer Portumleitung von Port 80 (Container) auf 8080 (Host) einrichten

Genau genommen wird durch podman pod create ebenfalls ein Container erzeugt, der dauerhaft pausiert wird
Seine primäre

Aufgabe besteht darin, die Container-Gruppe am Leben zu halten, solange es darin keine weiteren Container gibt In dem Pod werden nun ein MariaDB-Datenbankserver und das Administrations-Tool phpMyAdmin ausgeführt

Bei den beiden run-Kommandos ist die Option --pod mypod entscheidend
An den phpMyAdmin-Container übergeben Sie mit PMA_HOST wahlweise den Namen des MariaDB-Containers oder den Namen des Pods (hier mypod)

Beachten Sie, dass alle Container in einem Pod intern dieselbe IP-Adresse verwenden!

podman pod create -p 8080:80 -n mypod

podman run -d --name mariadb - test --pod mypod \ -e MYSQL_RO OT _ P A SS W O R D =geheim \ -v myvolume :/ var /lib / mysql \ mariadb

podman run -d --name pma --pod mypod \

-e PMA_HOST = mariadb - test phpmyadm in / phpmyadm i n

Auf dem Host-Rechner können Sie nun im Webbrowser mittels http://localhost:8080 auf den Webserver von phpMyAdmin zugreifen und sich auf dem MariaDB-Server als root mit dem Passwort geheim anmelden

Die hier skizzierte Vorgehensweise sieht also ein wenig anders aus als ein vergleichbares Setup unter Docker, ist aber ebenso einfach einzurichten
Pods stoßen allerdings an ihre Grenzen, wenn Sie mehrere Dienste nach außen hin mit unterschiedlichen Ports freigeben möchten, wenn

Sie also z

B
phpMyAdmin mit Port 8080 und WordPress mit Port 8081 verbinden möchten
Dann müssen Sie sich auch in Pods mit einem Netzwerk-Setup auseinandersetzen

podman pod kennt außer create eine Menge weiterer Unterkommandos:

podman pod ps bzw

podman pod list listet alle Pods auf

podman pod top <podname> liefert eine Liste aller Prozesse aus allen Containern, die im angegebenen Pod ausgeführt werden podman pod stop <podname> beendet alle Container des angegebenen Pods

Wie üblich können Sie anstelle des Podnamens auch die Option --all angeben, um die

Container aller aktiven Pods zu beenden podman pod start <podname> startet alle Container eines Pods podman pod pause <podname> bzw

podman pod unpause <podname> pausiert die Container eines Pods bzw
setzt ihre Ausführung fort

podman pod rm <podname> löscht den Pod, sofern er keine Container enthält

Um einen Pod samt Containern zu löschen, verwenden Sie podman pod rm --force

Laufende Container werden vor dem Löschen gestoppt

podman pod prune [--force] löscht alle Pods, die gerade nicht laufen

Die vorhin eingerichtete Container-Gruppe kann somit unkompliziert gestoppt und gelöscht werden:

podman pod stop mypod podman pod rm mypod

Praktische Bedeutung von Pods Wenn Sie wie in diesem Buch vorgeschlagen Container-Setups mit podman-compose erstellen, spielen Pods keine große Rolle

podman-compose verwendet (wohl auch aus

Gründen der Kompatibilität mit docker compose) keine Pods, sondern erstellt mit podman network ein eigenes Netzwerk für alle in der Compose-Datei definierten Services Pods sind aber dann ein spannendes Unterscheidungsmerkmal zu Docker, wenn Sie Container-Gruppen manuell oder per Script erstellen oder wenn Sie mit Kubernetes-nahen Tools arbeiten

Merkwürdigerweise geht die offizielle Podman-

Dokumentation auf das Konzept von Pods kaum ein und enthält nur eine Referenz der pod-Subkommandos

Aufschlussreicher sind die beiden folgenden Blog-Artikel:

https://developers.redhat.com/blog/2019/01/15/podman-managingcontainers-pods https://mohitgoyal.co/2021/04/23/spinning-up-and-managing-pods-withmultiple-containers-with-podman

Zugriff auf Container-Dateisysteme (podman mount) Während der Zugriff eines Containers auf ein Verzeichnis des Hosts ein aus Docker vertrautes Verfahren ist, können Sie in Podman umgekehrt auch auf das Dateisystem eines Containers zugreifen

Dazu müssen Sie zuerst mit pod mount <containername>

den Ort des Mount-Verzeichnisses ermitteln

Dieses Kommando können Sie allerdings nicht als normaler Benutzer ausführen – das führt nur zu einer Fehlermeldung

Vielmehr müssen Sie zuerst podman unshare ausführen, um in den von Podman benutzten Namespace zu wechseln

Alle weiteren Kommandos werden in dieser

Umgebung ausgeführt; ihnen ist das Zeichen # vorangestellt Im folgenden Beispiel starten Sie einen Container mit dem Webserver Apache

Während der Container läuft, führen Sie podman mount <containername> aus
Das Kommando liefert eine ziemlich lange Zeichenkette mit dem Mount-Verzeichnis zurück

Normalerweise ist es zweckmäßig, diese Zeichenkette in einer Variablen zu speichern

Anschließend können Sie sich den Inhalt dieses Verzeichnisses ansehen und sogar Veränderungen durchführen
Wenn Sie fertig sind, verlassen Sie die Namespace-

Umgebung mit exit oder (Strg)+(D)

user$ podman run --name myapache -d -p 8080:80 \ docker

io / library / httpd

user$ podman unshare

podman mount myapache

/ home /kofler /

local / share / containe rs / storage /.../ merged

mountdir = $ ( podman unshare podman mount myapache )

ls -l $mountdi r

root root 4096 21
Okt 15:39 bin

root root 4096 21
Okt 15:39 boot

root root 4096 18
Nov 08:16 dev

exit

Standardmäßig haben Sie auf das Mount-Verzeichnis Schreibund Leserechte

Sie können also beispielsweise auf dem Host-Rechner ein Script ausführen, das Veränderungen im Dateisystem des Containers durchführt

podman mount ohne Parameter listet alle aktuell in den Host-Verzeichnisbaum eingebundenen Container-Dateisysteme auf

Mit podman mount --latest wenden Sie das

Kommando auf den zuletzt gestarteten Container an, was oft Tipparbeit spart

Images erzeugen (podman build, Buildah) podman build -t <imgname>

liest die Datei Dockerfile oder Containerfile aus dem lokalen Verzeichnis und erzeugt daraus ein Image
Dabei gilt die in Kapitel 4, »Eigene

Docker-Images (Dockerfiles)«, beschriebene Syntax

Hinter den Kulissen greift podman build allerdings auf Buildah zurück
Dabei handelt es sich um ein eigenes Image-

Build-Tool der Podman-Familie: https://buildah.io https://www.redhat.com/de/topics/containers/what-is-buildah https://dev.to/cedricclyburn/containers-without-docker-podman-buildahand-skopeo-1eal