Qu’est-ce que Podman : principes et architecture

Podman est une contraction de « POD manager » c'est un outil de gestion des conteneurs Open Source développé par Red Hat.

C'est une alternative sérieuse à Docker, avec un fonctionnement quasi identique du point de vue de l’utilisateur mais qui apporte des différences structurelles pour plus de sécurité et de flexibilité.

Dans cet article, nous vous proposons une présentation des principes et de l'architecture de Podman.

Architecture sans daemon

La première différence entre Podman et Docker qui vient à l’esprit est sans doute son architecture sans démon.

Contrairement à Docker, qui repose sur un service central (dockerd, exécuté en arrière-plan avec les privilèges root) Podman n’a pas de daemon : chaque conteneur est lancé directement par la commande podman elle-même, sans intermédiaire persistant.

Un conteneur Podman s’exécute comme un processus Linux standard, plutôt qu’en tant que process géré par un service centralisé.

Cette approche daemonless vient avec plusieurs avantages notables :

• elle réduit les risques de sécurité puisqu’il n’y a pas de daemon root qui tourne en permanence.
• elle améliore la gestion des ressources car aucun processus de fond consommant la mémoire ne tourne lorsque aucun conteneur n’est actif.
• elle améliore l’isolation des conteneurs en évitant un unique accès de contrôle à tous les conteneurs sans permissions fines (le modèle de dockerd)
• les conteneurs survivent à une mise à jour de podman ou à un reboot.

Donc l’absence de démon central tournant en “root” rend le fonctionnement de Podman plus transparent et robuste, chaque conteneur étant géré de façon autonome par le système d’exploitation.

Rootless

Nous l’avons déjà évoqué, Podman a été conçu dès le départ pour fonctionner en mode rootless, c’est-à dire sans nécessiter de privilège administrateur pour lancer des conteneurs. Docker historiquement exigeait l’accès root, même s’il lui est maintenant possible d’exploiter le mode rootless.

Podman permet à un utilisateur non privilégié de lancer et gérer ses propres conteneurs. 

Il utilise les user namespaces du kernel pour mapper l’utilisateur root à l’intérieur du conteneur vers un utilisateur privilégié sur l’hôte, offrant une isolation supplémentaire.

Le mode rootless présente des avantages en matière de sécurité : vous pouvez exécuter des conteneurs avec différents comptes utilisateurs du système avec des privilèges limités. Une faille sur un conteneur ne permettra pas l'accès à l’hôte de la machine. Par ailleurs il vous garantit qu’un utilisateur Podman ne peut pas empiéter sur les conteneurs d’un autre utilisateur (au sens de compte Unix) sur le même hôte, ce que Docker ne permet pas.

Un développeur peut donc lancer ses conteneurs en tant que simple utilisateur. En cas de défaillance, l’attaquant ne disposerait pas de droit root sur l’hôte et de plus, chaque utilisateur a son propre espace de conteneurs et d’images, stocké dans son répertoire home.

Podman, par son approche rootless, réduit grandement la surface d’attaque et en fait un outil plus sûr que Docker (par défaut).

Support des standards OCI

Tout comme Docker, Podman s’inscrit pleinement dans l’écosystème standard des conteneurs en supportant les spécifications OCI pour les images et les runtime.

Par défaut, Podman s’appuie d’ailleurs sur runC, le runtime de conteneur OCI utilisé aussi par Docker, pour lancer les conteneurs. Cela signifie que Podman peut exécuter nativement les images conteneurs existantes (Docker ou OCI) sans conversion ni modification. Cette compatibilité garantit que les images créées ou utilisées avec Docker fonctionnent tout aussi bien sous Podman.

Sa CLI permet de créer et manipuler des conteneurs OCI conformément aux normes de l’industrie.

Intégration avec systemd

Sur les serveurs Linux, Podman offre une excellente intégration avec systemd. Étant donné que Podman n’a pas de démon propre pour garder les conteneurs actifs, il peut déléguer cette tâche à systemd. Concrètement, Podman permet de générer des fichiers d’unité systemd correspondant à vos conteneurs grâce à la commande “podman generate systemd”.

Une fois ces unitfiles créés, vos conteneurs peuvent être démarrés et supervisés comme n’importe quel service systemd. En particulier vous pouvez utiliser systemctl --user ... pour profiter de ce mécanisme sans être root, permettant à un développeur sans accès privilégié d’être maître du déploiement de bout en bout.

