Explorer « Podman », l’alternative à Docker renforcée côté sécurité

 (betterstack.com)
6 points par GN⁺ 2024-01-14 | 1 commentaires | Partager sur WhatsApp
  • Podman offre une expérience d’exécution de conteneurs proche de Docker, tout en se distinguant sur la sécurité et la traçabilité d’audit grâce à son fonctionnement sans démon
  • Docker utilise une architecture client-serveur centrée sur le Docker daemon, tandis que Podman crée les conteneurs directement depuis la session utilisateur, ce qui rend le suivi de l’utilisateur exécutant plus clair
  • Comme il respecte les standards OCI, il peut exécuter des images Docker Hub comme hello-world, caddy, wordpress ou mysql:5.7, et dans de nombreux cas il suffit de remplacer la commande docker par podman
  • Contrairement à Docker, les noms d’images courts ne prennent pas automatiquement Docker Hub comme valeur par défaut : il faut donc utiliser soit un nom d’image complet, soit un alias, soit le paramètre unqualified-search-registries
  • Les configurations multi-conteneurs peuvent être gérées avec Podman Compose, des pods ou des manifests Kubernetes, mais Podman ne dispose pas d’une orchestration de production intégrée comme Docker Swarm ; il faut donc utiliser un système externe comme Kubernetes

Là où Podman et Docker divergent

  • Podman est un moteur de conteneurs open source qui vise à offrir une alternative plus sûre et plus légère que Docker
  • Il exécute les conteneurs sans démon résidant en permanence, avec une architecture où l’utilisateur gère directement les conteneurs
  • Son orientation de sécurité par défaut privilégie les conteneurs rootless, les espaces de noms utilisateur et un usage plus prudent des capabilities du noyau
  • Sa forte compatibilité avec les images Docker et le modèle de commandes Docker en fait une option pratique pour les développeurs et administrateurs système cherchant une alternative à Docker

Architecture et traçabilité d’audit

  • Docker utilise un modèle client-serveur : les demandes d’exécution de conteneurs sont transmises du client Docker au Docker daemon
    • Les processus de conteneur deviennent des processus enfants du Docker daemon, et non de la session utilisateur
    • Lorsque auditd, le système d’audit Linux, détecte des événements liés aux processus de conteneur, l’ID utilisateur d’audit peut apparaître comme unset plutôt que comme l’ID utilisateur réel
    • Avec cette architecture, il est difficile de relier une activité malveillante à un utilisateur précis
  • Podman utilise une architecture sans démon
    • Chaque conteneur est créé directement via la session de connexion de l’utilisateur
    • Les données de processus du conteneur conservent les informations utilisateur
    • auditd peut détecter et enregistrer précisément l’ID de l’utilisateur ayant lancé un processus de conteneur donné
  • Selon l’image, le démarrage des conteneurs avec Podman peut être jusqu’à 50 % plus rapide qu’avec Docker

Gestion du cycle de vie des conteneurs

  • Comme Podman n’a pas de démon, sa manière de gérer le cycle de vie des conteneurs diffère aussi de Docker
  • Sous Linux, il s’appuie fortement sur Systemd
    • Il utilise un service systemd appelé podman-restart pour appliquer la politique de redémarrage des conteneurs définie avec le flag --restart always
    • Ce service redémarre automatiquement les conteneurs spécifiés après un redémarrage du système
  • Podman fournit aussi une commande pour générer des fichiers de service Systemd à partir de conteneurs en cours d’exécution
    • Placer les conteneurs sous gestion systemd facilite leur démarrage, leur arrêt et leur supervision
  • Docker traite ce type de tâche à l’intérieur de son daemon

