Aller au contenu

Module 5 — Gestion de l’état : distant, drift, import et workspaces

Durée indicative du cours : 1h30
Durée indicative de l’atelier : — (atelier à venir)
Durée totale (cours + atelier) : ~2h00–2h30 selon lab

Objectif du module

En Terraform Basics et à l’atelier 5, vous avez observé le state, lu un plan de drift, et listé des ressources.
Ici, on agit : state distant, verrouillage, import, state rm, workspaces CLI, et décisions de réconciliation.

Prérequis mental : config, state et cloud sont trois choses distinctes (module 3 Basics — workflow).

Pourquoi le state local ne suffit plus

Avec un terraform.tfstate sur le disque :

  • un seul poste « possède » la vérité ;
  • risque de perte (disque, mauvaise branche Git si on commit par erreur) ;
  • deux personnes peuvent apply sans se voir.

Un backend distant stocke le state sur un service partagé (Azure Storage, Terraform Cloud, S3, etc.).
L’équipe lit et écrit le même carnet d’état, avec des contrôles d’accès.

Rappel

Un dossier racine Terraform = un state (par workspace).
Découper les stacks change aussi le nombre de states — on y revient au module 7.

Backend distant — exemple Azure Storage

Configuration typique (souvent dans versions.tf ou backend.tf) :

terraform {
  required_version = ">= 1.10.0"

  backend "azurerm" {
    resource_group_name  = "rg-tfstate-shared"
    storage_account_name = "sttfstatelab001"
    container_name       = "tfstate"
    key                  = "platform/demo.tfstate"
  }
}

Points à retenir :

  • Le backend se configure au terraform init (et parfois -migrate-state si on quitte le local).
  • Les secrets du storage (clés, SAS) ne vont pas dans le HCL versionné : env, MSI, OIDC, ou partial config.
  • La clé (key) identifie l’objet state dans le conteneur.
terraform init
# Première migration depuis un state local :
# terraform init -migrate-state

Migration

Migrer le state est une opération d’équipe.
Vérifiez qu’aucun apply concurrent n’est en cours, et que tout le monde init ensuite sur le même backend.

À enrichir

Checklist de création du storage (chiffrement, soft-delete, RBAC), partial backend + fichier -backend-config, et atelier guidé de migration lab.

State lock — ne pas confondre avec le lockfile

Verrou Fichier / mécanisme Protège quoi
Lockfile providers .terraform.lock.hcl Versions exactes des providers (vu en Basics)
State lock Lease / lock du backend Deux écritures concurrentes sur le même state

Pendant un plan / apply (selon backend), Terraform tente d’acquérir le lock.
Si un autre run le détient, vous voyez souvent : Error acquiring the state lock.

Forcer le unlock

terraform force-unlock <LOCK_ID> existe.
Ne l’utilisez que si vous êtes sûrs qu’aucun autre processus légitime ne tourne.
Un unlock trop tôt = state corrompu ou divergences d’équipe.

Sur Azure Storage, le lock s’appuie typiquement sur un lease du blob d’état.

Trois situations à ne pas confondre

Situation State Cloud Ce que fait souvent le plan Levier principal
Drift Ressource présente Modifiée hors Terraform (portail, autre outil) ~ update ou recreate Adapter le code puis apply, ou accepter le réel via refresh / réécriture HCL
Orphelin hors state Absente Ressource créée à la main Terraform ignore la ressource import (puis aligner le HCL)
Dans le state, détruite dehors Présente Ressource absente Recreate / erreurs provider Recréer via apply, ou state rm si on sort du management

Drift — ressource déjà gérée

Le state connaît la ressource.
Quelqu’un a changé un tag ou une SKU dans le portail.
Le plan propose de revenir à la config (ou de détecter un replace).

Réflexe :

  1. Lire le plan sans paniquer.
  2. Décider : le code a raison, ou le portail a raison.
  3. Soit apply pour réimposer le code, soit modifier le HCL pour matcher le réel (puis plan propre).

