from Docker to Podman
Contenu
Dans le cadre de la normalisation des containers , l'initiative Open Container Initiative OCI est née
from Docker to Podman
Red Hat a décider de flaguer le package containerd.io sur sa distribution
Red Hat recommande l’utilisation de podman ainsi que les outils de containers buildah, skopeo, conmon, runc + … pour un environement de développement
En environement de Production, c’est pluôt le couple CRI-O + Kubernetes ❤️
pourquoi choisir podman ?
point faible docker
- Docker centralise tous les containers sous le même processus containerd.io ==> SPOF
- le processus containerd.io own l’ensemble des processus child (running container)
- si containerd.io
s'arrete / crash, tous les processus child sont perdus (voir ci-dessous)
|
|
- Aussi un simple utilisateur exécute un container avec les privilèges root et un accès complet au système hôte (voir ci-dessous)
- l'ensemble des images sont télécharger et stocker dans le même dossier
/var/lib/docker/image/overlay2/imagedb/content/sha256
(voir ci-dessous)
podman : un puissant alternatif
- podman + libpod : plus besoin de démarrer un daemon !
interaction directe avec runC à travers conmon ✔️
Tous les conteneurs sont exécutés par runC sans dépendre d’un processus unique - chaque utilisateur héberge ces images dans son home directory
~/.local/share/containers/storage/overlay-images
- chaque container s'exécute sans privilège root
|
|
- podman accepte la création et l'exécution des Pods depuis (manifests YAML) Kubernetes
Podman + Kubernetes ❤️
Podman permet surtout une transition simple depuis l’environement de développement local vers l’environement de production Kubernetes Cluster CRI-O
à votre service ❤️
Si cet article vous a plu, je vous invite à contacter notre entreprise integrateur open source pour vous aider à mettre en place cette solution et la faire évoluer selon vos besoins.
Aussi, je vous invites à vous abonner à nos réseaux sociaux:
démo en vidéo
Et voici la vidéo résumant tout ce que je viens de vous dire 😉
à venir