Après plusieurs années d’utilisation de Docker, notamment sur mon infrastructure personnelle, j’ai eu envie de tester un autre outil pour gérer mes conteneurs. Parmi les alternatives qui existent une m’avait donné envie d’en savoir plus : “Podman” particulièrement après en avoir entendu parler au FOSDEM 2020.
Une histoire de conteneur …
Il y a de grandes chances que vous connaissiez déjà Docker qui bousculé les habitudes de travail avec les conteneurs, mais cette technologie est bien plus vieille que Docker. Je ne vais pas vous faire un historique complet, mais il faut savoir que les conteneurs existaient déjà. On peut penser aux solutions antérieures à Docker comme OpenVZ ou Linux Container qui était d’ailleurs utilisé comme base par Docker dans ses jeunes années.
Alors qu’est-ce que Docker a apporté pour rencontrer un tel succès ? Un écosystème et une manière de faire nouvelle au moment de l’essor du DevOps. Le fait de décrire ces conteneurs dans un fichier (Dockerfile), de pouvoir stocker et partager des images (Docker hub), de réutiliser des layers. Tout cela a beaucoup changé la manière de travailler en grande partie grâce à cet écosystème qui permettait de répondre aux paradigmes apparus notamment en parallèle de la mouvance DevOps, comme le pet vs cattle par exemple.
Mais avec le temps la société qui gère Docker a subi quelques difficultés, notamment après le succès de Kubernetes face à Swarm, son orchestrateur maison. De plus, le moteur de Docker n’ayant jamais été passé sous licence libre, les libristes avaient donc tendance à le bouder quelque peu.
…Qui devient une histoire de Pod
En quelques années, vous l’avez surement vu Kubernetes est devenu un standard dans le monde de l’orchestration de conteneurs. Parmi tous les apports de Kubernetes, je vais m’attarder sur une qui a son importance dans l’histoire, le pod. Alors le pod est une notion qui désigne une unité dans Kubernetes représentant un ensemble de conteneurs qui sont liés. Ils ne pourront par exemple jamais être séparés sur deux machines différentes et interagir directement entre eux.
Cette notion est par essence très importante dans Kubernetes, mais n’est pas du tout présente dans Docker. C’est là qu’on entre dans une situation qu’ironiquement Docker voulait nous éviter : le développeur sur son ordinateur utilise du Docker voir docker-compose et sur les environnements on utilise du Kubernetes qui va plus reposer sur la notion de Pod. Même si la notion est relativement proche, je trouve dommage de perdre la fameuse homogénéité que Docker devait apporter.
Et c’est là qu’apparaît : PODMAN !
Podman est une alternative à la ligne de commande Docker supportée par RedHat, qui va vous permettre déjà de gérer des conteneurs sans avoir de démon, et sans les droits root sur la machine, mais surtout gérer des Pods nativement ! Vous avez bien compris, on apporte la notion de pod démocratisé par Kubernetes en “local”. Podman ne s’arrête pas là en matière de synergie, il va permettre d’exporter et d’importer directement des définitions yml Kubernetes !
Ok, du coup là vous devez vous dire que c’est génial, mais que vous avez appris Docker et qu’il faut tout réapprendre. Et là Podman a encore la réponse pour vous, la syntaxe des commandes est très proche de Docker à tel point qu’ils conseillent même de faire un alias docker=podman.
Familiarisons-nous avec Podman
Quoi de mieux pour découvrir une technologie que de la manipuler ?
- Installation de Podman
Le plus simple est de suivre la documentation officielle. Sur Debian, il suffit d’ajouter le dépôt et de l’installer avec APT :
Pour Debian 10
echo 'deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/Release.key | sudo apt-key add -
sudo apt-get update -qq
sudo apt-get -qq -y install podman
- Les actions basiques (Docker-like)
Les actions basiques ressemblent en général à l’option près à la commande Docker. Même les images et dépôts Docker sont compatibles !
Démarrer un conteneur
root@tmp /root » podman run hello-world
Trying to pull docker.io/library/hello-world...
Getting image source signatures
Copying blob 0e03bdcc26d7 done
Copying config bf756fb1ae done
Writing manifest to image destination
Storing signatures
Hello from Docker!
This message shows that your installation appears to be working correctly.
[...]
Vous remarquez d’ailleurs que par défaut, Podman va chercher les images directement sur le Docker hub.
Lister les conteneurs
root@tmp /root » podman ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4ec0e83cb175 docker.io/library/hello-world:latest /hello About a minute ago Exited (0) About a minute ago agitated_vaughan
On peut voir notre conteneur “Hello World” que vous pouvez supprimer avec podman rm $CONTAINER_ID
Petit tutoriel pour découvrir les pods !
Vous vous demandez surement où sont les fameux Pod, car bon pour l’instant cala ressemble plus à un équivalent de Docker.
Pour vous parler des pods on va partir sur un objectif simple :
- Monter un Wordpress en container
- Il sera contenu dans un pod
- Le pod contiendra 2 container : Wordpress front et MySQL la base de données
On créé tout d’abord le pod qui va contenir nos containers, en lui demandant d’exposer le port 80 à l’extérieur. Cela nous permettra d’accèder à notre Wordpress.
podman pod create --name wordpress -p 80
Votre pod est donc créé, vous pouvez l’observer :
podman pod ls
POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID
4ee4f1e626e7 wordpress Created 2 minutes ago 1 caf216f50735
Si on exectute d’ailleur un ps, on voit que Podman créer en même temps que le pod un conteneur pour le gérer comme sur Kubernetes (l’image est d’ailleurs originaire de Kubernetes)
podman ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
caf216f50735 k8s.gcr.io/pause:3.2 About a minute ago Created 0.0.0.0:80->80/tcp 4ee4f1e626e7-infra
On peut ensuite créer nos 2 conteneurs en les attachant au pod créé précédemment
MySQL
podman run -d --pod wordpress -e MYSQL_ROOT_PASSWORD=VOTRE_MOT_DE_PASSE mysql:5.7Wordpress
podman run -d --pod wordpress -e WORDPRESS_DB_HOST=127.0.0.1 -e WORDPRESS_DB_USER=root -e WORDPRESS_DB_PASSWORD=VOTRE_MOT_DE_PASSE -e WORDPRESS_DB_NAME=localhost -e WORDPRESS_TABLE_PREFIX=wp_ wordpress:latest
Vous remarquerez que pour interroger la base MySQL Wordpress se base sur le localhost, en effet ils sont dans le même Pod vous pouvez donc communiquer directement sur cette interface.
Vous pouvez maintenant utiliser votre instance Wordpress sur le port 80 :)
De Podman à Kubernetes
Je vous ai parlé d’une autre fonctionnalité qui me semble bien intéressante, l’export et l’import de yml on va la tester avec notre Wordpress.
Pour exporter un pod directement dans un fichier yml il suffit de faire :
podman generate kube -f /tmp/wordpress.yml wordpress
Vous pouvez aussi faire le cheminement inverse, à partir de fichier généré par Podman ou un fichier de Kubernetes.
podman play kube /tmp/wordpress.yml
D’ailleurs, si vous tentez de recréer notre exemple vous allez surement avoir une erreur 500 sur le Wordpress évoquant un timeout sur la base de données. Une petite explication s’impose, de base la définitions des pods dans les fichiers yml ne permets pas d’avoir la notion de dépendance entre les conteneurs, donc le Wordpress démarre avant la base de données donc il ne peut pas s’y connecter. En redémarrant le conteneur Wordpress vous allez observer un retour du service.
Une fois que vous avez terminé les tests, vous pouvez stopper le pod et le supprimer :
podman pod stop wordpress
podman pod rm wordpress
Ce n’est bien sûr qu’une exploration de la surface de Podman, je vous invite à pousser l’utilisation si ça vous intéresse et consulter la documentation officielle.
Que penser de Podman face à Docker
Alors que penser de Podman, je pense que c’est une alternative très avantageuse à Docker pour plusieurs raisons, même si certaines choses sont encore perfectibles.
Dans les quelques défauts, il y a problème de dépendance qui est liée au format de description utilisé par Kubernetes. On peut le contourner au besoin avec de petits “hack” dans les conteneurs ou en passant par le projet podman-compose ce qui reste un peu dommage, car on perd le côté natif. Un dernier point qui est mériterait aussi de s’améliorer c’est la documentation, qui est moins complète/agréable que Docker je trouve.
Pour les utilisateurs de Windows, je sais qu’il y en a, Podman n’est pas compatible nativement avec Windows. Néanmoins, WSLv2 permet visiblement de l’utiliser ce qui est plutôt une bonne nouvelle.
Le fait d’avoir des commandes très proches de Docker est une bonne chose, même si parfois à l’utiliser j’ai l’impression qu’on a forcé un peu pour rester sur une apparence Docker.
Ne pas avoir de démon et ne pas nécessiter les droits root sont des avantages assez séduisants. Mais je pense que le vrai avantage est bien la synergie avec Kubernetes. Celui-ci étant devenu aujourd’hui qu’on le veuille ou non un standard. Même si elle ne va pas vous générer un fichier prêt pour la production en une commande, elle pourra accompagner les développeurs à tester des programmes sur Kubernetes facilement. De mon point de vue le fait que la solution soit open source et soutenu par RedHat est aussi un signe encourageant.
Personnellement, je n’utilise plus Docker quand c’est possible, je trouve que Podman plus agréable surtout la notion de Pod. J’espère que Podman va gagner en efficacité, notamment avec la prometteuse version 2 qui arrive ! Néanmoins, Docker est bien installé sur le marché et je ne pense pas que Podman va le détrôner en tout cas pas tout de suite, surtout vu la communauté de Docker. Dans tous les cas je vous invite à suivre de près l’actualité de Podman !
PS : Si vous souhaitez utiliser directement Podman pour héberger des services, je ne peux que vous conseiller l’excellent combo Ansible / Podman / systemd que vous pouvez découvrir sur cette publication de RedHat : https://redhatnordicssa.github.io/ansible-podman-containers-1. Je l’utilise pour mes services personnel, c’est stable et efficace.