Conteneurisation : Docker, alternatives et écosystème des conteneurs

La conteneurisation est devenue le standard pour le packaging et le déploiement d'applications. Si Docker a été pionnier, l'écosystème inclut désormais de multiples runtimes, orchestrateurs et outils de construction.

Runtimes de conteneurs

Docker Engine reste le runtime le plus utilisé pour le développement. Cependant, dans les environnements Kubernetes de production, containerd (le runtime que Docker utilise lui-même en interne) est devenu la référence. Kubernetes a déprécié Docker comme runtime en v1.24, se standardisant sur le Container Runtime Interface (CRI).

Podman (de Red Hat) offre une alternative sans daemon et sans root à Docker avec un CLI compatible. Il est particulièrement populaire dans les environnements soucieux de sécurité et les écosystèmes RHEL/Fedora.

CRI-O est une implémentation CRI légère conçue spécifiquement pour Kubernetes, sans les couches supplémentaires de Docker.

tadata

Docker	Podman	Kubernetes pod
Root daemon dockerd; socket = root on host	Daemonless, fork/exec; rootless by default	kubelet + CRI (containerd/CRI-O); no Docker socket since 1.24
Default caps 14, seccomp default profile	Same OCI defaults, seccomp on	Caps and seccomp set per pod in securityContext; seccompProfile RuntimeDefault
User namespaces opt-in (userns-remap)	User namespaces always (rootless)	hostUsers: false (user namespaces for pods, on by default in 1.33, GA in 1.36)
Policy: none built in	policy.json signature policy	Pod Security Admission: privileged / baseline / restricted per namespace
Image trust: DCT/Notary, cosign	sigstore in policy.json	Admission webhooks (Kyverno, Gatekeeper, cosign policy-controller)
Network: bridge, iptables, icc	CNI, netavark	NetworkPolicy default-deny per namespace; CNI Calico/Cilium

Extrait de la fiche « Docker Hardening, Supply Chain and Detection » · Demander la fiche complète

Construction d'images

Le paysage de la construction d'images conteneur s'est étendu bien au-delà des Dockerfiles :

Docker Build avec BuildKit fournit des builds multi-étapes, le caching de couches et des étapes parallèles
Buildpacks (Cloud Native Buildpacks / Paketo) détectent automatiquement le type d'application et créent des images optimisées sans Dockerfile — supportés nativement par GCP Cloud Run et Heroku
Kaniko construit des images à l'intérieur de clusters Kubernetes sans accès au daemon Docker — essentiel pour des pipelines CI/CD sécurisés
ko se spécialise dans la construction d'images d'applications Go avec un overhead minimal
Jib (de Google) construit des images Java optimisées sans Dockerfile

tadata

La même application en build multi-stage : le fichier de lock copié en premier, un cache mount pour uv, l'image devel uniquement dans l'étape de build. Une modification du code ne reconstruit plus que deux petites couches

Extrait de la fiche « Docker for ML: GPU Images That Build Fast » · Demander la fiche complète

Registres de conteneurs

Chaque fournisseur cloud propose un registre géré : AWS ECR, GCP Artifact Registry et Azure Container Registry. Pour les stratégies auto-hébergées ou multi-cloud, Harbor (projet CNCF diplômé) est l'option open source leader avec scan de vulnérabilités, signature d'images et réplication.

GitHub Container Registry (ghcr.io) s'intègre étroitement avec GitHub Actions et est de plus en plus utilisé pour les images de projets open source.

Sécurité et chaîne d'approvisionnement

La sécurité des conteneurs est devenue une préoccupation de premier ordre :

Trivy (d'Aqua Security) est le scanner de vulnérabilités open source le plus populaire pour les images, systèmes de fichiers et IaC
Grype (d'Anchore) fournit un scan rapide avec intégration SBOM
Cosign (de Sigstore) permet la signature et la vérification d'images — de plus en plus requis dans les environnements réglementés
Les images distrôless (de Google) et Chainguard Images minimisent la surface d'attaque en supprimant shells et gestionnaires de paquets des images de production
Docker Scout et Snyk Container offrent un scan commercial avec des recommandations de remédiation actionnables

tadata

Chaîne d'approvisionnement des images : prouver la provenance (niveaux SLSA), lister les composants (SBOM, software bill of materials), contrôler à l'admission. Images de base : distroless, Alpine ou Chainguard. Admission : Kyverno verifyImages, Sigstore policy-controller ou GKE Binary Authorization. Exécution : retirer les capabilities, imagePullPolicy: Always, pull secrets par namespace

Extrait de la fiche « Kubernetes Security, part 2: secrets, runtime, response » · Demander la fiche complète

Orchestration au-delà de Kubernetes

Si Kubernetes domine l'orchestration, des alternatives plus simples existent pour les charges plus légères :

Docker Compose reste excellent pour le développement local et les petits déploiements
AWS ECS fournit une plateforme de conteneurs gérée plus simple sans la complexité de Kubernetes
GCP Cloud Run et AWS App Runner offrent une exécution de conteneurs entièrement serverless
Nomad (de HashiCorp) fournit une alternative plus légère à Kubernetes avec un support multi-workload (conteneurs, VMs, binaires)

Bonnes pratiques

Utilisez des builds multi-étapes pour garder les images de production petites et sécurisées
Préférez les images de base distrôless ou minimales aux distributions OS complètes
Scannez les images dans le CI/CD avant de les pousser vers les registres
Signez les images avec Cosign pour l'intégrité de la chaîne d'approvisionnement
Utilisez .dockerignore pour empêcher les fichiers sensibles d'entrer dans les images
Épinglez les versions d'images de base (utilisez les digests, pas juste les tags) pour des builds reproductibles
Exécutez en non-root — la plupart des applications n'ont pas besoin de privilèges root dans le conteneur