Découvrir Terraform : Infrastructure as Code déclarative
À la fin de ce tutoriel, vous saurez ce qu’est Terraform, pourquoi l’Infrastructure as Code (IaC) déclarative change la gestion du cloud, quels concepts retenir (HCL, providers, state, plan/apply), et comment la série P2 s’articule en 22 étapes.
Niveau : Débutant · Temps estimé : 25–35 min · Versions testées : Terraform 1.9+, AWS provider 5.x · Dernière vérification : 2026-09-10
Slug proposé :
terraform-overview· Série : Terraform · Remplace / fusionne : #1597
Prérequis
- Avoir suivi (ou parcouru) le hub AWS : compte sécurisé, utilisateur IAM quotidien, CLI configurée
- Un terminal (bash, zsh ou PowerShell) et un éditeur de texte
- Aucune installation Terraform n’est exigée ici (le tuto Install suit)
- Notions de base : fichier de config, terminal, Region AWS
Coût estimé : 0 € — hub conceptuel. Les labs suivants créeront des ressources AWS ; gardez une alerte de budget active.
Ce que nous allons construire
Comprendre Terraform (hub P2)
├── Problème : clic console vs IaC
├── 4 idées : déclaratif, plan, graphe, providers
├── Comparaison courte (scripts / CloudFormation / Pulumi)
├── Anatomie d’un projet (.tf + state)
├── Mini config HCL (S3) commentée
├── Workflow aperçu : init → plan → apply → destroy
└── Carte des 22 tutos de la série(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Vue d’ensemble Terraform : IaC déclarative, state, providers et workflow ».)
Ce hub remplace le post #1597 (anglais marketing HashiCorp, Elementor, ~134 mots) par un contenu original, pédagogique, en français.
Étape 1 — Pourquoi l’IaC (le problème du clic console)
Créer un bucket S3, un VPC ou un ALB à la main dans la console fonctionne… jusqu’au moment où il faut reproduire l’environnement, le documenter, l’auditer, ou le reconstruire après incident.
Le clic console pose quatre problèmes :
- Non reproductible — personne ne se souvient de tous les réglages trois mois plus tard.
- Difficile à revoir — pas de pull request sur un clic.
- Dérive (drift) — la réalité cloud s’éloigne de ce que l’équipe croit avoir déployé.
- Lent à scaler — 1 Region → OK ; 3 comptes × 2 Regions → cauchemar.
L’Infrastructure as Code décrit l’infra dans des fichiers versionnés (Git). Terraform est un outil d’IaC déclaratif : vous déclarez l’état désiré ; Terraform calcule et applique les changements.
Étape 2 — Terraform en 4 idées
| Idée | En une phrase |
|---|---|
| Déclaratif | Vous décrivez ce que vous voulez (resource "aws_s3_bucket" …), pas comment appeler chaque API. |
| Plan | terraform plan montre le delta (create / update / destroy) avant de toucher au cloud. |
| Graphe / dépendances | Terraform ordonne les créations (subnet après VPC) via le graphe de ressources. |
| Providers | Plugins par plateforme (AWS, Azure, Kubernetes…). Un même workflow, des API différentes. |
Terraform lit du HCL, maintient un state (local ou distant) qui mappe ressources logiques ↔ IDs réels, puis propose un plan avant le apply.
Étape 3 — Terraform vs alternatives (bref, équitable)
Aucun outil n’est « le seul bon ». Choisissez selon le contexte.
| Approche | Style | Forces | Limites typiques |
|---|---|---|---|
| Scripts (bash, AWS CLI) | Impératif | Simple pour une action ponctuelle | Peu de plan, idempotence manuelle |
| CloudFormation | Déclaratif AWS-natif | Intégré AWS, StackSets | YAML/JSON verbeux ; multi-cloud limité |
| Pulumi | Langages généraux (TS, Python…) | Boucles et tests familiers | Courbe outillage + runtime |
| Terraform | Déclaratif HCL | Providers, plan clair, modules, multi-cloud | State à bien gérer ; HCL à apprendre |
Pour cette série : Terraform ≥ 1.9 + AWS provider 5.x. Objectif : maîtriser le workflow et les patterns utiles en lab.
Étape 4 — Anatomie d’un projet Terraform
mon-lab/
├── versions.tf # required_version + required_providers
├── providers.tf # configuration du provider aws
├── main.tf # resources
├── variables.tf # inputs (optionnel au début)
├── outputs.tf # valeurs exposées
└── terraform.tfstate # généré après apply (ne pas committer en clair)Conventions utiles :
- Un dossier = un root module (unité
init/plan/apply). - Les fichiers
*.tfsont fusionnés ; découpez pour la lisibilité. - Le state est la mémoire de Terraform : sans lui, il ne sait plus ce qu’il gère.
- En équipe : backend distant (S3 + lock — tuto dédié) ; zéro secret en clair dans Git.
Mise en forme sans toucher au cloud :
terraform fmt -recursiveÉtape 5 — Mini configuration HCL commentée
Exemple minimal : un bucket S3, versions épinglées. Lecture et fmt suffisent ici ; l’apply n’est pas obligatoire.
versions.tf :
terraform {
# Série testée avec Terraform 1.9+
required_version = ">= 1.9.0"
required_providers {
aws = {
source = "hashicorp/aws"
# AWS provider 5.x
version = "~> 5.0"
}
}
}providers.tf :
provider "aws" {
# Alignez la Region sur votre profil CLI (ex. eu-west-3)
region = "eu-west-3"
# Auth : profil nommé / variables d'environnement / SSO —
# jamais de access_key en dur dans les .tf
}main.tf :
resource "aws_s3_bucket" "lab_demo" {
bucket = "lab-demo-CHANGEZ-MOI-en-suffixe-unique"
tags = {
Project = "devopselastichayway"
Managed = "terraform"
Stage = "overview"
}
}Lecture rapide :
terraform { … }: contraintes d’outil et de providers.provider "aws": Region et auth implicite.resource "TYPE" "NAME": TYPE = type provider ; NAME = étiquette locale (aws_s3_bucket.lab_demo).
Quand Terraform sera installé (tuto suivant) :
terraform init # télécharge le provider aws ~> 5.0
terraform fmt
terraform validate
terraform plan # aperçu : + create (si credentials OK)
# apply / destroy → détail dans le tuto WorkflowÉtape 6 — Le workflow en une page (aperçu)
| Commande | Rôle |
|---|---|
terraform init |
Prépare le dossier : providers, modules, backend |
terraform plan |
Calcule le diff state ↔ config ; aucune mutation cloud |
terraform apply |
Applique le plan (souvent après confirmation) |
terraform destroy |
Détruit les ressources suivies dans le state |
Cycle mental : éditer les .tf → fmt / validate → plan (relire !) → apply → commit Git des .tf (pas du state sensible).
Le state lie aws_s3_bucket.lab_demo à l’ID réel. Une ressource créée à la main reste invisible tant qu’elle n’est pas importée (terraform import — plus tard).
Étape 7 — Carte de la série Terraform (P2, 22 tutos)
- Overview (cette page) — IaC, concepts, carte
- Install — Linux / Windows / macOS
- Workflow — init, plan, apply, destroy
- Blocks & language — syntaxe HCL
- Providers / resources — profondeur AWS provider
- Variables — inputs typés
- Locals — valeurs dérivées
- Outputs — exposer des résultats
- State & backend S3 + lock — state distant
- Data sources — lire l’existant
- Loops —
for_each/count/for - Conditionals — expressions conditionnelles
- Dynamic blocks — blocs dynamiques
- Modules (1/2) — écrire un module
- Modules (2/2) — consommer / registry
- Workspaces — isolations légères
- Provisioners — et pourquoi les éviter
- EBS — volumes
- ELB / ALB — équilibrage
- IAM — rôles et politiques en HCL
- RDS — base managée
- VPC (fusion) · Auto Scaling · Route 53 — réseau, scale, DNS
Chaque page garde la même structure (prérequis, étapes, nettoyage, erreurs, quiz).
Étape 8 — Vérification de fin de parcours
- Vous expliquez IaC déclarative vs clic console en 30 secondes.
- Vous citez les 4 idées : déclaratif, plan, graphe, providers.
- Vous situez Terraform face à scripts / CloudFormation / Pulumi sans caricature.
- Vous reconnaissez
versions.tf,provider,resource, et le rôle du state. - Vous connaissez l’ordre
init → plan → apply → destroy. - Prochain tuto : Installer Terraform.
Nettoyage
Rien à détruire dans AWS pour ce hub. Si vous avez quand même fait un apply du bucket démo :
terraform destroyVérifiez la console S3 (bonne Region). Ne committez ni *.tfstate ni credentials.
Erreurs fréquentes
| Symptôme | Cause | Correction |
|---|---|---|
| Confusion Terraform = CloudFormation | Vocabulaire mélangé | Terraform = multi-provider ; CloudFormation = service AWS natif |
| Tout scripter en bash « plus simple » | Habitude impérative | Bash pour le glue ; infra durable → déclaratif + plan |
| State commité dans Git | Mauvaise hygiène | .gitignore sur .tfstate ; backend S3+lock en équipe |
Access keys dans un .tf |
Anti-pattern sécurité | Profil CLI, env vars ou SSO — jamais de clés en clair |
plan ignoré / -auto-approve systématique |
Précipitation | Lire le plan : les destroys coûtent cher en attention |
Quiz (3 questions)
1. Que signifie « déclaratif » pour Terraform ?
- A. Vous écrivez chaque appel API AWS dans l’ordre exact
- B. Vous décrivez l’état désiré ; Terraform calcule les actions
- C. Vous devez utiliser CloudFormation en parallèle
2. À quoi sert principalement terraform plan ?
- A. Télécharger les providers
- B. Afficher le diff prévu sans modifier le cloud
- C. Supprimer le fichier de state
3. Pourquoi le state est-il critique ?
- A. Il remplace Git
- B. Il mappe la config vers les IDs réels dans le cloud
- C. Il contient obligatoirement vos access keys
Réponses : 1‑B · 2‑B · 3‑B
Pourquoi / quand lire ce hub en premier
Vous gagnez du temps en posant le vocabulaire avant d’installer le binaire ou de lancer un apply. Ce hub répond à la question « pourquoi Terraform plutôt que la console ? » sans vous faire payer une ressource AWS. Quand votre équipe bascule vers l’IaC, ce texte sert de référence commune : déclaratif, plan, graphe de dépendances, providers, state. Relisez-le après le premier lab Workflow : les mêmes mots prendront une valeur concrète.
Pièges à éviter dès le jour 1
- Confondre Terraform (outil multi-cloud) et CloudFormation (service AWS) : utiles tous les deux, périmètres différents.
- Croire que le HCL « exécute » comme un script bash : Terraform converge vers un état désiré ; l’ordre des fichiers
.tfn’est pas un ordre d’exécution séquentiel. - Sous-estimer le state : sans lui, Terraform ne sait pas ce qu’il a déjà créé. En lab, le state local suffit ; en équipe, visez S3 + verrouillage (tuto dédié).
- Coller des access keys dans un
.tf« pour aller plus vite » : utilisez un profil CLI / SSO ; Region de labca-central-1; Terraform ≥ 1.9. - Sauter le plan : un destroy non lu dans le plan reste le classique des incidents IaC.
FAQ complémentaire (overview)
Faut-il maîtriser AWS avant Terraform ? Des bases (Region, IAM, S3) aident. La série part du hub AWS et reste Free Tier friendly.
Terraform remplace-t-il Ansible ? Non. Terraform gère surtout le provisioning d’infra ; Ansible brille sur la configuration applicative. Ils se complètent souvent.
Puis-je tout faire en console puis « importer » ? Possible (terraform import), mais plus difficile. Préférez déclarer d’abord, appliquer ensuite.
Pourquoi une série en 22 tutos ? Chaque page isole une compétence (variables, state, modules…) pour éviter les pavés impossibles à maintenir.
Pour aller plus loin
- Doc officielle : Introduction to Terraform, AWS provider 5.x
- Sur ce site : après Install, enchaînez Workflow puis Blocks & language
- Rappel budget : une ressource oubliée (NAT Gateway, ALB) facture vite — le nettoyage fait partie du métier
Maillage série Terraform (P2)
| ← Précédent | — (hub de la série Terraform) |
| → Suivant | Installer Terraform (Linux, Windows, macOS) — à rédiger |
| Aussi | Workflow · Blocks & language · Providers/resources · State & backend S3+lock |
| Carte | Overview · Install · Workflow · Blocks · Providers · Variables · Locals · Outputs · State · Data sources · Loops · Conditionals · Dynamic blocks · Modules ×2 · Workspaces · Provisioners · EBS · ELB/ALB · IAM · RDS · VPC · Auto Scaling · Route 53 |
Cas réel — quand Terraform n’est pas le bon premier réflexe
Un atelier interne « on met tout dans Terraform » finit souvent par un state qui décrit aussi le DNS perso, un compte e-mail et trois secrets copiés-collés. Ce n’est pas de l’IaC : c’est un inventaire figé. Gardez Terraform pour ce qui a un cycle de vie cloud (réseau, compute, IAM, data stores). Les documents, les tickets et les runbooks restent hors state.
Piège fréquent : mesurer le succès au nombre de ressources dans le state plutôt qu’à la capacité de destroy puis recréer le lab. Si vous ne pouvez pas détruire sans peur, le module n’est pas encore un lab pédagogique — c’est déjà de la prod déguisée. En ca-central-1, un bucket + un rôle IAM suffisent à prouver le workflow ; n’ajoutez une VPC complète que lorsque le cours l’exige.
À retenir : Terraform décrit un écart, pas un souhait. Le plan est la vérité opérationnelle. Relisez chaque − comme s’il s’agissait d’une base de données, même quand ce n’est « que » un tag.
Retour parcours Terraform — hub de la série et leçons sœurs.
