IaC (3/6) — Comment Terraform pense : plan & state

L’idée reçue

« terraform apply exécute mon code, comme un script. »

Pas du tout. Terraform ne « joue » pas des étapes : il compare un état voulu à un état réel, puis calcule le minimum de changements pour les réconcilier. Ce mécanisme — le même sur Proxmox, AWS ou Azure — est ce qui distingue vraiment l’IaC déclarative d’un script. C’est LE module à comprendre en profondeur.

À la fin de ce module, tu sauras…

Expliquer les trois « mondes » que Terraform compare
Lire un plan et ses symboles (+, -, ~, -/+)
Comprendre le rôle et le danger du fichier d’état
Observer create, update in-place, replace et destroy — par la preuve

01Les trois mondes de Terraform

Tout le raisonnement de Terraform tient dans la comparaison de trois représentations de ton infrastructure :

Monde	C’est quoi	Où
Desired state	ce que tu veux	tes fichiers `.tf`
Known state	ce que Terraform croit exister	fichier `terraform.tfstate`
Real world	ce qui existe vraiment	l’API du provider (Proxmox…)

Comprends le principe, une fois pour toutes

Quand tu lances plan, Terraform : (1) lit ton desired state (le code), (2) lit son known state (le fichier tfstate), (3) interroge l’API pour rafraîchir le real world, puis (4) calcule les différences et propose un plan d’actions pour aligner le réel sur le voulu. apply exécute ce plan. Ce cycle — refresh → compare → plan → apply — est identique quel que soit le provider. Comprends-le ici, tu le connais partout.

02Un plan sur du vide

Expérience 1

plan quand rien n’existe encore

Ajoute une ressource simple à ton main.tf — un pool Proxmox, léger et sans risque, parfait pour observer le mécanisme :

Manipule

resource "proxmox_virtual_environment_pool" "lab" {
pool_id = "soria-lab"
comment = "Pool geré par Terraform"
}

Manipule

terraform plan

Observe

Terraform will perform the following actions:

# proxmox_virtual_environment_pool.lab will be created
+ resource "proxmox_virtual_environment_pool" "lab" {
    + pool_id = "soria-lab"
    + comment = "Pool geré par Terraform"
  }

Plan: 1 to add, 0 to change, 0 to destroy.

Le + signifie création. Terraform a comparé : desired = 1 pool, known = rien, real = rien → il faut créer. Remarque : plan n’a rien fait, il a seulement montré son intention.

Comprends plan est une simulation

plan est une prévisualisation sans effet : il calcule et affiche ce qu’il ferait, sans rien modifier. C’est un filet de sécurité fondamental — tu vois toujours l’impact avant d’agir. Les symboles : + créer, - détruire, ~ modifier sur place, -/+ remplacer (détruire puis recréer).

03apply : et naissance du state

Expérience 2

Exécuter le plan, et découvrir le fichier d’état

Manipule

terraform apply
# tape 'yes' à la confirmation
ls -la terraform.tfstate

Observe

proxmox_virtual_environment_pool.lab: Creating...
proxmox_virtual_environment_pool.lab: Creation complete after 1s

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

-rw------- 1 ben ben 1234 terraform.tfstate

Le pool existe maintenant sur Proxmox, et un fichier terraform.tfstate est apparu : c’est le known state. Terraform y a enregistré ce qu’il vient de créer.

Comprends pourquoi le state existe

Le fichier d’état est la mémoire de Terraform : il fait le lien entre ton code (« pool lab ») et l’objet réel (l’ID Proxmox correspondant). Sans lui, Terraform ne saurait pas que « le pool de mon code » est « ce pool précis sur Proxmox » — il ne pourrait ni le modifier ni le supprimer proprement. Le state, c’est ce qui permet le suivi dans le temps.

04Rejouer : la convergence

Expérience 3

plan une deuxième fois, sans rien changer

Manipule

terraform plan

Observe

No changes. Your infrastructure matches the configuration.

Aucun changement. Desired == known == real : tout concorde, Terraform ne fait rien. C’est la convergence — et la grande différence avec un script, qu’on ne peut pas rejouer sans risque.

Comprends idempotence par comparaison

Un script bash create_pool relancé échouerait (« existe déjà ») ou dupliquerait. Terraform, lui, compare d’abord : comme l’état voulu correspond déjà au réel, il n’agit pas. Tu peux lancer apply autant de fois que tu veux : le résultat est toujours le même état. Cette sûreté vient du modèle déclaratif + state.

05Modifier : update in-place (~)

Expérience 4

Change une valeur, observe le ~

Modifie le commentaire du pool dans main.tf :

Manipule

  comment = "Pool SORIA - modifie par Terraform"

Manipule

terraform plan

