L'état Terraform

Le state est la pièce centrale de Terraform. Sans le comprendre, on ne comprend pas pourquoi Terraform fait ce qu'il fait. Avec lui, on peut diagnostiquer n'importe quelle situation : ressource fantôme, import manuel, refactoring de code.

Qu'est-ce que le state

Le fichier terraform.tfstate est un JSON qui mappe chaque ressource déclarée en HCL à sa contrepartie réelle (ID, attributs, dépendances). Lors d'un plan, Terraform compare :

1. L'état désiré (le code HCL)
2. L'état actuel (le state file)
3. L'état réel (interrogation de l'API du provider)

Le plan résulte de la diff entre ces trois états.

Commandes de gestion du state

# Lister toutes les ressources dans le state
terraform state list

# Voir les attributs d'une ressource
terraform state show aws_instance.web

# Renommer une ressource dans le state (après refactoring du code)
terraform state mv aws_instance.web aws_instance.web_server

# Supprimer une ressource du state sans la détruire
# (utile pour "désadopter" une ressource sans la supprimer)
terraform state rm aws_instance.legacy

# Forcer le rafraîchissement du state depuis les APIs
terraform refresh   # ou terraform plan -refresh-only

Import : adopter une ressource existante

Pour gérer avec Terraform une ressource créée manuellement ou par un autre outil :

# Depuis Terraform 1.5 : import block dans le code
import {
  to = aws_instance.web
  id = "i-0123456789abcdef0"
}

resource "aws_instance" "web" {
  # Terraform génère la config avec : terraform plan -generate-config-out=generated.tf
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}

# Ancienne méthode (toujours supportée)
terraform import aws_instance.web i-0123456789abcdef0

Moved blocks : refactoring sans destruction

Lors d'un refactoring (renommage de ressource, passage à for_each), le moved block indique à Terraform que c'est la même ressource sous un nouveau nom :

moved {
  from = aws_instance.web
  to   = aws_instance.web_server["web1"]
}

State et sécurité

Le state contient potentiellement des données sensibles en clair : mots de passe, clés API, certificats. Même avec des variables sensitive = true, les valeurs sont stockées en clair dans le state. Conséquences pratiques :

• Ne jamais stocker le state dans Git
• Utiliser un backend distant avec chiffrement au repos (S3+SSE, GCS, Terraform Cloud)
• Restreindre l'accès au bucket/backend au minimum nécessaire

Workspaces et state

Chaque workspace Terraform maintient son propre state file. Sur un backend S3, les states sont stockés dans des clés différentes selon le workspace :

s3://mon-bucket/terraform/projet/terraform.tfstate           # workspace default
s3://mon-bucket/terraform/projet/env:/staging/terraform.tfstate  # workspace staging