podman desktop – wenn die gui gar nicht auf dem server läuft

podman desktop taucht in Diskussionen immer dann auf, wenn jemand nach etwas Grafischem für podman fragt. Also nach einem Gegenstück zu docker desktop. Die kurze Antwort: ja, das gibt es. Die etwas längere Antwort ist deutlich interessanter. podman desktop funktioniert nämlich an einer Stelle anders, als man zunächst vermutet. Schauen wir uns das an: was das Ding kann, wie es sich zu cockpit verhält und wie man damit container auf einem entfernten server verwaltet. Und zwar, ohne dass auf dem eigenen Rechner überhaupt ein container läuft.

Die eigentliche Überraschung: die GUI läuft dort, wo der server gar nicht ist

Der erste Denkfehler ist schnell gemacht: dass podman desktop eine Art Kontrollzentrum auf dem server wäre. Ist es nicht. podman desktop ist eine reine Client-Anwendung. Für alle, die es genau wissen wollen: eine Electron-App. Sie läuft auf dem eigenen Notebook oder Desktop. Der eigentliche container-Kram lebt komplett woanders – die engine, die images und die laufenden pods.

Das Ganze baut auf dem Client-Server-Modell auf, das podman ohnehin mitbringt. podman spricht über einen Socket mit einer REST-API. Die GUI ist letztlich nur eine hübsche Oberfläche über genau diese API. Ob die engine lokal läuft oder auf einem server im Keller, ist ihr reichlich egal. Hauptsache, sie kommt an den Socket. Auf macOS und Windows fällt das kaum auf. podman steckt dort sowieso in einer kleinen Linux-VM, und podman desktop verwaltet diese VM gleich mit. Unter Linux wird der Trick dagegen richtig sichtbar: hier trennen sich GUI und engine sauber voneinander.

Das klingt nach einer Nebensächlichkeit, ist aber der entscheidende Punkt für alles Weitere. GUI auf dem Notebook, engine auf dem server – diese Kombination ist ausgesprochen komfortabel. Man muss nur einmal verstanden haben, wie die Verbindung zustande kommt. Genau dahin kommen wir gleich.

podman desktop gegen cockpit – zwei Werkzeuge, zwei Philosophien

Wer container auf einem server im Blick behalten will, landet früher oder später bei dieser Frage: podman desktop oder doch lieber cockpit? Beide zeigen laufende container und pods. Beide lassen einen an Ports, Volumes und Umgebungsvariablen herumschrauben. Sie kommen aber aus komplett unterschiedlichen Richtungen.

cockpit: Verwaltung direkt auf der Maschine

cockpit ist ein browserbasiertes Administrations-Interface und läuft direkt auf dem server. Man ruft es im Browser auf und loggt sich ein. Neben den containern hat man dann gleich Storage, Netzwerk, Firewall, Benutzer, Dienste und Logs im selben Fenster. container sind dort nur ein Reiter unter vielen. Das Podman-Modul ergänzt ein viel breiteres System-Admin-Werkzeug. Kein Client nötig, kein extra Programm auf dem Notebook: der Browser reicht.

podman desktop: Werkzeugkasten für den Arbeitsplatz

podman desktop dreht den Spieß um. Es ist eine App für den Arbeitsplatz, die sich per Socket mit einer oder mehreren engines verbindet. Gebaut ist sie erkennbar für Leute, die nicht nur verwalten, sondern auch bauen. Eine GUI erstellt images aus einem Containerfile, inklusive Build-Log. Das fertige image lässt sich direkt in eine Registry schieben. Über einen Extension-Marktplatz rüstet man Compose-Unterstützung, kind, Lima und allerlei anderes nach. Und mehrere entfernte engines verwaltet man aus einer einzigen Oberfläche heraus. cockpit bleibt dagegen pro server ein eigener Browser-Tab.

