Sortie de Podman v6.0.0

• Podman v6.0.0 est une version majeure qui affine l’expérience de gestion des conteneurs, en combinant une modernisation de l’infrastructure cœur avec des améliorations de sécurité et d’ergonomie
• Le réseau passe d’une approche centrée sur slirp4netns et iptables à une base Netavark, Pasta et nftables, afin de réduire la charge de maintenance et de préparer les futures évolutions
• La fonctionnalité expérimentale Pesto rootless port forwarding prend en charge la préservation correcte de l’IP source pour les conteneurs rootless sur des réseaux personnalisés
• Podman Machine améliore l’ergonomie avec plusieurs fournisseurs de VM, et podman machine os update permet de maintenir l’environnement VM à jour
• Quadlet, le traitement des fichiers de configuration, la compatibilité avec l’API Docker et la sortie des commandes ont aussi été affinés, ce qui facilite la gestion multi-utilisateur et la transition depuis Docker

---

Ce qui change dans Podman v6.0.0

• La dernière version est disponible sur la page des releases GitHub et devrait bientôt arriver dans les gestionnaires de paquets

• Modernisation du réseau

  • Transition de slirp4netns et iptables vers Netavark, Pasta et nftables
  • Cette pile réseau rationalisée simplifie la maintenance et sert de base aux futures fonctionnalités
  • La prise en charge expérimentale de Pesto rootless port forwarding permet de préserver correctement l’IP source pour les conteneurs rootless sur des réseaux personnalisés

• Améliorations de Podman Machine

  • L’ergonomie a été améliorée pour gérer plus fluidement plusieurs fournisseurs de VM
  • La commande podman machine os update permet de maintenir l’environnement VM à jour
  • D’autres améliorations associées seront présentées plus en détail dans un article ultérieur

• Extensions de Quadlet

  • Ajout de la prise en charge de l’API REST
  • Le suivi des fichiers associés a été amélioré pour en faciliter la gestion
  • Les fonctionnalités des unités .volume ont été étendues
  • Des chemins de recherche supplémentaires ont été ajoutés pour faciliter le packaging des distributions

Configuration et compatibilité Docker

• Le traitement des fichiers de configuration a changé, ce qui permet aux administrateurs de gérer les environnements multi-utilisateurs de façon plus fluide et plus fiable
  • Les détails sont disponibles dans Podman 6 configuration file changes
• La compatibilité Docker a également été améliorée
  • La prise en charge de l’API Docker a été mise à jour
  • La sortie des commandes a été affinée, ce qui facilite la transition de Docker vers Podman
• La liste complète des changements est récapitulée dans les notes de version de Podman v6.0.0

[click]

Je compte passer à Podman quand podman compose deviendra vraiment utilisable, mais impossible de savoir quand ce sera le cas.
De nos jours, j’ai l’impression qu’exécuter directement avec docker run, c’est surtout pour des conteneurs temporaires ou des tests, donc un support limité de Compose me semble être un gros point faible.
Quand on a besoin d’une configuration verbeuse et d’une gestion rigoureuse, autant utiliser k8s.
En 2026, l’attrait de Docker ou de Podman, c’est justement de pouvoir définir toute la stack utilisée par une application dans un seul fichier yml, simplement, sans avoir à gérer les multiples définitions de ressources de k8s.
Et si l’argument mis en avant est la compatibilité avec k8s, il vaut largement mieux utiliser une implémentation légère de k8s qui tourne en local, comme k3s, minikube ou microk8s.
Je ne pense pas que le problème soit le rootless.

[GN⁺]

Avis sur Hacker News

