Refactoriser l’état avec moved et removed

Lorsque vous renommez une ressource dans votre configuration, Terraform constate que l’ancienne adresse a disparu et qu’une nouvelle apparaît. Par défaut, il va détruire puis recréer la ressource, ce qui peut entraîner une interruption de service ou une perte de données.

Les outils de refactorisation de l’état vous permettent d’indiquer à Terraform qu’une ressource a simplement été déplacée.

Commencez par lister les éléments suivis dans l’état. La commande terraform state list affiche toutes les adresses des ressources gérées.

L’approche classique consiste à utiliser terraform state mv, qui réécrit l’adresse d’une ressource dans l’état. Ici, nous renommons une instance de aws_instance.web en aws_instance.app.

state mv est une action CLI manuelle et ponctuelle. Elle n’est pas enregistrée dans le code : les coéquipiers qui appliquent la même modification sur leur machine doivent donc la répéter. Cette approche est source d’erreurs dans les flux de travail collaboratifs.

Le bloc moved enregistre un renommage dans votre configuration. Terraform l’applique automatiquement pour tout le monde lors du prochain plan, puis vous pouvez supprimer le bloc ultérieurement.

Les blocs moved permettent également d’encapsuler des ressources dans un module. L’adresse cible inclut le chemin du module.

Après avoir ajouté un bloc moved, exécutez terraform plan. Un déplacement correct n’affiche ni destruction ni création, mais uniquement une modification d’adresse. Si un remplacement apparaît toujours, le bloc est incorrect.

Vous pouvez parfois vouloir que Terraform cesse de gérer une ressource sans détruire l’infrastructure réelle. La commande impérative est terraform state rm.

Les versions récentes de Terraform prennent en charge un bloc removed. Avec lifecycle { destroy = false }, Terraform oublie la ressource dans l’état, tout en laissant l’infrastructure réelle intacte.

Pour les projets volumineux, terraform state mv -state-out peut déplacer des ressources entre plusieurs fichiers d’état, ce qui est utile pour diviser un monolithe en piles appliquées indépendamment.

Terraform écrit un fichier .backup avant de modifier l’état. Toutefois, avec des moteurs principaux distants, vérifiez toujours que l’état n’est pas verrouillé par un coéquipier avant toute opération manuelle, afin d’éviter une corruption.

Testez vos connaissances en matière de refactorisation.

Vous pouvez maintenant restructurer l’infrastructure sans la détruire :

• state mv / state rm pour les modifications impératives.
• Les blocs moved pour les renommages déclaratifs.
• Les blocs removed pour oublier une ressource sans la détruire.
• Vérifiez toujours avec un plan qui n’affiche aucun remplacement.