Damit zur eigentlichen Empfehlung, die man sich merken kann. Läuft da ein dedizierter server ohne grafische Oberfläche? Und will man als Betreiber einfach nur seine Dienste am Laufen halten? Dann ist cockpit in den meisten Fällen die sinnvollere Wahl. Es sitzt direkt auf der Maschine und braucht keinen Client. Die container-Verwaltung ist dort in genau den Admin-Kontext eingebettet, in dem man sowieso unterwegs ist. podman desktop spielt seine Stärken erst beim Bauen von images aus. Oder wenn man mehrere Maschinen im Blick behalten muss. Oder wenn man lieber nativ statt im Browser arbeitet. Kurz: cockpit ist das Verwalter-Werkzeug, podman desktop das Entwickler-Werkzeug.

Per ssh auf den server – so kommt die Verbindung zustande

Kommen wir zum spannenden Teil, der Remote-Verbindung. Wichtig zu wissen: podman desktop bringt keine eigene SSH-Mechanik mit. Die Verbindungslogik läuft komplett über den lokalen podman-Client. Heißt konkret: auf dem Notebook muss podman selbst installiert sein, klassisch per dnf install podman oder apt install podman. Das gilt auch dann, wenn dort gar keine container laufen sollen. podman desktop liest anschließend nur die Verbindungen aus, die der Client kennt.

Auf dem server wiederum muss der passende Socket aktiv sein. Bei einer rootless-Umgebung sieht das so aus:

systemctl --user enable --now podman.socket

Danach legt man auf dem Notebook die Verbindung an. Der lokale Client baut den SSH-Tunnel zum entfernten Socket auf:

podman system connection add mein-server \
  --identity ~/.ssh/podman_remote \
  ssh://user@server/run/user/1000/podman/podman.sock

Ein SSH-Key ohne Passphrase-Abfrage macht das Ganze deutlich angenehmer; ed25519 ist die unkomplizierte Wahl. In podman desktop aktiviert man dann in der Podman-Extension die SSH-Verbindungen. Anschließend taucht der server in der Liste auf, samt seiner container und pods. Ein VPN liegt einfach als Netzwerk-Ebene darunter und muss lediglich den SSH-Verkehr durchlassen. Die podman-API selbst hängt nie offen im Netz. Verschlüsselung und Authentifizierung übernimmt SSH.

rootless oder rootful: der Klassiker unter den Stolperfallen

Über einen Punkt stolpert man garantiert einmal: die Trennung zwischen rootless und rootful. Der rootless-Socket (/run/user/1000/podman/podman.sock) und der rootful-Socket (/run/podman/podman.sock) führen komplett getrennte Welten. Getrennter Storage, getrennte container. Verbindet man sich rootless, sieht man nur, was der eigene User gestartet hat. Ein mal eben mit sudo hochgezogener pod landet dagegen im rootful-Bereich. Über die rootless-Verbindung ist er schlicht unsichtbar. Taucht ein pod partout nicht in der GUI auf, ist meist nicht die Verbindung kaputt. Man schaut nur in den falschen Namespace.

Das gilt genauso für pods, die als systemd-Dienst laufen. Ob man sich als user oder als root verbinden muss, hängt allein von der Unit ab. Eine rootless-Unit unter dem eigenen User braucht die rootless-Verbindung. Eine System-Unit unter root braucht entsprechend die rootful-Verbindung. Wie man pods sauber als Dienst mit Autostart und Update einrichtet, hatte ich im Artikel podman – pod automatisieren beschrieben. Wer das gelesen hat, weiß hier sofort, welchen Socket er ansprechen muss.

kubernetes: yaml, kube play und ein bisschen Cluster-Gefühl

podman kann bekanntlich mehr als nur einzelne container. Es versteht kubernetes-YAML, und genau das spiegelt sich in podman desktop wider. Über kube play lassen sich pods direkt aus einer YAML-Beschreibung starten. Dieselbe Datei könnte man später auch einem echten kubernetes-Cluster vorwerfen. Für den Homelab-Betrieb ist das ein netter Mittelweg: pods deklarativ beschreiben, ohne gleich einen kompletten Cluster hochzuziehen.