• Je ne comprends pas pourquoi Docker reste encore bien plus populaire que Podman. Si on regarde l’implémentation, Podman est clairement meilleur, et les nouvelles fonctions réseau sont aussi une amélioration bienvenue

  • La raison principale est sans doute que le déploiement est un peu plus fastidieux et comporte davantage d’étapes séparées. C’est particulièrement vrai si on veut passer en rootless, ce qu’il faudrait d’ailleurs faire
    Pour quelqu’un qui n’est pas d’abord orienté Linux, par exemple un développeur débutant qui apprend à conteneuriser une application, devoir gérer des fichiers d’unité systemd ou la configuration de kubelet, créer un compte de service local dédié et penser à activer linger est bien plus intimidant que d’installer Docker, créer un fichier docker compose et cliquer sur « start »
    Je comprends pourquoi cette approche a été choisie, mais elle reste assez rustique et peu accueillante
  • fuse-overlayfs était sensiblement plus lent que la configuration overlayfs de Docker. Il y a peut-être une façon de le reconfigurer, mais je n’ai pas revérifié récemment
    En compilant ghostty en Zig, il me semble que ça cassait dans Podman avec une erreur vague du type « unknown file », et au final j’ai découvert que fuse-overlayfs ne prenait pas en charge certains attributs qu’il essayait de vérifier
    Chaque fois que j’essaie de migrer, ce sont ce genre de petits problèmes aléatoires qui finissent par me bloquer. Je l’utilise quand même pour des usages simples
  • La dernière fois que j’ai vérifié, podman compose n’avait qu’une ressemblance de façade avec docker compose. Même des choses comme inotify semblaient aussi casser souvent de manière aléatoire côté Podman
    J’aimerais recommander Podman, mais la compatibilité avec docker compose n’est pas bonne, et si inotify manque sur les volumes, l’expérience développeur en souffre trop
  • Un nom de marque plus fort y est sans doute aussi pour quelque chose. Sur macOS, Docker Desktop était plus intuitif. Cela dit, ces derniers temps, il est devenu extrêmement sujet aux erreurs, et le nettoyage des montages de fichiers ou des règles réseau échouait aléatoirement, ou bien tout devenait soudainement très lent au point qu’il fallait redémarrer la VM
    Podman sur macOS donne l’impression d’être bien moins abouti, et OrbStack est une bien meilleure option
    Je n’utilise Podman que sur Linux, où il est très rapide. Mais on dirait quand même que la plupart de ses fonctionnalités sont pensées pour remplacer Kubernetes via une intégration avec systemd, tandis que le support de docker compose reste instable et que le TUI/UX est en retrait par rapport à l’original
  • J’ai abandonné Podman pour des raisons mineures. L’une d’elles est que, contrairement à Docker, il a choisi de gérer SELinux, ce qui m’a obligé à modifier les labels de sécurité SELinux sur un système CentOS standard. C’était rédhibitoire
    Un autre problème concernait de petites différences avec Docker, au point que le Docker compose packagé ne fonctionnait pas tel quel. En repassant à Docker, tout marchait immédiatement et je pouvais reprendre ma journée de travail ; je n’avais pas envie de perdre du temps à déboguer ça

• Après que Docker Desktop s’est encore mis à consommer une quantité énorme de mémoire de façon aléatoire, je suis passé à Podman, et cela a vraiment été aussi simple que de le pointer vers un docker-compose.yml
  Aucun changement n’a été nécessaire, et je n’ai plus besoin de laisser un démon tourner en permanence. C’est un excellent logiciel

  • colima était meilleur que Docker Desktop, et Orbstack meilleur que colima. Puis je suis tombé sur les microVM smolvm de https://smolmachines.com's
  • À cause des absurdités autour de l’IA chez Docker, ça a fini par être la goutte d’eau et j’ai essayé de passer à Podman, mais j’ai rencontré quelques problèmes de compatibilité. C’était il y a quelques mois, donc je ne me souviens plus des détails
    J’ai donc essayé Rancher Desktop et, à part le fait que j’oublie sans cesse son nom, ça a tout simplement marché. C’est une autre option simple pour ceux qui en ont besoin