Options d’orchestration

  • En développement local, les utilisateurs de Docker définissent et gèrent généralement les applications multi-conteneurs avec Docker Compose
  • Podman ne prend pas en charge nativement les fichiers Compose, mais propose Podman Compose comme alternative compatible
    • Il fonctionne généralement avec les fichiers docker-compose.yml existants
    • Les utilisateurs habitués à Docker Compose peuvent continuer à utiliser leurs fichiers Compose existants
  • L’approche native de Podman permet d’utiliser des pods
    • C’est un concept emprunté à Kubernetes
    • Il permet de gérer plusieurs conteneurs comme une seule unité
  • Pour les déploiements en production, Podman ne dispose pas d’un outil d’orchestration intégré comme Docker Swarm
    • Dans ce cas, un système d’orchestration externe comme Kubernetes constitue une alternative
    • Kubernetes peut s’intégrer à Podman, mais une configuration et des réglages supplémentaires peuvent être nécessaires pour un fonctionnement correct

Paramètres de sécurité par défaut

  • Un risque majeur en sécurité des conteneurs est l’évasion de conteneur, qui peut compromettre le système hôte
  • Podman est conçu pour fournir des paramètres de sécurité par défaut plus stricts que Docker
    • conteneurs rootless
    • espaces de noms utilisateur
    • profils seccomp
  • Docker permet aussi d’utiliser des conteneurs rootless, des espaces de noms utilisateur et des profils seccomp, mais ils ne sont pas activés par défaut et nécessitent souvent une configuration supplémentaire
  • La configuration par défaut de Podman exécute les conteneurs rootless dans un espace de noms utilisateur isolé, ce qui limite l’impact d’une éventuelle évasion
  • La configuration par défaut de Docker exécute les processus de conteneur en tant que root, ce qui accroît le risque en cas d’évasion
  • Les valeurs par défaut des capabilities diffèrent également
    • Podman démarre par défaut les conteneurs avec 11 capabilities
    • Docker utilise une configuration par défaut plus permissive avec 14 capabilities
  • Les deux outils peuvent être configurés avec une sécurité renforcée, mais Podman demande généralement moins d’efforts pour atteindre cet état

Différences notables dans la comparaison des fonctionnalités

  • Podman prend en charge une architecture sans démon et l’intégration avec Systemd
  • Il peut regrouper des conteneurs en pods et manipuler du YAML Kubernetes
  • Docker prend en charge Docker Swarm, contrairement à Podman
  • La plupart des autres fonctionnalités peuvent être considérées comme globalement équivalentes des deux côtés

Installation et environnements d’exécution

  • Comme Docker, Podman peut fonctionner sur les principaux systèmes d’exploitation
    • macOS
    • Windows
    • principales distributions Linux
  • La différence importante est qu’il s’exécute nativement sous Linux, tandis qu’une machine virtuelle est nécessaire sous Windows et macOS
  • Les exemples supposent une distribution Linux basée sur Debian : Ubuntu, Mint ou Debian
  • Pour installer une version récente de Podman, il faut une distribution relativement récente
    • Au moment de la rédaction, la dernière version majeure de Podman est 4.x
    • Ubuntu 22.04 LTS reste lié à Podman 3.x
    • Les exemples se basent sur Ubuntu 23.10
  • Après installation, la sortie d’exemple indique podman version 4.3.1 et confirme que la commande podman peut être exécutée localement

Exécution d’images Docker et compatibilité OCI

  • Podman peut exécuter l’image hello-world construite avec les outils de l’écosystème Docker
  • Cette compatibilité vient du fait que Docker et Podman respectent tous deux les standards OCI (Open Container Initiative)
    • OCI définit les spécifications du format d’image et du runtime
    • Il permet l’interopérabilité entre différents runtimes de conteneurs
  • La plupart des images et conteneurs Docker de Docker Hub peuvent être utilisés avec Podman
  • Il est possible de migrer des workloads existants vers Podman sans modification, ou de tirer parti de la bibliothèque d’images de Docker Hub
  • Même si la sortie de hello-world affiche “Hello from Docker!”, l’exécution réelle est assurée par Podman
    • Ni le client Docker ni le Docker daemon n’interviennent dans le processus d’exécution

