Optimiser l'IC et le DC avec les containers Docker et Kubernetes
Introduction
Docker et Kubernetes sont les deux faces d'une même pièce pour le CI/CD moderne. Docker garantit la reproductibilité du build, Kubernetes assure le déploiement fiable. Sur mes projets, la combinaison des deux a systématiquement transformé des pipelines fragiles en chaînes de livraison robustes. Voici comment je les associe concrètement.
Le Dockerfile comme contrat de build
Le Dockerfile est le contrat qui garantit que l'application se construit et s'exécute de la même façon partout. Chez TEKYN, le monorepo e-commerce contenait 8 services, chacun avec son Dockerfile multi-stage. Le stage de build compilait l'application, le stage de test exécutait les tests dans un environnement isolé, et le stage final produisait une image de production minimale basée sur Alpine ou distroless. Ce pattern garantit que si le test passe dans le conteneur, l'application fonctionnera en production. Sur WizOps.fr, le Dockerfile du frontend Nuxt.js utilise le même principe : build Node.js, puis copie des artefacts dans une image légère. Le résultat : des images de production de 80 Mo au lieu de 800 Mo avec les dépendances de dev.
Le registry comme pièce centrale du pipeline
Le container registry est le hub entre le CI et le CD. J'utilise systématiquement GHCR (GitHub Container Registry) pour les projets GitHub, ECR pour les projets AWS, et Artifact Registry pour GCP. Chez Bloomflow, les images étaient taggées avec le SHA du commit et la branche, ce qui permettait une traçabilité parfaite entre le code source et l'image déployée en production. ArgoCD surveillait le registry et déployait automatiquement les nouvelles images taggées main-*. Le nettoyage des vieilles images était automatisé via une policy de rétention : on gardait les 20 dernières images par branche et toutes les images de moins de 30 jours. Sans ce nettoyage, le registry d'un projet actif peut dépasser 100 Go en quelques mois.
Kubernetes comme plateforme de déploiement
Une fois l'image dans le registry, Kubernetes prend le relais. Chez Coopengo, sur un cluster EKS AWS certifié HDS, chaque service avait son Helm chart définissant le Deployment, le Service, le HPA, les NetworkPolicies et les PodDisruptionBudgets. Le pipeline CI produisait l'image, mettait à jour le tag dans le values.yaml du chart Helm, et ArgoCD synchronisait le cluster. Le rolling update de Kubernetes garantissait zéro downtime : les anciens pods ne s'arrêtaient que quand les nouveaux étaient prêts (readiness probe verte). La migration de Helm v2 à v3 que j'ai menée chez Coopengo a aussi simplifié l'architecture en supprimant Tiller et ses problèmes de RBAC.
L'environnement de review par pull request
Un pattern puissant que j'ai implémenté chez Padam Mobility : un environnement Kubernetes complet par pull request. Chaque PR déclenchait la création d'un namespace Kubernetes éphémère avec l'application, sa base de données, et un ingress temporaire. Le développeur et le product owner pouvaient tester la fonctionnalité sur une URL unique avant le merge. Le namespace était automatiquement supprimé 24 heures après le merge de la PR ou sa fermeture. Ce pattern consomme des ressources (environ 5% du cluster dédié aux environnements de review), mais le gain en qualité de review et en vitesse de validation est considérable. Les aller-retours entre développeurs et PO ont diminué de 60%.
La sécurité de la chaîne d'approvisionnement
La supply chain security est un sujet critique. Chez KNDS, les images Docker étaient scannées par Trivy à deux moments : lors du build (dans le pipeline CI) et en continu dans le cluster (via un CronJob). Les images de base étaient épinglées par digest (pas par tag) pour éviter les attaques par substitution. Les Dockerfiles utilisaient uniquement des images officielles approuvées listées dans un registry miroir interne. De plus, les manifestes Kubernetes étaient validés par OPA/Gatekeeper qui interdisait le déploiement d'images non signées ou provenant de registries non autorisés. Cette chaîne de confiance complète est exigeante à mettre en place mais indispensable dans un contexte défense.
Conclusion
Docker et Kubernetes forment l'épine dorsale du CI/CD moderne. Docker pour la reproductibilité du build, le registry pour la traçabilité, Kubernetes pour le déploiement fiable. Les patterns avancés (review environments, supply chain security) ajoutent des couches de qualité et de sécurité. Mon expérience montre que cette stack, bien configurée, permet de passer de déploiements mensuels stressants à des déploiements quotidiens sereins.