Module 3 — Le workflow Terraform en pratique

Durée indicative du cours : 0h40–0h45 (matin Jour 1 — socle condensé)
Durée indicative de l’atelier : ~0h45–1h00 — Ateliers Jour 1
Durée totale (cours + atelier) : partagée avec le module 2 sur le matin Jour 1

Cycle de vie d’une ressource

flowchart TB
  subgraph cycle [Cycle de vie]
    Code[Écrire / modifier .tf]
    Init[terraform init]
    Plan[terraform plan]
    Apply[terraform apply]
    Geree[Ressource + state]
    Destroy[terraform destroy]
  end

  Code --> Init --> Plan --> Apply --> Geree
  Geree --> Plan
  Geree --> Destroy

Terraform compare trois sources d’information :

Configuration (fichiers .tf) — état désiré
State (terraform.tfstate) — ce que Terraform croit gérer
Réalité cloud (via API) — ce qui existe vraiment chez Azure

Maîtriser ce triangle évite la moitié des confusions de débutant — et une bonne part des pièges d’examen.

Config, state et cloud : qui lit quoi ?

En une phrase

Le state est le carnet de Terraform : « voici les ressources que je gère et leurs attributs connus ».
Le cloud est la réalité : Terraform le consulte surtout pendant plan / apply pour calculer l’écart.
Les fichiers .tf disent ce que vous voulez. Sans state fiable, Terraform ne sait plus faire le lien.

Quand Terraform lit surtout le state

Situation	Ce qui se passe
`terraform state list` / `state show`	Lecture du fichier d’état (pas un inventaire complet du cloud)
`terraform output`	Valeurs exposées depuis le state / la config
Juste après un `apply` réussi	Le state vient d’être aligné avec ce qui a été appliqué

Quand Terraform interroge aussi le cloud

Situation	Ce qui se passe
`terraform plan`	Compare config, state et cloud, puis propose créations, mises à jour ou destructions
`terraform apply`	Même logique, puis écrit dans le cloud et met à jour le state
`terraform destroy`	Plan de destruction basé sur le state, exécuté via les API

Piège classique — modification hors Terraform

Vous modifiez une ressource dans le portail Azure sans passer par le .tf. Au prochain plan, Terraform peut détecter un drift (dérive) et proposer de remettre le cloud comme dans le code.

Ce n’est pas un bug : Terraform considère le code comme la source de vérité. Aujourd’hui, on observe et on lit le plan. Demain (Jour 2), on apprendra à agir : importer, retirer du state, réconcilier.

Les quatre commandes essentielles

`terraform init`

Initialise le répertoire de travail. Sans un init réussi, la plupart des autres commandes refusent de tourner correctement.

terraform init

Tâche	Résultat local
Installer les providers	Plugins dans `.terraform/providers/`
Configurer le backend	Local par défaut ; distant au Jour 2
Écrire / respecter le lockfile	`.terraform.lock.hcl`

Insight

init ne crée pas de ressources cloud. C’est la mise en route du projet. On peut le relancer sans danger dans la plupart des cas.

Quand relancer init : premier démarrage, clone Git, changement de required_providers, suppression de .terraform/, ou (plus tard) changement de backend.

Variantes à connaître pour l’exam et le terrain :

terraform init              # cas normal
terraform init -upgrade     # versions plus récentes dans la plage required_providers
terraform init -reconfigure # reconfigure le backend sans migrer le state
# terraform init -migrate-state  # migration de state — Jour 2, avec prudence

Documentation officielle : terraform init.

Le fichier de verrouillage `.terraform.lock.hcl`

Créé ou mis à jour par terraform init. C’est le registre exact des providers (version + hashes) choisis pour ce projet.

required_providers dit : « j’accepte une plage » (ex. ~> 3.0).
Le lockfile dit : « sur ce commit, on a figé azurerm 3.x.y ».

Sans lockfile partagé, chaque machine peut résoudre une version différente dans la plage. Avec le lockfile commité, tout le monde (y compris la CI) réinstalle la même version.