Import — adopter une ressource existante

# CLI historique
terraform import azurerm_resource_group.main /subscriptions/.../resourceGroups/rg-demo-lab

# Config moderne (Terraform récent) — idée
# bloc import { to = azurerm_resource_group.main ; id = "..." }

Bonne pratique :

  1. Écrire (ou générer) le HCL de la ressource avant ou juste après l’import.
  2. Utiliser l’ID Azure correct.
  3. Enchaîner un terraform plan : idéalement no changes, sinon comprendre chaque écart.

state rm — sortir du management sans détruire le cloud

terraform state rm azurerm_resource_group.main

La ressource reste dans Azure.
Terraform ne la gère plus.
Utile pour découper une stack, reprendre une main, ou corriger une erreur d’adresse — pas un réflexe quotidien.

state rm ≠ destroy

terraform destroy supprime le cloud.
state rm oublie seulement l’entrée dans le carnet.

Refresh : ce que ça fait, ce que ça ne répare pas

Pendant plan / apply, Terraform rafraîchit en général les attributs connus depuis le cloud.
Pour seulement aligner le state sur le réel, sans appliquer le .tf :

terraform apply -refresh-only

(L’ancienne commande terraform refresh est voisine ; on préfère -refresh-only.)

Le refresh ne :

  • n’importe pas une ressource inconnue du state ;
  • ne « répare » pas un HCL faux ;
  • ne remplace pas une décision d’équipe (code vs réel).

Rappel Basics : section refresh.

Réconciliation — choisir une stratégie

Objectif Action typique
Revenir au code Corriger le drift par apply
Adopter le réel Adapter le HCL, puis refresh / import / plan propre
Sortir du management state rm (ressource conserve dans le cloud)
Adopter une orpheline Écrire le HCL + import

Message examen TA-004

Savoir nommer drift, import, refresh et state rm, et ce que chacun touche (state vs cloud).

Workspaces CLI

Un workspace CLI est un espace d’état nommé pour le même code (même dossier, même backend).
Ce n’est pas un dossier Git différent : c’est une clé de state différente.

Idée Détail
Défaut Workspace default
Ce qui est isolé Le state (donc les ressources gérées sous ce nom)
Ce qui ne change pas Les fichiers .tf (sauf si vous branchez la logique sur terraform.workspace)
Référence HCL terraform.workspace → chaîne du workspace actif 
terraform workspace list
terraform workspace show
terraform workspace new lab-alice
terraform workspace select default
# terraform workspace delete lab-alice   # seulement si OK à perdre ce state

Backend local : souvent terraform.tfstate.d/<nom>/terraform.tfstate.
Backend Azure Storage : le nom du workspace entre en général dans le chemin / la clé de l’objet.

Usages légitimes de terraform.workspace dans le HCL (détail au module 8) :

locals {
  name_suffix = terraform.workspace == "default" ? "lab" : terraform.workspace
}

output "current_workspace" {
  value = terraform.workspace
}

Limites

Un mauvais workspace select puis apply touche le mauvais state.
Pour dev / test / prod sérieux, combinez discipline (tfvars, CI, droits) — ne comptez pas sur le seul nom de workspace.
Les workspaces Terraform Cloud sont un autre produit (même mot) — module 11.

Commandes state utiles (aperçu)

Commande Rôle
terraform state list Lister les adresses dans le state
terraform state show <addr> Afficher une ressource du state
terraform state mv Renommer / déplacer une adresse (refactor)
terraform state rm Retirer du state sans destroy cloud
terraform import Adopter une ressource cloud dans le state

Le module 6 approfondit import, -target, fmt et validate dans le workflow quotidien.

Suite

Poursuivre avec le module 6 — Commandes avancées.
Pratique (quand l’atelier sera prêt) : drift portail → décision ; ressource à la main → import ; cas state rm contrôlé.