Podman v6.0.0 veröffentlicht

 (blog.podman.io)
1 Punkte von GN⁺ 4 시간 전 | 2 Kommentare | Auf WhatsApp teilen
  • Podman v6.0.0 ist ein Major Release, das die Erfahrung bei der Container-Verwaltung verfeinert und sowohl Modernisierungen der Kerninfrastruktur als auch Verbesserungen bei Sicherheit und Usability umfasst
  • Beim Networking erfolgt der Wechsel von slirp4netns und iptables hin zu Netavark, Pasta und nftables, um den Wartungsaufwand zu reduzieren und die Grundlage für künftige Funktionserweiterungen zu schaffen
  • Die experimentelle Funktion Pesto rootless port forwarding unterstützt den Erhalt der korrekten Source-IP bei rootless Containern in Custom Networks
  • Podman Machine verbessert die Usability für mehrere VM-Anbieter und ermöglicht es, die VM-Umgebung mit podman machine os update auf dem neuesten Stand zu halten
  • Quadlet, die Verarbeitung von Konfigurationsdateien, Docker-API-Kompatibilität und Befehlsausgaben wurden ebenfalls verfeinert, was die Verwaltung in Multi-User-Umgebungen und den Umstieg von Docker erleichtert

Was sich in Podman v6.0.0 geändert hat

  • Das aktuelle Release ist auf der GitHub-Release-Seite verfügbar und wird demnächst auch über Paketmanager verteilt

  • Modernisierung des Networkings

    • Umstellung von slirp4netns und iptables hin zu Netavark, Pasta und nftables
    • Der bereinigte Networking-Stack vereinfacht die Wartung und bildet die Basis für künftige Funktionserweiterungen
    • Experimentelle Unterstützung für Pesto rootless port forwarding ermöglicht den Erhalt der korrekten Source-IP bei rootless Containern in Custom Networks

  • Verbesserungen an Podman Machine

    • Die Usability wurde verbessert, damit mehrere VM-Anbieter reibungsloser genutzt werden können
    • Mit dem Befehl podman machine os update lässt sich die VM-Umgebung auf dem neuesten Stand halten
    • Weitere zugehörige Verbesserungen sollen in einem künftigen separaten Beitrag ausführlicher behandelt werden

  • Erweiterungen bei Quadlet

    • REST-API-Unterstützung wurde hinzugefügt
    • Die Nachverfolgung zugehöriger Dateien wurde verbessert, was die Verwaltung erleichtert
    • Die Funktionen von .volume-Units wurden erweitert
    • Zusätzliche Suchpfade zur Vereinfachung des Deployment-Packagings sind enthalten

Konfiguration und Docker-Kompatibilität

  • Die Verarbeitung von Konfigurationsdateien wurde geändert, sodass Administratoren Multi-User-Umgebungen reibungsloser und zuverlässiger verwalten können
  • Auch die Docker-Kompatibilität wurde verbessert
    • Die Unterstützung der Docker API wurde aktualisiert
    • Befehlsausgaben wurden verfeinert, um den Umstieg von Docker auf Podman zu erleichtern
  • Die vollständige Änderungsliste ist in den Podman v6.0.0 release notes zusammengefasst

Verwandte Beiträge

2 Kommentare

 
click 3 시간 전

