L'intégration et le déploiement continu avec Docker et Kubernetes
CI/CD avec Docker et Kubernetes : de la théorie à la production
Docker et Kubernetes sont les deux faces d'une même pièce pour la CI/CD moderne. Docker crée des artefacts reproductibles, Kubernetes les déploie de manière fiable. Voici comment j'orchestre cette combinaison sur le terrain.
L'intégration continue : build Docker automatisé
Le pipeline CI commence toujours par un build Docker. Pour WizOps.fr, GitHub Actions construit des images Docker multi-plateforme avec Buildx à chaque push sur main, puis les pousse sur GHCR. Chez Epiconcept, le même pattern s'applique pour des applications de santé publique : chaque pull request déclenche un build Docker et une série de tests dans un conteneur identique à la production. La clé est la reproductibilité : si le build passe en CI, il passera en production. Point final.
Le déploiement continu : Kubernetes comme plateforme de livraison
Chez KNDS dans la défense, le déploiement continu repose sur ArgoCD qui surveille les manifestes Kubernetes dans Git. Dès qu'une nouvelle image Docker est référencée dans le Helm Chart, ArgoCD déploie automatiquement sur le cluster OVH Cloud. Ce pattern GitOps élimine tout accès direct au cluster : personne ne fait de kubectl apply en production. Chez Padam Mobility, j'ai poussé ce concept plus loin avec des environnements éphémères : chaque branche feature déploie un environnement Kubernetes complet, permettant aux développeurs de tester dans des conditions proches de la production.
Tests automatisés dans des conteneurs Docker
Les tests sont au coeur de la CI, et Docker les rend bien plus fiables. Chez Bloomflow, les tests d'intégration s'exécutent dans des conteneurs Docker avec une base de données PostgreSQL éphémère. Plus de "ça marche chez moi mais pas en CI" : l'environnement de test est strictement identique à la production. Chez Coopengo, j'ai utilisé le même pattern pour tester des applications en environnement HDS sur AWS, avec des conteneurs de test qui montent les mêmes secrets et les mêmes ConfigMaps que la production.
Gestion de configuration : Ansible et Terraform en complément
Docker et Kubernetes ne couvrent pas tout. Terraform provisionne l'infrastructure cloud (VPC, clusters, bases de données), et Ansible gère les configurations qui ne sont pas conteneurisées. Chez F2R2, les 25 modules Terraform créent l'architecture AWS complète, tandis que les manifestes Kubernetes gèrent le déploiement applicatif. Cette séparation des responsabilités est essentielle : chaque outil fait ce qu'il fait le mieux, sans empiéter sur les autres.
Surveillance post-déploiement : Prometheus et Grafana
Un déploiement réussi ne s'arrête pas quand le conteneur est lancé. Il s'arrête quand les métriques confirment que tout fonctionne. Chez Metronome, Prometheus collecte les métriques de chaque pod Kubernetes et Grafana les affiche en temps réel. Chez Earny SA, après la migration GCP vers AWS, la stack Grafana/Prometheus/Loki m'a permis de comparer les performances avant et après migration et de valider que le SLA était respecté. Mon conseil : définissez vos SLO avant de déployer, pas après.
La CI/CD n'est pas un projet, c'est une culture
Mettre en place Docker et Kubernetes pour la CI/CD, c'est 20% technique et 80% culturel. Il faut convaincre les équipes de merger souvent, de tester systématiquement, et de faire confiance au pipeline. Quand cette culture est en place, les déploiements deviennent des non-événements, et l'équipe peut se concentrer sur ce qui compte vraiment : livrer de la valeur aux utilisateurs.