Podman im Blick: die sicherere Docker-Alternative

 (betterstack.com)
6 Punkte von GN⁺ 2024-01-14 | 1 Kommentare | Auf WhatsApp teilen
  • Podman bietet ein Container-Ausführungserlebnis ähnlich wie Docker, arbeitet aber ohne Daemon und hebt sich dadurch bei Sicherheit und Audit-Trails ab
  • Docker nutzt eine Client-Server-Architektur rund um den Docker-Daemon, während Podman Container direkt in der Benutzersitzung erstellt, wodurch die Nachverfolgung des ausführenden Benutzers klarer wird
  • Da Podman dem OCI-Standard folgt, kann es Images wie hello-world, caddy, wordpress und mysql:5.7 aus Docker Hub ausführen; in vielen Fällen lässt sich der Befehl docker einfach durch podman ersetzen
  • Kurze Image-Namen verwenden nicht wie bei Docker automatisch Docker Hub als Standard, daher ist entweder ein vollständiger Image-Name, ein Alias oder die Einstellung unqualified-search-registries erforderlich
  • Multi-Container-Setups lassen sich mit Podman Compose, Pods und Kubernetes-Manifesten handhaben; eine eingebaute Produktions-Orchestrierung wie Docker Swarm gibt es jedoch nicht, dafür muss ein externes System wie Kubernetes verwendet werden

Wo sich Podman und Docker unterscheiden

  • Podman ist eine Open-Source-Container-Engine, die eine sicherere und leichtgewichtigere Alternative zu Docker sein soll
  • Sie führt Container ohne dauerhaft laufenden Daemon aus und hat eine Struktur, bei der Benutzer Container direkt verwalten
  • Die grundlegende Sicherheitsausrichtung setzt auf rootless Container, User Namespaces und einen vorsichtigeren Einsatz von Kernel-Capabilities
  • Durch die hohe Kompatibilität mit Docker-Images und dem Docker-Befehlsschema ist Podman eine praktische Option für Entwickler und Systemadministratoren, die eine Docker-Alternative suchen

Architektur und Audit-Trails

  • Docker verwendet ein Client-Server-Modell; Anfragen zur Container-Ausführung werden vom Docker-Client an den Docker-Daemon weitergegeben
    • Container-Prozesse werden nicht zu Kindprozessen der Benutzersitzung, sondern des Docker-Daemons
    • Wenn das Linux-Audit-System auditd Ereignisse von Container-Prozessen erkennt, kann die Audit User ID als unset statt als tatsächliche Benutzer-ID angezeigt werden
    • In dieser Struktur ist es schwierig, bösartige Aktivitäten einem bestimmten Benutzer zuzuordnen
  • Podman verwendet eine daemonlose Architektur
    • Jeder Container wird direkt über die Login-Sitzung des Benutzers erstellt
    • Die Prozessdaten des Containers behalten Benutzerinformationen bei
    • auditd kann die Benutzer-ID, die einen bestimmten Container-Prozess gestartet hat, genau erkennen und protokollieren
  • Je nach Image kann die Startgeschwindigkeit von Containern mit Podman bis zu 50 % höher sein als mit Docker

Verwaltung des Container-Lebenszyklus

  • Da Podman keinen Daemon hat, unterscheidet sich auch die Verwaltung des Container-Lebenszyklus von Docker
  • Unter Linux stützt sich Podman stark auf Systemd
    • Für die Umsetzung der Neustart-Policy von Containern, die mit dem Flag --restart always angegeben wurden, nutzt Podman einen systemd-Dienst namens podman-restart
    • Dieser Dienst startet die angegebenen Container nach einem Systemneustart automatisch neu
  • Podman stellt auch einen Befehl bereit, der aus einem laufenden Container eine Systemd-Service-Datei erzeugt
    • Wenn Container unter systemd-Verwaltung stehen, lassen sie sich leichter starten, stoppen und überprüfen
  • Docker erledigt solche Aufgaben innerhalb des Daemons

