Cas pratiques Terraform

Contexte : Les valeurs des variables sont actuellement définies en dur dans main.tf. Le Problème : Cela empêche une personnalisation simple selon l'environnement. Contraintes : Définir les variables dans variables.tf et utiliser terraform.tfvars pour les valeurs. Livrable attendu : Fournir une configuration propre séparant déclaration des variables et valeurs spécifiques via terraform.tfvars.

Contexte : Une équipe utilise Terraform pour gérer son infrastructure en local. Le Problème : L'état Terraform est stocké de manière incohérente car le backend n'est pas correctement configuré. Contraintes : Configurer un backend local cohérent. Aucun backend distant requis. Extrait actuel : terraform { required_version = ">= 1.0.0" } Livrable attendu : Ajouter une configuration backend locale correcte garantissant une gestion propre du fichier terraform.tfstate.

Contexte : Une instance EC2 doit être associée à un security group créé dans la même configuration. Le Problème : Terraform applique les ressources dans un ordre incorrect causant une erreur intermittente. Contraintes : Corriger la dépendance via référence explicite ou depends_on si nécessaire. Livrable attendu : Adapter la configuration Terraform pour garantir l'ordre correct de création des ressources.

Contexte : Une ressource S3 est définie dans Terraform pour stocker des fichiers statiques. Le Problème : terraform plan échoue en indiquant qu'un argument inconnu est utilisé dans la ressource. Extrait actuel : resource "aws_s3_bucket" "static" { bucket_name = "my-bucket" } Contraintes : Corriger uniquement la configuration Terraform sans modifier le provider. Livrable attendu : Adapter la ressource avec les attributs corrects afin que le plan s'exécute sans erreur.

Contexte : Vous venez d'intégrer une équipe qui provisionne une machine virtuelle via Terraform sur un cloud public. Le Problème : Lors de l'exécution de terraform plan, une erreur indique qu'une variable instance_type est utilisée mais non déclarée. Contraintes : Vous devez corriger uniquement les fichiers Terraform. Aucune modification côté cloud provider. La variable doit être configurable via un fichier terraform.tfvars. Extrait actuel : resource "aws_instance" "app" { ami = "ami-123456" instance_type = var.instance_type } Livrable attendu : Ajouter correctement la déclaration de variable et permettre son paramétrage via terraform.tfvars afin que terraform plan s'exécute sans erreur.

Contexte : Une équipe souhaite réutiliser la même configuration d'instance EC2 dans plusieurs projets. Le Problème : Le code est actuellement dupliqué dans différents repositories. Contraintes : Créer un module Terraform simple dans un dossier modules/instance et l'appeler depuis main.tf. Livrable attendu : Proposer une structure de module réutilisable et un appel correct du module depuis la configuration principale.

Contexte : Une petite équipe souhaite automatiser la création d'une instance EC2 pour un environnement de test. Le Problème : Aucun code Terraform n'existe encore dans le projet. Contraintes : Configurer le provider AWS, définir une région et créer une instance EC2 minimale. Aucun module externe requis. Livrable attendu : Fournir un fichier main.tf minimal permettant d'initialiser Terraform et de créer une instance EC2 fonctionnelle.

Contexte : Une équipe démarre un nouveau projet d'infrastructure as code avec Terraform. Le Problème : Les développeurs ne savent pas quelles étapes exécuter pour initialiser correctement le projet. Contraintes : Utiliser uniquement les commandes Terraform standards. Livrable attendu : Décrire les étapes nécessaires pour initialiser le projet avec terraform init, vérifier la configuration avec terraform validate et planifier les changements avec terraform plan.

Contexte : Plusieurs environnements (dev, staging, prod) utilisent la même configuration Terraform. Le Problème : Les noms des ressources sont codés en dur, provoquant des conflits entre environnements. Contraintes : Utiliser une variable environment pour construire dynamiquement le nom de la ressource. Livrable attendu : Adapter la configuration Terraform pour générer un nom de ressource dynamique basé sur la variable environment.

Contexte : Une instance cloud est créée via Terraform et son IP publique doit être communiquée à l'équipe. Le Problème : Aucune sortie n'est définie dans la configuration Terraform. Contraintes : Ajouter un bloc output permettant d'afficher l'adresse IP publique après terraform apply. Livrable attendu : Fournir une configuration Terraform incluant un output affichant l'attribut public_ip de la ressource créée.