• J’adore vraiment Quadlet. Pendant des années, j’ai hébergé des conteneurs rootless sans problème avec Hetzner, Ansible, SystemD et RockyLinux, et j’ai extrait cette configuration dans un dépôt modèle
  [1] https://github.com/Mati365/hetzner-podman-bunjs-deploy

  • J’ai remplacé k3s par quadlet sur mon home server et la consommation électrique a baissé de 8 %

• J’aimerais connaître des retours d’expérience sur une migration de Docker vers Podman
  J’ai beaucoup de fichiers compose dans ma configuration homelab/automatisation, donc c’est ce qui m’inquiète le plus

  • J’ai migré de Docker vers Podman il y a environ 15 mois, et je ne compte jamais revenir en arrière. Personnellement, quadlet, c’est-à-dire l’intégration systemd, est vraiment excellent, et cela permet de surveiller bien plus facilement un ensemble de services en cours d’exécution, qu’il s’agisse de services systemd classiques ou de conteneurs
    L’exécution rootless est aussi très intuitive, et Podman est très rapide. Personnellement, docker compose ne me manque pas vraiment, mais je comprends que son absence puisse être bloquante pour d’autres. Je n’ai jamais utilisé le plugin compose de Podman
  • J’ai converti un énorme fichier docker compose de mon homelab en podman quadlet. De mémoire, les premiers services ont pris un peu de temps à migrer, car il y avait moins de documentation et d’exemples pour quadlet que pour les fichiers compose, mais après ça a été très simple. Je recommande vivement
    Le seul vrai problème, c’est la validation. Il n’y a pas de commande intégrée pratique pour valider les fichiers quadlet, et systemd ne signale pas non plus les échecs de génération. Il faut d’abord faire un --dry-run, ou transformer la commande complète en alias approprié, ou bien vérifier les erreurs dans le journal
  • J’ai migré il y a quelques années, avant la 5.0, et je n’ai jamais regardé en arrière. Pour les fichiers compose, quadlet mérite d’être envisagé
    Pour une conversion rapide, on peut utiliser directement podman-compose, ou configurer docker compose pour qu’il pointe vers le socket Podman[0]
    Il existe aussi podlet[1], qui convertit les fichiers compose en quadlet natif. Pour les fichiers compose simples ou de complexité moyenne, il gère généralement tout très bien automatiquement et fonctionne immédiatement. Il a aussi été question d’en faire une bibliothèque afin que d’autres outils puissent convertir de manière transparente les fichiers compose en quadlet, donc j’espère voir apparaître davantage d’outils de ce type à l’avenir
    Si vous êtes un minimum à l’aise avec les fichiers d’unité systemd, écrire directement des fichiers Quadlet n’est pas difficile. La plupart des arguments docker run ou podman run ont un équivalent direct en quadlet, donc une fois habitué au format INI plutôt qu’à YAML, il est facile de partir d’un fichier compose pour produire un quadlet équivalent
    [0] https://www.redhat.com/en/blog/podman-docker-compose
    [1] https://github.com/containers/podlet
  • J’ai tout migré vers Podman rootless il y a 1 à 2 ans. Certains conteneurs ont eu des problèmes de permissions en lisant d’anciennes données, parce qu’ils s’exécutaient avec un UID différent
    C’est le seul vrai problème que j’ai rencontré, et la même chose se serait probablement produite en passant d’un Docker root à un Docker rootless. Je ne regrette absolument pas et je ne compte jamais revenir en arrière
  • Je suis presque aussi reconnaissant envers Podman qu’envers git
    Podman m’a semblé mature et raisonnable. Si le conteneur de quelqu’un dépend des droits su, je blâme cette personne, pas Podman

