Terraform Infrastructure Code en pratique : le code et les commandes qui comptent vraiment

Terraform Infrastructure Code : l'essentiel en un article — vrai code, schémas et étapes concrètes, extraits d'un cours de 38 leçons.

Terraform Infrastructure Code en pratique : le code et les commandes qui comptent vraiment

Pas de théorie interminable ici : on ouvre le terminal et on pratique. Voici l'essentiel de Terraform Infrastructure Code, extrait directement d'un cours complet de 38 leçons — avec du vrai code que tu peux copier-coller maintenant.

tl;dr
  • Introduction a Terraform et l'IaC
  • Installation et Premiers Pas
  • Langage HCL Providers Variables et Ressources
  • Modules et Organisation du Code
  • State Backend Distant et Workspaces
~$ cat ./parcours.md # Terraform Infrastructure Code — 10 chapitres
01
Introduction à Terraform et l'IaC
→ Chapitre 00 – Leçon 1 : Pourquoi l'IaC ? Pourquoi Terraform ?→ Chapitre 00 – Leçon 2 : Le Cycle de Vie Terraform — init, plan, apply, destroy+ 1 autres leçons
02
Installation et Premiers Pas
→ Chapitre 01 – Leçon 1 : Installation de Terraform sur Windows, Linux et macOS→ Chapitre 01 – Leçon 2 : Premier Projet — Déployer une Instance EC2 sur AWS+ 1 autres leçons
03
Langage HCL Providers Variables et Ressources
→ Chapitre 02 – Leçon 1a : Syntaxe HCL et Blocs Fondamentaux→ Chapitre 02 – Leçon 1b : Types, Expressions et Variables Locales+ 4 autres leçons
04
Modules et Organisation du Code
→ Chapitre 03 – Leçon 1 : Créer et Utiliser des Modules Locaux→ Chapitre 03 – Leçon 2 : Registre Terraform, Modules Publics et Versioning+ 2 autres leçons
05
State Backend Distant et Workspaces
→ Chapitre 04 – Leçon 1 : Gestion de l'État Terraform — terraform.tfstate→ Chapitre 04 – Leçon 2 : Backend Distant — S3 + DynamoDB et Terraform Cloud+ 1 autres leçons
06
CICD Sécurité et Bonnes Pratiques
→ Chapitre 05 – Leçon 1a : Pipeline Terraform avec GitHub Actions et OIDC→ Chapitre 05 – Leçon 1b : Pipeline Terraform avec Jenkins+ 3 autres leçons
07
Labs Guides Pratiques AWS
→ Chapitre 06 – Lab 01 : Site Statique S3 + CloudFront (Étape par Étape)→ Chapitre 06 – Lab 02 : Module VPC Réutilisable Multi-Environnements+ 2 autres leçons
08
Terraform avec Microsoft Azure
→ Chapitre 07 – Leçon 1 : Azure Fondamentaux et Authentification Terraform→ Chapitre 07 – Leçon 2 : Premier Projet Azure — VNet, NSG et VM Linux+ 2 autres leçons
🏁
Projet final (+ 2 chapitres en chemin)
→ Tu repars avec un projet concret et démontrable

Chapitre 08 – Leçon 2 : Premier Projet GCP — VPC, Firewall et Compute Engine

NOTEObjectif — Déployer une infrastructure GCP de base : un VPC custom-mode avec subnet régional, des règles firewall (SSH + HTTP), et une instance Compute Engine avec serveur Nginx provisionné via startup script.

1. Prérequis

Avant de démarrer, assurez-vous que tous les éléments ci-dessous sont en place. Sans ces prérequis, le terraform apply échouera avec des erreurs d'authentification ou d'API non activée.

1.1 Comptes et outils

1.2 Identifiants GCP à récupérer

Vous aurez besoin de ces informations pour configurer le provider Terraform et authentifier les API calls :

