TP 25 : Manipuler et réparer le state

TP 25 : Manipuler et réparer le state

Objectifs

À l’issue de ce TP, vous serez capable de :

• inspecter le state avec state list et state show ;
• déplacer une entrée avec state mv ;
• détacher une ressource du state avec state rm sans la détruire ;
• récupérer et inspecter le state brut avec state pull ;
• mesurer les risques des manipulations directes et savoir quand les éviter.

Prérequis

• Terraform >= 1.5.
• Le provider random (aucun coût cloud).

Avertissement : les commandes terraform state modifient directement la source de vérité. Sur un backend distant, prenez toujours une sauvegarde avant d’agir.

Contexte

Un state d’InfraBank a dérivé après une intervention manuelle. Vous devez le réparer chirurgicalement, sans détruire ni recréer d’infrastructure, tout en comprenant pourquoi ces opérations restent des exceptions.

Étape 1 : Construire un state à manipuler

versions.tf

terraform {
  required_version = ">= 1.5"
  required_providers {
    random = {
      source  = "hashicorp/random"
      version = "~> 3.6"
    }
  }
}

main.tf

resource "random_pet" "app" {
  length = 2
}

resource "random_integer" "port" {
  min = 8000
  max = 9000
}

terraform init
terraform apply -auto-approve

Étape 2 : Lister et inspecter

terraform state list
# random_integer.port
# random_pet.app

terraform state show random_pet.app

state show affiche tous les attributs stockés pour une ressource : c’est votre outil de diagnostic principal.

Étape 3 : Sauvegarder avant toute modification

terraform state pull > state.backup.json
head -c 300 state.backup.json

state pull récupère le state brut (utile pour l’archiver ou l’inspecter en JSON). Conservez cette copie : c’est votre filet.

Étape 4 : Déplacer une entrée avec state mv

state mv renomme une adresse dans le state, comme le bloc moved mais en impératif. On l’utilise ponctuellement, par exemple pour absorber un renommage déjà appliqué ailleurs.

terraform state mv random_pet.app random_pet.application
terraform state list
# random_integer.port
# random_pet.application

Il faut maintenant aligner le code sur le state, sinon le prochain plan proposera de recréer :

resource "random_pet" "application" {
  length = 2
}

terraform plan
# No changes.

Note : pour un refactoring durable et versionné, préférez le bloc moved (TP 24). state mv est réservé aux réparations ponctuelles.

Étape 5 : Détacher sans détruire avec state rm

state rm retire une ressource du state sans la détruire dans le cloud. Cas d’usage : transférer une ressource vers une autre configuration, ou cesser de la gérer avec Terraform.

terraform state rm random_integer.port
terraform state list
# random_pet.application

La ressource n’est plus suivie. Attention : le prochain plan considérera random_integer.port comme absente et proposera de la recréer si le code la déclare encore. Retirez donc aussi le code correspondant, ou ré-importez la ressource (TP 23) pour la rattacher.

Ici, retirez le bloc random_integer du code :

# supprimer le bloc random_integer.port de main.tf
terraform plan
# No changes.

Étape 6 : Comprendre les risques

Démonstration de la dérive : détachez la ressource restante mais gardez son code.

terraform state rm random_pet.application
terraform plan
# Plan: 1 to add ...  -> Terraform veut recréer ce qu'il ne suit plus

Ce plan illustre le danger central : le state et le code doivent rester cohérents. Un state rm sans nettoyage du code, ou un state mv sans mise à jour du code, produit soit une recréation, soit un doublon. Restaurez si besoin :

terraform state push state.backup.json   # restauration depuis la sauvegarde

Vérification

• state list reflète les manipulations effectuées.
• Après chaque opération, terraform plan a été ramené à « No changes » en alignant le code.
• La sauvegarde state.backup.json permet un retour arrière.

Nettoyage

# Si des ressources subsistent :
terraform destroy -auto-approve
rm -f state.backup.json