Ich würde umsteigen, sobald podman compose brauchbar wird, aber ich habe keine Ahnung, wann das endlich der Fall sein wird.
Ich denke, dass man heutzutage docker run direkt nur noch für temporäre Container oder Testläufe verwendet; dass die Compose-Unterstützung nicht gut ist, halte ich für eine große Schwäche.
Wenn man umfangreiche Konfiguration und zuverlässiges Management braucht, ist es besser, einfach k8s zu verwenden.
Im Jahr 2026 liegt der Reiz von Docker oder Podman doch darin, dass man ohne die vielen Ressourcen-Definitionen von k8s den in einer App verwendeten Stack bequem in einer einzigen YAML-Konfigurationsdatei definieren kann.
Wenn man k8s-Kompatibilität in den Vordergrund stellt, ist es viel sinnvoller, einfach eine leichtgewichtige lokal laufende k8s-Implementierung wie k3s, minikube oder microk8s zu verwenden.
Ich glaube nicht, dass rootless das Problem ist.
 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • Ich verstehe nicht, warum Docker immer noch so viel populärer ist als Podman. Rein von der Implementierung her ist Podman eindeutig besser, und die neuen Netzwerkfunktionen sind eine willkommene Verbesserung

    • Der Hauptgrund dürfte sein, dass die Bereitstellung etwas umständlicher ist und aus mehr voneinander getrennten Schritten besteht. Besonders wenn man rootless arbeiten will – was man eigentlich tun sollte.
      Für Leute, die nicht primär unter Linux unterwegs sind, etwa Nachwuchsentwickler, die App-Containerisierung lernen, ist es ziemlich einschüchternd, mit systemd-Unit-Dateien oder kubelet-Konfigurationen umzugehen, ein dediziertes lokales Dienstkonto anzulegen und auch noch daran zu denken, linger zu aktivieren – verglichen damit, Docker zu installieren, eine docker-compose-Datei zu erstellen und auf „Start“ zu drücken.
      Ich verstehe, warum dieser Ansatz gewählt wurde, aber er ist ziemlich sperrig und wenig einsteigerfreundlich
    • fuse-overlayfs war spürbar langsamer als Dockers overlayfs-Konfiguration. Vielleicht gibt es eine Möglichkeit, das anders zu konfigurieren, aber ich habe es in letzter Zeit nicht mehr geprüft.
      Beim Bauen von ghostty mit Zig ist es unter Podman, glaube ich, mit einem vagen „unknown file“-Fehler abgebrochen; am Ende stellte sich heraus, dass fuse-overlayfs einige Attribute nicht unterstützte, die abgefragt werden sollten.
      Jedes Mal, wenn ich umsteigen will, bremsen mich solche zufälligen kleinen Probleme aus. Für einfache Anwendungsfälle nutze ich es
    • Als ich zuletzt nachgesehen habe, war podman compose nur oberflächlich so etwas wie docker compose. Dinge wie inotify scheinen auf Podman-Seite auch häufig zufällig kaputtzugehen.
      Ich würde Podman gern empfehlen, aber die Kompatibilität zu docker compose ist nicht gut, und wenn inotify auf Volumes fehlt, ist die Developer Experience ein zu großes Problem
    • Ein stärkerer Markenname dürfte ebenfalls ein Grund sein. Unter macOS war Docker Desktop intuitiver. Allerdings sind zuletzt sehr häufig Fehler aufgetreten: Datei-Mounts oder das Aufräumen von Netzwerkregeln schlugen zufällig fehl, oder es wurde plötzlich extrem langsam, sodass ich die VM neu starten musste.
      Podman unter macOS wirkt deutlich weniger ausgereift, und OrbStack ist die deutlich bessere Option.
      Unter Linux nutze ich ausschließlich Podman, und dort ist es sehr schnell. Trotzdem wirken die meisten Funktionen darauf ausgerichtet, in Kombination mit systemd Kubernetes zu ersetzen, während ausgerechnet die Unterstützung für docker compose instabil ist und TUI/UX hinter dem Original zurückbleiben
    • Ich habe Podman aus Kleinigkeiten aufgegeben. Eine war, dass es SELinux anders behandelt als Docker, sodass auf einem Standard-CentOS-System Änderungen an SELinux-Sicherheitslabels nötig waren. Das war für uns nicht akzeptabel.
      Ein weiteres Problem waren kleine Unterschiede zu Docker, die ausreichten, dass ein paketiertes Docker Compose nicht unverändert lief. Wenn ich auf Docker wechsle, läuft es sofort und ich kann meinen Arbeitstag fortsetzen; ich wollte keine Zeit darauf verwenden, das zu debuggen

  • Nachdem Docker Desktop wieder einmal zufällig angefangen hatte, riesige Mengen Speicher zu verbrauchen, bin ich zu Podman gewechselt, und es war wirklich so einfach wie installieren und auf die docker-compose.yml zeigen.
    Es waren keinerlei Änderungen nötig, und jetzt muss auch kein Daemon dauerhaft laufen. Großartige Software

    • colima war besser als Docker Desktop, und Orbstack war besser als colima. Dann habe ich smolvm, die MicroVM von https://smolmachines.com's, entdeckt
    • Wegen Dockers KI-Unsinn war für mich schließlich die Grenze überschritten, und ich habe versucht, zu Podman zu wechseln, bin aber auf ein paar Kompatibilitätsprobleme gestoßen. Das war vor ein paar Monaten, daher erinnere ich mich nicht mehr an die Details.
      Also habe ich Rancher Desktop ausprobiert, und abgesehen davon, dass ich den Namen ständig vergesse, funktionierte es einfach gut. Für alle, die so etwas brauchen, ist es eine weitere einfache Option

  • Quadlet mag ich wirklich sehr. Ich habe über Jahre hinweg rootless Container mit Hetzner, Ansible, SystemD und RockyLinux problemlos gehostet und diese Konfiguration als Template-Repository herausgezogen.
    [1] https://github.com/Mati365/hetzner-podman-bunjs-deploy

    • Nachdem ich meinen Homeserver von k3s auf quadlet umgestellt hatte, sank der Stromverbrauch um 8%

  • Mich interessieren Erfahrungen mit dem Umstieg von Docker auf Podman
    In meinem Homelab-/Automatisierungs-Setup gibt es viele Compose-Dateien, und genau das macht mir am meisten Sorgen

    • Ich bin vor etwa 15 Monaten von Docker auf Podman umgestiegen und habe nicht vor, je wieder zurückzugehen. Persönlich finde ich quadlet, also die systemd-Integration, wirklich großartig; damit lässt sich ein Bündel laufender Dienste – egal ob normale systemd-Services oder Container – deutlich einfacher überwachen
      Rootless-Ausführung ist ebenfalls sehr intuitiv, und Podman ist sehr schnell. Persönlich vermisse ich docker compose nicht besonders, aber ich verstehe, dass das Fehlen von docker compose für andere ein K.-o.-Kriterium sein kann. Das Compose-Plugin von Podman habe ich nie ausprobiert
    • Ich habe in meinem Homelab eine riesige docker-compose-Datei auf podman quadlet umgestellt. Soweit ich mich erinnere, hat es bei den ersten paar Diensten etwas gedauert, weil es im Vergleich zu Compose-Dateien nicht so viel Quadlet-Dokumentation und Beispiele gab; danach war es aber sehr einfach. Klare Empfehlung
      Das einzige Problem ist die Validierung. Es gibt keinen praktischen eingebauten Befehl zum Validieren von Quadlet-Dateien, und systemd warnt auch nicht, wenn die Generierung fehlschlägt. Man muss zuerst --dry-run ausführen, den gesamten Befehl in einen passenden Alias packen oder im Journal nach Fehlern schauen
    • Ich bin vor ein paar Jahren, vor 5.0, umgestiegen und habe nicht zurückgeschaut. Für Compose-Dateien lohnt es sich, quadlet in Betracht zu ziehen
      Für eine schnelle Umstellung kann man podman-compose direkt verwenden oder docker compose so konfigurieren, dass es auf den Podman-Socket zeigt[0]
      Es gibt auch podlet[1], das Compose-Dateien in native Quadlets umwandelt. Einfache bis mittelkomplexe Compose-Dateien verarbeitet es meist von selbst gut und sie laufen direkt. Es gibt auch Überlegungen, das als Bibliothek bereitzustellen, damit andere Tools Compose-Dateien transparent in Quadlets umwandeln können; ich hoffe daher, dass künftig mehr ähnliche Tools auftauchen
      Wenn man mit systemd-Unit-Dateien auch nur ein wenig vertraut ist, ist es nicht schwer, Quadlet-Dateien selbst zu schreiben. Die meisten Argumente von docker run oder podman run lassen sich direkt auf Quadlet abbilden. Sobald man sich statt YAML an das INI-Format gewöhnt hat, ist es einfach, anhand einer Compose-Datei ein äquivalentes Quadlet zu erstellen
      [0] https://www.redhat.com/en/blog/podman-docker-compose
      [1] https://github.com/containers/podlet
    • Ich bin vor ein bis zwei Jahren komplett auf rootless Podman umgestiegen. Bei einigen Containern gab es beim Lesen alter Daten Berechtigungsprobleme; Ursache war, dass sie mit einer anderen UID liefen
      Das waren tatsächlich alle Probleme, die ich hatte, und beim Umstieg von Docker mit Root-Rechten auf rootless Docker hätte es dasselbe Problem gegeben. Ich bereue nichts und werde definitiv nicht zurückgehen
    • Ich bin Podman so dankbar wie git
      Podman ist ausgereift und vernünftig. Wenn der Container von jemandem von su-Rechten abhängt, gebe ich nicht Podman die Schuld, sondern dieser Person

  • Was ich an Podman nicht mag, ist, dass es so tut, als sei es Docker-kompatibel, es aber kleine Unterschiede gibt, die einen später beißen. Nutzer von Docker-basierten Projekten versuchen, sie mit Podman auszuführen, und kommen am Ende zum Projekt und beschweren sich

    • Die meisten Unterschiede kamen nicht von der Socket-API, logischem Verhalten oder Unterschieden in der Kommandozeile. Sie entstehen vor allem daraus, dass Docker davon ausgeht, mit Root-Rechten zu laufen, während Podman das standardmäßig nicht tut
      Podman/Docker-Inkompatibilitäten zu beheben heißt daher meist, mit dieser Annahme umzugehen. Zum Beispiel fügt man dem Podman-Befehl ein paar Flags hinzu, um zu ändern, wie User-Namespace-Mappings zwischen Container und Host funktionieren
    • Ich nutze Podman seit drei Jahren auf Mac und Linux, und leider war dieses Problem immer real. Ich bin bereit, hartnäckig nach der Ursache zu suchen und Bugs zu melden, aber für viele Leute wird es einfach kaputt wirken
      Zuletzt stimmte bei Netavark das Verhalten beim Empfangen von Broadcast-Traffic auf veröffentlichten Ports nicht mit Docker überein
    • Stimmt. Das hat mich über Jahre von Podman abgehalten. Inzwischen sehe ich, dass es kluge Ideen hat, und wenn man RHEL nutzt, ist es die naheliegende Wahl; aber man sollte ehrlicher kommunizieren, dass eine Eingewöhnung nötig ist
      Besonders dann, wenn man von Docker mit Root-Rechten auf rootless Podman umsteigt

  • Ich frage mich, wie Podman heutzutage ist. Unter macOS nutze ich OrbStack, und das scheint deutlich schneller zu sein. Falls macOS 27 ähnlich wie WSL microVM-basierte, nativere und performantere Linux-Container hinzufügt, weiß ich nicht, wie sich das Spielfeld verändern wird

    • Zu macOS kann ich nicht viel sagen, aber unter Linux passt es für meine Zwecke reibungslos. Ein Punkt, auf den man achten sollte: Podman Compose verwendet standardmäßig docker-compose als Provider
      Den podman-compose-Provider habe ich nicht ausprobiert, und der Name unterscheidet sich leicht und verwirrend von Podman Compose. Podman Compose ist eine höhere Abstraktion über docker-compose oder podman-compose. Wenn nötig, kann Podman Container auch über die Docker-Engine ausführen
    • Gleiche Frage und gleiche Situation. Ich habe es unter MacOS ausprobiert und musste tief in Redhat-Foren eintauchen, um ein erstes Problem zu verstehen. Der Wechsel zu OrbStack war die naheliegende Wahl, aber aus Feature-Sicht gibt es klare Trade-offs

  • Quadlet und rootless Container sind die zwei großen Gründe, von Docker auf Podman umzusteigen

    • Rootless war der Grund, warum ich vor ein paar Jahren auf Podman umgestiegen bin. Es ist wirklich reibungslos, und ich muss mir keine Sorgen mehr über undurchsichtige Berechtigungsprobleme oder Service-Fehler machen

  • Podman ist gut, aber ich verstehe nicht, warum diese graue Schriftfarbe so ist. Sie sieht nicht gut aus, ist mit einem Kontrastverhältnis von 4,96:1 schwer zu lesen und erreicht nicht einmal WCAG-AAA-Niveau

  • Ich betreibe meinen Homeserver seit etwa zwei Jahren mit podman + quadlets und habe in den Release Notes ein paar Dinge gesehen, die man mitnehmen sollte
    podman quadlet list wurde in v5.6.0 hinzugefügt und listet Quadlets und deren Container auf
    podman system migrate --migrate-db ist ein in v5.8.0 hinzugefügtes Flag. Früher hatte ich eine Warnung gesehen, dass die Unterstützung für die Bolt-DB eingestellt wird, aber es gab kein Tool zur Migration auf sqlite; jetzt gibt es eines. Alternativ wird das automatisch erledigt, wenn man auf podman 6.0.0 aktualisiert

  • Ich würde gern von Erfahrungen mit Podman beim Bauen von Images für CRI-Runtimes statt Docker hören
    Wenn man ein Image mit Podman baut, läuft es dann unter cri-o, Docker und diversen anderen Runtimes?
    Da docker build sudo erfordert und das in agentenbasierten Workflows lästig wird, überlege ich, Images mit rootless Podman zu bauen.