Quiz : Terraform et OpenTofu, les fondamentaux

En déclaratif, on décrit l'état voulu (deux instances, un réseau, une base) et l'outil calcule les actions pour y arriver ; en impératif, on écrit la suite des actions. L'approche déclarative rend l'opération idempotente : appliquer deux fois la même description ne change rien la seconde fois. Leçon 1.

Le 10 août 2023, HashiCorp a fait passer Terraform de la licence libre MPL 2.0 à la BUSL 1.1, qui n'est pas une licence libre. OpenTofu est une bifurcation de la dernière version MPL (1.5.7), libre, hébergée par la Linux Foundation. Les deux partagent le langage HCL, le format de l'état et les fournisseurs ; chacun a depuis des fonctionnalités propres. Leçon 1.

+ créer, ~ modifier en place, -/+ remplacer (détruire puis recréer, la cause étant signalée par # forces replacement), - détruire. On lit d'abord la ligne Plan: N to add, N to change, N to destroy, et l'on refuse un remplacement inattendu. Leçons 1 et 2.

Il télécharge les fournisseurs (en respectant les contraintes de version et en vérifiant leurs signatures) dans .terraform/, configure le backend de l'état, et écrit .terraform.lock.hcl avec les versions retenues et leurs empreintes. Le fichier de verrouillage se versionne ; le répertoire .terraform/ non. Leçons 2 et 4.

Terraform refuse : le plan est périmé (Saved plan is stale), parce que l'état a changé depuis sa création. Il faut refaire un plan. C'est ce qui rend sûr le schéma « plan relu, puis apply de ce plan ». Leçons 2 et 12.

Elle crée une dépendance : Terraform crée le réseau avant la ressource qui le référence, et la détruit avant lui. C'est pourquoi l'ordre des blocs dans les fichiers n'a pas d'importance, et pourquoi depends_on n'est presque jamais nécessaire. Leçons 3 et 8.

Toute version 2.x supérieure ou égale à 2.84, mais pas 3.0 : ~> laisse augmenter le dernier composant écrit. La version effectivement retenue est figée dans le fichier de verrouillage, et ne change qu'avec terraform init -upgrade. Leçon 4.

Dans les variables d'environnement (SCW_ACCESS_KEY, SCW_SECRET_KEY...), sinon dans la configuration du fournisseur, sinon dans le fichier de configuration de la CLI scw. Jamais dans le code versionné. Leçon 4.

Non : sensitive masque l'affichage dans les plans et les sorties, mais la valeur est écrite en clair dans l'état. Pour qu'un secret n'y soit jamais écrit, il faut une valeur éphémère (Terraform 1.10, OpenTofu 1.11) passée à un argument en écriture seule (password_wo). Leçons 5 et 10.

prod.auto.tfvars : du plus fort au plus faible, -var et -var-file, puis les fichiers *.auto.tfvars, puis terraform.tfvars.json et terraform.tfvars, puis TF_VAR_, puis la valeur par défaut. Les fichiers *.auto.tfvars sont lus sans qu'on le demande, ce qui surprend. Leçon 5.

Il associe chaque ressource du code à l'objet réel (son identifiant), garde ses attributs et les dépendances, et permet de calculer le plan. Il contient tous les attributs, y compris les valeurs sensibles, en clair : mots de passe, clés générées. Il se protège donc comme un secret. Leçon 6.

state rm fait oublier la ressource à Terraform, sans la détruire : l'objet continue d'exister, hors gestion. Supprimer le bloc puis appliquer détruit l'objet. Le bloc removed avec destroy = false fait la première chose de façon relue et versionnée. Leçons 6 et 11.

Deux apply simultanés liraient le même état puis écriraient chacun le leur : l'un perdrait les changements de l'autre, ou les deux créeraient la même ressource. Avec use_lockfile = true, le backend crée un fichier de verrou par écriture conditionnelle dans le bucket ; l'ancien verrouillage par DynamoDB est déprécié chez Terraform. Object Storage de Scaleway le prend en charge depuis le 26 mai 2026. Leçon 7.

Les espaces de travail partagent le même backend, les mêmes identifiants et le même code : rien n'empêche une commande lancée dans le mauvais espace de toucher la production. Des états séparés, avec des droits distincts par environnement, limitent le rayon d'impact d'une erreur. Leçons 5 et 7.

lifecycle { create_before_destroy = true }. Il suppose que les deux objets peuvent coexister : pas de nom ou d'adresse unique imposés qui entreraient en conflit. Le réglage se propage aux ressources dont elle dépend. Leçon 8.

Les instances sont identifiées par leur index : retirer l'élément du milieu décale les suivants. Le plan modifie (ou remplace) l'instance d'index 1 pour lui donner le troisième nom, et détruit celle d'index 2 : deux instances touchées au lieu d'une. Avec for_each sur un ensemble de noms, chaque instance est identifiée par sa clé, et seule celle qui disparaît est détruite. Un bloc moved permet de passer de l'un à l'autre sans rien recréer. Leçons 9 et 11.

Pour générer des sous-blocs répétés à partir d'une collection (règles d'un groupe de sécurité, frontends), quand les écrire en clair n'est pas raisonnable. Jamais pour lifecycle ou provisioner, et pas par habitude : un bloc écrit en clair se relit mieux sur le plan. Leçon 9.

Un bloc import (to = l'adresse dans le code, id = l'identifiant chez le fournisseur, par exemple fr-par/<id> pour une base Scaleway), une configuration écrite à la main ou ébauchée par -generate-config-out, puis un apply. L'import est réussi quand le plan suivant ne propose aucun changement. Leçon 11.

Une tâche planifiée qui lance terraform plan -detailed-exitcode (ou -refresh-only pour isoler la dérive) : le code 0 signifie aucun changement, 2 des changements, 1 une erreur. Le code 2 déclenche une alerte, puis l'on réapplique, adopte dans le code, ou ignore un attribut en le justifiant. Leçons 11 et 12.

Le plan tourne sur chaque demande de fusion, y compris pour du code pas encore relu : il ne doit avoir que des droits de lecture. L'apply, après fusion et dans un environnement protégé, a les droits d'écriture. Scaleway n'ayant pas de fédération d'identité, ce sont des clés d'API distinctes, limitées au projet et qui expirent. Leçon 12.