Conteneurisation avancee
Au-dela des bases de Docker, la conteneurisation avancee couvre les techniques de production : optimisation des images, securite, gestion des registres, runtimes alternatifs et orchestration. Ces pratiques sont essentielles pour deployer des conteneurs de maniere fiable et securisee en production.
Optimisation des images
Multi-stage builds : utiliser plusieurs etapes FROM dans un Dockerfile pour separer la compilation de l'image finale. Le stage de build contient le compilateur et les dependances de developpement (Go, Node.js, Java). L'image finale ne contient que le binaire et les dependances runtime. Resultat : images 10-100x plus petites. Images de base : utiliser alpine (5 MB), distroless (Google, minimal, pas de shell), ou scratch (vide) plutot 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.
Securite des conteneurs
Scan de vulnerabilites : Trivy, Snyk ou Docker Scout analysent les images pour les CVE connues. Integrer dans le CI. Utilisateur non-root : toujours executer 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 donnees. 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 defaut. GitHub Container Registry (ghcr.io) : integre a GitHub Actions. AWS ECR, Google Artifact Registry, Azure Container Registry : registres cloud manages. Harbor : registre open-source auto-heberge avec scan de vulnerabilites et replication. Bonnes pratiques : tag semantique (v1.2.3 plutot 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 leger utilise par Kubernetes (Docker l'utilise aussi sous le capot). Podman : alternative a Docker sans daemon, rootless par defaut, 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 securite supplementaire. Kubernetes utilise le CRI (Container Runtime Interface) et est agnostique du runtime.
Orchestration en production
L'orchestration gere le deploiement, le scaling et la haute disponibilite 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 proprietaire AWS, plus simple que Kubernetes pour les workloads AWS. Le choix depend de la taille de l'equipe, de la complexite des workloads et de l'expertise disponible.