Wer es eine Nummer größer mag, holt sich über die Extensions einen echten Mini-Cluster ins Boot. kind läuft als Erweiterung – kubernetes-in-docker, funktioniert aber auch mit podman. Damit betreibt man lokal einen Test-Cluster und bedient ihn aus podman desktop heraus. Für reine container- und pod-Verwaltung ist das overkill. Zum Testen von kubernetes-Manifesten vor dem Produktivgang ist es dagegen Gold wert.

Ein kleiner Stolperstein am Rande, den ich in einem eigenen Beitrag auseinandergenommen habe: bei kube play zieht ein :latest-Tag beim Service-Neustart klammheimlich ein neues image. Die Details stehen im Artikel wenn der Service-Neustart heimlich ein Update zieht. Nur als Erinnerung, falls sich jemand über eine plötzlich andere Version wundert.

compose: die docker-compose.yml, aber mit podman drunter

Und was ist mit den ganzen docker-compose.yml-Dateien, die man über die Jahre angesammelt hat? Auch dafür gibt es einen Weg. podman desktop bindet Compose-Unterstützung über eine Extension ein. Multi-Container-Setups starten damit aus einer Compose-Datei heraus. In der GUI erscheinen sie als zusammengehörige Gruppe. Im Hintergrund arbeitet das über den compose-kompatiblen Weg von podman. Die vertraute Syntax bleibt also, die engine darunter ist eine andere.

Ganz ohne Sternchen ist das nicht. Nicht jede exotische Compose-Direktive verhält sich unter podman haargenau wie unter docker. An manchen Ecken merkt man der Sache ihre docker-Herkunft an. Für die typischen Homelab-Stacks aus ein paar Diensten funktioniert es aber erfreulich unaufgeregt. Bestehende Dateien muss man jedenfalls nicht neu schreiben, nur weil man von docker zu podman gewechselt ist.

Und was ist mit docker? Ein kurzer Seitenblick auf docker desktop

Weil die Frage garantiert kommt: ja, podman desktop kann auch mit docker reden. Läuft auf dem System eine docker-engine, erkennt podman desktop sie und zeigt deren container ebenfalls an. Die Oberfläche ist also nicht strikt auf podman festgenagelt. Sie stellt beide Welten gleichzeitig dar. Für alle mitten in der Migration von docker zu podman ist das ausgesprochen praktisch. Man muss nicht von heute auf morgen alles umstellen.

podman desktop und docker desktop im Vergleich

Der Vergleich zu docker desktop drängt sich auf, schließlich war das lange das Vorbild. Bei der reinen container-Verwaltung nehmen die beiden sich wenig. Oberfläche für container, images, Volumes und Logs hat docker desktop genauso. Der eigentliche Unterschied liegt woanders. docker desktop ist proprietär und für größere Unternehmen seit einigen Jahren kostenpflichtig lizenziert. podman desktop steht unter einer offenen Lizenz und ist schlicht kostenlos.

Dazu kommt ein architektonischer Unterschied. podman kommt ohne dauerhaft laufenden Hintergrund-Daemon aus und nimmt rootless-Betrieb von Haus aus ernst. Gerade auf servern und im Sicherheitskontext ist das ein Argument. Wer aus der docker-Welt kommt, findet sich in podman desktop trotzdem sofort zurecht. Der Umstieg fühlt sich weniger nach Bruch an als nach einem Motorwechsel bei gleichem Armaturenbrett.

Warum es andersherum nicht funktioniert

Wenn podman desktop docker verwalten kann – geht das eigentlich auch umgekehrt? Kann docker desktop eine podman-engine übernehmen? Kurz gesagt: nein. Der Grund dafür ist durchaus lehrreich. Die Kompatibilität zwischen den beiden Welten ist keine Einbahnstraße mit Gegenverkehr. Sie läuft ziemlich einseitig, und sie sitzt komplett auf der podman-Seite.

