Conteneurisation avancee
Au-delà des bases de Docker, la conteneurisation avancee couvre les techniques de production : optimisation des images, sécurité, gestion des registres, runtimes alternatifs et orchestration. Ces pratiques sont essentielles pour déployer des conteneurs de manière fiable et sécurisée en production.
Optimisation des images
Multi-stage builds : utiliser plusieurs étapes FROM dans un Dockerfile pour séparer la compilation de l'image finale. Le stage de build contient le compilateur et les dépendances de développement (Go, Node.js, Java). L'image finale ne contient que le binaire et les dépendances runtime. Résultat : images 10-100x plus petites. Images de base : utiliser alpine (5 MB), distroless (Google, minimal, pas de shell), ou scratch (vide) plutôt que ubuntu (72 MB). Layer caching : ordonner les instructions du Dockerfile du moins au plus changeant (OS deps, app deps, code source) pour maximiser le cache.
Sécurité des conteneurs
Scan de vulnérabilités : Trivy, Snyk ou Docker Scout analysent les images pour les CVE connues. Intégrer dans le CI. Utilisateur non-root : toujours exécuter le processus comme un utilisateur non-privilegie (USER dans le Dockerfile). Read-only filesystem : monter le filesystem en lecture seule (--read-only), volumes temporaires pour les données. Pas de secrets dans l'image : utiliser les secrets Docker, les variables d'environnement, ou des gestionnaires de secrets (Vault). Image signing : signer les images avec Cosign (Sigstore) pour garantir leur provenance.
Registres de conteneurs
Les registres stockent et distribuent les images. Docker Hub : registre public par défaut. GitHub Container Registry (ghcr.io) : integre à GitHub Actions. AWS ECR, Google Artifact Registry, Azure Container Registry : registres cloud manages. Harbor : registre open-source auto-heberge avec scan de vulnérabilités et réplication. Bonnes pratiques : tag semantique (v1.2.3 plutôt que latest), images immuables (ne jamais re-push un tag existant), retention policy pour nettoyer les anciennes images.
Runtimes alternatifs
Docker n'est plus le seul runtime de conteneurs. containerd : runtime léger utilise par Kubernetes (Docker l'utilise aussi sous le capot). Podman : alternative à Docker sans daemon, rootless par défaut, compatible avec les commandes Docker. CRI-O : runtime minimaliste pour Kubernetes uniquement. Kata Containers : conteneurs dans des micro-VM pour une isolation renforcee. gVisor : sandbox kernel de Google pour une sécurité supplémentaire. Kubernetes utilise le CRI (Container Runtime Interface) et est agnostique du runtime.
Orchestration en production
L'orchestration gere le déploiement, le scaling et la haute disponibilité des conteneurs. Kubernetes : standard de l'industrie, complexe mais puissant. Docker Swarm : plus simple mais moins adopte. Nomad (HashiCorp) : orchestre conteneurs et workloads non-conteneurises. ECS (AWS) : orchestration propriétaire AWS, plus simple que Kubernetes pour les workloads AWS. Le choix dépend de la taille de l'équipe, de la complexité des workloads et de l'expertise disponible.