L'état Terraform : ce qu'il stocke, pourquoi il est verrouillé et comment la dérive se manifeste

Ce que c'est

La documentation sur l'état (citée) décrit l'objectif premier de l'état comme le stockage des correspondances entre les objets d'un système distant et les instances de ressources déclarées dans la configuration : lorsque Terraform crée un objet distant, il enregistre l'identité de cet objet en regard de l'adresse de ressource, afin que des modifications ultérieures mettent à jour ou suppriment le même objet. L'état est un fichier texte JSON ; par défaut, il réside localement sous le nom terraform.tfstate, et la documentation déconseille de le stocker dans le contrôle de version ou dans tout stockage dépourvu de verrouillage et de contrôle d'accès, car cela peut entraîner une perte de données ou exposer des secrets stockés dans le fichier d'état.

Verrouillage (cité) : si le backend le prend en charge, Terraform verrouille l'état pour toute opération susceptible de l'écrire, silencieusement, et refuse de continuer lorsque le verrou ne peut pas être obtenu. force-unlock existe pour un verrou laissé par une exécution qui a planté, et prend l'identifiant du verrou comme garde-fou.

Pourquoi c'est important

Deux personnes ou deux pipelines qui appliquent en même temps sans verrou peuvent chacun écrire un état qui omet les ressources de l'autre ; le plan suivant propose alors de recréer ou de détruire une infrastructure réelle. La dérive, un changement effectué dans une console ou par un autre outil, n'est pas en soi une erreur, mais elle reste invisible jusqu'au prochain plan, et la documentation sur le plan (citée) avertit qu'appliquer systématiquement avec -target mène à une dérive de configuration non détectée.

Comment l'appliquer

• Utiliser un backend distant avec verrouillage et versionnement (stockage d'objets plus un mécanisme de verrou, ou un backend hébergé), et restreindre l'accès en lecture aussi strictement que l'accès en écriture, car l'état contient des valeurs d'attributs telles que des mots de passe générés.
• Exécuter terraform plan -refresh-only selon un calendrier régulier pour lister la dérive sans proposer de changements de configuration, et décider au cas par cas s'il faut adopter le changement dans le code ou le défaire.
• Produire les plans avec -out en intégration continue et appliquer exactement ce plan sauvegardé après relecture ; utiliser -detailed-exitcode pour faire échouer un contrôle lorsqu'une différence existe.
• Garder un état par rayon d'impact (blast radius) : séparer les environnements et séparer les fondations à longue durée de vie (réseaux, identité) des services fréquemment modifiés.
• Déplacer ou renommer des ressources avec des blocs moved plutôt que d'éditer l'état à la main.

Pièges

Un terraform import ou un state rm change les correspondances sans toucher à l'infrastructure, de sorte que le plan suivant peut sembler surprenant. Les mises à niveau de fournisseur (provider) peuvent réécrire les schémas d'état. La page sur l'état citée avertit que le fichier d'état peut contenir des secrets ; marquer une variable sensitive la masque dans la sortie, pas dans le fichier.