Podman et CRI-O, le nouveau duo de la conteneurisation
A part si vous êtes un fan de conteneurs, il y’a de forte chance que vous n’ayez pas entendu parler de Podman et CRI-O.
Ces deux projets open source sont à l’origine d’une révolution dans le monde des conteneurs : le remplacement de Docker.
Et là, premier étonnement : pourquoi remplacer Docker ?
Bien que Docker Inc. ait relancé la mode des conteneurs, ce composant tout en un est aujourd’hui un point de contention et risque de SPOF.
Le binaire docker contient les instructions pour construire les images de conteneurs, de quoi les exécuter et même de quoi monter un cluster swarm.
Évidement un monolithe dans un monde de micro-service ça coince.
Podman et CRI-O viennent remplacer les fonctionnalités de docker tout en gardant une compatibilité pour ne pas tout chambouler.
Coté DEV : Podman
Podman vient remplacer la ligne de commande docker.
La compatibilité est telle que vous pouvez créer un alias afin de ne pas avoir à changer vos habitudes ni même vos scripts.
alias docker=podman
L’un des intérêts de podman est qu’il n’y a plus de daemon.
Tous les conteneurs sont lancés par runC sans dépendre d’un processus unique.
Deuxièmement, Podman a été conçu avec pour fonctionner de pair avec Kubernetes.
Podman peut utiliser les manifests YAML de Kubernetes. A la fois pour lancer des Pods ou générer des manifests à partir d’un Pod existant.
Coté OPS : CRI-O
CRI-O vient remplacer le daemon docker en tant que moteur applicatif.
Plus léger, CRI-O n’est pas un outil à tout faire client/serveur. Il ne fait qu’une chose et le fait bien (True UNIX Srptit)
Plus sure, CRI-O déclenche une instance de runC par pod. Tous les pod ne sont pas lié à un seul daemon qui est un SPOF.
Conclusion
SUSE et openSUSE sont évidement contributeurs sur ces projets.
Retrouver Podman et CRI-O dans SLES 15 et CaaSP v4 notre solution basée sur Kubernetes.
Podman et CRI-O était déjà disponible en Tech Preview dans SUSE CaasP v3.
Liens
Related Articles
Run SAP
SUSE for Public Cloud
Security
No comments yet