"Versionnage ? Oh, je prends toujours la dernière version - qu’est-ce qui pourrait bien mal tourner ?"
C’est précisément ce genre d’attitude qui explique pourquoi certains ingénieurs sont réveillés à 3 heures du matin par un appel d’urgence. Et pourquoi, le lendemain matin, tout le monde regarde ses chaussures pendant le Daily Stand-up.
Avant que cela ne vous arrive aussi, parlons-en brièvement dans le dernier volet de notre série « Terraform @ Scale ».
Lire la suite : Terraform @ Scale - Partie 7 : Bonnes pratiques pour le versionnage des modules
"Au diable la visibilité - tant que ça marche !"
C’est avec cet état d’esprit que la plupart des équipes de Platform Engineering courent à leur perte. C’est un peu comme cuisiner les yeux bandés dans une cuisine inconnue : ça peut fonctionner un moment, mais lorsque ça brûle, c’est pour de bon.
Et rien n’est pire que de voir des visages désemparés lorsque tout part en fumée.
Dans les deux parties précédentes, nous avons abordé la douleur liée aux dépendances. Voyons aujourd’hui quelles sont les options dont nous disposons pour repêcher un projet déjà tombé dans le puits avant qu’il ne soit trop tard.
Dans l’article précédent, nous avons examiné la complexité cachée des modules imbriqués et l’effet domino, et nous avons pris conscience des conséquences désagréables que cela peut entraîner dans l’exploitation et le lifecycle-management. On peut ouvrir toute grande la porte à ce type de problèmes en commettant des erreurs de débutant – surtout l’erreur de regrouper plusieurs, voire tous les modules Terraform dans un dépôt Git commun. Avec un peu plus de séniorité et une planification soignée, on peut cependant minimiser ces problèmes dès le départ.
Voyons dans cette partie comment gérer ces dépendances en pratique, sans que la douleur ne devienne insupportable.
Lire la suite : Terraform @ Scale - Partie 6b : Gestion pratique des modules imbriqués
Quand une simple mise à jour de module paralyse 47 équipes...
Nous sommes lundi matin, 10h30. L’équipe de Platform Engineering d’un grand fournisseur de Managed Cloud Services vient de publier une mise à jour « inoffensive » du module de base pour les instances VM, passant de la version v1.3.2 à la v1.4.0. Le changement ? Un nouveau tag Freeform obligatoire pour l’affectation des ressources à des centres de coûts.
Ce que personne n’a anticipé : l’ingénieur senior qui, autrefois en tant que décideur, avait insisté avec véhémence pour déposer tous les modules Terraform dans un seul dépôt Git. « La gestion de versions, c’est trop de micro-management. Comme ça, c’est plus ordonné. Et cela demande moins de travail », avait-il dit à l’époque.
Le même lundi, à 15h00 : 47 équipes de clients différents signalent déjà que leurs pipelines CI/CD échouent. La raison ? Leurs root-modules référencent les modules mis à jour par le fournisseur, mais personne n’a implémenté les nouveaux paramètres dans ses propres root-modules. Le contrôle de conformité du fournisseur est actif et rejette les exécutions Terraform en raison des tags obligatoires manquants. Ce qui devait être une amélioration s’est transformé en un arrêt organisationnel complet avec un impact massif sur les clients d’hébergement.
Bienvenue dans le monde des dépendances entre modules avec Terraform @ Scale.
Lire la suite : Terraform @ Scale - Partie 6a : Comprendre et gérer les modules imbriqués
Dans l’article précédent 5a, nous avons vu à quelle vitesse de grands déploiements Terraform atteignent les limites d’API, par exemple lorsque des tests DR créent des centaines de ressources en parallèle et que des erreurs 429 déclenchent en cascade des tentatives de réexécution. Cette suite reprend le fil et montre comment gérer consciemment ces limites avec l’API Gateway d’Oracle Cloud Infrastructure et d’Amazon API Gateway, comment les observer proprement et comment les rendre robustes à l’exploitation via « Policy as Code ».
Lire la suite : Terraform @ Scale - Partie 5b : API Gateways
