Maîtrisez l'Infrastructure as Code avec Terraform et déployez des architectures AWS robustes, scalables et professionnelles. Une formation progressive, technique et complète pour étudiants, ingénieurs DevOps et candidats WorldSkills.
Ce guide exhaustif couvre l'ensemble de l'écosystème Terraform, de l'initiation aux architectures les plus avancées. Chaque section est conçue pour vous faire progresser méthodiquement, avec des exemples concrets orientés AWS.
IaC, concepts fondateurs et positionnement sur le marché DevOps
Core, Providers, State, Graphs et workflow détaillé
Resources, Variables, Modules, Workspaces et Lifecycle
Provider AWS, authentification, API et bonnes pratiques IAM
VPC, EC2, S3, ALB et architectures complètes avec code
Remote backend, locking DynamoDB et architecture modulaire
CI/CD, Terraform Cloud, Terragrunt et sécurité
Multi-account, Blue/Green, DR et bonnes pratiques avancées
Terraform est un outil open-source développé par HashiCorp qui permet de définir, provisionner et gérer l'infrastructure informatique à travers du code déclaratif. Plutôt que de cliquer manuellement dans une console cloud ou d'exécuter des scripts impératifs, vous décrivez l'état souhaité de votre infrastructure dans des fichiers .tf, et Terraform se charge de la créer, la modifier ou la détruire automatiquement.
Terraform utilise le langage HCL (HashiCorp Configuration Language), un langage lisible conçu pour être à la fois humain-friendly et machine-parsable. Il supporte plus de 3 000 providers — AWS, Azure, GCP, Kubernetes, GitHub, Datadog, et bien d'autres — ce qui en fait l'outil d'IaC le plus polyvalent du marché.
L'Infrastructure as Code est un paradigme fondamental du DevOps moderne. Il consiste à gérer et provisionner l'infrastructure via des fichiers de configuration plutôt que par des processus manuels. Les avantages sont considérables :
- Reproductibilité : déployez la même infrastructure en un clic
- Versioning : chaque changement est tracé dans Git
- Collaboration : les équipes travaillent sur le même code
- Auditabilité : historique complet des modifications
- Automatisation : intégration dans les pipelines CI/CD
Déclaratif (Terraform, CloudFormation) : vous décrivez ce que vous voulez. L'outil détermine comment y arriver.
Impératif (Scripts Bash, SDK AWS) : vous décrivez étape par étape les actions à exécuter.
Terraform adopte l'approche déclarative, ce qui simplifie la gestion de l'état et réduit les erreurs humaines.
En quelques années, Terraform s'est imposé comme la référence incontournable de l'Infrastructure as Code. Son adoption massive s'explique par une combinaison unique d'avantages que ses concurrents ne parviennent pas à égaler simultanément.
Un seul outil pour AWS, Azure, GCP et des centaines d'autres services. Aucun vendor lock-in.
Écosystème massif : +3 000 providers, Terraform Registry, modules communautaires et documentation riche.
Architecture modulaire qui permet de réutiliser et partager des composants d'infrastructure comme du code applicatif.
Plan d'exécution prévisible, state management robuste et idempotence garantie à chaque déploiement.
Comprendre l'architecture interne de Terraform est essentiel pour diagnostiquer les problèmes, optimiser les performances et maîtriser le comportement de l'outil en production. Terraform n'est pas une simple CLI — c'est un moteur d'orchestration sophistiqué qui construit des graphes de dépendances, communique avec des APIs externes et maintient un état cohérent de votre infrastructure.
Le moteur principal écrit en Go. Il parse les fichiers HCL, construit le graphe de dépendances, calcule le plan d'exécution et orchestre les appels aux providers. C'est le cerveau de Terraform.
Des binaires indépendants qui implémentent les APIs de chaque service cloud. Le provider AWS traduit vos ressources HCL en appels API AWS. Chaque provider est versionné et maintenu séparément.
Le fichier terraform.tfstate est la source de vérité. Il mappe vos ressources déclarées aux ressources réelles dans le cloud. Sans lui, Terraform ne peut pas déterminer les changements nécessaires.
Le système de stockage du state. Peut être local (par défaut) ou distant (S3, Terraform Cloud, Consul). Le backend distant permet le travail d'équipe et le verrouillage du state.
Terraform utilise trois types de graphes internes pour orchestrer le déploiement de manière optimale et sûre. Ces graphes sont au cœur de sa capacité à paralléliser les opérations tout en respectant les dépendances.
Représente les relations entre toutes les ressources. Par exemple, un Security Group doit exister avant l'instance EC2 qui le référence. Terraform le détecte automatiquement via les références.
Graphe généré lors de terraform plan. Il compare l'état actuel (state) avec l'état désiré (code) et calcule les opérations nécessaires : create, update ou destroy.
Graphe final utilisé par terraform apply. Il détermine l'ordre d'exécution optimal, parallélise les opérations indépendantes et sérialise les dépendantes.
Chaque commande déclenche des processus internes distincts. terraform init télécharge les providers et initialise le backend. terraform plan lit le state, interroge les APIs pour détecter les drifts, puis génère un diff. terraform apply exécute les changements en respectant le graphe de dépendances. terraform destroy inverse le graphe et supprime les ressources en ordre inverse.
Avant de déployer quoi que ce soit, il est impératif de maîtriser les briques de base du langage HCL et de l'écosystème Terraform. Chaque concept joue un rôle précis dans la construction d'une infrastructure maintenable et évolutive. Voici les éléments essentiels que tout ingénieur DevOps doit connaître parfaitement.
Le provider est le pont entre Terraform et un service externe. Il expose les ressources et data sources disponibles pour un cloud ou une API donnée.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "eu-west-1"
}Le bloc required_providers verrouille la version du provider pour assurer la reproductibilité. Le bloc provider configure les paramètres de connexion (région, profil, credentials).
Les resources sont les éléments d'infrastructure que Terraform crée et gère. Chaque resource correspond à un objet réel dans le cloud.
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t3.micro"
subnet_id = aws_subnet.main.id
tags = {
Name = "WebServer"
Environment = "production"
}
}Les data sources permettent de lire des informations existantes sans les gérer. Idéal pour référencer des ressources créées hors Terraform.
data "aws_ami" "ubuntu" {
most_recent = true
owners = ["099720109477"]
filter {
name = "name"
values = ["ubuntu/images/hvm-ssd/*"]
}
}La gestion des données dans Terraform repose sur trois mécanismes complémentaires qui rendent votre code flexible, réutilisable et lisible. Maîtriser leur utilisation est indispensable pour écrire du Terraform de qualité professionnelle.
Paramètres d'entrée qui rendent le code configurable. Supportent les types string, number, bool, list, map et object. Définies avec des valeurs par défaut et des validations.
variable "instance_type" {
type = string
default = "t3.micro"
description = "Type d'instance EC2"
validation {
condition = contains(["t3.micro","t3.small"], var.instance_type)
error_message = "Type non autorisé."
}
}Valeurs exportées après le déploiement. Essentielles pour la communication inter-modules et l'affichage d'informations utiles (IPs, URLs, ARNs).
output "instance_public_ip" {
value = aws_instance.web.public_ip
description = "IP publique du serveur"
}Variables calculées internes au module. Permettent de factoriser des expressions complexes et d'éviter la répétition de code.
locals {
common_tags = {
Project = var.project_name
Environment = var.environment
ManagedBy = "terraform"
}
}Les modules sont des conteneurs réutilisables de configuration Terraform. Ils encapsulent un ensemble de ressources liées (ex : un module VPC, un module EC2). Ils acceptent des variables en entrée et exposent des outputs.
module "vpc" {
source = "./modules/vpc"
cidr_block = "10.0.0.0/16"
environment = var.environment
}Les workspaces permettent de gérer plusieurs états (state files) pour une même configuration. Chaque workspace a son propre terraform.tfstate, idéal pour séparer dev/staging/prod.
terraform workspace new staging
terraform workspace select prod
terraform workspace listLe bloc lifecycle contrôle le comportement de création et destruction. depends_on force des dépendances explicites quand Terraform ne peut pas les détecter automatiquement.
resource "aws_instance" "web" {
lifecycle {
create_before_destroy = true
prevent_destroy = true
ignore_changes = [tags]
}
}L'intégration entre Terraform et AWS est l'une des plus matures et des plus utilisées dans l'écosystème. Comprendre comment ces deux outils communiquent est fondamental pour diagnostiquer les erreurs, optimiser les performances et sécuriser vos déploiements. Le provider AWS de Terraform est le plus téléchargé du registry avec des milliards de téléchargements.
La sécurité de l'authentification est un pilier critique de tout déploiement Terraform. Plusieurs méthodes existent, chacune adaptée à un contexte spécifique. En production, les méthodes basées sur les rôles IAM sont toujours préférables aux clés statiques.
Méthode la plus simple : AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY en variables d'environnement. À éviter en production — risque d'exposition.
Utilise les profils configurés via aws configure. Le provider référence le profil avec profile = "mon-profil". Convenable pour le développement local.
Méthode recommandée en production. Les instances EC2 ou runners CI/CD assument un rôle IAM automatiquement. Aucune clé statique nécessaire.
Permet de basculer vers un rôle dans un autre compte AWS. Essentiel pour le multi-account et le principe du moindre privilège.
provider "aws" {
region = "eu-west-1"
assume_role {
role_arn = "arn:aws:iam::123456789012:role/TerraformDeployRole"
session_name = "terraform-deploy"
external_id = "unique-external-id"
}
}Passons à la pratique avec des exemples concrets et complets. Chaque déploiement est accompagné du code intégral, d'explications détaillées et du diagramme d'architecture correspondant. Ces exemples couvrent les cas d'usage les plus courants que vous rencontrerez en entreprise ou en compétition WorldSkills.
Le VPC (Virtual Private Cloud) est la fondation de toute infrastructure AWS. Il isole logiquement vos ressources et contrôle le flux réseau. Voici un déploiement complet avec subnet public, Internet Gateway et table de routage.
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
enable_dns_support = true
enable_dns_hostnames = true
tags = { Name = "main-vpc" }
}
resource "aws_subnet" "public" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.1.0/24"
availability_zone = "eu-west-1a"
map_public_ip_on_launch = true
tags = { Name = "public-subnet" }
}
resource "aws_internet_gateway" "igw" {
vpc_id = aws_vpc.main.id
tags = { Name = "main-igw" }
}
resource "aws_route_table" "public" {
vpc_id = aws_vpc.main.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.igw.id
}
tags = { Name = "public-rt" }
}
resource "aws_route_table_association" "public" {
subnet_id = aws_subnet.public.id
route_table_id = aws_route_table.public.id
}VPC (10.0.0.0/16) : réseau privé virtuel avec 65 536 adresses IP disponibles.
Subnet public (10.0.1.0/24) : sous-réseau de 256 adresses avec attribution automatique d'IP publiques.
Internet Gateway : passerelle qui connecte le VPC à Internet. Sans elle, aucune communication externe n'est possible.
Route Table : dirige le trafic 0.0.0.0/0 (tout Internet) vers l'IGW. L'association lie la table au subnet.
💡 Ce pattern est la base de 90% des architectures AWS.
Déployer une instance EC2 requiert plusieurs ressources complémentaires : un Security Group pour le pare-feu, une Key Pair pour l'accès SSH, et optionnellement une Elastic IP pour une adresse statique.
resource "aws_security_group" "web_sg" {
name = "web-server-sg"
description = "Autorise HTTP et SSH"
vpc_id = aws_vpc.main.id
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
description = "HTTP depuis Internet"
}
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["YOUR_IP/32"]
description = "SSH restreint"
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
resource "aws_key_pair" "deployer" {
key_name = "deployer-key"
public_key = file("~/.ssh/id_rsa.pub")
}
resource "aws_instance" "web" {
ami = data.aws_ami.ubuntu.id
instance_type = "t3.micro"
subnet_id = aws_subnet.public.id
vpc_security_group_ids = [aws_security_group.web_sg.id]
key_name = aws_key_pair.deployer.key_name
tags = { Name = "WebServer", Environment = "production" }
}
resource "aws_eip" "web_eip" {
instance = aws_instance.web.id
domain = "vpc"
}resource "aws_s3_bucket" "data" {
bucket = "my-app-data-${var.env}"
tags = local.common_tags
}
resource "aws_s3_bucket_versioning" "data" {
bucket = aws_s3_bucket.data.id
versioning_configuration {
status = "Enabled"
}
}
resource "aws_iam_role" "s3_access" {
name = "s3-access-role"
assume_role_policy = data.aws_iam_policy_document.assume.json
}
resource "aws_iam_role_policy" "s3_policy" {
role = aws_iam_role.s3_access.id
policy = data.aws_iam_policy_document.s3.json
}resource "aws_lb" "app" {
name = "app-alb"
internal = false
load_balancer_type = "application"
security_groups = [aws_security_group.alb.id]
subnets = aws_subnet.public[*].id
}
resource "aws_autoscaling_group" "app" {
name = "app-asg"
desired_capacity = 2
max_size = 10
min_size = 1
vpc_zone_identifier = aws_subnet.private[*].id
launch_template {
id = aws_launch_template.app.id
version = "$Latest"
}
target_group_arns = [aws_lb_target_group.app.arn]
}Ces architectures représentent les patterns fondamentaux de tout déploiement AWS professionnel. Le bucket S3 avec versioning et IAM role illustre la gestion sécurisée du stockage. L'ALB couplé à un Auto Scaling Group garantit la haute disponibilité et l'élasticité automatique de votre application.
Le fichier terraform.tfstate est probablement le composant le plus critique — et le plus dangereux — de tout déploiement Terraform. C'est la source de vérité absolue : il contient le mapping complet entre vos ressources déclarées en HCL et les ressources réelles existantes dans AWS. Sans ce fichier, Terraform est aveugle.
Le state stocke les IDs de toutes les ressources, leurs attributs actuels, les métadonnées des providers, les dépendances calculées et la version du format. Il peut contenir des données sensibles (mots de passe, clés API) en clair.
Le state contient des secrets, peut créer des conflits en équipe et risque d'être corrompu. Un state local partagé via Git = des désastres garantis (destruction accidentelle de ressources, conflits d'état).
La solution standard : stocker le state dans un bucket S3 chiffré avec versioning activé. Permet le partage sécurisé en équipe et la récupération en cas de corruption.
Empêche deux personnes d'exécuter terraform apply simultanément. DynamoDB fournit un verrou distribué (lock) qui protège contre les corruptions concurrentes.
terraform {
backend "s3" {
bucket = "my-terraform-state-bucket"
key = "prod/infrastructure/terraform.tfstate"
region = "eu-west-1"
encrypt = true
dynamodb_table = "terraform-state-lock"
# Optionnel : KMS key pour chiffrement avancé
# kms_key_id = "arn:aws:kms:eu-west-1:..."
}
}
# Ressources pour créer le backend (à faire une seule fois)
resource "aws_s3_bucket" "tf_state" {
bucket = "my-terraform-state-bucket"
}
resource "aws_s3_bucket_versioning" "tf_state" {
bucket = aws_s3_bucket.tf_state.id
versioning_configuration { status = "Enabled" }
}
resource "aws_dynamodb_table" "tf_lock" {
name = "terraform-state-lock"
billing_mode = "PAY_PER_REQUEST"
hash_key = "LockID"
attribute {
name = "LockID"
type = "S"
}
}
Les modules sont la clé d'une infrastructure Terraform maintenable à grande échelle. Ils transforment du code monolithique en composants réutilisables, testables et versionnés — exactement comme les bibliothèques en développement logiciel.
Stockés dans votre repository. Parfaits pour la logique métier spécifique à votre organisation.
Modules communautaires validés par HashiCorp. Ex : terraform-aws-modules/vpc/aws.
Chaque module versionné via Git tags. Utilisez les contraintes : version = "~> 3.0".
modules/
├── vpc/
│ ├── main.tf # Ressources principales
│ ├── variables.tf # Variables d'entrée
│ ├── outputs.tf # Valeurs exportées
│ ├── versions.tf # Contraintes provider
│ └── README.md # Documentation
├── ec2/
│ ├── main.tf
│ ├── variables.tf
│ └── outputs.tf
└── rds/
├── main.tf
├── variables.tf
└── outputs.tfenvironments/
├── dev/
│ ├── main.tf # module "vpc" { source = "../../modules/vpc" }
│ ├── terraform.tfvars # instance_type = "t3.micro"
│ └── backend.tf # key = "dev/terraform.tfstate"
├── staging/
│ ├── main.tf
│ ├── terraform.tfvars # instance_type = "t3.small"
│ └── backend.tf # key = "staging/terraform.tfstate"
└── prod/
├── main.tf
├── terraform.tfvars # instance_type = "t3.large"
└── backend.tf # key = "prod/terraform.tfstate"Cette structure garantit que le même code est déployé dans chaque environnement avec des paramètres différents. Les modules sont partagés, seules les variables changent. C'est le pattern recommandé par HashiCorp et utilisé en compétition WorldSkills.
En entreprise, Terraform ne fonctionne jamais en isolation. Il s'intègre dans des pipelines CI/CD, des outils de gouvernance et des systèmes de gestion des secrets. Cette section couvre les pratiques professionnelles qui distinguent un déploiement amateur d'une infrastructure de production.
Le développeur pousse ses changements HCL sur une branche feature
terraform plan s'exécute dans la CI et le résultat est posté en commentaire de la PR
L'équipe review le plan, valide les changements et merge dans main
terraform apply -auto-approve s'exécute après merge sur la branche principale
name: Terraform Deploy
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
terraform:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
- name: Terraform Init
run: terraform init
- name: Terraform Plan
run: terraform plan -out=tfplan
if: github.event_name == 'pull_request'
- name: Terraform Apply
run: terraform apply -auto-approve tfplan
if: github.ref == 'refs/heads/main'Plateforme SaaS de HashiCorp offrant : exécution distante des plans, state management intégré, contrôle d'accès RBAC, intégration VCS native et coût estimé automatique. Idéal pour les équipes qui veulent une solution clé en main.
Wrapper autour de Terraform qui simplifie la gestion multi-environnement. Il élimine la duplication de code backend, gère les dépendances entre modules et applique le DRY (Don't Repeat Yourself) à vos configurations.
Utilisez Sentinel (HashiCorp) ou OPA (Open Policy Agent) pour définir des règles automatisées. Ex : interdire les instances non chiffrées, forcer les tags obligatoires, limiter les régions autorisées.
Détecte les modifications manuelles effectuées hors Terraform. Exécutez terraform plan régulièrement via un cron CI pour identifier les dérives et les corriger avant qu'elles ne causent des incidents.
Ne jamais stocker de secrets dans le code ou les variables. Utilisez AWS Secrets Manager, HashiCorp Vault ou les variables d'environnement CI/CD. Référencez-les via data sources dans Terraform.
Cette section s'adresse aux ingénieurs confirmés et aux candidats aux compétitions WorldSkills Cloud Computing. Les architectures présentées ici représentent l'état de l'art en matière de déploiement d'infrastructure. Maîtriser ces patterns vous distinguera des autres candidats et vous préparera aux défis les plus complexes du monde professionnel.
En entreprise, chaque environnement (dev, staging, prod) vit dans un compte AWS séparé pour l'isolation de sécurité. Terraform gère cette complexité via assume_role et des providers aliasés.
provider "aws" {
alias = "production"
region = "eu-west-1"
assume_role {
role_arn = "arn:aws:iam::PROD_ACCT:role/Deploy"
}
}
provider "aws" {
alias = "staging"
region = "eu-west-1"
assume_role {
role_arn = "arn:aws:iam::STG_ACCT:role/Deploy"
}
}
resource "aws_instance" "prod_web" {
provider = aws.production
# ...
}Pour la haute disponibilité et la disaster recovery, déployez les ressources dans plusieurs régions AWS simultanément. Terraform gère cela avec des providers aliasés par région.
provider "aws" {
alias = "primary"
region = "eu-west-1"
}
provider "aws" {
alias = "secondary"
region = "us-east-1"
}
module "primary_infra" {
source = "./modules/infra"
providers = { aws = aws.primary }
}
module "dr_infra" {
source = "./modules/infra"
providers = { aws = aws.secondary }
}Deux environnements identiques coexistent. Le trafic est basculé du « blue » (actuel) vers le « green » (nouveau) via un changement de DNS ou d'ALB listener. Rollback instantané en cas de problème.
resource "aws_lb_listener_rule" "green" {
listener_arn = aws_lb_listener.main.arn
action {
type = "forward"
target_group_arn = var.is_green_active ?
aws_lb_target_group.green.arn :
aws_lb_target_group.blue.arn
}
}Envoyez un petit pourcentage du trafic (5-10%) vers la nouvelle version. Surveillez les métriques CloudWatch. Si tout est stable, augmentez progressivement. Terraform gère les weighted target groups de l'ALB.
Combinez create_before_destroy = true, les health checks ALB et les rolling updates de l'ASG. L'ancienne infrastructure n'est détruite qu'après validation de la nouvelle.
Architecture multi-région avec réplication S3 cross-region, RDS read replicas, Route 53 failover routing et AMI copies automatiques. Le RTO (Recovery Time Objective) vise moins de 15 minutes.
La différence entre un déploiement Terraform fonctionnel et un déploiement professionnel réside dans le respect de conventions strictes. Ces bonnes pratiques ont été validées par la communauté, les équipes HashiCorp et les experts en compétitions internationales.
project/
├── environments/
│ ├── dev/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── outputs.tf
│ │ ├── terraform.tfvars
│ │ └── backend.tf
│ ├── staging/
│ └── prod/
├── modules/
│ ├── networking/
│ ├── compute/
│ ├── database/
│ └── security/
├── .gitignore
├── .terraform-version
└── README.md{project}-{env}-{resource}-{description}
Ex : myapp-prod-ec2-webserver
Tags obligatoires sur chaque ressource :
Project
Environment
ManagedBy = terraform
Owner
CostCenter
- Least privilege : permissions minimales pour chaque rôle
- Pas de credentials hardcodées : utilisez des rôles IAM
- State chiffré : S3 + KMS obligatoire
- Secrets externalisés : AWS Secrets Manager ou Vault
- MFA pour les opérations destructrices
Même les ingénieurs expérimentés commettent ces erreurs. Les connaître en amont vous épargnera des heures de debugging et potentiellement des incidents de production. Chaque erreur listée ici a causé des problèmes réels en entreprise ou en compétition.
State local partagé via Git, absence de locking, pas de versioning S3. Conséquence : corruption du state, perte de ressources, déploiements conflictuels. Solution : Remote backend S3 + DynamoDB dès le jour 1.
Clés AWS écrites en dur dans les fichiers .tf. Conséquence : Fuite de secrets si le repo est public ou compromis. Solution : Variables d'environnement, IAM roles, AWS Vault.
Oublier depends_on quand Terraform ne peut pas détecter automatiquement la dépendance. Conséquence : Erreurs de déploiement aléatoires. Solution : Utiliser les références implicites ou depends_on explicite.
Modules trop gros (god modules) ou trop granulaires. Conséquence : Code impossible à maintenir. Solution : Un module = une responsabilité logique (réseau, compute, database).
Modifications manuelles dans la console AWS non reflétées dans le code. Conséquence : Le prochain apply écrase les changements manuels. Solution : Plan automatique régulier + interdiction des changements manuels.
Une confusion fréquente chez les débutants concerne le positionnement de Terraform par rapport à Kubernetes et Docker. Ces outils sont complémentaires, pas concurrents. Chacun opère à un niveau différent de la stack.
Docker
Kubernetes / ECS
Terraform
Niveau : Application
Empaquette votre code et ses dépendances dans un conteneur portable. Répond à la question : "Comment exécuter mon application de manière identique partout ?"
Niveau : Orchestration
Gère le déploiement, le scaling et la santé des conteneurs. Répond à la question : "Comment faire tourner mes conteneurs en production de manière fiable ?"
Niveau : Infrastructure
Provisionne les serveurs, réseaux et services cloud sur lesquels Kubernetes et Docker s'exécutent. Répond à la question : "Comment créer l'infrastructure elle-même ?"
En pratique, Terraform crée le cluster EKS (Kubernetes managé AWS), Docker build les images applicatives, et Kubernetes orchestre les conteneurs sur le cluster. Les trois outils forment la chaîne complète du DevOps moderne.
Cette roadmap progressive vous guide de vos premiers pas avec Terraform jusqu'au niveau expert requis pour les compétitions internationales et les postes senior en entreprise. Chaque étape nécessite environ 2 à 4 mois de pratique régulière.
Syntaxe HCL, resources de base, premier déploiement EC2
Modules, remote state, variables complexes, CI/CD
Multi-account, Policy as Code, architectures HA
Custom providers, DR, WorldSkills, architectures à grande échelle
Que vous prépariez la certification AWS Solutions Architect, AWS DevOps Engineer ou la compétition WorldSkills Cloud Computing, maîtriser Terraform est un avantage décisif. Cette section vous donne les clés pour exceller dans ces épreuves exigeantes.
Remote backend, locking, import, state mv. En compétition, une erreur de state peut vous faire perdre 30 minutes précieuses. Automatisez tout.
Arrivez avec vos propres modules testés. VPC, EC2, RDS, ALB — prêts à l'emploi avec des variables paramétrables. Gain de temps énorme.
VPC, subnets, route tables, NAT Gateway, NACLs, Security Groups. Le réseau est la base de tout. Une erreur ici bloque tout le reste.
Policies, Roles, Instance Profiles, cross-account access. La sécurité est évaluée dans chaque épreuve. Least privilege = points bonus.
Certaines API AWS ne sont pas immédiatement cohérentes. Un terraform apply peut échouer si une ressource n'est pas encore propagée. Utilisez depends_on et des time_sleep si nécessaire.
Les dépendances inversées lors du destroy peuvent causer des erreurs. Un ALB avec des listeners actifs ne peut pas être supprimé tant que les target groups ne sont pas vidés.
Les comptes de compétition ont souvent des limites strictes (nombre d'EIPs, vCPUs). Vérifiez les quotas avant de déployer et optimisez votre architecture en conséquence.
Lisez TOUT avant de coder. Identifiez les dépendances entre les parties. Certaines tâches dépendent d'autres — commencez par la fondation (VPC, IAM).
Arrivez avec une bibliothèque de modules testés et documentés. En compétition, copier-coller un module fonctionnel prend 30 secondes vs 20 minutes de rédaction.
Ne codez pas tout puis apply. Faites des apply fréquents pour détecter les erreurs tôt. Un plan de 50 ressources qui échoue est impossible à debugger rapidement.
Utilisez des outputs pour vérifier rapidement que vos ressources sont correctement créées : IPs, DNS, ARNs. Ne perdez pas de temps dans la console AWS.
Les évaluateurs vérifient la propreté du code, les tags, la documentation. Réservez 15 minutes en fin d'épreuve pour le polish final.
Oui, Terraform CLI est open-source et gratuit. Terraform Cloud offre un tier gratuit pour les petites équipes (jusqu'à 5 utilisateurs). Les plans payants ajoutent la gouvernance, le SSO et le support.
Absolument. Terraform supporte des providers pour GitHub, Datadog, PagerDuty, Kubernetes, Cloudflare, et des centaines d'autres services. Tout ce qui a une API peut potentiellement avoir un provider.
Utilisez un remote backend (S3 + DynamoDB pour AWS) ou Terraform Cloud. Activez le locking, le chiffrement et le versioning. Ne commitez JAMAIS le state dans Git.
Si vous êtes 100% AWS et ne prévoyez pas de changer : CloudFormation suffit. Si vous voulez du multi-cloud, un écosystème plus riche ou une syntaxe plus lisible : Terraform est le choix recommandé.
La documentation HashiCorp (developer.hashicorp.com/terraform) est la référence ultime. Complétez avec le Terraform Registry pour les exemples de modules communautaires.
HashiCorp Terraform Associate pour valider vos compétences. Complétez avec AWS Solutions Architect Associate et AWS DevOps Engineer Professional pour un profil complet.
Créez un lab personnel sur AWS (Free Tier). Déployez, détruisez, recommencez. Contribuez à des modules open-source sur le Terraform Registry. La pratique fait la maîtrise.
"Infrastructure as Code n'est pas qu'une technologie — c'est une philosophie qui transforme la façon dont nous construisons et gérons le cloud."
— La communauté DevOps mondiale