Gestion des noms d’images courts

  • Docker utilise docker.io, c’est-à-dire Docker Hub, comme registre par défaut lorsqu’un nom d’image complet n’est pas précisé
  • Podman ne recommande pas l’usage de noms courts et ne suppose pas automatiquement un registre par défaut
  • hello-world dispose d’un alias dans shortnames.conf, il est donc résolu en docker.io/library/hello-world
  • Lancer une image sans alias comme caddy avec un nom court produit l’erreur suivante
    • Error: short-name "caddy" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
  • Il existe trois solutions
    • Utiliser un nom d’image complet, par exemple docker.io/library/caddy
    • Ajouter une section [aliases] dans registries.conf pour définir l’alias "caddy"="docker.io/caddy"
    • Définir unqualified-search-registries=["docker.io"] pour rechercher les noms courts sur Docker Hub
  • La configuration par utilisateur peut être placée dans $HOME/.config/containers/registries.conf
    • Ce fichier est prioritaire sur /etc/containers/registries.conf
    • Il peut être configuré sans droits root, ce qui s’accorde mieux avec l’approche rootless
  • Pour utiliser Podman comme substitut à Docker, le paramètre unqualified-search-registries est plus pratique à long terme que les alias

Utilisation de registres privés

  • Comme Docker, Podman peut utiliser des registres privés
  • L’exemple avec un compte Docker Hub suit le flux suivant
    • Créer un access token dans Docker Hub
    • Définir la description sur Podman tutorial et les permissions sur Read & Write
    • Créer un private repository
    • Se connecter avec podman login docker.io
  • Si docker.io est la première entrée unqualified-search-registries dans registries.conf, il peut être omis, mais préciser le registre est une bonne pratique
  • Si aucun registre n’est fourni, podman login échoue avec l’erreur suivante
    • Error: no registries found in registries.conf, a registry must be provided
  • Après connexion, il est possible de pousser l’image hello-world vers un private repository, de supprimer l’image publique locale, puis d’exécuter un conteneur depuis l’image du private repository
  • Sans identifiants de connexion valides, le pull d’une image privée provoque une erreur d’accès refusé et d’authentification requise
  • La principale différence visible dans l’usage des registres privés est qu’on écrit podman au lieu de docker, et Podman peut être utilisé avec les private registries courants

Exécuter plusieurs conteneurs avec Podman Compose

  • Lorsque plusieurs conteneurs doivent être exécutés comme une seule unité, Podman propose plusieurs options
    • Podman Compose
    • pods
    • manifests Kubernetes
  • L’exemple utilise Podman Compose pour lancer WordPress et MySQL
  • Podman Compose est un outil piloté par la communauté qui implémente la Compose specification et s’intègre à Podman
  • Il dépend de Python 3 et, dans l’exemple, il est installé avec pipx
    • La sortie d’installation d’exemple indique podman-compose 1.0.6
    • La version de Podman utilisée est 4.3.1
  • Si pipx s’installe dans $HOME/.local/bin, ce chemin peut ne pas se trouver dans $PATH
    • pipx ensurepath permet d’ajouter ce chemin
    • Il faut ouvrir un nouveau terminal ou recharger le fichier de configuration du shell