Cette intégration implique qu’un conteneur Podman peut survivre à un redémarrage du système ou de l’utilisateur, systemd le relancera selon la politique définie, comblant l’absence de démon.

De plus, Podman supporte l’activation par socket, ce qui permet à un conteneur d’être lancé uniquement à la demande.

Pour un administrateur la gestion de conteneur via systemd apporte un contrôle unifié et la permet d’utiliser les mécanismes standard de logs, monitoring et gestion des permissions de systemd. 

Podman est adapté aux environnement de prod ou l’on souhaite traiter les conteneurs comme des services systèmes.

API RESTful

Podman fournit une API REST permettant de piloter la gestion des conteneurs via des outils externes. Elle est optionnelle, et elle fonctionne avec un service API REST par compte Unix, utilisant une socket Unix par défaut.

En activant le service API de Podman il est possible d’envoyer des requêtes REST pour créer, lister, modifier ou supprimer des conteneurs, images, volumes, etc.

L’API de Podman respecte le style REST et permet ainsi l’intégration avec divers clients HTTP (CURL, Postman, etc.) ou libraries. Il existe même des outils en Python (comme Pypodman) qui utilisent cette API pour exécuter à distance les mêmes opérations qu’en local.

Notons que Podman vise la compatibilité avec l’API Docker. Il est possible de le configurer pour qu’il écoute sur le socket Docker, afin de permettre à des outils comme docker-compose de fonctionner sans modification.

Cette API permet l’orchestration et l’automatisation des conteneurs Podman dans des pipelines CI/CD ou des outils tiers, de la même manière qu’on le ferait avec Docker.

Pods vs conteneurs

Comme son nom l’indique, Podman prend en charge des pods.

Un pod c’est un groupe de conteneurs qui partagent entre eux certains composants comme le réseau et qui sont gérés comme une unité. Avec Podman, vous pouvez aussi bien lancer des conteneurs individuels qu’assembler plusieurs conteneurs au sein d’un pod commun. Par exemple, vous pourriez définir un pod app qui contient un conteneur pour l’application web, un conteneur pour une base de données et un conteneur pour un proxy HTTP, tous les trois partageant le même réseau interne. Ils pourront communiquer en localhost et être exposés ensemble.

Podman crée en interne un conteneur infra invisible pour maintenir le pod puis y attache vos conteneurs applicatifs.

Compatibilité Docker

Un des objectifs affichés de Podman est d’être hautement compatible avec Docker pour simplifier la transition. En pratique, Podman réutilise le même format d’images de conteneur (OCI), prend en charge les mêmes commandes CLI et options que l’outil Docker et expose une API compatible Docker.

La plupart des commande Docker que vous connaissez (run, pull, build, ps, etc.) fonctionnent de manière identique avec Podman.

Et il existe même un paquet podman-docker qui cré un alias de la commande docker vers podman.

En termes d’expérience développeur, cela implique une migration très facile : un Dockerfile existant pourra être construit avec podman build sans modification.

Les images sur Docker Hub ou d’autres registres peuvent être ‘pulled’ et exécutés par Podman de la même manière.

Podman et par ailleurs compatible avec Docker Compose : on peut soit utiliser podman-compose, soit configurer Podman pour qu’il gère les appels du daemon docker afin d’exécuter un docker-compose classique pointant en fait vers Podman.

La limite se situe là ou Docker ne joue pas le jeu de l’Open Source, sur certaines fonctions propriétaires, comme le mode swarm ou certains plugins.

Dans la plupart des cas, la compatibilité de Podman avec Docker est suffisamment forte pour q’un CTO envisage de remplacer Docker par Podman sans perturber le workflows existants.

Conclusion

Podman se présente comme une alternative solide à Docker qui met l’accent sur la sécurité et l’efficacité.

Pour un CTO, le choix de Podman peut venir de la volonté de renforcer la sécurité de l’infrastructure conteneurs ou d’optimiser les ressources système.

Et il pourra atteindre ces objectifs sans pour autant sacrifier la compatibilité avec l’existant, ce qui fait de Podman une solution intéressante pour l’adoption de conteneurs dans des environnements de production exigeants.

Si vous souhaitez nous confier la gestion de votre infrastructure Podman, nous nous ferons un plaisir de vous accompagner