• Ce que je n’aime pas chez Podman, c’est qu’il fait semblant d’être compatible Docker, alors qu’il y a ensuite de petites différences qui finissent par mordre. Les utilisateurs de projets basés sur Docker essaient de les lancer avec Podman, puis finissent par venir se plaindre du côté du projet

  • La plupart des différences ne venaient pas de l’API socket, du comportement logique ou de la ligne de commande. Elles venaient surtout du fait que Docker est supposé s’exécuter avec les privilèges root, alors que Podman, par défaut, non
    Donc corriger les incompatibilités Podman/Docker consiste généralement à gérer cette hypothèse, par exemple en ajoutant quelques drapeaux à la commande Podman pour changer la manière dont le mappage des espaces de noms utilisateur fonctionne entre le conteneur et l’hôte
  • J’utilise Podman sur Mac et Linux depuis 3 ans, et malheureusement ce problème a toujours été réel. Je suis prêt à chercher obstinément la cause racine et à signaler des bugs, mais pour beaucoup de gens, ça semblera juste cassé
    Le cas le plus récent, c’est que Netavark n’avait pas un comportement compatible avec Docker pour la réception du trafic broadcast sur les ports publiés
  • Oui. C’est à cause de ça que j’ai évité Podman pendant des années. Aujourd’hui, je pense qu’il y a des idées intelligentes derrière, et si vous utilisez RHEL, c’est un choix évident, mais il faudrait être plus honnête sur le fait qu’une adaptation est nécessaire
    C’est particulièrement vrai lorsqu’on passe d’un Docker root à un Podman rootless

• Je me demande comment est Podman de nos jours. Sur macOS, j’utilise OrbStack et j’ai l’impression que c’est bien plus rapide. Si macOS 27 ajoute des conteneurs Linux plus natifs et plus performants, basés sur des microVM, un peu comme WSL, je ne sais pas comment cela changera la donne

  • Je ne connais pas bien macOS, mais sous Linux, ça convient parfaitement à mon usage. Un point à noter, c’est que Podman Compose utilise docker-compose comme fournisseur par défaut
    Je n’ai pas essayé le fournisseur podman-compose, et son nom est légèrement différent, ce qui le rend confus avec Podman Compose. Podman Compose est une abstraction de plus haut niveau au-dessus de docker-compose ou podman-compose. Si besoin, on peut aussi faire exécuter des conteneurs via le moteur Docker avec Podman
  • Même question et même situation. Je l’ai essayé sur MacOS, et j’ai dû fouiller profondément dans les forums Redhat pour comprendre le premier problème que j’ai rencontré. Passer à OrbStack était un choix évident, mais il y a bien des compromis clairs du point de vue des fonctionnalités

• Quadlet et les conteneurs rootless sont les deux grandes raisons de migrer de Docker vers Podman

  • Le rootless est la raison pour laquelle j’ai migré vers Podman il y a quelques années. C’est vraiment fluide, et je n’ai plus à m’inquiéter de problèmes de permissions obscurs ni d’erreurs de service

• Podman est bien, mais je ne comprends pas ce choix de texte gris. C’est désagréable à regarder et, avec un contraste de 4,96:1, c’est difficile à lire, et cela n’atteint même pas le niveau AAA du WCAG

• Je fais tourner mon serveur domestique depuis environ 2 ans avec podman + quadlets, et j’ai repéré quelques points intéressants dans les notes de version
  podman quadlet list a été ajouté dans la v5.6.0 et liste les quadlets ainsi que leurs conteneurs
  podman system migrate --migrate-db est un drapeau ajouté dans la v5.8.0. J’avais déjà vu l’avertissement sur l’abandon du support de la base bolt, mais il n’y avait pas d’outil pour migrer vers sqlite ; maintenant il y en a un. Sinon, une mise à niveau vers podman 6.0.0 s’en charge automatiquement

• Je serais curieux d’avoir des retours d’expérience sur l’utilisation de Podman pour construire des images destinées à un runtime CRI plutôt qu’à Docker
  Si on construit une image avec Podman, pourra-t-elle être exécutée sur cri-o, Docker et d’autres runtimes ?
  docker build nécessite sudo, ce qui devient pénible dans un workflow basé sur des agents, donc j’hésite à construire les images avec Podman en mode rootless