Dans la dernière partie de cette série, nous avons montré comment des Data Sources apparemment inoffensives dans les modules Terraform peuvent devenir un véritable problème de performance. Des exécutions de terraform plan durant plusieurs minutes, des pipelines instables et des effets incontrôlables de limitation d’API en étaient les conséquences.
Mais comment éviter élégamment et durablement ce piège de mise à l’échelle ?
Dans cette partie, nous présentons des modèles d’architecture éprouvés vous permettant de centraliser les Data Sources, de les injecter avec parcimonie en termes de ressources, et ainsi de garantir des exécutions Terraform rapides, stables et prévisibles, même avec des centaines d’instances de modules.
Au programme : trois stratégies de solution évolutives, un guide pas-à-pas éprouvé en pratique et une checklist de bonnes pratiques pour des modules d’infrastructure prêts pour la production.
Lire la suite : Terraform @ Scale - Partie 4b : Bonnes pratiques pour des Data Sources évolutives
Les Data Sources de Terraform sont un moyen populaire de renseigner dynamiquement des variables avec des valeurs réellement existantes de l’environnement cloud concerné. Mais leur utilisation dans des infrastructures dynamiques demande une certaine prévoyance. Il suffit par exemple d’un innocent data.oci_identity_availability_domains dans un module - et soudain, chaque exécution de terraform plan prend des minutes au lieu de secondes. Car 100 instances de module signifient 100 appels API, et votre fournisseur cloud commence à appliquer un throttling. Bienvenue dans le monde de l’amplification API involontaire via les Data Sources.
Dans cet article, je vous montre pourquoi les Data Sources dans les modules Terraform peuvent poser un problème de mise à l’échelle.
Lire la suite : Terraform @ Scale - Partie 4a : Les Data Sources sont dangereuses !
Même l’architecture d’infrastructure la plus sophistiquée ne peut pas prévenir toutes les erreurs. C’est pourquoi il est essentiel de surveiller de manière proactive les opérations Terraform - en particulier celles qui peuvent avoir des conséquences potentiellement destructrices. L’objectif est de détecter précocement les modifications critiques et de déclencher automatiquement des alertes, avant qu’un rayon d’impact incontrôlé ne survienne.
Oui, bien sûr - votre ingénieur système vous rappellera sans doute que Terraform affiche l’intégralité du plan avant l’exécution d’un apply et qu’il faut encore confirmer manuellement l’exécution par la saisie de "yes".
Ce que votre ingénieur ne vous dit pas : il ne lit en réalité pas le plan avant de le lancer.
« Ça ira. »
La Key/Value Secrets Engine fait partie intégrante de presque toute implémentation de Vault. Il constitue la base du stockage sécurisé des secrets statiques et est, en pratique, utilisé bien plus fréquemment que de nombreux Secrets Engines dynamiques.
Après l’introduction théorique dans la partie 2a, nous abordons dans cet article le travail concret avec le Secrets Engine KV. Nous montrons comment écrire, lire, mettre à jour et supprimer des secrets, et analysons de manière pratique les différences entre les versions 1 et 2 de KV. L’accent est mis sur les commandes pertinentes en production, les écueils réalistes et des recommandations concrètes pour le quotidien opérationnel, c’est pourquoi je vous transmets ces connaissances sous forme de tutoriel mêlé à une fiche mémo.
Malgré une minimisation rigoureuse du blast radius, des états segmentés et des garde-fous dans le cycle de vie, l'incident finit tôt ou tard par se produire : un terraform apply supprime par erreur des ressources en production - ou un terraform destroy affecte plus que prévu.
Que faire lorsque le mal est déjà fait ?
Dans le dernier article de cette série, je vous ai expliqué comment minimiser le blast radius. Dans cette suite, je vous présente des techniques éprouvées pour restaurer des états Terraform corrompus et limiter les dégâts après un incident.
Lire la suite : Terraform @Scale - Partie 3b : Stratégies de récupération après un Blast Radius
Plus d'articles...
- Plongée approfondie dans HashiCorp Vault – Partie 2a : Activer la Key/Value Secrets Engine
- Terraform @ Scale - Partie 3a: Gestion du Blast Radius
- Plongée approfondie dans HashiCorp Vault - Partie 1 : Fondamentaux des Secrets Engines
- Terraform @ Scale - Partie 2 : L’art du dimensionnement optimal des States
