Infrastructure as Code avec Terraform : de zéro à la production

Pourquoi l'Infrastructure as Code

L'Infrastructure as Code (IaC) consiste à gérer l'infrastructure via des fichiers de configuration versionnés plutôt que par des clics manuels dans une console cloud. Les avantages sont la reproductibilité (recréer un environnement identique en une commande), l'auditabilité (chaque changement est dans le git log) et la collaboration (review de PR sur l'infra comme sur le code).

Terraform : les concepts clés

Terraform utilise le langage HCL (HashiCorp Configuration Language) pour décrire l'état désiré de l'infrastructure. Il calcule le diff entre l'état actuel et l'état désiré, puis applique les changements nécessaires.

• Provider : plugin qui interface avec un cloud (AWS, GCP, Azure, Kubernetes...)
• Resource : un objet d'infrastructure (EC2 instance, S3 bucket, DNS record...)
• State : fichier JSON qui stocke l'état actuel de l'infra gérée par Terraform
• Plan : preview des changements avant application (terraform plan)
• Module : bloc de configuration réutilisable et paramétrable

Structure d'un projet Terraform

Une bonne structure de projet facilite la maintenance, le travail en équipe et la réutilisation.

infrastructure/
├── modules/
│   ├── networking/      # VPC, subnets, security groups
│   ├── compute/         # ECS, EC2, Lambda
│   ├── database/        # RDS, ElastiCache
│   └── monitoring/      # CloudWatch, alertes
├── environments/
│   ├── staging/
│   │   ├── main.tf      # Appelle les modules
│   │   ├── variables.tf # Variables spécifiques staging
│   │   └── terraform.tfvars
│   └── production/
│       ├── main.tf
│       ├── variables.tf
│       └── terraform.tfvars
├── backend.tf           # Config du state remote (S3)
└── versions.tf          # Versions des providers

State Management

Le state Terraform est critique — il mappe les ressources HCL aux ressources réelles dans le cloud. En équipe, le state doit être remote (S3 + DynamoDB pour le locking) pour éviter les conflits et les corruptions.

• Toujours utiliser un backend remote (S3 + DynamoDB lock) en équipe
• Activer le versioning du bucket S3 pour rollback le state en cas de corruption
• Ne jamais modifier le state manuellement (sauf terraform state mv/rm)
• Séparer les states par environnement ET par domaine pour limiter le blast radius
• Utiliser terraform plan en CI avant chaque apply — review obligatoire