Suite de ma série sur la certification Terraform Associate, après le module sur les providers et le state. Le troisième objectif de l’exam guide s’intitule “Core Terraform workflow”.

Le cycle Write, Plan, Apply

Le workflow Terraform “de base” (un seul développeur, sans HCP Terraform ni CI) tient en trois étapes qui se répètent :

• Write : j’écris ou je modifie la configuration HCL.
• Plan : Terraform compare la configuration au state et à l’infrastructure réelle, puis affiche le diff des actions qu’il compte effectuer.
• Apply : Terraform exécute ce plan et met à jour le state en conséquence.

terraform init

Première commande à lancer dans un nouveau répertoire de configuration, ou après avoir ajouté un nouveau provider/module :

• Télécharge les providers déclarés dans required_providers et les modules référencés, puis met à jour le fichier de lock (vu dans le module précédent).
• Configure le backend (local par défaut, ou distant s’il est défini).
• Idempotente : la relancer sur un répertoire déjà initialisé ne casse rien, c’est même le réflexe à avoir après un git pull qui touche aux versions de providers.

terraform init

terraform fmt et terraform validate

Deux commandes rapides à passer avant de committer, qui ne touchent ni au state ni à l’infrastructure :

• terraform fmt reformate les fichiers .tf selon la convention de style canonique (indentation, alignement des =).
• terraform validate vérifie que la configuration est syntaxiquement correcte et cohérente en interne (types, arguments requis, références). Elle ne contacte pas le provider et ne sait donc pas si une ressource existe déjà ou si les credentials sont valides.

terraform fmt -recursive
terraform validate

terraform plan

C’est l’étape qui rend Terraform prévisible : avant de toucher à quoi que ce soit, il annonce ce qu’il va faire.

• Compare la configuration, le state, et l’état réel de l’infrastructure via des appels en lecture au provider.
• Affiche un diff coloré : + création, - destruction, ~ mise à jour, et parfois -/+ (destroy puis recreate, quand un attribut ne peut pas être modifié en place).
• Peut être sauvegardé dans un fichier avec -out, pour garantir que l’apply qui suit exécute exactement ce plan et rien d’autre (important en CI, où le code peut changer entre les deux étapes).

terraform plan -out=tfplan

terraform apply

Exécute les actions du plan et persiste le résultat dans le state.

• Sans fichier de plan en argument, apply recalcule un plan et demande une confirmation interactive (yes) avant d’exécuter.
• Avec un fichier de plan (terraform apply tfplan), aucune confirmation n’est demandée : c’est le mode utilisé en CI/CD, après une revue humaine du plan affiché en amont.
• Terraform ordonne les créations/modifications/destructions selon le graphe de dépendances qu’il construit à partir de la configuration, pas selon l’ordre d’écriture des blocs.

terraform apply tfplan

terraform destroy

Détruit toutes les ressources gérées par le state courant.

• Fonctionne comme un apply dont le plan ne contient que des destructions.
• -target permet de limiter la portée à une ressource précise, mais c’est un outil de dépannage ponctuel, pas une pratique à généraliser : il casse la vision globale du plan et peut laisser des ressources dans un état incohérent avec la configuration.

terraform destroy

Ce qu’il faut retenir

• plan avant apply n’est pas optionnel : c’est la seule étape qui donne une visibilité sur ce qui va changer avant que ça ne change réellement.
• -out transforme un plan en contrat : ce qui a été revu est exactement ce qui sera appliqué, ce qui est indispensable dès qu’un pipeline CI s’intercale entre la revue humaine et l’exécution.
• fmt et validate sont des commandes de formattage et validation syntaxique, l’infrastructure sous jacente n’est pas analysée.

Prochaine étape de la série : la configuration Terraform.