Démanteler le monolithe Terraform : le guide pas à pas
Les exécutions de Terraform durent des minutes au lieu de secondes, une modification d'une équipe casse celle d'une autre, et chaque déploiement ressemble à un pari. Quand un seul fichier d'état commence à ressembler à un monolithe, le remède est le même qu'en développement logiciel : le décomposer. Scinder un état Terraform volumineux en états plus petits et ciblés réduit l'impact des erreurs, accélère les plans et permet à chaque équipe de gérer sa partie de l'infrastructure sans coordination permanente.
Pourquoi un monolithe nuit—and comment le repérer
Un fichier d'état trop large devient un goulot d'étranglement en termes de coordination. Réseau, calcul, DNS et piles applicatives cohabitent au même endroit ; un simple redimensionnement de sous-réseau impose désormais une revue inter-équipes. Des exécutions lentes de terraform plan sont le premier symptôme, mais le vrai danger réside dans l'amplification des risques : une faute de frappe sur une ressource peut se propager à des systèmes sans lien. Si deux ressources ne sont jamais modifiées ensemble dans une même demande de modification, elles devraient probablement appartenir à des états distincts.
Cartographiez avant de déplacer les pièces
Commencez par regrouper les ressources selon des frontières naturelles : réseau (VPC, sous-réseaux, tables de routage), DNS (zones et enregistrements), calcul (clusters, machines virtuelles), infrastructure applicative (bases de données, caches) et supervision (tableaux de bord, alertes). Dessinez les flèches entre ces groupes – le réseau alimente le calcul, le calcul alimente le DNS et l'application, l'application alimente la supervision. Les valeurs qui traversent ces lignes (IDs de VPC, listes de sous-réseaux, endpoints de clusters) sont les câbles que vous devrez reconfigurer après la scission.
Déplacez les ressources sans drame
La commande state mv de Terraform déplace les ressources du monolithe vers le nouvel état sans les recréer. Après chaque déplacement, exécutez terraform plan sur le nouvel état et sur le monolithe restant ; la ressource déplacée doit disparaître du plan du monolithe et apparaître inchangée dans le nouvel état. Procédez groupe logique par groupe logique pour garder la transition prévisible.
Remplacez les références directes par des entrées et sorties
Une fois les ressources réparties dans des états séparés, les références doivent passer de consultations directes à des variables. Un module de calcul qui utilisait autrefois aws_vpc.main.id déclare désormais private_subnet_ids comme variable, tandis que le module réseau exporte cette liste en sortie. Les données circulent entre les états via les sorties exposées par le producteur et consommées par le consommateur – soit via des sources de données terraform_remote_state, soit avec un gestionnaire de dépendances dédié comme Snap CD.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.