Mettre en place une chaîne CI/CD avec Docker et Kubernetes

L'intégration continue (CI) vérifie automatiquement chaque modification du code : compilation, tests, analyse statique, construction d'un artefact. Le déploiement continu (CD) livre cet artefact dans les environnements successifs, jusqu'à la production, de manière reproductible et sans intervention manuelle sujette à l'erreur.

L'objectif n'est pas la vitesse pour elle-même, mais la confiance : tout déploiement doit être identique en préproduction et en production, traçable jusqu'au commit d'origine et réversible en quelques minutes. Docker fournit l'artefact immuable, Kubernetes fournit le mécanisme de déploiement et de retour arrière.

Les outils d'orchestration de pipeline (GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines) sont interchangeables pour l'essentiel. Ce qui compte, c'est la structure des étapes et les règles de qualité imposées à chacune, pas la marque de l'outil qui les exécute.

Le Dockerfile doit produire une image minimale et déterministe. Utilisez une construction en plusieurs étapes (multi-stage) : une première étape compile avec tous les outils de développement, une seconde ne copie que les fichiers nécessaires à l'exécution dans une image de base légère, ce qui réduit la taille et la surface d'attaque.

Épinglez les versions des images de base et des dépendances, exécutez le processus avec un utilisateur non privilégié et ajoutez un fichier .dockerignore pour exclure les fichiers inutiles ou sensibles. Le cache de couches doit être exploité en ordonnant les instructions du moins au plus changeant.

Chaque image doit être identifiée par un tag immuable, typiquement le SHA du commit, en plus d'éventuels tags lisibles. Le tag « latest » ne doit jamais être déployé en production : il rend impossible de savoir ce qui tourne réellement et de revenir en arrière proprement.

Un pipeline typique enchaîne : installation des dépendances avec cache, analyse statique et formatage, tests unitaires, construction de l'image, analyse de sécurité de l'image avec un outil comme Trivy ou Grype, puis publication dans le registre uniquement si toutes les étapes précédentes ont réussi.

Les tests d'intégration qui nécessitent une base de données ou une file d'attente s'exécutent dans des conteneurs éphémères lancés par le pipeline. Cela garantit un environnement identique à chaque exécution et évite les dépendances à des services partagés dont l'état varie.

Le pipeline doit être rapide : au-delà d'une dizaine de minutes, les développeurs cessent d'attendre le résultat et les erreurs sont détectées plus tard. Parallélisez les étapes indépendantes et ne reconstruisez que ce qui a changé dans un dépôt qui contient plusieurs services.

Les manifestes Kubernetes (Deployment, Service, Ingress, ConfigMap, Secret, HorizontalPodAutoscaler) doivent être versionnés avec le code ou dans un dépôt dédié. Helm ou Kustomize permettent de gérer les variations entre environnements sans dupliquer les fichiers ni les maintenir à la main.

Chaque Deployment doit définir des sondes de vivacité (liveness) et de disponibilité (readiness), des limites et requêtes de ressources, et une stratégie de mise à jour progressive (rolling update) avec un nombre maximal d'instances indisponibles. Sans sonde de disponibilité, Kubernetes envoie du trafic à des pods qui ne sont pas encore prêts.

Les secrets ne doivent jamais être en clair dans le dépôt. Utilisez un gestionnaire externe (AWS Secrets Manager, HashiCorp Vault) synchronisé via External Secrets Operator, ou des secrets chiffrés avec Sealed Secrets ou SOPS, afin que le dépôt reste lisible sans être dangereux.

L'approche GitOps consiste à faire du dépôt Git la source de vérité de l'état souhaité du cluster. Un opérateur comme Argo CD ou Flux surveille le dépôt et applique automatiquement les changements. Le pipeline CI ne déploie plus directement : il met à jour le tag d'image dans le dépôt de configuration.

Les avantages sont considérables : historique complet des déploiements dans Git, revue par pull request avant la production, détection des dérives entre l'état déclaré et l'état réel, et retour arrière par simple revert du commit fautif, sans accès direct au cluster.

Cela impose une discipline : toute modification manuelle sur le cluster sera écrasée par l'opérateur. C'est précisément ce que l'on cherche, mais l'équipe doit l'avoir compris et accepté avant la mise en place, sous peine de frustrations.

Le rolling update par défaut remplace progressivement les pods et convient à la majorité des services sans état. Pour les changements risqués, un déploiement blue/green maintient deux versions complètes et bascule le trafic d'un coup ; un déploiement canary envoie d'abord une fraction du trafic à la nouvelle version.

Les déploiements canary et progressifs sont facilités par des outils comme Argo Rollouts ou Flagger, qui automatisent la promotion ou le retour arrière selon des métriques (taux d'erreur, latence). Cela suppose une observabilité en place : métriques, journaux et traces centralisés et consultables.

Les migrations de base de données doivent rester compatibles avec la version précédente de l'application pendant le déploiement, puisque les deux versions cohabitent quelques minutes. Sans cette précaution, le retour arrière devient impossible au moment précis où vous en avez besoin.

Les erreurs les plus courantes que nous rencontrons : images construites différemment selon l'environnement, absence de tests avant la construction de l'image, secrets dans les variables du pipeline sans rotation, accès administrateur du pipeline au cluster de production, et absence de procédure de retour arrière testée.

Une chaîne CI/CD est un produit à part entière. Elle mérite une revue régulière, une documentation à jour et une personne responsable de son bon fonctionnement, exactement comme l'application qu'elle livre.