Orchestrierungsoptionen

  • In der lokalen Entwicklung definieren und verwalten Docker-Nutzer Multi-Container-Anwendungen meist mit Docker Compose
  • Podman unterstützt Compose-Dateien nicht nativ, bietet mit Podman Compose aber eine kompatible Alternative
    • In der Regel funktioniert sie mit vorhandenen docker-compose.yml-Dateien
    • Wer mit Docker Compose vertraut ist, kann bestehende Compose-Dateien weiterverwenden
  • Als nativen Ansatz von Podman lassen sich Pods verwenden
    • Das Konzept stammt aus Kubernetes
    • Mehrere Container können wie eine Einheit verwaltet werden
  • Für Produktions-Deployments hat Podman kein eingebautes Orchestrierungswerkzeug wie Docker Swarm
    • In diesem Fall ist ein externes Orchestrierungssystem wie Kubernetes die Alternative
    • Kubernetes kann mit Podman integriert werden, erfordert für korrektes Funktionieren aber möglicherweise zusätzliche Konfiguration und Einrichtung

Sicherheits-Defaults

  • Ein großes Risiko bei Container-Sicherheit ist ein Container Escape, bei dem das Hostsystem kompromittiert wird
  • Podman ist darauf ausgelegt, stärkere Standard-Sicherheitseinstellungen als Docker bereitzustellen
    • rootless Container
    • User Namespaces
    • seccomp-Profile
  • Auch Docker kann rootless Container, User Namespaces und seccomp-Profile verwenden, sie sind jedoch nicht standardmäßig aktiviert und erfordern oft zusätzliche Konfiguration
  • Die Standardkonfiguration von Podman führt rootless Container in isolierten User Namespaces aus und begrenzt so die Auswirkungen eines potenziellen Escapes
  • Die Docker-Standardkonfiguration führt Container-Prozesse als root aus, was im Fall eines Escapes ein höheres Risiko bedeutet
  • Auch die Standardwerte für Capabilities unterscheiden sich
    • Podman startet Container standardmäßig mit 11 Capabilities
    • Docker verwendet mit 14 Capabilities permissivere Standardeinstellungen
  • Beide Tools lassen sich stark absichern, doch Podman erfordert im Allgemeinen weniger Aufwand, um diesen Zustand zu erreichen

Auffällige Unterschiede im Funktionsvergleich

  • Podman unterstützt eine daemonlose Architektur und Systemd-Integration
  • Container können zu Pods gebündelt werden, außerdem kann Podman mit Kubernetes-YAML umgehen
  • Docker unterstützt Docker Swarm, Podman jedoch nicht
  • Die meisten übrigen Funktionen kann man auf beiden Seiten als weitgehend gleichwertig betrachten

Installation und Laufzeitumgebung

  • Podman kann wie Docker auf den wichtigsten Betriebssystemen ausgeführt werden
    • macOS
    • Windows
    • große Linux-Distributionen
  • Der wichtige Unterschied ist, dass Podman unter Linux nativ läuft, unter Windows und macOS jedoch eine virtuelle Maschine benötigt
  • Die Beispiele gehen von Debian-basierten Linux-Distributionen aus: Ubuntu, Mint und Debian
  • Für die Installation einer aktuellen Podman-Version ist eine relativ neue Distribution erforderlich
    • Zum Zeitpunkt der Erstellung ist die neueste Hauptversion von Podman 4.x
    • Ubuntu 22.04 LTS ist an Podman 3.x gebunden
    • Die Beispiele basieren auf Ubuntu 23.10
  • Die Beispielausgabe nach der Installation ist podman version 4.3.1 und bestätigt, dass der Befehl podman lokal ausgeführt werden kann

Docker-Images ausführen und OCI-Kompatibilität

  • Podman kann das hello-world-Image ausführen, das mit Werkzeugen aus dem Docker-Ökosystem gebaut wurde
  • Diese Kompatibilität besteht, weil sowohl Docker als auch Podman dem OCI-Standard (Open Container Initiative) folgen
    • OCI definiert die Spezifikation für Image-Formate und die Runtime-Spezifikation
    • Dadurch können unterschiedliche Container-Runtimes interoperabel sein
  • Die meisten Docker-Images und Container aus Docker Hub können mit Podman verwendet werden
  • Bestehende Workloads lassen sich ohne Änderungen zu Podman verschieben, oder man kann die Image-Bibliothek von Docker Hub nutzen
  • Auch wenn in der Ausgabe von hello-world „Hello from Docker!“ erscheint, ist die tatsächliche Ausführung durch Podman erfolgt
    • Weder Docker-Client noch Docker-Daemon sind am Ausführungsvorgang beteiligt

