Comment opérer Terraform à grande échelle

• Plus de 165 000 ressources cloud gérées dans 625 workspaces Terraform et 38 comptes AWS
  • Sur 170 ingénieurs, 40 sont des spécialistes de l’infrastructure
  • 225 déploiements d’infrastructure (terraform apply) et 723 plans (terraform plan) exécutés chaque jour
• Pour y parvenir, l’équipe a adopté Terraform Cloud afin d’automatiser le processus de déploiement de l’infrastructure, en réduisant le travail manuel et les erreurs des développeurs

Problèmes avant l’adoption de Terraform Cloud

• Besoin de privilèges AWS élevés : l’équipe infrastructure devait disposer d’un niveau élevé d’accès à AWS
• Travail chronophage : il fallait exécuter terraform apply dans chaque répertoire, puis répéter les cycles de revue et d’approbation ; un seul changement pouvait affecter plus de 120 workspaces
• Dérive de l’infrastructure : des modifications imprévues s’accumulaient, nécessitant des revues et actions supplémentaires au moment de l’application

Mise en place de Terraform Cloud et effets obtenus

• Élimination de la dérive → suppression de la dérive de l’infrastructure, réduisant les risques et la charge pour les développeurs
• Gain de temps pour les développeurs → environ 8 000 heures économisées par an (l’équivalent de la charge de travail de 4 développeurs)
• Traçabilité des changements → les logs d’audit permettent de suivre les changements et facilitent le débogage
• Prise en charge des speculative plans → les changements peuvent être testés automatiquement et les résultats consultés directement dans la CI GitHub

Mode d’exploitation actuel de Terraform Cloud

• Auto-hébergé : Terraform Cloud for Business est installé en interne, et les agents TFC tournent dans un cluster ECS au sein des comptes AWS
• Organisation des pools d’agents : 120 agents répartis entre environnement de développement (40) et environnement de production (80) afin de maintenir une forte simultanéité

Éléments suivis en priorité

1. Épuisement des agents et limites de simultanéité → alerte envoyée à l’astreinte en cas de manque d’agents
2. Durée des plans → alerte envoyée à l’équipe si un plan dépasse 4 minutes en environnement de développement
3. Dérive de l’infrastructure → non mesurée actuellement (la dérive est devenue quasi inexistante)

Optimisations pour améliorer la qualité

• Développement d’une CLI TFC : permet de revoir et d’approuver automatiquement les changements sur plusieurs workspaces via une CLI
• Mise en place d’un système de notifications : automatisation via des alertes Slack pour éviter qu’un terraform apply ne soit oublié
• Gestion automatisée des workspaces : utilisation de Terraform pour gérer 625 workspaces et application de tags pour distinguer les équipes propriétaires
• Analyse de l’usage de Terraform Cloud : exploitation de l’API TFC pour collecter les données de versions d’état, mesurer l’utilisation des ressources et suivre la croissance
• Sauvegarde du Terraform State : sauvegarde automatique des fichiers d’état dans un bucket S3 pour permettre la reprise en cas d’incident
• Gestion des dépendances entre workspaces : création d’un arbre de dépendances des modules afin de configurer automatiquement les répertoires à surveiller par chaque workspace
• Automatisation des mises à niveau des providers : utilisation de Dependabot pour mettre à jour les providers chaque mois et réduire la charge de maintenance grâce à l’automatisation

Améliorations prévues

• Déploiement progressif : passage d’un modèle de release basé sur la branche main à un déploiement multi-étapes (développement → staging → production)
• Découpage des grands workspaces : subdivision des 625 workspaces actuels en plus de 1 500, afin de réduire les temps de plan et d’application et de limiter le périmètre d’impact des changements
• Amélioration des notifications : ajout d’une fonction de réattribution dans les alertes Slack et introduction d’une génération automatique de la commande tfc review
• Auto-scaling des agents : adoption d’un système d’auto-scaling basé sur EKS pour gérer efficacement des charges de travail variables
• Open source des outils développés en interne : publication en open source de divers outils internes pour que d’autres équipes puissent aussi en profiter