Contexte : Une organisation déploie la même architecture sur dev, staging et prod. Le Problème : Les configurations sont dupliquées et difficiles à maintenir. Contraintes : Créer un module Terraform réutilisable acceptant des variables comme environment, instance_type et tags. Aucun code dupliqué. Livrable attendu : Définir la structure d'un module réutilisable et montrer comment l'appeler avec des paramètres différents selon l'environnement.

Contexte : Un module réseau crée un VPC et des subnets. Un autre module application doit utiliser ces ressources. Le Problème : Les informations ne sont pas correctement transmises entre modules. Contraintes : Utiliser des outputs dans le module réseau et les consommer dans le module application. Livrable attendu : Décrire une configuration propre permettant de transmettre les identifiants VPC et subnets entre modules via outputs et variables.

Contexte : Une infrastructure doit déployer des ressources dans deux régions AWS différentes. Le Problème : Le provider actuel est défini pour une seule région. Contraintes : Déclarer plusieurs providers avec alias et les associer aux ressources appropriées. Livrable attendu : Proposer une configuration Terraform utilisant des providers multiples avec alias pour gérer des déploiements multi-régions.

Contexte : Une ressource de monitoring doit être créée uniquement en production. Le Problème : Elle est actuellement provisionnée dans tous les environnements. Contraintes : Utiliser une variable booléenne et count ou for_each pour conditionner la création. Livrable attendu : Adapter la configuration Terraform afin que la ressource ne soit créée que si la variable enable_monitoring est vraie.

Contexte : Une même configuration Terraform doit gérer dev et prod. Le Problème : Les environnements sont actuellement gérés via duplication de dossiers. Contraintes : Utiliser les workspaces Terraform pour isoler les states par environnement. Livrable attendu : Expliquer comment configurer et utiliser les workspaces afin de séparer correctement les environnements sans duplication excessive.

Contexte : Une instance EC2 a été créée manuellement via la console AWS. Le Problème : L'équipe souhaite désormais la gérer via Terraform sans la recréer. Contraintes : Utiliser terraform import pour intégrer la ressource dans le state existant. Livrable attendu : Décrire les étapes nécessaires pour définir la ressource dans la configuration et l'importer correctement dans le state Terraform.

Contexte : Une équipe utilise Terraform avec un state local stocké sur les postes développeurs pour gérer une infrastructure AWS. Le Problème : Le state est sujet à conflits et risques de perte. L'équipe souhaite centraliser le state dans un backend distant S3 avec verrouillage. Contraintes : Configurer un backend S3 avec versioning activé et verrouillage via DynamoDB. Aucune recréation d'infrastructure autorisée. Livrable attendu : Proposer une configuration Terraform permettant la migration propre du state vers S3 avec verrouillage, incluant les blocs backend et les étapes nécessaires.

Contexte : Un projet Terraform devient complexe avec toutes les ressources dans un seul fichier main.tf. Le Problème : La configuration est difficile à maintenir et peu lisible. Contraintes : Organiser le projet en fichiers distincts (providers.tf, variables.tf, outputs.tf, main.tf). Livrable attendu : Proposer une structure de projet Terraform claire et maintenable adaptée à une infrastructure de taille moyenne.

Contexte : Une équipe doit créer plusieurs instances EC2 basées sur une liste d'environnements. Le Problème : La configuration actuelle duplique manuellement les blocs resource. Contraintes : Utiliser for_each ou count pour générer dynamiquement les ressources à partir d'une variable liste. Livrable attendu : Proposer une configuration Terraform utilisant for_each ou count afin de créer plusieurs ressources sans duplication de code.

Contexte : Une variable instance_type est librement configurable par les développeurs. Le Problème : Certaines valeurs invalides provoquent des erreurs tardives côté provider. Contraintes : Ajouter un bloc validation dans la variable pour limiter les valeurs acceptées. Livrable attendu : Proposer une déclaration de variable Terraform incluant une validation personnalisée empêchant l'utilisation de types non autorisés.

Contexte : Une application critique doit être hautement disponible sur plusieurs régions AWS. Le Problème : L'infrastructure actuelle est limitée à une seule région, sans réplication ni failover. Contraintes : Utiliser providers aliasés, ressources répliquées et configuration cohérente entre régions. Livrable attendu : Décrire une architecture Terraform permettant un déploiement multi-régions cohérent avec réplication des composants critiques.