Umgang mit kurzen Image-Namen

  • Wenn kein vollständiger Image-Name angegeben wird, verwendet Docker docker.io, also Docker Hub, als Standard-Registry
  • Podman empfiehlt kurze Namen nicht und nimmt nicht automatisch eine Standard-Registry an
  • hello-world hat in shortnames.conf einen Alias und wird daher als docker.io/library/hello-world interpretiert
  • Wird ein Image ohne Alias wie caddy mit kurzem Namen ausgeführt, tritt folgender Fehler auf
    • Error: short-name "caddy" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
  • Es gibt drei Lösungswege
    • Einen vollständigen Image-Namen verwenden und zum Beispiel docker.io/library/caddy explizit angeben
    • In registries.conf einen Abschnitt [aliases] hinzufügen und mit "caddy"="docker.io/caddy" einen Alias definieren
    • unqualified-search-registries=["docker.io"] setzen, damit kurze Namen in Docker Hub gesucht werden
  • Benutzerspezifische Einstellungen können in $HOME/.config/containers/registries.conf liegen
    • Diese Datei hat Vorrang vor /etc/containers/registries.conf
    • Sie kann ohne Root-Rechte konfiguriert werden und passt dadurch besser zum rootless Ansatz
  • Wenn Podman als Docker-Ersatz genutzt werden soll, ist die Einstellung unqualified-search-registries langfristig bequemer als Aliasse

Private Registries verwenden

  • Podman kann wie Docker private Registries verwenden
  • Ein Beispiel mit einem Docker-Hub-Konto folgt diesem Ablauf
    • In Docker Hub ein Access Token erstellen
    • Die Beschreibung auf Podman tutorial und die Berechtigung auf Read & Write setzen
    • Ein private repository erstellen
    • Mit podman login docker.io einloggen
  • Wenn docker.io der erste Eintrag in unqualified-search-registries in registries.conf ist, kann er weggelassen werden; es ist jedoch Best Practice, die Registry explizit anzugeben
  • Wenn keine Registry angegeben wird, schlägt podman login mit folgendem Fehler fehl
    • Error: no registries found in registries.conf, a registry must be provided
  • Nach dem Login kann man das hello-world-Image in ein private repository pushen, das lokale öffentliche Image löschen und anschließend einen Container mit dem Image aus dem private repository ausführen
  • Ohne gültige Login-Zugangsdaten treten beim Pull eines privaten Images Fehler wegen Zugriffverweigerung und erforderlicher Authentifizierung auf
  • Der auffällige Unterschied bei der Nutzung privater Registries ist, dass podman statt docker vorangestellt wird; Podman kann mit weit verbreiteten private Registries verwendet werden

Multi-Container-Ausführung mit Podman Compose

  • Wenn mehrere Container als eine Einheit ausgeführt werden sollen, bietet Podman mehrere Optionen
    • Podman Compose
    • Pods
    • Kubernetes-Manifeste
  • Das Beispiel verwendet Podman Compose, um WordPress und MySQL auszuführen
  • Podman Compose ist ein Community-getriebenes Tool, das die Compose specification implementiert und in Podman integriert ist
  • Es hängt von Python 3 ab; im Beispiel wird es mit pipx installiert
    • Die Beispielausgabe der Installation lautet podman-compose 1.0.6
    • Die verwendete Podman-Version ist 4.3.1
  • Wenn pipx in $HOME/.local/bin installiert wird, befindet sich dieser Pfad möglicherweise nicht in $PATH
    • Mit pipx ensurepath kann der Pfad hinzugefügt werden
    • Danach muss ein neues Terminal geöffnet oder die Shell-Konfigurationsdatei neu eingelesen werden