Observe

  # proxmox_virtual_environment_pool.lab will be updated in-place
~ resource "proxmox_virtual_environment_pool" "lab" {
    ~ comment = "Pool geré par Terraform" -> "Pool SORIA - modifie par Terraform"
  }

Plan: 0 to add, 1 to change, 0 to destroy.

Le ~ = modification sur place. Terraform a détecté que seul le commentaire diffère entre desired et known, et propose de le mettre à jour sans détruire le pool. Applique pour confirmer.

Comprends in-place vs replace

Certains attributs se changent sur place (~, l’objet reste). D’autres, immuables, imposent un remplacement (-/+ : détruire puis recréer) — par exemple changer le nom d’une VM chez certains providers. Terraform connaît, pour chaque attribut, s’il est modifiable à chaud, grâce au provider. Toujours lire le plan : un -/+ inattendu sur une VM de prod peut être dangereux.

06Le drift : quand le réel diverge

Expérience 5

Modifie « à la main », et laisse Terraform le détecter

Dans l’interface Proxmox, change manuellement le commentaire du pool soria-lab. Puis :

Manipule

terraform plan

Observe

Note: Objects have changed outside of Terraform

~ resource "proxmox_virtual_environment_pool" "lab" {
    ~ comment = "modifie a la main" -> "Pool SORIA - modifie par Terraform"
  }
Plan: 0 to add, 1 to change, 0 to destroy.

Terraform a rafraîchi le réel, détecté que quelqu’un a modifié le pool hors de son contrôle (le drift !), et propose de ramener le réel vers ton code. C’est exactement le problème du manuel (module 7.1), désormais détecté et corrigé automatiquement.

Comprends la vraie valeur de l’IaC

C’est ici que l’IaC prouve sa supériorité : ton code est la source de vérité. Toute dérive manuelle est repérée au prochain plan et corrigée au prochain apply. Fini le « personne ne sait l’état réel » : l’état voulu est écrit, versionné, et appliqué en continu. Ce comportement est identique sur AWS ou Azure — c’est une propriété du moteur, pas du provider.

07Détruire (-)

Expérience 6

destroy : supprimer proprement

Manipule

terraform destroy
# lis le plan (des '-'), puis 'yes'

Observe

  # proxmox_virtual_environment_pool.lab will be destroyed
- resource ...
Destroy complete! Resources: 1 destroyed.

Le - = destruction. Terraform sait exactement quoi supprimer grâce au state, et met à jour le fichier d’état en conséquence. Cycle de vie complet : create → update → destroy, tout tracé.

Comprends pourquoi le state rend destroy sûr

Terraform ne détruit que ce qu’il a créé (ce qui est dans son state) — pas les autres ressources de ton Proxmox. Le state délimite précisément le périmètre géré. C’est aussi pourquoi perdre ou corrompre le fichier d’état est grave : Terraform « oublie » ce qu’il gérait. En production, on stocke le state à distance (backend partagé, verrouillé) plutôt qu’en local — un sujet clé quand on travaille en équipe.

✓Ce que tu retiens

Terraform ne joue pas un script : il réconcilie trois mondes — ton code (desired), le fichier d’état (known), et le réel via l’API (real). plan simule et affiche les actions (+ - ~ -/+), apply les exécute, le state fait le lien code ↔ objets réels et permet le suivi (drift compris). Ce cycle refresh → compare → plan → apply est identique sur toutes les plateformes.

Mini-projet

Prouve le raisonnement de Terraform

À faire

Crée une ressource pool, observe le plan (+), applique, et ouvre le fichier d’état.
Relance plan : prouve « No changes » (convergence).
Modifie une valeur dans le code : observe le ~ et applique.
Modifie la ressource à la main dans Proxmox : prouve la détection du drift au plan suivant.
Fais un destroy et observe les -.
Documente dans BookStack : les 3 mondes, les symboles du plan, et pourquoi le state est critique.

Fil rouge — Tu comprends comment Terraform pense. Passons au concret utile : au module suivant, on crée une vraie VM sur Proxmox avec cloud-init, en paramétrant tout par des variables — le genre de code qu’on réutilise pour toute une flotte, ici comme sur n’importe quel cloud.

?Auto-évaluation

1. Quels sont les trois « mondes » que Terraform compare ?

Le desired state (ton code), le known state (fichier tfstate), et le real world (l’API du provider).

2. Que font les symboles +, -, ~ et -/+ dans un plan ?

+ créer, - détruire, ~ modifier sur place, -/+ remplacer (détruire puis recréer).

3. Pourquoi le fichier d’état est-il critique ?

Il relie ton code aux objets réels et délimite le périmètre géré. Le perdre fait « oublier » à Terraform ce qu’il gérait ; d’où le stockage distant et verrouillé en équipe.