podman ist eine Container-Engine ohne Daemon, die weitgehend die Kommandozeile von docker übernimmt und zusätzlich Pods kennt. Diese Referenz zeigt Container, Pods, Images, systemd-Integration und den Übergang zu Kubernetes.

Container verwalten

podman run -d --name web -p 8080:80 nginx:alpine
podman ps                       # laufende Container
podman ps -a                    # alle, auch gestoppte
podman logs -f web
podman exec -it web sh
podman stop web
podman rm web
podman inspect web | head -40

Der wichtigste Unterschied zu Docker: Es gibt keinen Dienst, der ständig läuft. Jeder Aufruf arbeitet eigenständig. Das bedeutet auch, dass Container nach einem Neustart nicht automatisch wieder starten – dafür ist systemd zuständig (siehe unten).

Rootless arbeiten

podman info | grep -i rootless
podman unshare cat /proc/self/uid_map    # ID-Zuordnung ansehen
podman run --userns=keep-id -v "$PWD:/data:Z" alpine ls -la /data

--userns=keep-id ist bei rootless Containern wichtig, damit geschriebene Dateien dem eigenen Benutzer gehören statt einem neu zugeordneten. Das Suffix :Z setzt den SELinux-Kontext beim Binden eines Verzeichnisses.

Pods – mehrere Container mit geteiltem Netz

podman pod create --name app -p 8080:80
podman run -d --pod app --name web nginx
podman run -d --pod app --name sidecar alpine sleep 3600
podman pod ps
podman pod logs app
podman pod stop app ; podman pod rm app

Innerhalb eines Pods erreichen sich die Container über localhost. Damit lässt sich ein Sidecar-Muster testen, ohne einen Cluster zu betreiben.

Images und Registries

podman build -t mein-image:1.0 .
podman images
podman pull registry.example.org/team/app:1.4.0
podman login registry.example.org
podman push mein-image:1.0 registry.example.org/team/mein-image:1.0
podman rmi mein-image:1.0

# Werkzeuge der Familie
skopeo copy docker://nginx:1.27 docker://registry.example.org/spiegel/nginx:1.27
buildah bud -t mein-image:1.0 .
podman manifest create multi:1.0
podman manifest add multi:1.0 docker://nginx:1.27-arm64

Übergang zu Kubernetes

# Laufenden Pod als Manifest ausgeben
podman kube generate app > app.yaml
podman generate kube app > app.yaml       # ältere Schreibweise

# Manifest im lokalen Podman ausführen
podman play kube app.yaml
podman play kube --down app.yaml

Damit lässt sich ein Deployment lokal entwickeln und später unverändert in einem Cluster anwenden – der praktisch wertvollste Vorteil des Pod-Konzepts.

Als systemd-Dienst betreiben

# Variante 1: Unit über podman generate erzeugen (ältere Versionen)
podman generate systemd --new --name web --files
mkdir -p ~/.config/systemd/user && mv container-web.service ~/.config/systemd/user/
systemctl --user daemon-reload
systemctl --user enable --now container-web

# Damit Dienste nach dem Logout weiterlaufen
loginctl enable-linger $USER

Neuere Versionen setzen auf Quadlet: Eine Datei ~/.config/containers/systemd/web.container beschreibt den Container deklarativ, systemctl --user daemon-reload erzeugt daraus eine Unit. Fehlt enable-linger, verschwinden die Dienste beim Abmelden – ein klassischer Anfängerfehler.

Wartung

podman system df
podman system prune -a
podman volume ls ; podman volume inspect pgdata
podman --version ; podman info --format '{{.Host.OCIRuntime.Name}}'

Verwandte Grundlagen: Podman, docker-Befehle, Buildah, Container.