ÉlémentComment l'obtenirExemple
Project ID (string court)gcloud config get-value projectmon-projet-tf-prod
Project Number (12 chiffres)gcloud projects describe PROJECT_ID --format="value(projectNumber)"123456789012
Organization ID (optionnel)gcloud organizations list987654321000
Billing Account IDgcloud billing accounts list0X0X0X-0Y0Y0Y-0Z0Z0Z
Service Account emailFormat standard du SA Terraformtf-sa@PROJECT_ID.iam.gserviceaccount.com
WARNINGSécurité critique — Ne JAMAIS committer la clé JSON du Service Account dans Git. En production, préférer Workload Identity Federation (OIDC) qui supprime totalement le besoin de clés statiques. Pour le dev local, gcloud auth application-default login suffit.

1.3 Configurer l'authentification gcloud + ADC

Une seule fois sur votre poste : on s'authentifie avec son compte Google, on fixe le projet, on crée un Service Account dédié à Terraform et on configure les Application Default Credentials (ADC) que Terraform lit automatiquement.

bash
# 1. Login utilisateur (ouvre le navigateur)
gcloud auth login

# 2. Sélectionner le projet
gcloud config set project mon-projet-tf-prod

# 3. Créer un Service Account dédié à Terraform
gcloud iam service-accounts create tf-sa \
    --display-name="Terraform Service Account"

# 4. Attribuer le rôle (Editor pour les exercices, plus restreint en prod)
gcloud projects add-iam-policy-binding mon-projet-tf-prod \
    --member="serviceAccount:tf-sa@mon-projet-tf-prod.iam.gserviceaccount.com" \
    --role="roles/editor"

# 5. ADC pour le dev local (méthode recommandée pour Terraform)
gcloud auth application-default login

# 6. (Alternative CI/CD) Créer une clé JSON — sensible, à protéger !
gcloud iam service-accounts keys create key.json \
    --iam-account=tf-sa@mon-projet-tf-prod.iam.gserviceaccount.com
# export GOOGLE_APPLICATION_CREDENTIALS=$PWD/key.json

# 7. Vérifier
gcloud auth list
gcloud config list project

1.4 Activer les APIs GCP requises

GCP requiert d'activer explicitement chaque service avant de pouvoir l'utiliser. Pour cette leçon, seul Compute Engine est strictement nécessaire, mais autant activer les APIs courantes en une fois :

bash
gcloud services enable \
    compute.googleapis.com \
    cloudresourcemanager.googleapis.com \
    iam.googleapis.com \
    iap.googleapis.com

# Vérifier les APIs activées
gcloud services list --enabled

1.5 Permissions IAM minimales

Pour cet exercice, le Service Account Terraform doit pouvoir créer des ressources Compute Engine et lire le projet. Le rôle roles/editor (utilisé en 1.3) couvre largement le besoin. En production, on préférera des rôles ciblés comme roles/compute.admin + roles/iam.serviceAccountUser (least privilege).

1.6 Clé SSH pour Compute Engine

