infra / terraform

Premier fichier .tf et providers

Leçon 21 exercice

Explication

Ce que vous allez apprendre

Écrire un premier fichier main.tf valide avec un bloc terraform et un bloc provider
Comprendre le rôle exact d'un provider dans l'architecture de Terraform
Suivre le cycle de vie standard : init, plan, apply, destroy
Utiliser terraform validate et terraform fmt avant tout apply
Trouver la documentation d'un provider sur le Terraform Registry

Dans quel contexte ?

Terraform est installé (leçon précédente), mais un dossier vide ne fait rien du tout : il faut désormais écrire une véritable configuration. Une petite équipe veut créer son tout premier bucket de stockage S3 sur AWS, en région Paris, sans passer par la console web.

D'abord, il faut comprendre à quoi sert un "provider"

Terraform lui-même ne sait rien faire directement avec AWS, Azure ou GCP : c'est un moteur générique qui délègue tout le travail concret à des plugins appelés "providers". Un provider AWS sait comment créer un bucket S3 ou une instance EC2 en traduisant du HCL en appels réels à l'API AWS.

Chaque provider vient d'un registre centralisé, le Terraform Registry, où il est identifié par un couple namespace/nom (hashicorp/aws) et une contrainte de version (~> 5.0, qui autorise toute version 5.x mais pas 6.0).

Bloc HCL	Rôle
`terraform { required_providers { ... } }`	Déclare quels providers utiliser, et avec quelle contrainte de version
`provider "aws" { region = ... }`	Configure l'accès concret à l'API (région, credentials implicites)
`resource "type" "nom" { ... }`	Décrit un objet cloud concret à créer

Prérequis

Cette leçon suppose que Terraform est déjà installé (voir la leçon précédente) et qu'un compte AWS (ou équivalent) avec des identifiants d'accès valides est configuré localement.

Une fois le provider déclaré, comment Terraform sait-il qu'il faut le télécharger ?

C'est le rôle de terraform init, la toute première commande à lancer dans n'importe quel projet Terraform. Elle lit les blocs required_providers, télécharge les plugins correspondants depuis le Registry, et prépare le répertoire de travail — sans jamais toucher au cloud lui-même.

Piège fréquent

Oublier de relancer terraform init après avoir ajouté un nouveau provider ou module dans la configuration produit une erreur explicite ("Provider not found") plutôt qu'un comportement silencieux. Le réflexe à prendre : dès qu'un fichier .tf change ses dépendances, relancer init avant tout plan.

Maintenant que le provider est prêt, il reste à comprendre le cycle de vie complet

terraform plan calcule un diff entre l'état actuel (rien, au tout premier lancement) et l'état désiré décrit dans le code, sans jamais rien modifier réellement. terraform apply applique ensuite ce plan, après une confirmation explicite ("yes") — une sécurité qu'il ne faut désactiver (-auto-approve) qu'en connaissance de cause.

Bonne pratique

Prends l'habitude systématique de lancer terraform fmt (reformatage automatique) puis terraform validate (vérification de syntaxe et de cohérence, sans appel réseau) avant chaque plan. Ces deux commandes sont instantanées et évitent de découvrir une erreur de syntaxe seulement après avoir attendu la réponse de l'API cloud.

Le piège à connaître avant de continuer

terraform destroy supprime TOUTES les ressources gérées par la configuration courante, sans distinction. Sur un projet de démonstration ce n'est pas grave, mais lancé par erreur sur un projet de production, les conséquences sont immédiates et souvent irréversibles.

Le cycle de base maîtrisé, la prochaine leçon va plus loin dans le détail d'une ressource : ses attributs, ses dépendances envers d'autres ressources, et les mécanismes count/for_each pour en créer plusieurs à la fois.

Commandes & code

Premier fichier .tf et providers

# main.tf : un provider déclare QUEL cloud/API Terraform va piloter
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"     # registre officiel : namespace/nom
      version = "~> 5.0"            # contrainte de version : 5.x, mais pas 6.0
    }
  }
  required_version = ">= 1.5.0"     # version minimale de Terraform lui-même
}

provider "aws" {
  region = "eu-west-3"              # région Paris
}

# Une première ressource : un bucket S3
resource "aws_s3_bucket" "exemple" {
  bucket = "mon-bucket-terraform-demo-2026"
}

# Cycle de vie de base : init -> plan -> apply -> destroy
terraform init                       # télécharge les providers déclarés, initialise le répertoire
terraform validate                    # vérifie la syntaxe et la cohérence, sans appeler le cloud
terraform fmt                         # reformate les fichiers .tf selon le style canonique
terraform plan                        # calcule le diff entre l'état actuel et l'état désiré
terraform apply                       # applique le plan (demande confirmation "yes")
terraform apply -auto-approve         # applique sans confirmation interactive (attention en prod)
terraform destroy                     # détruit toutes les ressources gérées par cette config

# Où trouver les providers et leur documentation ?
# https://registry.terraform.io -> registre officiel, un provider par cloud/service
# Chaque provider expose des "resources" (créent des objets) et des "data sources" (lisent l'existant)

Résumé

Un bloc provider configure l'accès à une API cloud ; required_providers fixe les sources et versions.
Le cycle standard est init (télécharge providers) -> plan (calcule le diff) -> apply (applique).
terraform fmt et terraform validate sont à lancer systématiquement avant tout plan/apply.

Exercices pratiques

1 disponible

Mission : débloquer un premier déploiement bloqué

Objectif : Diagnostiquer une erreur de provider manquant et sécuriser le cycle plan/apply avant toute exécution en production.

Contexte

Un stagiaire vient d'écrire son tout premier main.tf avec un bloc terraform { required_providers { aws = { ... } } } } et un provider "aws". Il lance directement terraform plan sans jamais avoir exécuté terraform init auparavant, et obtient une erreur Provider not found: registry.terraform.io/hashicorp/aws.

Résoudre l’exercice →