Exemple WordPress et MySQL

  • L’exemple définit l’utilisateur, le mot de passe et le nom de la base de données dans un fichier .env, puis configure les services WordPress et MySQL dans docker-compose.yml
  • Lors de l’exécution de podman-compose up -d, Podman Compose analyse docker-compose.yml
  • Traitement du service wordpress
    • Recherche le volume external nécessaire et le crée s’il n’existe pas
    • Recherche le network approprié et le crée s’il n’existe pas
    • Lance le conteneur wordpress
    • Si l’image locale n’existe pas, récupère wordpress:latest depuis le registre docker.io configuré
  • Traitement du service db
    • Crée le volume podman-tutorial_db
    • Vérifie le réseau existant
    • Lance le conteneur mysql:5.7
    • Si l’image locale n’existe pas, la récupère depuis Docker Hub
  • Après exécution, la page d’installation de WordPress est accessible sur localhost:8080
  • La sortie de podman ps indique que les conteneurs wordpress et db sont en cours d’exécution
    • wordpress a un port mappé en 0.0.0.0:8080->80/tcp
    • db s’exécute avec l’image mysql:5.7
  • La liste des images affiche docker.io/library/wordpress:latest et docker.io/library/mysql:5.7
  • La liste des réseaux affiche le réseau podman par défaut et le réseau podman-tutorial_default créé par Podman Compose
    • podman-tutorial_default est créé pour isoler les conteneurs définis dans docker-compose.yml des autres conteneurs du même système
  • La liste des volumes affiche podman-tutorial_db et podman-tutorial_wordpress
  • podman-compose down arrête et supprime les conteneurs, mais conserve les réseaux et les volumes
    • La suppression de volumes se fait avec podman volume rm
    • La suppression de réseaux se fait avec podman network rm
  • Les commandes sont presque identiques à Docker et Docker Compose ; la différence est qu’on tape podman et podman-compose au lieu de docker et docker-compose

Critères de choix

  • Podman est une alternative pratique à Docker pour exécuter des workloads conteneurisés
  • Il peut accomplir la plupart des tâches que Docker sait faire, avec l’avantage de ne pas nécessiter de démon en arrière-plan
  • Il fournit aussi des fonctionnalités absentes de Docker
    • travailler avec des fichiers manifest Kubernetes
    • organiser des conteneurs individuels en pods
  • Si vous avez besoin d’une solution de gestion de conteneurs plus légère et plus sûre, Podman peut être le meilleur choix
  • Si vous privilégiez un écosystème puissant et un vaste soutien communautaire, Docker peut être plus adapté
  • Pour aller plus loin, vous pouvez consulter le site officiel de Podman, la documentation et la communauté

À lire aussi

