Optimiser le Déploiement Continu avec Terraform et Kubernetes
Introduction
Combiner Terraform pour l'infrastructure et Kubernetes pour les applications dans un pipeline de déploiement continu unifié est un défi que j'ai relevé sur plusieurs missions. La difficulté : synchroniser deux cycles de vie différents (infrastructure lente et stable, applications rapides et fréquentes) dans un workflow cohérent.
Le pipeline dual : infra et applicatif
Chez F2R2, j'avais conçu deux pipelines distincts mais interconnectés. Le pipeline infra (Terraform) s'exécutait sur les changements dans le répertoire terraform/ : validate, plan, apply, puis mise à jour des outputs (endpoints de cluster, ARN des rôles IAM) dans un fichier partagé. Le pipeline applicatif (Docker + Helm + ArgoCD) s'exécutait sur les changements dans apps/ : build, test, push image, mise à jour du tag dans les values Helm. Les deux pipelines partageaient des données via les outputs Terraform stockés dans le state S3, référencés dans les values Helm via des data sources. Cette architecture garantissait que le pipeline applicatif utilisait toujours les bonnes configurations d'infrastructure.
La synchronisation infra/app lors des changements majeurs
Le cas complexe arrive quand un changement nécessite une modification simultanée de l'infra et de l'application. Chez Earny SA, la migration GCP vers AWS nécessitait de créer l'infra AWS (Terraform) puis de redéployer les applications (Helm) sur le nouveau cluster. J'ai utilisé un pipeline orchestrateur qui exécutait les étapes dans l'ordre : terraform apply pour créer le cluster EKS, helm install pour déployer les addons (cert-manager, ingress, ArgoCD), puis argocd sync pour déployer les applications. Les smoke tests validaient chaque étape avant de passer à la suivante. La bascule DNS du trafic de GCP vers AWS se faisait en dernière étape, avec un rollback automatique si les métriques se dégradaient.
Le GitOps pour Terraform : Atlantis et alternatives
Pour appliquer le GitOps à Terraform (PR-based workflow), j'ai utilisé différentes approches. Chez F2R2, un workflow GitHub Actions custom exécutait terraform plan sur chaque PR, postait le résultat en commentaire, et exécutait terraform apply après le merge. Cette approche maison avait l'avantage de la simplicité et du contrôle total. Chez Bloomflow, j'avais testé Atlantis (un serveur qui écoute les PR GitHub et exécute Terraform) mais l'ai abandonné à cause de sa complexité de déploiement et de maintenance. L'approche GitHub Actions native est plus simple à maintenir et offre la même fonctionnalité. Le pattern est maintenant bien rodé : plan en PR, apply au merge, notification en cas d'erreur.
La gestion des secrets dans le pipeline dual
Dans un pipeline qui gère à la fois Terraform et Kubernetes, les secrets sont multiples : credentials cloud pour Terraform, tokens de registry Docker pour le build, kubeconfig pour les déploiements Kubernetes, et secrets applicatifs. Chez KNDS, j'avais centralisé tous les secrets dans HashiCorp Vault. Terraform accédait à Vault via le provider vault pour créer des secrets AWS éphémères. Le pipeline CI récupérait le kubeconfig depuis Vault pour les opérations kubectl. Les secrets applicatifs étaient gérés par External Secrets Operator dans le cluster. Aucun secret n'était stocké dans GitHub Secrets ni dans le code. Cette architecture "zero secrets in CI" est le standard de sécurité que j'applique dans les contextes sensibles.
Le disaster recovery de l'infrastructure complète
Le test ultime d'un pipeline Terraform + Kubernetes est le disaster recovery : recréer l'infrastructure complète à partir de zéro. Chez Bloomflow, j'ai validé ce scénario une fois par trimestre. Le Terraform recréait le cluster Kubernetes, les bases de données (restaurées depuis un snapshot S3), et les addons. ArgoCD redéployait automatiquement toutes les applications dès qu'il était installé. Le temps de restauration complète : 45 minutes pour un cluster de 20 services. Ce test régulier a révélé des problèmes qui n'apparaissent que lors d'un provisionnement from scratch : des ordering issues dans Terraform, des secrets non sauvegardés, et des dépendances circulaires entre services. Chaque test renforçait la procédure.
Conclusion
Le déploiement continu combinant Terraform et Kubernetes est un défi d'architecture plus que de technique. Le pipeline dual (infra + applicatif), la synchronisation lors des changements majeurs, le GitOps pour Terraform, la gestion centralisée des secrets, et le test régulier de disaster recovery forment un ensemble cohérent qui garantit une infrastructure reproductible et des applications déployées en continu. Cette approche, validée sur des architectures multi-comptes AWS et des migrations cloud, est le standard que je recommande pour les organisations qui prennent leur infrastructure au sérieux.