podman stellt von Haus aus einen docker-kompatiblen Socket bereit und gibt sich nach außen wie docker aus. Alles, was sonst mit docker spricht, kann deshalb ohne Umbau mit podman reden – die docker-CLI, Scripte, CI-Tools. Man zeigt sie per DOCKER_HOST einfach auf den podman-Socket. Die offiziellen Podman-Desktop-Docs zur Docker-Kompatibilität beschreiben das im Detail. Das ist aber die CLI- und API-Ebene, nicht docker desktop als Programm.

docker desktop selbst ist fest um seine eigene docker-engine herumgebaut, gebündelt in einer VM. Einen Schalter für eine fremde podman-engine bringt es nicht mit. podman desktop wurde dagegen von Anfang an für mehrere engines gleichzeitig entworfen. Etwas zugespitzt: docker merkt gar nicht, dass es mit podman redet. podman tut nur überzeugend so, als wäre es docker. Genau deshalb bringt podman desktop beide Welten unter einen Hut, während docker desktop in seiner eigenen bleibt.

tgz oder flatpak? Die Installationsfrage unter Linux

Bleibt die Frage, wie das Ding überhaupt aufs Notebook kommt. Auf der Projektseite stehen zwei Wege bereit: ein flatpak über Flathub und ein schlichtes tgz-Archiv. Beide stammen aus demselben Release. Das flatpak baut allerdings über eine eigene Pipeline auf Flathub-Seite. Die neueste Version kann dort also ein, zwei Tage später ankommen als im Archiv aus dem Release.

Das tgz ist kein Installer, sondern ein reines Anwendungsbündel: entpacken, Ordner nach /opt schieben, starten, fertig. Menüeintrag und Verknüpfung bastelt man sich allerdings selbst. Vor allem aber gibt es keinerlei Update-Mechanismus. Bei jeder neuen Version lädt man manuell herunter und ersetzt den Ordner. Beruhigend dabei: die Konfiguration liegt unter ~/.local/share/containers/podman-desktop/, nicht im Programmordner. Ein Update per Ordner-Austausch kostet also keine Einstellungen.

Das flatpak nimmt einem die Update-Pflege ab, ein flatpak update genügt. Dafür handelt man sich die bekannten Sandbox-Kompromisse ein. Der Zugriff auf ~/.ssh und den podman-Socket will über die Flatpak-Berechtigungen sauber freigegeben sein. Sonst findet die App die SSH-Identität für die Remote-Verbindung nicht. Unterm Strich: wer Updates nicht von Hand pflegen will, nimmt das flatpak. Wer die Sandbox partout nicht mag, greift zum tgz und lebt mit dem manuellen Aufwand.

Was ist denn nun besser?

Wie so oft gibt es die eine richtige Antwort nicht. podman desktop und cockpit lösen unterschiedliche Probleme, auch wenn sie sich bei container und pods überschneiden. Für den reinen Server-Betrieb ohne grafische Oberfläche ist cockpit meist der pragmatischere Weg. Das gilt vor allem, wenn jemand keine images bauen, sondern nur Dienste am Laufen halten will. Direkt auf der Maschine, im Browser, eingebettet in den restlichen System-Admin-Kram.

podman desktop ist dagegen das Werkzeug der Wahl, sobald man aktiv entwickelt und images baut. Auch für mehrere entfernte engines aus einer Oberfläche spricht einiges. Dasselbe gilt für bestehende docker- und compose-Setups. Die Client-Server-Architektur macht das Ganze erstaunlich flexibel: eine GUI auf dem Notebook, beliebig viele engines dahinter, sauber über SSH verbunden. Man muss nur einmal verinnerlichen, dass Oberfläche und container-Betrieb an verschiedenen Orten stattfinden. Dann fügt sich der Rest von selbst zusammen.