Contexte : Une architecture complexe inclut plusieurs modules dépendant partiellement les uns des autres (réseau, sécurité, compute). Le Problème : Terraform signale des dépendances circulaires empêchant l'exécution du plan. Contraintes : Repenser la structure des modules pour supprimer les cycles tout en conservant la cohérence fonctionnelle. Livrable attendu : Décrire une stratégie de refactorisation permettant d'éliminer les dépendances circulaires via séparation logique et découplage des responsabilités.

Contexte : Une infrastructure critique est gérée par un unique state Terraform volumineux. Le Problème : Chaque modification déclenche des plans massifs et augmente le risque d'erreurs lors des apply. Contraintes : Segmenter l'infrastructure en plusieurs states indépendants tout en conservant les dépendances logiques entre composants. Livrable attendu : Décrire une stratégie de découpage du state en stacks cohérentes, avec gestion des outputs distants et remote_state sécurisé.

Contexte : Une entreprise impose des règles strictes (tags obligatoires, types d'instances limités, chiffrement activé). Le Problème : Rien n'empêche actuellement un développeur de provisionner une ressource non conforme. Contraintes : Intégrer des policies as code via Sentinel ou OPA pour valider les plans avant apply. Livrable attendu : Proposer une architecture intégrant une couche de gouvernance permettant de bloquer les plans non conformes automatiquement.

Contexte : Une équipe souhaite déclencher automatiquement les plans et apply Terraform via des Pull Requests. Le Problème : Les déploiements sont exécutés localement, sans traçabilité centralisée. Contraintes : Utiliser Terraform Cloud ou backend distant, exécutions distantes, validation automatique et politique d'approbation avant apply. Livrable attendu : Proposer une architecture GitOps complète intégrant validation automatique, plan review et apply contrôlé en environnement sécurisé.

Contexte : Une infrastructure existante a été créée manuellement sur AWS et doit être progressivement migrée vers Terraform. Le Problème : Une recréation complète provoquerait une interruption de service critique. Contraintes : Utiliser terraform import, validation progressive et stratégie zero-downtime. Livrable attendu : Proposer un plan détaillé de migration progressive permettant d'importer les ressources existantes dans Terraform sans interruption de service.

Contexte : Une infrastructure importante comporte plusieurs centaines de ressources Terraform. Le Problème : Les commandes plan et apply deviennent lentes et difficiles à analyser. Contraintes : Mettre en place une stratégie de découpage logique, utilisation de depends_on minimale et parallélisation optimisée. Livrable attendu : Décrire une stratégie d'optimisation permettant d'améliorer les performances et la maintenabilité sur une infrastructure volumineuse.

Contexte : Une infrastructure AWS complète (VPC, subnets, EC2, RDS, IAM) est définie dans un seul repository Terraform monolithique utilisé par plusieurs équipes. Le Problème : Le code est difficile à maintenir, les changements ont des impacts imprévisibles et aucune version stable des composants n'est clairement définie. Contraintes : Extraire les composants critiques en modules versionnés, hébergés séparément. Garantir la compatibilité ascendante et éviter toute destruction accidentelle des ressources existantes. Livrable attendu : Proposer une stratégie de modularisation complète, incluant versionnement des modules, gestion des dépendances inter-modules et plan de migration progressif sécurisé.

Contexte : Une infrastructure nécessite de nombreux secrets dynamiques (credentials bases de données, tokens API). Le Problème : Les secrets sont actuellement stockés dans des variables Terraform statiques. Contraintes : Intégrer HashiCorp Vault comme source de secrets dynamiques sans exposer les données dans le state. Livrable attendu : Proposer une architecture Terraform intégrant Vault pour récupération sécurisée de secrets et minimisation des risques d'exposition dans le state.

Contexte : Une organisation déploie son infrastructure sur plusieurs comptes AWS distincts (shared-services, dev, prod). Le Problème : Les configurations actuelles ne distinguent pas clairement les comptes, créant un risque de déploiement dans le mauvais environnement. Contraintes : Utiliser plusieurs providers avec alias, rôles IAM assumés et isolation stricte des states. Livrable attendu : Proposer une architecture Terraform permettant des déploiements multi-comptes sécurisés avec providers aliasés et gestion robuste des identités.