Beispiel mit WordPress und MySQL

  • Das Beispiel definiert in einer .env-Datei Datenbankbenutzer, Passwort und Namen und konfiguriert WordPress- und MySQL-Dienste über docker-compose.yml
  • Beim Ausführen von podman-compose up -d analysiert Podman Compose die Datei docker-compose.yml
  • Verarbeitung des Dienstes wordpress
    • Das erforderliche external volume wird gesucht und, falls nicht vorhanden, erstellt
    • Das passende network wird gesucht und, falls nicht vorhanden, erstellt
    • Der Container wordpress wird ausgeführt
    • Wenn kein lokales Image vorhanden ist, wird wordpress:latest aus der konfigurierten Registry docker.io geholt
  • Verarbeitung des Dienstes db
    • Das Volume podman-tutorial_db wird erstellt
    • Das vorhandene Netzwerk wird geprüft
    • Der Container mysql:5.7 wird ausgeführt
    • Wenn kein lokales Image vorhanden ist, wird es aus Docker Hub geholt
  • Nach dem Start ist die WordPress-Installationsseite unter localhost:8080 erreichbar
  • Die Ausgabe von podman ps zeigt, dass die Container wordpress und db laufen
    • Für wordpress ist der Port als 0.0.0.0:8080->80/tcp gemappt
    • db läuft mit dem Image mysql:5.7
  • In der Image-Liste erscheinen docker.io/library/wordpress:latest und docker.io/library/mysql:5.7
  • In der Netzwerk-Liste erscheinen das Standardnetzwerk podman und das von Podman Compose erstellte Netzwerk podman-tutorial_default
    • podman-tutorial_default wird erstellt, um die in docker-compose.yml definierten Container von anderen Containern auf demselben System zu isolieren
  • In der Volume-Liste erscheinen podman-tutorial_db und podman-tutorial_wordpress
  • podman-compose down stoppt und entfernt die Container, behält aber Netzwerke und Volumes bei
    • Zum Entfernen von Volumes verwendet man podman volume rm
    • Zum Entfernen von Netzwerken verwendet man podman network rm
  • Die Befehle sind nahezu identisch mit Docker und Docker Compose; der Unterschied besteht darin, statt docker und docker-compose podman und podman-compose einzugeben

Entscheidungskriterien

  • Podman ist eine praktische Alternative zu Docker für das Ausführen von Container-Workloads
  • Es kann die meisten Aufgaben erledigen, die Docker beherrscht, und hat den Vorteil, keinen Hintergrund-Daemon zu benötigen
  • Podman bietet auch Funktionen, die Docker nicht hat
    • Arbeit mit Kubernetes-Manifest-Dateien
    • Organisation einzelner Container in Pods
  • Wenn eine leichtgewichtigere und sicherere Lösung für Container-Management benötigt wird, kann Podman die bessere Wahl sein
  • Wenn ein starkes Ökosystem und breite Community-Unterstützung Priorität haben, kann Docker besser passen
  • Als weiterführende Quellen können die offizielle Podman-Website, die Dokumentation und die Community herangezogen werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-14