Pour se connecter en SSH à la VM (en dehors d'IAP), GCP supporte deux modes : OS Login (recommandé, auth via IAM — utilisé dans cette leçon) ou clés SSH classiques via la metadata du projet. Voici comment générer une clé dédiée GCP :

bash
# Générer une paire de clés RSA 4096 bits dédiée à GCP
ssh-keygen -t rsa -b 4096 -f ~/.ssh/gcp_vm -C "votre-user@gcp"

# Option A : OS Login activé sur la VM (utilisé dans cette leçon)
# → la clé publique est gérée par IAM, rien à pousser en metadata

# Option B : Ajout via metadata du projet (clé SSH classique)
gcloud compute project-info add-metadata \
    --metadata-from-file ssh-keys=~/.ssh/gcp_vm.pub

# Restreindre les permissions de la clé privée (obligatoire)
chmod 400 ~/.ssh/gcp_vm
WARNINGClé JSON SA ≠ clé SSH — Ne pas confondre la clé JSON du Service Account (auth Terraform aux APIs GCP) avec la clé SSH (auth utilisateur à la VM). La première est extrêmement sensible : sa fuite donne accès à toutes les ressources du projet. Toujours la chiffrer au repos, la rotater régulièrement et la révoquer dès qu'elle n'est plus nécessaire.

2. Structure du Projet

Voici l'arborescence type de cette leçon. Le code est organisé en plusieurs fichiers .tf selon leur responsabilité, plus un script Bash externe injecté dans la VM via metadata_startup_script.

bash
# Structure recommandée pour ce projet
premier-projet-gcp/
├── versions.tf        # Configuration Terraform + provider google
├── variables.tf       # Variables d'entrée (project_id, region, zone, ...)
├── main.tf            # VPC + subnet + firewall rules + VM Compute Engine
├── outputs.tf         # IP publique, commande SSH IAP, URL HTTP
├── startup-script.sh  # Script Bash exécuté au boot de la VM (Nginx)
├── terraform.tfvars   # Valeurs spécifiques (project_id, ...) — NON-COMMITTÉ
└── .gitignore         # Exclure .tfstate, .tfvars, .terraform/, key.json

2.1 Rôle de chaque fichier

FichierRôleLu par Terraform ?
versions.tfBloc terraform { required_providers } + bloc provider "google"Oui
variables.tfVariables d'entrée avec type, default, descriptionOui
main.tfToutes les resource et data sources GCPOui
outputs.tfOutputs exposés après apply (IP, URL, commande SSH IAP)Oui
startup-script.shScript Bash injecté dans la VM via la fonction file()Lu par file()
terraform.tfvarsValeurs concrètes des variables (project_id = "...")Auto-chargé
.gitignoreExclure *.tfstate, *.tfvars, .terraform/, key.jsonNon (Git)

2.2 Comment Terraform charge les fichiers

Chapitre 08 – Leçon 1 : GCP Fondamentaux et Authentification Terraform

NOTEObjectif — Comprendre la hiérarchie GCP (Organization, Folder, Project), installer et configurer gcloud CLI, créer un Service Account, activer les APIs requises, et configurer le provider google de Terraform.
TIPPré-requis — Avoir terminé les Chapitres 00 à 04. Disposer d'un compte GCP (300 USD gratuits pour 90 jours : cloud.google.com/free).

1. Hiérarchie GCP vs AWS et Azure

NiveauAWSAzureGCP
Top-levelOrganizationTenantOrganization
Conteneur intermédiaireOUManagement GroupFolder
Compte de facturationAccountSubscriptionProject (avec Billing Account lié)
RégionRegionLocationRegion (us-central1, europe-west1, northamerica-northeast1...)
ZoneAZAvailability ZoneZone (us-central1-a, -b, -c)
Identité de serviceIAM RoleService Principal / MIService Account
WARNINGDifférence majeure — Sur GCP, chaque ressource appartient à un Project. Le Project est l'unité fondamentale de facturation, IAM, et quotas. La quasi-totalité des ressources GCP demandent un project explicite.

2. Installer gcloud CLI

Windows (PowerShell)

Téléchargement et exécution de l'installeur officiel Google Cloud SDK pour Windows. Une fois lancé, l'installeur configure gcloud, gsutil et bq, et propose d'initialiser la connexion à votre compte GCP.

bash
(New-Object Net.WebClient).DownloadFile("https://dl.google.com/dl/cloudsdk/channels/rapid/GoogleCloudSDKInstaller.exe", "$env:Temp\GoogleCloudSDKInstaller.exe")
& $env:Temp\GoogleCloudSDKInstaller.exe

macOS

Installation de gcloud via Homebrew (le gestionnaire de paquets macOS le plus utilisé). Le cask installe le SDK complet et l'ajoute automatiquement au PATH.

bash
brew install --cask google-cloud-sdk

Linux (apt)

Procédure officielle Debian/Ubuntu : ajouter le dépôt APT Google, importer la clé GPG signée, puis installer google-cloud-cli. Cette méthode permet de bénéficier des mises à jour automatiques via apt.

bash
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" \
    | sudo tee /etc/apt/sources.list.d/google-cloud-sdk.list

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg \
    | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg

sudo apt update && sudo apt install -y google-cloud-cli

Validation rapide de l'installation : la commande affiche les versions du SDK, de bq (BigQuery) et gsutil (Storage). Une sortie vide indique un problème de PATH à corriger avant de continuer.

bash
# Vérifier
gcloud --version
# Google Cloud SDK 488.x.x
# bq 2.x.x
# gsutil 5.x.x

3. Créer et Configurer un Project GCP

Bootstrap complet d'un projet GCP en CLI :

bash
# 1. Connexion (ouvre le navigateur)
gcloud auth login

# 2. Créer un project (project_id doit être globalement unique)
PROJECT_ID="monprojet-tf-$(date +%s)"
gcloud projects create $PROJECT_ID --name="Mon Projet Terraform"

# 3. Lier au billing account (obligatoire pour la plupart des ressources)
BILLING_ID=$(gcloud billing accounts list --format="value(ACCOUNT_ID)" --limit=1)
gcloud billing projects link $PROJECT_ID --billing-account=$BILLING_ID

# 4. Définir le project actif
gcloud config set project $PROJECT_ID
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

# 5. Vérifier
gcloud config list
# [compute]
# region = us-central1
# zone = us-central1-a
# [core]
# project = monprojet-tf-1714234567

4. Activer les APIs Nécessaires

WARNINGGCP exige l'activation explicite des APIs — Contrairement à AWS, où les services sont disponibles immédiatement, sur GCP il faut activer chaque API avant utilisation. Les premières erreurs Terraform sont presque toujours liées à une API non activée.

Activation en lot des APIs GCP les plus courantes nécessaires pour Compute, Storage, IAM, Cloud SQL, Cloud Run et Secret Manager. La seconde commande (gcloud services list --enabled) permet de vérifier ce qui est déjà activé sur le project.

bash
# Activer les APIs courantes
gcloud services enable \
    compute.googleapis.com           `# Compute Engine` \
    storage.googleapis.com           `# Cloud Storage` \
    cloudresourcemanager.googleapis.com `# Resource Manager` \
    iam.googleapis.com               `# IAM` \
    iamcredentials.googleapis.com    `# IAM Credentials (pour SA tokens)` \
    sqladmin.googleapis.com          `# Cloud SQL Admin` \
    run.googleapis.com               `# Cloud Run` \
    secretmanager.googleapis.com     `# Secret Manager` \
    --project=$PROJECT_ID

# Lister les APIs activées
gcloud services list --enabled --project=$PROJECT_ID

Chapitre 03 – Leçon 4 : Projet Serverless — Lambda, API Gateway et VPC avec Modules

NOTEObjectif — Déployer une architecture serverless complète sur AWS avec Terraform : un VPC, une fonction Lambda, et un API Gateway — le tout organisé en modules réutilisables. Ce projet illustre comment les modules Terraform s'assemblent pour former une infrastructure de production.

1. Prérequis

Ce projet déploie 3 modules Terraform qui orchestrent ensemble un VPC, une fonction Lambda et un API Gateway. Avant de lancer terraform apply, vérifiez que tous les éléments ci-dessous sont en place — sinon vous obtiendrez des erreurs IAM, des timeouts d'invocation Lambda ou des erreurs 500 sur l'API.

1.1 Comptes et outils

1.2 Identifiants AWS à récupérer

Vous aurez besoin de ces 3 informations depuis la console AWS pour authentifier Terraform :

ÉlémentOù le trouverExemple
Account ID (12 chiffres)Console AWS → en haut à droite, cliquer sur votre nom → Mon compte123456789012
Access Key IDIAM → Users → votre user → Security credentials → Create access keyAKIAIOSFODNN7EXAMPLE
Secret Access KeyAffiché UNE SEULE FOIS lors de la création (sinon recréer une nouvelle clé)wJalrXUt...EXAMPLEKEY
WARNINGSécurité critique — Ne JAMAIS committer ces clés dans Git. Toujours les configurer via aws configure (stockées dans ~/.aws/credentials) ou des variables d'environnement. Ajoutez *.tfvars, *.tfstate*, .terraform/ et dist/ à votre .gitignore.

1.3 Configurer l'authentification AWS CLI

Une seule fois sur votre poste : exécutez aws configure et collez vos clés. Le fichier ~/.aws/credentials est créé, et Terraform le lira automatiquement (le provider AWS et le provider archive n'ont besoin d'aucun token spécifique).

bash
aws configure
# AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
# AWS Secret Access Key [None]: wJalrXUt...EXAMPLEKEY
# Default region name [None]: ca-central-1
# Default output format [None]: json

# Vérifier que ça fonctionne
aws sts get-caller-identity
# {
#   "UserId": "AIDA...EXAMPLE",
#   "Account": "123456789012",        ← Votre Account ID
#   "Arn": "arn:aws:iam::123456789012:user/votre-user"
# }

1.4 Permissions IAM minimales

Le user (ou rôle) utilisé doit pouvoir créer Lambda, API Gateway, IAM (rôles d'exécution), VPC, et CloudWatch Logs. Pour cet exercice, attachez les policies managées suivantes au user IAM :

Policy managée AWSPourquoi
AWSLambda_FullAccessCréer/modifier la fonction Lambda et les aws_lambda_permission
AmazonAPIGatewayAdministratorCréer la REST API, les méthodes, les intégrations et le déploiement
IAMFullAccessCréer le rôle d'exécution Lambda et y attacher les policies
AmazonVPCFullAccessCréer le VPC, les subnets et le Security Group du module vpc
CloudWatchLogsFullAccessCréer le aws_cloudwatch_log_group de la Lambda
TIPEn production — On restreindra ces permissions selon le principe least privilege (voir Chapitre 05). Pour un compte d'apprentissage, PowerUserAccess + IAMFullAccess suffit également.

1.5 Code source Lambda

Le module data "archive_file" (utilisé dans le main.tf racine) zippe automatiquement votre code Python à chaque plan. Vous devez créer le dossier source avant le premier terraform plan, sinon Terraform échouera avec « source_dir does not exist » :

bash
# Créer la structure attendue par data "archive_file"
mkdir -p src/lambda
touch src/lambda/index.py        # Le contenu sera vu en section 8

# Pas de SSH/.pem nécessaire ici — la Lambda s'invoque via API Gateway, pas en SSH
NOTEDifférence avec EC2 — Contrairement au projet EC2 du Chapitre 01, ce lab ne nécessite aucune key pair SSH. Lambda est un service managé : on déploie du code, AWS s'occupe du serveur.

2. Structure du Projet

Voici l'arborescence complète du projet, pensée pour la modularité. Le main.tf racine joue le rôle de chef d'orchestre : il instancie les 3 modules et connecte leurs outputs/inputs. Chaque module dans modules/ est auto-suffisant (il a ses propres variables.tf et outputs.tf) et pourrait être réutilisé dans un autre projet.

bash
# Structure complète du projet serverless
project-serverless/
├── providers.tf               # Versions Terraform + provider AWS + archive
├── variables.tf               # Variables globales (project_name, environment, region)
├── main.tf                    # Orchestration : appels module.vpc, module.lambda, module.api_gateway
├── outputs.tf                 # Outputs racines (api_url, lambda_name, lambda_arn)
├── terraform.tfvars           # Valeurs concrètes (NON-COMMITTÉ)
├── .gitignore                 # *.tfstate, *.tfvars, .terraform/, dist/
├── README.md
│
├── src/
│   └── lambda/
│       └── index.py           # Code Python de la Lambda
│
├── dist/                      # ZIP généré par data "archive_file" (NON-COMMITTÉ)
│   └── lambda.zip
│
├── environments/              # Valeurs spécifiques par environnement
│   ├── dev.tfvars
│   └── prod.tfvars
│
└── modules/
    ├── vpc/                   # Module réseau réutilisable
    │   ├── main.tf            # aws_vpc, aws_subnet, aws_security_group
    │   ├── variables.tf       # prefix, cidr, environment
    │   └── outputs.tf         # vpc_id, private_subnets, lambda_sg_id
    │
    ├── lambda/                # Module fonction Lambda + IAM
    │   ├── main.tf            # aws_lambda_function, aws_cloudwatch_log_group
    │   ├── iam.tf             # Rôle d'exécution + policy attachments
    │   ├── variables.tf       # function_name, runtime, handler, vpc_id...
    │   └── outputs.tf         # function_name, function_arn, invoke_arn
    │
    └── api_gateway/           # Module API REST
        ├── main.tf            # aws_api_gateway_rest_api, methods, deployment
        ├── variables.tf       # api_name, lambda_arn, lambda_name
        └── outputs.tf         # api_id, api_url, stage

2.1 Rôle de chaque fichier

FichierRôleNiveau
providers.tfVersions de Terraform + providers (aws, archive)Racine
variables.tfVariables globales partagées entre tous les modulesRacine
main.tf (racine)Instancie les modules et fait passer les outputs de l'un en inputs de l'autreRacine
outputs.tf (racine)Réexpose les outputs des modules au niveau projet (ex. api_url)Racine
modules/<m>/main.tfLogique métier du module (ressources AWS)Module
modules/<m>/variables.tfInterface publique du module — ce qu'un consommateur peut configurerModule
modules/<m>/outputs.tfValeurs exposées par le module (consommables par le racine ou un autre module)Module
src/lambda/index.pyCode applicatif Python — zippé automatiquement par data "archive_file"App
environments/*.tfvarsValeurs concrètes par environnement (passées via -var-file)Config

2.2 Comment Terraform charge les fichiers — il n'y a PAS de "point d'entrée"

NOTEConcept clé — Terraform ne lit pas main.tf en premier. Il fusionne automatiquement TOUS les fichiers .tf du dossier courant en un seul ensemble. Les noms main.tf, iam.tf, variables.tf sont une convention, pas une obligation technique. Dans le module lambda/, séparer iam.tf de main.tf améliore la lisibilité — pour Terraform, c'est strictement équivalent à un seul gros fichier.
va-plus-loin

Cet article couvre les extraits les plus utiles — le cours complet Terraform Infrastructure Code (10 chapitres, 38 leçons, exercices corrigés et projet final) t'emmène jusqu'au bout.

./acceder-au-cours-complet cours gratuit : Maîtriser Claude Code

FAQ

Combien de temps pour apprendre Terraform Infrastructure Code ?
Avec une progression structurée (10 chapitres, 38 leçons courtes et pratiques), on atteint un niveau opérationnel en quelques semaines à raison de 30 à 60 minutes par jour. L'important est de pratiquer chaque notion immédiatement.
Faut-il des prérequis ?
Mieux vaut être à l'aise avec les fondamentaux du domaine : ce contenu va en profondeur, avec des cas réels.
Par où commencer concrètement ?
Reproduis les commandes de cet article, puis suis le cours complet Terraform Infrastructure Code : il enchaîne les 38 leçons dans l'ordre, avec exercices et projet final.

📬 Tu veux recevoir ce type de guide chaque semaine ? Abonne-toi gratuitement — code réel, zéro blabla.