Podman: Linux-Container einfach gemacht, Teil 3
Seite 6: Podman-API und Remote-Client
Obwohl Linux den Servermarkt dominiert, verwenden viele Desktopanwender und Entwickler Windows oder macOS. Um Nutzern dieser Systeme Podman zugänglich zu machen, folgten die Podman-Entwickler dem Beispiel von Docker und entwickelten einen Remote-Client, der mit Podman-Instanzen auf entfernten Linux-Systemen kommunizieren kann.
Der Podman-Remote-Client kommuniziert über die Varlink-API von Podman, die Zugriff auf nahezu alle Funktionen von Podman erlaubt (z. B. Ausführen eines Containers, Bauen von Images etc.). Varlink ist sowohl ein Protokoll als auch eine Schnittstellenbeschreibungssprache und unterstützt eine Vielzahl an Programmiersprachen (z. B. Go, Python, Java). Damit schlagen die Podman-Entwickler zwei Fliegen mit einer Klappe, denn die API kann nicht nur vom Remote-Client, sondern auch von Drittanbietern verwendet werden. Zum Beispiel verwendet COCKPIT die Varlink-API für das Management von Containern über ein Web-Interface.
Eine eingehende Varlink-Anfrage startet Podman per Systemd-Socket-Aktivierung, was sowohl lokal als auch entfernt per SSH funktioniert. In einem ausführlichen Blogbeitrag erklärt Varlink-Entwickler Harald Hoyer, wie die Systemd-Socket-Aktivierung funktioniert, und demonstriert, wie man in wenigen Codezeilen einen Podman-Client in Rust implementieren kann.
Das folgende Beispiel schaut sich den Podman-Remote-Client etwas genauer an. Zunächst installiert man Podman auf einem frisch installierten Fedora-30-Server und führt einen Container aus.
[server]# dnf install podman podman-remote -y
[server]# podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
[server]# podman run --name from-server -d alpine top
Nun kann der Podman-Varlink-Service per Systemd starten, und man kann ihn lokal testen.
[server]# systemctl start io.podman.service
[server]# podman-remote ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0a5ab8afc7f0 docker.io/library/alpine:latest top 24 seconds ago Up 23 seconds ago from-server
Der Remote-Client verbindet sich mit dem lokalen Varlink-Socket und zeigt den zuvor gestarteten Container an. Nun verbinden sich Nutzer von einer anderen Maschine mit dem Host. Die explizite Passwortabfrage ist nicht notwendig, wenn der Server den öffentlichen SSH-Schlüssel des Nutzers autorisiert hat.
[heise]$ podman-remote --remote-host 192.168.122.96 --username valentin images
valentin@192.168.122.96's password:
REPOSITORY TAG IMAGE ID CREATED SIZE
docker.io/library/alpine latest 4d90542f0623 2 weeks ago 5.85 MB
[~]$ podman-remote --remote-host 192.168.122.96 --username valentin ps
valentin@192.168.122.96's password:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55581ca92460 docker.io/library/alpine:latest top 11 minutes ago Up 11 minutes ago from-server
Der Podman-Remote-Client auf Windows und macOS befindet sich derzeit noch in Entwicklung, kann aber bereits aus dem Quellcode kompiliert werden. Linux unterstützt den Remote-Client schon länger und man kann ihn aus den offiziellen Paketquellen von Fedora und openSUSE installieren. Nur wenige Befehle des nativen Clients werden vom Remote-Client nicht angeboten. Zum Beispiel ist podman-image-sign aus Sicherheitsgründen bewusst nicht für den Remote-Client implementiert, wohingegen sich podman-login und podman-logout in Entwicklung befinden.
Checkpoint und Restore
Seit Version 1.0 unterstützt Podman die Funktionen, Container einzufrieren (podman-container-checkpoint) und zu einem späteren Zeitpunkt wieder zu starten (podman-container-restore). Für die Checkpoint-und-Restore-Funktionen setzt Podman auf CRIU. CRIU erlaubt es, Linux-Prozesse im User-Space einzufrieren und auf dem Dateisystem abzulegen, sodass sie zum Zeitpunkt des Einfrierens wieder starten können. Eine genaue Beschreibung von CRIU würde den Rahmen des Artikels sprengen, doch können Interessierte auf der offiziellen Webseite Informationen zur Funktionsweise von CRIU und deren Anwendung finden.
Im Kontext von Containern gibt es einige Anwendungsmöglichkeiten von CRIU, das neben Podman auch Docker und LXC unterstützt. Beispielsweise können während eines Systemneustarts Container zu einem bestimmten Zeitpunkt eingefroren und nach einem erfolgreichen Neustart wieder gestartet werden – und das völlig transparent für die Container. Ein weiterer Anwendungsfall ist die Live-Migration eines Containers auf ein anderes System, wie das folgende Beispiel demonstriert.
Zunächst startet man einen Container auf dem Host, friert ihn ein und kopiert das Abbild auf einen Server:
[heise]$ sudo podman run --name heise -d alpine top
f32c89ac7d01bf51d4cbc34f0af1336defa438b71623ea8981824a8072ba3362
[heise]$ sudo podman container checkpoint --export `pwd`/heise.tar.gz heise
f32c89ac7d01bf51d4cbc34f0af1336defa438b71623ea8981824a8072ba3362
[heise]$ sudo scp heise.tar.gz valentin@192.168.122.96:/heise.tar.gz
Auf dem Server importieren Anwender zunächst das Abbild:
[valentin@localhost ~]$ sudo podman container restore --import /heise.tar.gz f32c89ac7d01bf51d4cbc34f0af1336defa438b71623ea8981824a8072ba3362
[valentin@localhost ~]$ sudo podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Der heise-Container ist nun zwar importiert, doch man muss ihn noch explizit starten:
[valentin@localhost ~]$ sudo podman start heise
heise
[valentin@localhost ~]$ sudo podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f32c89ac7d01 docker.io/library/alpine:latest top 29 seconds ago Up 5 seconds ago heise
Grundsätzlich setzt die Checkpoint-Restore-Funktion Root-Rechte voraus. Google berichtet zwar davon, Prozesse mit CRIU auch ohne Root migrieren zu können, doch ist dafür nach wie vor ein privilegierter Helfer-Prozess nötig und für rootless-Podman damit nicht realisierbar.
