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.
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.
- 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
Chapitre 08 – Leçon 2 : Premier Projet GCP — VPC, Firewall et Compute Engine
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ément | Comment l'obtenir | Exemple |
|---|---|---|
| Project ID (string court) | gcloud config get-value project | mon-projet-tf-prod |
| Project Number (12 chiffres) | gcloud projects describe PROJECT_ID --format="value(projectNumber)" | 123456789012 |
| Organization ID (optionnel) | gcloud organizations list | 987654321000 |
| Billing Account ID | gcloud billing accounts list | 0X0X0X-0Y0Y0Y-0Z0Z0Z |
| Service Account email | Format standard du SA Terraform | tf-sa@PROJECT_ID.iam.gserviceaccount.com |
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.
# 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 project1.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 :
gcloud services enable \
compute.googleapis.com \
cloudresourcemanager.googleapis.com \
iam.googleapis.com \
iap.googleapis.com
# Vérifier les APIs activées
gcloud services list --enabled1.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 :
# 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_vm2. 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.
# 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
| Fichier | Rôle | Lu par Terraform ? |
|---|---|---|
versions.tf | Bloc terraform { required_providers } + bloc provider "google" | Oui |
variables.tf | Variables d'entrée avec type, default, description | Oui |
main.tf | Toutes les resource et data sources GCP | Oui |
outputs.tf | Outputs exposés après apply (IP, URL, commande SSH IAP) | Oui |
startup-script.sh | Script Bash injecté dans la VM via la fonction file() | Lu par file() |
terraform.tfvars | Valeurs concrètes des variables (project_id = "...") | Auto-chargé |
.gitignore | Exclure *.tfstate, *.tfvars, .terraform/, key.json | Non (Git) |
2.2 Comment Terraform charge les fichiers
Chapitre 08 – Leçon 1 : GCP Fondamentaux et Authentification Terraform
gcloud CLI, créer un Service Account, activer les APIs requises, et configurer le provider google de Terraform.1. Hiérarchie GCP vs AWS et Azure
| Niveau | AWS | Azure | GCP |
|---|---|---|---|
| Top-level | Organization | Tenant | Organization |
| Conteneur intermédiaire | OU | Management Group | Folder |
| Compte de facturation | Account | Subscription | Project (avec Billing Account lié) |
| Région | Region | Location | Region (us-central1, europe-west1, northamerica-northeast1...) |
| Zone | AZ | Availability Zone | Zone (us-central1-a, -b, -c) |
| Identité de service | IAM Role | Service Principal / MI | Service Account |
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.
(New-Object Net.WebClient).DownloadFile("https://dl.google.com/dl/cloudsdk/channels/rapid/GoogleCloudSDKInstaller.exe", "$env:Temp\GoogleCloudSDKInstaller.exe")
& $env:Temp\GoogleCloudSDKInstaller.exemacOS
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.
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.
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-cliValidation 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.
# 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 :
# 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
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.
# 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_IDChapitre 03 – Leçon 4 : Projet Serverless — Lambda, API Gateway et VPC avec Modules
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ément | Où le trouver | Exemple |
|---|---|---|
| Account ID (12 chiffres) | Console AWS → en haut à droite, cliquer sur votre nom → Mon compte | 123456789012 |
| Access Key ID | IAM → Users → votre user → Security credentials → Create access key | AKIAIOSFODNN7EXAMPLE |
| Secret Access Key | Affiché UNE SEULE FOIS lors de la création (sinon recréer une nouvelle clé) | wJalrXUt...EXAMPLEKEY |
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).
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 AWS | Pourquoi |
|---|---|
AWSLambda_FullAccess | Créer/modifier la fonction Lambda et les aws_lambda_permission |
AmazonAPIGatewayAdministrator | Créer la REST API, les méthodes, les intégrations et le déploiement |
IAMFullAccess | Créer le rôle d'exécution Lambda et y attacher les policies |
AmazonVPCFullAccess | Créer le VPC, les subnets et le Security Group du module vpc |
CloudWatchLogsFullAccess | Créer le aws_cloudwatch_log_group de la Lambda |
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 » :
# 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
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.
# 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, stage2.1 Rôle de chaque fichier
| Fichier | Rôle | Niveau |
|---|---|---|
providers.tf | Versions de Terraform + providers (aws, archive) | Racine |
variables.tf | Variables globales partagées entre tous les modules | Racine |
main.tf (racine) | Instancie les modules et fait passer les outputs de l'un en inputs de l'autre | Racine |
outputs.tf (racine) | Réexpose les outputs des modules au niveau projet (ex. api_url) | Racine |
modules/<m>/main.tf | Logique métier du module (ressources AWS) | Module |
modules/<m>/variables.tf | Interface publique du module — ce qu'un consommateur peut configurer | Module |
modules/<m>/outputs.tf | Valeurs exposées par le module (consommables par le racine ou un autre module) | Module |
src/lambda/index.py | Code applicatif Python — zippé automatiquement par data "archive_file" | App |
environments/*.tfvars | Valeurs 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"
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.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 CodeFAQ
Combien de temps pour apprendre Terraform Infrastructure Code ?
Faut-il des prérequis ?
Par où commencer concrètement ?
📬 Tu veux recevoir ce type de guide chaque semaine ? Abonne-toi gratuitement — code réel, zéro blabla.