terraform plan -out=tfplan : cette commande, exécutée avant tout apply, devrait toujours produire un fichier de plan figé, relu intégralement avant d’être appliqué, plutôt qu’un enchaînement direct de terraform apply sans étape intermédiaire de relecture humaine.
Cette liste de contrôle porte spécifiquement sur la revue d’un rôle Terraform réutilisable, destiné à provisionner de nouveaux serveurs WordPress au sein d’un parc en croissance. Elle ne traite pas d’Ansible, déjà couvert ailleurs pour la partie configuration applicative post-déploiement, mais uniquement du module Terraform responsable du provisionnement de l’infrastructure elle-même.
Le fichier de plan doit être lu intégralement, ligne par ligne
Un rôle Terraform correctement écrit peut malgré tout produire un plan inattendu si une variable a été mal transmise, ou si l’état distant ne reflète plus fidèlement l’infrastructure réelle après une modification manuelle effectuée hors Terraform. La revue commence donc systématiquement par la lecture complète de la sortie de terraform plan, avec une attention particulière portée aux ressources marquées pour destruction et recréation, plutôt qu’à une simple modification en place.
- Une ressource marquée
-/+(destruction puis recréation) sur un serveur déjà en production doit toujours déclencher une question explicite : ce remplacement est-il réellement souhaité, ou révèle-t-il une dérive entre l’état Terraform et la réalité du terrain ? - Le nombre total de ressources affectées doit correspondre à ce qui était attendu avant l’exécution : un plan qui affecte davantage de ressources que prévu mérite d’être interrompu et investigué avant validation.
L’état Terraform et son verrouillage à distance
Le fichier d’état (terraform.tfstate) contient la représentation complète de l’infrastructure gérée, y compris potentiellement des données sensibles issues des ressources créées. La revue vérifie systématiquement que cet état est stocké à distance, avec verrouillage actif, plutôt que localement sur le poste d’un seul membre de l’équipe.
terraform {
backend "s3" {
bucket = "infra-wordpress-tfstate"
key = "hebergement/production/terraform.tfstate"
region = "eu-west-3"
dynamodb_table = "terraform-locks"
encrypt = true
}
}
Le verrouillage via une table dédiée, ici illustrée avec DynamoDB, empêche deux membres de l’équipe d’appliquer simultanément des modifications concurrentes sur le même état, une situation qui peut sinon corrompre silencieusement la représentation de l’infrastructure réelle.
Contrôler les valeurs par défaut des variables sensibles
Un rôle Terraform réutilisable définit souvent des valeurs par défaut pour ses variables, afin de simplifier son adoption par d’autres membres de l’équipe. La revue vérifie qu’aucune valeur par défaut ne concerne un identifiant, un mot de passe ou une clé d’accès, ces éléments devant systématiquement être injectés via des variables sans valeur par défaut, alimentées par un gestionnaire de secrets externe au dépôt de code.
variable "db_root_password" {
description = "Mot de passe root MySQL, injecté via un gestionnaire de secrets"
type = string
sensitive = true
# Aucune valeur par défaut : la variable doit être fournie explicitement
}
L’attribut sensitive = true masque la valeur dans les journaux d’exécution de Terraform, mais ne garantit en rien qu’elle soit absente du fichier d’état lui-même : celui-ci continue de contenir la valeur en clair, ce qui renforce l’exigence de chiffrement du stockage distant évoquée plus haut.
Vérifier la compatibilité entre versions de Terraform et de providers
Un dernier point de contrôle porte sur les contraintes de version déclarées dans le rôle : une contrainte trop permissive sur la version du provider utilisé (par exemple pour un fournisseur d’infrastructure cloud) expose le parc au risque qu’un apply exécuté plusieurs mois plus tard utilise une version de provider différente de celle testée initialement, avec un comportement potentiellement modifié entre-temps.
terraform {
required_version = ">= 1.3.0, < 2.0.0"
required_providers {
openstack = {
source = "terraform-provider-openstack/openstack"
version = "~> 1.51.0"
}
}
}
Un rôle Terraform qui fonctionne aujourd’hui sans contrainte de version explicite n’offre aucune garantie qu’il produira le même résultat dans six mois, une fois les providers mis à jour en amont.
En résumé
La revue d’un rôle Terraform destiné au provisionnement de serveurs WordPress porte sur trois axes distincts de son module Ansible équivalent : la lecture complète et systématique du plan avant chaque application, la sécurisation du stockage et du verrouillage de l’état distant, et le contrôle strict des valeurs par défaut et des contraintes de version. Ces trois points, vérifiés avant chaque nouveau rôle mis en production, ont évité plusieurs incidents de dérive d’infrastructure sur ce parc en croissance continue.