Fichier / dossier	Rôle	Git ?
`required_providers` (dans `.tf`)	Plage autorisée	Oui
`.terraform.lock.hcl`	Version exacte + hashes	Oui (recommandé)
`.terraform/`	Cache plugins	Non
`terraform.tfstate`	État des ressources cloud	Non (en local / lab)

Deux « locks » différents — ne pas confondre

Concept	Fichier / lieu	Rôle	Quand
Dependency lock	`.terraform.lock.hcl`	Figer les versions des providers	Jour 1 — à maîtriser tout de suite
State lock	Backend distant	Empêcher deux `apply` en parallèle sur le même state	Jour 2 — équipe / CI

Documentation officielle : Dependency Lock File.

`terraform plan`

Calcule le plan d’exécution sans modifier le cloud.

terraform plan

Lire un plan

Sortie typique :

Symbole	Sens	Idée
`+`	create	Création
`~`	update in-place	Mise à jour sans recréer (souvent)
`-`	destroy	Destruction
`-/+`	replace	Détruire puis recréer (changement ForceNew, etc.)

Réflexe : lire le plan avant de confirmer un apply. En CI, le plan devient un artefact de revue.

Réflexe du jour

Un second plan / apply sans changement de code ni de cloud doit afficher No changes. C’est l’idempotence vue en vrai.

`terraform apply`

Applique le plan. Par défaut, Terraform recalcule un plan et demande confirmation.

terraform apply
# terraform apply -auto-approve   # à éviter en apprentissage et en prod non cadrée

Après un apply réussi : les ressources sont créées ou modifiées, et le state est mis à jour.

`terraform destroy`

Détruit les ressources gérées par ce state.

terraform destroy

Aussi puissant que dangereux : toujours lire le plan de destruction. En fin d’atelier Jour 1, le destroy évite de laisser des coûts de lab.

Qualité du code avant le cloud : `fmt` et `validate`

Ces deux commandes ne touchent pas Azure. Elles améliorent la qualité et détectent des erreurs avant un plan / apply.

terraform fmt
terraform validate   # après un init au moins une fois
terraform plan
terraform apply

Commande	Fait	Ne fait pas
`fmt`	Harmonise le style HCL	Changer le comportement de l’infra
`validate`	Vérifie syntaxe et cohérence interne	Remplacer un `plan` (pas d’appel API « est-ce déployable ? »)

State local vs state distant (aperçu)

	Local (Jour 1)	Distant (Jour 2)
Où	`terraform.tfstate` dans le dossier	Azure Storage, TFC / HCP, etc.
Collaboration	Un poste, un lab	Équipe / CI sur le même state
Lock d’état	Peu visible en solo	Essentiel pour éviter deux apply concurrents
Risque	Perte / oubli du fichier, pas de partage	Mauvaise config backend, migration à manier avec prudence

Aujourd’hui, le state local suffit pour ancrer le workflow. Demain, nous brancherons le même projet sur un backend distant et nous traiterons import, drift et commandes state.

Annonce Jour 2

Le Jour 2 ira vers le state distant, l’import, le drift en action, et le state lock backend. Prérequis mental : savoir lire un plan et distinguer dependency lockfile vs verrou d’état.

Erreurs fréquentes

Symptome	Cause probable
Provider introuvable	`init` non fait, ou `.terraform/` effacé
Auth Azure échoue	`az login` expiré / mauvaise souscription / `ARM_*` incomplets
State incohérent après interruption	Apply coupé ; ne pas éditer le tfstate à la main
Confusion « lock »	Mélanger `.terraform.lock.hcl` et le state lock distant

Aller plus loin — même idées en Basics

Un workflow très détaillé (tous les cas d’init, refresh, targeting) se trouve dans Terraform Basics — module 3. L’expérience drift « observation seule » est à l’atelier 5 Basics ; en Associate Jour 2, on agit sur le state.

Points à retenir

Workflow cœur : init → fmt / validate → plan → apply (puis destroy en fin de lab).
Le plan montre l’écart sans modifier Azure ; les symboles +, ~, -, -/+ se lisent avant de confirmer.
Le lockfile providers se versionne ; le state local non.
State local aujourd’hui ; state distant, import et drift action demain.

Suite

Pratique : Ateliers — Jour 1 matin.
Théorie suivante dès l’après-midi : module 4 — Providers.