Hacker-News-Kommentare

  • Es war gut, als Podman systemd-Unit-Dateien unterstützte. Damals konnten nicht nur Container, sondern auch ganze Pods per systemd automatisch gestartet und aktualisiert werden
    Dann wurde diese Funktion entfernt und stattdessen Quadlet vorangetrieben. Einzelne Container lassen sich als Unit-Dateien abbilden, für Pods muss man aber Kubernetes-Cluster-Definitionen verwenden
    Dazu kommt, dass Container im Gegensatz zu Docker SELinux-Richtlinien befolgen, weshalb ich oft Probleme hatte, auf gemappte Verzeichnisse zuzugreifen
    Am Ende ist mir unklar, was Podman eigentlich von einem will. Soll man Kubernetes nutzen? Keine logischen Pfade mappen und stattdessen nur dedizierte Verzeichnisse anlegen?

    • Ich hatte meine Infrastruktur bereits in docker-compose.yml definiert und habe dann entdeckt, dass podman-compose eine kaum dokumentierte Funktion zum Erzeugen von systemd-Units hat
      Diese Funktion nutzt nicht die inzwischen eingestellte Podman-Funktion, sondern schreibt die Unit-Dateien direkt, was für mich deutlich runder war als der bisherige Podman-Ansatz
      Aktiviert wird das mit $ podman-compose systemd -a create-unit, und die Registrierung der systemd-Units erfolgt mit $ podman-compose systemd -a register, $ systemctl --user enable --now "podman-compose@$PROJECT_NAME"
      Updates werden mit $ podman-compose pull und danach $ systemctl --user restart "podman-compose@$PROJECT_NAME" eingespielt. $PROJECT_NAME ist normalerweise der Verzeichnisname
      Wer nachsehen will: Der Quellcode der Funktion ist hier: https://github.com/containers/podman-compose/blob/f6dbce3618...
      Ich nutze zwar noch podman 4.3.1, aber es ist kein Grund ersichtlich, warum das in neueren Versionen nicht mehr funktionieren sollte
    • Dass „Container im Gegensatz zu Docker SELinux-Richtlinien befolgen“, ist eher ein Bug von Docker. Wenn ein System nicht für SELinux eingerichtet ist, sollte man das abschalten
      Und die systemd-Dateien, die podman-generate-systemd erzeugte, liefen am Ende im Wesentlichen nur auf "podman start containername" hinaus, also kann man sie auch leicht selbst schreiben. Im Gegensatz zu etwas wie docker-compose sind Container dabei aber fast eine Blackbox
      Der Vorteil von Quadlet ist, dass Container-Definitionen in .container-Dateien deklariert werden. Früher musste man die podman-run-Kommandozeile von Hand in eine systemd-Unit schreiben; in dieser Hinsicht ist Quadlet eine deutliche Verbesserung und kann auch eine Alternative zu docker-compose sein. Natürlich mit eigenen Vor- und Nachteilen
    • Ich bin seit Langem Fan, stimme hier aber zu
      Jedes Mal, wenn ich podman generate systemd [...] ausführen will, werde ich wieder daran erinnert, dass es diesen Wechsel gegeben hat
      Dass ich das nicht oft merke, liegt nur daran, dass ich mir dafür selbst eine brauchbare Ansible-Rolle gebaut habe
      Trotzdem wirkt es stark so, als habe Podman die Richtung verloren. Wenn man sich ohnehin schon auf das Pflegen von Unit-Dateien und das Modellieren von Beziehungen eingelassen hat, sollte man einfach den Generator weiter nutzen dürfen. Ob Quadlet oder die Behauptung, das sei besser, interessiert mich nicht
    • Wenn man sich nicht mit SELinux beschäftigen will, kann man in containers.conf Folgendes ergänzen: [containers] label=false
      Wenn einem das Standard-Sicherheitsniveau von Podman nicht gefällt, gibt es meist eine Möglichkeit, es abzuschalten
    • Ich bin kürzlich zu NixOS gewechselt, und dort wird alles, auch Container, systemd-zentriert behandelt
      Dieses Modell war sehr intuitiv, erforderte aber viel manuelle Migration, um es auf Docker Compose anzuwenden
      Deshalb habe ich ein Tool gebaut, das Compose-Dateien in NixOS-Konfigurationen umwandelt, damit sie nativ interpretiert und verwaltet werden können: https://github.com/aksiksi/compose2nix

  • Es gibt einen entscheidenden Vorteil von Podman gegenüber Docker, der fast nie erwähnt wird: Docker zerstört die Netzwerkkonfiguration
    Docker zusammen mit KVM-VMs und Bridges zu betreiben, ist ein Albtraum, während Podman sich schon mit den Standardeinstellungen viel besser einfügt
    Es ist auch oft vorgekommen, dass VPNs durch Docker kaputtgingen oder Docker selbst durch VPNs gestört wurde. Ich weiß nicht genau, wie Podmans Networking intern funktioniert, aber es scheint zumindest so entworfen zu sein, dass es andere Aufgaben nicht behindert. Das könnte ich über Docker niemals sagen

    • Für mich ist Buildah die eigentliche Kernfunktion. Es kann auch gut mit Docker funktionieren, gehört aber eher in dieselbe Werkzeugfamilie wie Podman
      Dockerfile ist meiner Meinung nach kompletter Müll. Bestehende Sprachen reichen völlig aus, und ich hasse es, wenn „gelangweilte Entwickler“ noch ein DSL oder gleich eine neue Programmiersprache erfinden. Besonders schlimm ist es bei YAML; hier ist es zwar kein YAML, aber Dockerfile ist ein hervorragendes Beispiel dafür, warum man mit so etwas aufhören sollte
      Wenn man sich Buildah ohne bud ansieht, wird klar warum. Sobald der Anwendungsfall auch nur leicht vom Standardpfad abweicht, kann man statt eines nervigen, halbgar gebastelten DSL einfach Bash, Fish oder was auch immer verwenden
      Solche schlechten Entscheidungen ziehen sich durch das gesamte Docker-Ökosystem. DCS und dessen ständig unfertiger Ersatz sind Beispiele dafür. Statt etablierte Signaturprotokolle wie Cosign zu nutzen, wollte man ein komplexes System bauen, das schwer zu automatisieren ist und besonders beim Schlüsseltausch Probleme macht
    • Podman ist kostenlos. Docker ist auch kostenlos, aber Docker ohne Docker Desktop zu installieren ist lästig
    • Ich betreibe Docker und KVM-VMs mit Bridges gerade jetzt gleichzeitig, und es läuft einfach problemlos. Seltsam

  • Es ist erfreulich, dass Podman mehr Verbreitung findet. Zu viele Tools gehen davon aus, dass Nutzer einfach zur sudo docker-Gruppe hinzugefügt werden, und scheitern deshalb bei sicherheitsbewussten Docker-Setups, die nicht blind Root-Zugriff geben

    • Ich finde es immer wieder ironisch, dass diese futuristische Welt aus Serverless und Containern letztlich darauf aufbaut, alles Mögliche als Root auszuführen

  • Als zertifizierter RHEL-Ingenieur nutze ich Podman schon seit einigen Jahren.
    Ehrlich gesagt gefällt es mir für den privaten Einsatz mit Containern ziemlich gut. Bei der Arbeit stellen wir Entwicklern aber weiterhin Docker bereit. Bisher gab es keine Möglichkeit, Entwicklern etwas anzubieten, das an die Einfachheit von docker compose heranreicht.
    Beim Erstellen von Container-Images nutzen wir in CI-Pipelines zwar auch buildah, aber aus Sicht der Entwickler als Endanwender ist docker compose nach wie vor dominant.

  • https://www.techrepublic.com/article/how-to-fix-the-docker-a...
    Wegen dieses Problems wäre ich fast betroffen gewesen.

    • Docker greift schon mit der Standardkonfiguration und -installation in iptables ein. Das war immer besonders ärgerlich, wenn man stattdessen die neueren nftables nutzen wollte.
    • Wegen Docks unsicherer Standardentscheidungen hat sich in einen privat selbstgehosteten Container aus einem GitHub-Projekt, der eigentlich nur für VPN-Nutzung gedacht war, ein Kryptominer eingeschlichen. Darüber ärgere ich mich immer noch.
    • Apropos Netzwerkprobleme: In einer verschachtelten Konfiguration gab es ein großes Problem, bei dem der Speicher für Netzwerkgeräte ausging und ein Systemneustart nötig wurde. Sonst wäre es eine großartige lxc-Alternative gewesen, was wirklich schade ist.

  • Ich verstehe immer noch nicht ganz, warum Red Hat so viel in die Entwicklung einer Docker-Alternative investiert, aber das Ergebnis gefällt mir wirklich sehr.
    Podman kann fast alles, was Docker kann, hat dabei aber zusätzliche Funktionen wie Pods oder ist in der Funktionsweise selbst oft besser, etwa durch den daemonlosen Ansatz bei der Container-Erstellung.
    Das größte Problem für normale Entwickler dürfte Docker Compose sein, aber wenn man einfache Compose-Dateien nutzt, gibt es das podman-compose-Skript, das mit der Docker-Compose-Spezifikation kompatibel sein will.
    Es gibt auch eine Möglichkeit, Podman als Backend für docker-compose zu verwenden [1]. Insgesamt sehe ich 2024 keinen Grund, auf einer Linux-Maschine Docker zu benutzen. Wie Podman auf macOS oder Windows ist, weiß ich allerdings nicht.
    [1] https://www.redhat.com/sysadmin/podman-docker-compose

    • Red Hat hat ursprünglich mit Docker zusammengearbeitet, um verschiedene schon früh sichtbar gewordene Probleme zu beheben, etwa systemd-Kompatibilitätsprobleme in bestimmten Anwendungsfällen, aber dabei kam nicht viel heraus.
      Nimmt man dazu, dass Docker früher wie heute besonders viele Sicherheitsprobleme hat und dass Docker-artige Container und Images unter Entwicklern extrem weit verbreitet sind, blieb nichts anderes übrig, als eine eigene Implementierung zu bauen, die besser zum Wertversprechen und Ansatz von RHEL passt.
      Docker kann zum Beispiel rootless betrieben werden, nutzt das aber immer noch nicht als Standard. In gehärteten Umgebungen sind sowohl die docker-Benutzergruppe als auch der Betrieb ohne Gruppe für viele Einsatzfälle aus Sicherheitsgründen schwer akzeptabel.
      Frühes Docker hat sich zu wenig darum bemüht, unprivilegierten Containern wenigstens minimale Isolation zu geben, und selbst nachdem die Probleme bekannt waren, dauerte ihre Behebung lange. Auch die Interaktion mit Firewalls, Netzwerkregeln und SELinux ist problematisch. Deshalb ist ein Docker-Verbot in Unternehmen mit dedizierten Linux-Systemadministratoren und starkem Sicherheitsfokus nicht ungewöhnlich.
    • Ich nutze Podman unter Windows. Docker auf Windows war für mich eine endlose Folge von Ärger und Frust.
      Schon am Anfang drängt die gesamte Dokumentation aggressiv in eine GUI-Installation, die alles andere als benutzerfreundlich ist. Sie startet beim Booten schwere Prozesse, verlangt aus irgendeinem Grund die Registrierung für ein Cloud-Konto und nervt dann noch damit, dass man das sogenannte Open-Source-Produkt nicht beruflich nutzen solle.
      Die nicht unterstützte Alternative einer „nur Kommandozeilen-Docker“-Installation war unnötig kompliziert und unterstützte, als ich es zuletzt probierte, die meisten WSL-VMs im Auslieferungszustand nicht einmal.
      Podman dagegen ist einfach winget install podman und stört nicht. Die Podman-VM startet nur dann, wenn ich tatsächlich Container laufen lassen muss, und wenn nicht, verhält sich das System wie zuvor.
      Wenn man etwas mit Compose-Dateien starten muss, gibt es podman-compose. Es kann mit ungewöhnlichen Setups eventuell nicht alles abdecken, aber für meine Zwecke hat es gut funktioniert.
      Was Podman nicht richtig kann, ist im Wesentlichen die VS-Code-Integration, aber der Aufwand, Docker unter Windows halbwegs zuverlässig zum Laufen zu bringen, ist viel nerviger, als ein paar VS-Code-Shortcuts zu verlieren, also ist das kein echtes Problem.
      Ich empfehle Podman als Standardlösung für Container unter Windows. Einen Grund für Docker sehe ich dort nur, wenn die Firma die Kosten übernimmt oder man komplexe Compose-Konfigurationen hat; in solchen Fällen könnte es sich ohnehin lohnen, auf Kubernetes umzusteigen.
    • Red Hat investiert deshalb, weil Docker so weit davon entfernt ist, wie Dinge unter Linux üblicherweise funktionieren.
      Es macht Dinge kaputt, hat sich jahrelang mit rootless schwergetan, und Vendor Lock-in gehört ebenfalls dazu.
      Podman ist offen, standardkonform und passt gut zu Kubernetes. Nur weil Docker zuerst im Markt für einfache Container da war, haben Entwickler absurd viel Aufwand in Docker investiert.
    • Ich hoffe, dass die Sichtweise „Unter Linux gibt es keinen Grund, Docker zu benutzen“ nicht zur Mehrheitsmeinung wird. Docker ist nicht Red Hat/IBM.
      Wenn Docker verschwindet, kann Red Hat seine Unternehmensagenda noch härter durchdrücken.
      Podman hat zwar Vorteile, aber auf dem Weg, alles von Docker zu ersetzen, hat Red Hat auch einiges nicht gut umgesetzt.
      Betrachtet man die Geschichte, wie Red Hat sich dem Container-Bereich genähert hat, haben sie zum Teil Zeit und Energie verschwendet, statt zu vielen Projekten beizutragen und sie zu verbessern.
      Red Hat ist kein Unternehmen mit einer Agenda, das einfach das Richtige für seine Kunden tun will; man sollte also im größeren Bild darüber nachdenken, was es wirklich anstrebt.
    • Ich nutze Podman auf macOS. Insgesamt war die Erfahrung besser als mit Docker, besonders bei der Unterstützung älterer macOS-Versionen.
      Der einzige größere Nachteil von Podman auf macOS ist, dass Container nicht das Host-Netzwerk verwenden können. Allerdings ist das nur selten nötig.
      Wenn man jedoch im Container mit Netzwerkthemen experimentiert und dabei denselben Hostnamen und dieselbe IP-Adresse wie auf dem Host behalten möchte, sollte man das im Hinterkopf behalten. Trotzdem kann man diese Einschränkung in der Praxis umgehen.

  • Der Security-first-Ansatz und die entsprechenden Entscheidungen wirken gut. Mir gefällt, dass die Standardeinstellungen sicher sind und dass es mit docker compose funktioniert.
    Ich frage mich allerdings, ob Podman, falls es einmal populär genug wird, irgendwann bei Befehlen und dem yml-Format einen eigenen Weg gehen wird. Im Moment wirkt es wie ein Tool, das sich auf Docker und das Docker-Compose-Dateiformat stützt.
    Es wäre gut, wenn Podman eine Alternative zu Swarm hätte. Derzeit wirkt es so, als würde Kubernetes nur als Krücke genutzt, weil eine leichtere Orchestrierung fehlt.
    Ein Team, das Sicherheit ernst nimmt, könnte vielleicht einen vernünftigen und einfachen Weg schaffen, Container in kleinerem Maßstab zu betreiben, ohne sich wie in einem Promotionsstudium tief in Kubernetes einarbeiten zu müssen, das schon in der Standardkonfiguration nicht sicher ist. Dabei könnte die Kompatibilität mit dem Docker-Compose-Format erhalten bleiben.

  • Ich stimme zu, dass rootless Container und isolierte Namespaces wichtige Sicherheitsfunktionen sind. Aber das geht auch mit Docker rootless und ist nicht kompliziert. Man muss es einfach entsprechend konfigurieren.
    Ich habe einmal einen Beitrag darüber geschrieben, wie man Mastodon mit allen derzeit möglichen Best Practices in Docker rootless einrichtet [1]
    Ein Vorteil dabei, bei Docker zu bleiben, ist die bessere Zugänglichkeit. Es gibt mehr Community und Blogs, docker compose-Konfigurationen sind weit verbreitet, und auch im Umfeld gibt es mehr Leute, die sich damit auskennen
    Letztlich führen sowohl Podman als auch Docker Prozesse in isolierten Namespaces des Hosts aus
    [1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...

  • Ich möchte nicht missverstanden werden. Podman ist großartig und ich nutze es inzwischen statt Docker, aber ich habe anfangs damit angefangen, weil ich dachte, es sei einfach ein schlichter Docker-Ersatz, und wurde dann von UID/GID-Mapping, SELinux-Richtlinien und fehlenden DNS-Einstellungen ziemlich hart erwischt
    Als ich versucht habe, Probleme zu beheben und system migrate auszuführen, habe ich mir auch mehrfach die gesamte Konfiguration zerschossen. Es gibt ein eigenes System rund um Sicherheits-ACLs, ID-Mapping und Labels
    Wenn man unter dem Home-Verzeichnis chmod -R ausführt, kann das wahrscheinlich alle Container lahmlegen
    Mit dem Ergebnis bin ich zufrieden, aber von einer Lösung, die wie Docker „einfach funktioniert“, war es weit entfernt. Seit ich damit angefangen habe, wurde es vermutlich deutlich verbessert

    • Ich habe dieses Jahr damit angefangen, um verschiedene Entwicklungsumgebungen zu isolieren und zu verhindern, dass npm zu leicht auf die gesamte Entwicklungsmaschine zugreift
      Für mich war es einfacher zu nutzen als Docker. Es wirkt so, als wäre es inzwischen besser als die oben geschilderte Situation

  • Im großen Bild wirkt Podman wie das Linux von früher: unverzichtbar
    Selbst wenn es nur sehr wenige Menschen nutzen, verhindert schon allein seine Existenz, dass seine viel größeren proprietären Geschwister schreckliche Dinge tun können
    Mit „Linux von früher“ ist hier nicht gemeint, dass Linux unwichtiger geworden wäre, sondern im Gegenteil, dass es heute noch unverzichtbarer und zentraler geworden ist

    • Wenn mit den „viel größeren proprietären Geschwistern“ Docker gemeint ist, ist das etwas ironisch. Denn auch RedHat und IBM tun im Open-Source-Bereich viele schlechte Dinge