1 commentaires

 
GN⁺ 2024-01-14
Avis sur Hacker News

  • J’aimais l’époque où Podman prenait en charge les fichiers d’unité systemd. Cela permettait de démarrer et de mettre à jour automatiquement via systemd non seulement des conteneurs, mais aussi des pods entiers
    Puis ils ont supprimé cette fonctionnalité et commencé à pousser Quadlet. Pour un conteneur seul, on peut utiliser un fichier d’unité, mais pour un pod il faut passer par une définition de cluster Kubernetes
    En plus, contrairement à Docker, les conteneurs respectent les définitions SELinux, donc je me suis retrouvé plusieurs fois embêté parce qu’ils n’arrivaient pas à accéder à des répertoires montés
    Au final, je ne comprends pas ce que Podman est censé nous faire faire. Utiliser Kubernetes ? Ne pas mapper de chemins logiques et créer des répertoires dédiés pour tout ?

    • J’avais déjà défini mon infra dans un docker-compose.yml, et j’ai découvert que podman-compose avait une fonctionnalité peu documentée pour générer des unités systemd
      Cette fonctionnalité n’utilise pas l’ancienne fonctionnalité Podman désormais abandonnée, elle écrit directement les fichiers d’unité, et personnellement je l’ai trouvée bien plus fluide que l’ancienne approche Podman
      Pour l’activer, c’est $ podman-compose systemd -a create-unit, et pour enregistrer l’unité systemd, on utilise $ podman-compose systemd -a register, puis $ systemctl --user enable --now "podman-compose@$PROJECT_NAME"
      Les mises à jour se font avec $ podman-compose pull, puis $ systemctl --user restart "podman-compose@$PROJECT_NAME". $PROJECT_NAME est généralement le nom du répertoire
      Si vous voulez vérifier, le code source de la fonctionnalité est ici : https://github.com/containers/podman-compose/blob/f6dbce3618...
      J’utilise encore podman 4.3.1, mais je ne vois pas pourquoi cette approche cesserait de fonctionner dans les versions ultérieures
    • Dire que « contrairement à Docker, les conteneurs respectent les définitions SELinux » est plutôt un bug de Docker. Si le système n’est pas configuré pour SELinux, il faut le désactiver
      Et les fichiers systemd que générait podman-generate-systemd se résumaient au final à exécuter "podman start containername", donc ils sont aussi faciles à écrire soi-même. Cela dit, contrairement à quelque chose comme docker-compose, le conteneur reste presque une boîte noire
      L’intérêt de Quadlet, c’est que la définition du conteneur est déclarée dans un fichier .container. Avant, on écrivait à la main la ligne de commande podman run dans une unité systemd ; de ce point de vue, Quadlet est une grosse amélioration et peut aussi être une alternative à docker-compose. Bien sûr, il y a des avantages et des inconvénients
    • Je suis fan de longue date, mais je suis d’accord sur ce point
      Chaque fois que j’essaie d’exécuter podman generate systemd [...], ça me rappelle qu’il y a eu cette transition
      Si je n’y suis pas confronté souvent, c’est parce que je me suis créé un rôle Ansible qui gère ça correctement
      Malgré tout, j’ai vraiment l’impression que Podman a perdu le cap. Puisqu’ils ont déjà accepté l’idée de maintenir des fichiers d’unité et de concevoir les relations entre eux, j’aimerais juste qu’ils nous laissent utiliser le générateur. Quadlet, ou le fait que ce soit soi-disant mieux, ne m’intéresse pas
    • Si vous ne voulez pas gérer SELinux, vous pouvez ajouter ceci à containers.conf : [containers] label=false
      Si le niveau de sécurité par défaut de Podman ne vous convient pas, il existe généralement un moyen de le désactiver
    • Je suis récemment passé à NixOS, et NixOS traite systemd comme la référence pour tout, y compris les conteneurs
      Ce modèle m’a paru très intuitif, mais l’appliquer à Docker Compose demandait beaucoup de migration manuelle
      J’ai donc créé un outil qui convertit les fichiers Compose en configuration NixOS, afin qu’ils puissent être interprétés et gérés nativement : https://github.com/aksiksi/compose2nix

  • Il y a un avantage décisif, rarement cité, qui devrait faire préférer Podman à Docker : Docker casse la configuration réseau
    Essayer de faire tourner en même temps Docker et des machines virtuelles KVM avec des bridges est un cauchemar, alors que Podman cohabite bien mieux avec la configuration par défaut
    Les VPN aussi ont souvent été cassés par Docker, ou ont cassé Docker. Je ne sais pas exactement comment fonctionne le réseau de Podman en interne, mais il semble au moins conçu pour ne pas gêner le reste du système. Je ne dirais jamais ça de Docker

    • Pour moi, Buildah est la vraie fonctionnalité clé. Il peut aussi bien fonctionner avec Docker, mais il est plus proche de la même famille d’outils que Podman
      À mes yeux, les Dockerfile sont de la pure merde. Des langages existants suffisent largement, et je déteste vraiment quand des « développeurs qui s’ennuient » inventent un nouveau DSL ou langage de programmation. Encore plus quand c’est du YAML ; ce n’est pas le cas ici, mais Dockerfile est un excellent exemple de pourquoi il faut arrêter ce genre de choses
      Si l’on regarde Buildah sans bud, la raison devient évidente. Dès que le cas d’usage sort un peu du chemin standard, on peut utiliser Bash, Fish ou ce qu’on veut, au lieu d’un DSL bancal et irritant
      Ces mauvaises décisions se retrouvent dans tout l’écosystème Docker. DCS et ses alternatives toujours inachevées en sont aussi des exemples. Au lieu d’utiliser un protocole de signature établi comme Cosign, ils ont voulu créer un système complexe difficile à automatiser, et particulièrement pénible pour la rotation des clés
    • Podman est gratuit. Docker aussi, mais installer Docker sans Docker Desktop est pénible
    • Je fais encore tourner Docker et des machines virtuelles KVM avec des bridges, et ça fonctionne simplement, sans cauchemar. C’est un peu bizarre

  • Je suis content que Podman soit de plus en plus utilisé. Trop d’outils sont conçus en partant du principe que l’utilisateur ajoute le groupe sudo docker, et ils cassent dans des configurations Docker soucieuses de la sécurité qui ne donnent pas l’accès root à tout-va

    • Ça m’a toujours fait rire que le futur de pointe type serverless et conteneurs se soit finalement construit sur le fait d’exécuter toutes sortes de choses en root

  • En tant qu’ingénieur RHEL certifié, j’utilise déjà Podman depuis quelques années
    Honnêtement, pour mon usage personnel des conteneurs, je l’apprécie plutôt bien. Mais au travail, nous fournissons toujours Docker aux développeurs. Jusqu’ici, nous n’avions aucun moyen de leur proposer quelque chose qui égale la simplicité de docker compose
    Quand nous créons des images de conteneurs, nous utilisons aussi buildah dans les pipelines CI, mais du point de vue des développeurs utilisateurs finaux, docker compose reste dominant

  • https://www.techrepublic.com/article/how-to-fix-the-docker-a...
    J’ai failli me faire avoir à cause de ce problème

    • Docker modifie iptables rien qu’avec la configuration et l’installation par défaut. Cela a toujours été un casse-tête, surtout quand on veut utiliser le plus récent nftables
    • À cause des choix par défaut peu sûrs de Docker, un mineur de cryptomonnaie s’est retrouvé dans un conteneur personnel auto-hébergé d’un projet GitHub qui était censé être réservé à un usage via VPN. Ça m’agace encore
    • À propos des problèmes de réseau, il y a eu un gros souci dans une configuration imbriquée où la mémoire pour les périphériques réseau venait à manquer, ce qui nécessitait un redémarrage du système. Sans cela, cela aurait été une excellente alternative à lxc ; dommage

  • Je ne sais toujours pas très bien pourquoi Red Hat investit dans la création d’une alternative à Docker, mais j’aime vraiment le résultat
    Podman fait presque tout ce que fait Docker, tout en ajoutant des fonctionnalités comme les pods, ou en proposant souvent une meilleure approche, comme un processus de création de conteneurs sans daemon
    Pour les développeurs ordinaires, le plus gros problème sera sans doute Docker Compose ; si vous utilisez un fichier compose simple, il existe un script podman-compose qui cherche à être compatible avec la spécification Docker Compose
    Il est aussi possible d’utiliser Podman comme backend de docker-compose [1]. Globalement, en 2024, je ne vois aucune raison d’utiliser Docker sur une machine Linux. Je ne sais pas très bien ce que vaut Podman sur macOS ou Windows
    [1] https://www.redhat.com/sysadmin/podman-docker-compose

    • À l’origine, Red Hat avait tenté de collaborer avec Docker pour corriger plusieurs problèmes apparus par le passé, par exemple des soucis de compatibilité avec systemd dans certains cas d’usage, mais sans grand résultat
      Si l’on ajoute à cela le fait que Docker a eu, et a encore, un nombre inhabituellement élevé de problèmes de sécurité, et que les conteneurs et images à la Docker sont extrêmement répandus chez les développeurs, Red Hat n’avait guère d’autre choix que de créer sa propre implémentation, plus conforme à la valeur et à l’approche de RHEL
      Par exemple, Docker peut fonctionner en rootless, mais ce n’est toujours pas le comportement par défaut. Dans un environnement renforcé, le groupe d’utilisateurs docker, comme l’exécution sans ce groupe, sont difficiles à accepter du point de vue de la sécurité dans de nombreux cas d’usage
      Les premières versions de Docker étaient beaucoup trop peu volontaristes pour assurer ne serait-ce qu’une isolation minimale des conteneurs non privilégiés, et même après que les problèmes ont été connus, il a fallu longtemps pour les corriger. Sa manière d’interagir avec le pare-feu, les règles réseau et SELinux pose aussi beaucoup de problèmes. Ce n’est pas rare que Docker soit interdit dans les entreprises qui disposent d’administrateurs système Linux dédiés et soucieux de sécurité
    • J’utilise Podman sous Windows. Docker sur Windows a été une suite interminable d’agacements et de frustrations
      Dès le départ, toute la documentation vous pousse vers une installation GUI agressivement peu conviviale. Elle lance des processus lourds au démarrage, exige pour une raison obscure de créer un compte cloud, et vous sermonne encore en disant qu’il ne faut pas utiliser ce prétendu produit open source au travail
      L’alternative non prise en charge consistant à installer « seulement Docker en ligne de commande » était inutilement complexe, et la dernière fois que j’ai essayé, la plupart des VM WSL ne la prenaient même pas en charge par défaut
      À l’inverse, avec Podman, winget install podman suffit, et il vous laisse tranquille. Je ne démarre la VM Podman que lorsque j’ai besoin d’exécuter des conteneurs ; quand je n’en ai pas besoin, le système se comporte comme avant
      Si je dois lancer quelque chose avec un fichier compose, il y a podman-compose. Il ne gère peut-être pas les configurations atypiques, mais pour mon usage il a bien fonctionné
      La seule chose que Podman ne fait pas vraiment correctement, c’est l’intégration à VS Code, mais les efforts nécessaires pour faire fonctionner Docker sagement sous Windows sont bien plus pénibles que la perte de quelques raccourcis VS Code, donc ce n’est pas un problème
      Je recommande Podman comme solution par défaut pour les conteneurs sous Windows. Les seules raisons d’utiliser Docker seraient que l’entreprise paie pour cela, ou que vous ayez une configuration compose complexe ; dans ce cas, cela vaut peut-être la peine de passer à Kubernetes
    • La raison pour laquelle Red Hat investit, c’est que Docker est trop éloigné de la façon dont les choses se font sous Linux
      Il fait des choses qui abîment le système, a galéré pendant des années avec le rootless, sans oublier le verrouillage fournisseur
      Podman est ouvert, respecte les standards et s’intègre bien à Kubernetes. La quantité d’efforts que les développeurs ont consacrée à Docker uniquement parce qu’il est arrivé le premier sur le marché des conteneurs faciles est absurde
    • J’espère que le point de vue « il n’y a aucune raison d’utiliser Docker sous Linux » ne deviendra pas majoritaire. Docker n’est pas Red Hat/IBM
      Si Docker disparaît, Red Hat pourra pousser son agenda d’entreprise avec une main encore plus forte
      Podman a des avantages, mais dans la tentative de Red Hat de remplacer tout ce que fait Docker, certaines parties n’ont pas été bien exécutées
      Quand on regarde l’histoire de l’approche de Red Hat dans le domaine des conteneurs, on voit aussi beaucoup de temps et d’efforts gaspillés dans des projets auxquels ils auraient pu contribuer et qu’ils auraient pu améliorer
      Red Hat n’est pas une entreprise dont l’agenda est de faire ce qui est juste pour ses clients ; il faut donc réfléchir à ce que l’on souhaite dans une perspective plus large
    • J’utilise Podman sur macOS. Dans l’ensemble, l’expérience a été meilleure qu’avec Docker, surtout pour la prise en charge des anciennes versions de macOS
      Le seul gros inconvénient de Podman pour macOS est qu’on ne peut pas utiliser le réseau de l’hôte depuis les conteneurs. Mais les cas où l’on veut utiliser le réseau de l’hôte depuis un conteneur sont rares
      En revanche, si vous faites des expérimentations réseau dans un conteneur et que vous voulez conserver le même nom d’hôte et la même adresse IP que l’hôte, il faut le garder en tête. Cela dit, j’arrive quand même à contourner cette limite

  • L’approche et les décisions axées sur la sécurité me paraissent bonnes. J’aime le fait que les réglages par défaut soient sûrs, et que cela fonctionne aussi avec docker compose
    Cela dit, je me demande si, si Podman devient suffisamment populaire, il finira un jour par suivre sa propre voie pour les commandes et le format yml. Pour l’instant, il ressemble à un outil qui s’appuie sur Docker et sur le format de fichiers Docker Compose
    J’aimerais qu’il existe dans Podman une alternative à Swarm. Aujourd’hui, faute d’orchestration, j’ai l’impression que Kubernetes sert un peu de béquille
    Une équipe attentive à la sécurité pourrait, me semble-t-il, mettre au point une manière raisonnable et simple d’exécuter des conteneurs à petite échelle, sans devoir étudier Kubernetes comme un doctorant alors que ses réglages par défaut ne sont pas sûrs. Et cela pourrait tout en conservant la compatibilité avec le format Docker Compose

  • Je suis d’accord pour dire que les conteneurs rootless et les espaces de noms isolés sont des fonctionnalités de sécurité importantes. Mais c’est aussi possible avec Docker rootless, et ce n’est pas compliqué. Il suffit de le configurer ainsi
    J’ai déjà écrit un article expliquant comment configurer Mastodon avec Docker rootless en appliquant toutes les bonnes pratiques actuellement disponibles [1]
    L’avantage de continuer à utiliser Docker, c’est qu’il est plus accessible. Il y a davantage de communauté et de blogs, les configurations docker compose sont répandues, et il y a aussi plus de gens autour de soi qui savent l’utiliser
    Au final, Podman comme Docker exécutent des processus dans des espaces de noms isolés de l’hôte
    [1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...

  • Qu’on ne se méprenne pas. Podman est excellent et je l’utilise aujourd’hui à la place de Docker, mais au début je l’ai abordé comme un simple substitut à Docker et je me suis fait sérieusement piéger par le mapping UID/GID, les politiques SELinux, une configuration DNS manquante, etc.
    Il m’est aussi arrivé plusieurs fois de lancer system migrate pour corriger un problème et de casser toute ma configuration. Il existe tout un système à part autour des ACL de sécurité, du mapping d’identifiants et des labels
    Si vous faites un chmod -R sous votre dossier personnel, il est probable que tous vos conteneurs meurent
    Je suis satisfait du résultat, mais on était loin d’une solution qui « marche tout simplement » comme Docker. Cela s’est probablement beaucoup amélioré depuis que j’ai commencé à l’utiliser

    • J’ai commencé à l’utiliser cette année, pour isoler plusieurs environnements de développement et empêcher npm d’accéder trop facilement à toute ma machine de dev
      De mon point de vue, c’était plus facile à utiliser que Docker. On dirait que les choses se sont améliorées par rapport aux situations décrites plus haut

  • Dans une perspective plus large, Podman me semble aussi indispensable que l’était Linux autrefois
    Même si très peu de gens l’utilisent, sa seule existence empêche ses grands frères propriétaires, bien plus gros, de faire des choses horribles
    Quand je dis « Linux autrefois », je ne veux pas dire que Linux est devenu moins important, mais qu’au contraire il est aujourd’hui encore plus indispensable et central

    • Si par « grands frères propriétaires, bien plus gros », vous voulez dire Docker, c’est un peu ironique. Car Red Hat et IBM font eux aussi pas mal de mauvaises choses dans l’open source