TP : Infrastructure as Code avec Terraform avec correction

Ce que vous allez apprendre dans ce TP

• Décrire une ressource en HCL
• Appliquer avec plan puis apply
• Détecter une dérive

Terraform + LocalStack #

Ce que vous allez apprendre dans cette section

• Décrire une ressource en HCL
• Appliquer avec plan puis apply
• Détecter une dérive

Contexte. Une infrastructure créée à la main est impossible à reproduire et à auditer. L'Infrastructure as Code décrit les ressources dans des fichiers versionnés : vous le pratiquez avec Terraform et détectez ce qu'est une dérive de configuration.

Prérequis : TP précédent (LocalStack), Terraform installé  ·  Durée estimée : 40 min

Un bucket versionné décrit en HCL.

1. 1. Configurer le provider

   Pourquoi ? Le provider indique à Terraform quelle API cibler ; en le pointant sur LocalStack, le même code fonctionnerait sur le vrai AWS en retirant les surcharges.

   Pointez le provider AWS vers LocalStack.
   Voir la correction

   # main.tf
   terraform {
     required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } }
   }
   provider "aws" {
     region = "eu-west-3"
     access_key = "test"
     secret_key = "test"
     skip_credentials_validation = true
     skip_requesting_account_id  = true
     s3_use_path_style           = true
     endpoints { s3 = "http://localhost:4566" }
   }

2. 2. Décrire la ressource

   Pourquoi ? Décrire le versioning et les étiquettes dans le code garantit qu'ils seront identiques partout et auditables dans Git.

   Créez un bucket avec le versioning et une étiquette env=lab.
   Voir la correction

   variable "nom" { default = "rapports-tf" }
   resource "aws_s3_bucket" "b" { bucket = var.nom  tags = { env = "lab", equipe = "plateforme" } }
   resource "aws_s3_bucket_versioning" "v" {
     bucket = aws_s3_bucket.b.id
     versioning_configuration { status = "Enabled" }
   }
   output "arn" { value = aws_s3_bucket.b.arn }

3. 3. Plan et application

   Pourquoi ? plan montre ce qui va changer avant de le faire : c'est le garde-fou qui évite les destructions accidentelles.

   Exécutez le cycle complet et observez l'état.
   Voir la correction

   terraform init
   terraform fmt -check && terraform validate
   terraform plan -out=tfplan
   terraform apply tfplan
   terraform state list && terraform output

4. 4. Dérive et destruction

   Pourquoi ? Modifier à la main puis relancer plan fait comprendre la dérive : l'état réel s'écarte du code, et Terraform propose de le corriger.

   Modifiez la ressource à la main, détectez la dérive, puis détruisez l'infrastructure.
   Voir la correction

   aws --endpoint-url http://localhost:4566 s3api put-bucket-versioning --bucket rapports-tf --versioning-configuration Status=Suspended
   terraform plan        # montre la dérive à corriger
   terraform apply -auto-approve
   terraform destroy -auto-approve

Niveau de difficulté : ●●○○○ (2/5)