Gestion du state Terraform à grande échelle

Le fichier state de Terraform est la source de vérité de votre infrastructure. Quand vous gérez un seul projet, le state local par défaut fonctionne bien. Mais dès que vous avez plusieurs environnements, membres d'équipe ou pipelines CI/CD, la gestion du state devient l'aspect le plus critique de votre workflow Terraform.

Remote State avec Azure Storage

Pour les projets basés sur Azure, je stocke le state Terraform dans Azure Blob Storage avec le versioning et le soft delete activés :

terraform {  backend "azurerm" {    resource_group_name  = "rg-terraform-state"    storage_account_name = "stterraformstate"    container_name       = "tfstate"    key                  = "prod/networking.tfstate"  }}

Le compte de stockage doit être provisionné en dehors de Terraform (via un script de bootstrap) et configuré avec :

#!/bin/bash
az storage account create \
  --name stterraformstate \
  --resource-group rg-terraform-state \
  --sku Standard_GRS \
  --encryption-services blob \
  --allow-blob-public-access false

az storage account blob-service-properties update \
  --account-name stterraformstate \
  --enable-versioning true \
  --enable-delete-retention true \
  --delete-retention-days 30

Le stockage géo-redondant (GRS) garantit que votre state survit aux pannes régionales. Le versioning vous permet de récupérer en cas de corruption accidentelle du state.

State Locking

Azure Blob Storage fournit un verrouillage natif basé sur les leases. Quand un terraform apply est en cours, une autre tentative échouera avec une erreur de verrouillage plutôt que de corrompre le state. C'est automatique avec le backend azurerm — aucune configuration supplémentaire n'est nécessaire.

Si un verrou reste bloqué (par exemple, un runner CI qui a crashé en plein apply), vous pouvez forcer le déverrouillage :

terraform force-unlock LOCK_ID

Mais utilisez cela avec précaution — assurez-vous qu'aucune autre opération n'est réellement en cours.

Structurer les fichiers State

Un seul gros fichier state pour tout est un anti-pattern. Je structure le state par couche et par environnement :

environments/
  prod/
    networking/    # VNets, subnets, NSGs, peerings
    compute/       # VMs, VMSS, clusters AKS
    data/          # Bases de données, stockage, caches
    monitoring/    # Log Analytics, alertes, dashboards
  staging/
    networking/
    compute/
    data/

Chaque répertoire a son propre fichier state. Cela apporte :

• Réduction du rayon d'impact : Un apply défectueux dans compute/ ne peut pas détruire votre réseau
• Opérations plus rapides : terraform plan s'exécute en secondes au lieu de minutes
• Workflows d'équipe indépendants : L'équipe réseau et l'équipe applicative ne se bloquent pas mutuellement

Références croisées avec les Data Sources

Quand les fichiers state sont séparés, vous devez partager les outputs entre eux. Utilisez les data sources terraform_remote_state :

data "terraform_remote_state" "networking" {  backend = "azurerm"  config = {    resource_group_name  = "rg-terraform-state"    storage_account_name = "stterraformstate"    container_name       = "tfstate"    key                  = "prod/networking.tfstate"  }} resource "azurerm_kubernetes_cluster" "aks" {  name                = "aks-prod"  location            = data.terraform_remote_state.networking.outputs.location  resource_group_name = data.terraform_remote_state.networking.outputs.resource_group_name   default_node_pool {    vnet_subnet_id = data.terraform_remote_state.networking.outputs.aks_subnet_id  }}

Hygiène du fichier State

Auditez régulièrement votre state avec terraform state list et nettoyez les ressources orphelines. Utilisez terraform import pour intégrer les ressources créées manuellement sous gestion, et terraform state rm pour retirer les ressources qui sont maintenant gérées ailleurs.

Un fichier state bien géré est le fondement d'une infrastructure-as-code fiable. Investissez le temps nécessaire dès le départ pour bien faire les choses.