Quand deux personnes modifient le même état d'infrastructure en même temps

Imaginez ceci : le développeur A et le développeur B doivent tous deux mettre à jour une partie de l'infrastructure. Ils récupèrent l'état actuel depuis le même bucket S3, chacun apporte ses propres modifications, puis tous deux renvoient leur nouvel état vers S3. Résultat ? Les modifications de l'un écrasent silencieusement celles de l'autre. L'infrastructure qui tourne dans le cloud ne correspond plus à ce que dit le fichier d'état. Personne ne sait quelles ressources sont réellement gérées, et l'équipe perd le contrôle.

Il ne s'agit pas ici de deux personnes éditant directement la même ressource. Il s'agit de deux personnes modifiant l'enregistrement de ces ressources. Et la solution s'appelle le verrouillage d'état (state locking).

Ce que fait réellement le verrouillage d'état

Le verrouillage d'état est simple dans son concept. Avant que quiconque ne commence à modifier l'état, le système tente de le verrouiller. Si le verrou est acquis, cette personne peut lire l'état, apporter des modifications et enregistrer la nouvelle version. Pendant ce temps, toute autre personne tentant d'accéder au même état est bloquée. Elle attend que le verrou soit libéré. Une fois les modifications enregistrées, le verrou se libère automatiquement.

Le diagramme de séquence suivant illustre comment deux développeurs interagissent avec les backends d'état et de verrouillage :

sequenceDiagram participant A as Développeur A participant B as Développeur B participant S3 as Backend d'état (S3) participant DB as Backend de verrouillage (DynamoDB) A->>DB: Acquérir le verrou DB-->>A: Verrou acquis A->>S3: Lire l'état actuel S3-->>A: Données d'état B->>DB: Acquérir le verrou DB-->>B: Verrou refusé (attente) A->>S3: Écrire le nouvel état S3-->>A: OK A->>DB: Libérer le verrou DB-->>A: Verrou libéré B->>DB: Acquérir le verrou DB-->>B: Verrou acquis B->>S3: Lire l'état actuel S3-->>B: Données d'état

Sans ce mécanisme, les modifications concurrentes corrompent votre état. Et un état corrompu signifie que vous n'avez plus de source fiable pour votre infrastructure.

Comment les différents backends gèrent les verrous

Tous les backends d'état ne gèrent pas le verrouillage de la même manière. Si vous stockez l'état dans S3, vous avez besoin d'un backend supplémentaire comme DynamoDB pour gérer le verrou. DynamoDB enregistre qui détient le verrou, quand il a commencé et quel état est verrouillé. Chaque fois que quelqu'un tente de modifier l'état, le système vérifie d'abord DynamoDB. Si un verrou est actif, l'opération s'arrête et renvoie une erreur.

Voici une configuration minimale de backend Terraform qui active le verrouillage d'état avec S3 et DynamoDB :

terraform {
  backend "s3" {
    bucket         = "my-company-terraform-state"
    key            = "prod/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

L'attribut dynamodb_table indique à Terraform d'utiliser une table DynamoDB nommée terraform-locks pour le verrouillage. Cette table doit exister avant d'exécuter terraform init. Elle nécessite une clé primaire nommée LockID (type String). Terraform créera et libérera automatiquement les entrées de verrouillage dans cette table lors des opérations sur l'état.

Certains backends intègrent le verrouillage nativement. Consul et etcd, par exemple, sont conçus pour les systèmes distribués, donc le verrouillage fait partie de leur fonctionnement normal. Vous n'avez pas besoin de configurer des composants supplémentaires comme DynamoDB. Mais cette commodité a un prix : vous devez désormais gérer et maintenir Consul ou etcd vous-même.

Quand les verrous échouent

Les verrous peuvent échouer d'une manière qui bloque votre état. Voici un scénario courant : quelqu'un démarre une modification, puis sa connexion Internet est interrompue en cours d'opération. Le verrou a été acquis mais jamais libéré car le processus est mort. L'état est maintenant verrouillé et personne ne peut le modifier.

Dans cette situation, vous devez forcer le déverrouillage (force unlock). Ce n'est pas une opération à prendre à la légère. Si vous forcez la libération d'un verrou alors que le processus d'origine est encore en cours d'exécution quelque part, vous risquez de corrompre l'état. L'équipe doit vérifier que le processus bloqué est bien mort avant de procéder à un déverrouillage forcé.

Des outils comme Terraform fournissent des commandes pour le déverrouillage manuel. Mais le déverrouillage forcé ne doit jamais être une opération de routine. Si votre équipe rencontre fréquemment des verrous bloqués, examinez les causes profondes : stabilité du réseau, configurations de timeout, ou la façon dont les pipelines sont exécutés.

Pourquoi cela va au-delà du simple verrouillage

Le verrouillage d'état est un pont vers une gestion d'environnement plus structurée. Une fois que votre état est à l'abri des modifications concurrentes, vous pouvez réfléchir à la façon d'utiliser une seule configuration pour plusieurs environnements sans dupliquer le code. C'est là que les workspaces entrent en jeu.

Mais avant de passer aux workspaces, assurez-vous que le verrouillage est correct. Une équipe qui ignore le verrouillage d'état finira par faire face à une situation où les modifications d'infrastructure disparaissent silencieusement, des ressources sont orphelines, et personne ne fait plus confiance au fichier d'état.

Checklist pratique pour le verrouillage d'état

  • Choisissez un backend avec support du verrouillage. S3 nécessite DynamoDB. Consul et etcd l'ont intégré. Sachez ce que votre backend exige.
  • Testez les scénarios d'échec de verrouillage. Simulez une perte de réseau pendant un changement d'état. Le verrou reste-t-il bloqué ? Votre équipe peut-elle récupérer sans panique ?
  • Documentez la procédure de déverrouillage forcé. Écrivez exactement comment vérifier qu'un processus bloqué est bien mort et comment libérer le verrou. Ne laissez pas cela à la connaissance informelle.
  • Surveillez la contention des verrous. Si plusieurs personnes rencontrent fréquemment des états verrouillés, votre équipe a peut-être besoin d'une meilleure coordination ou de modifications plus petites et plus fréquentes.
  • Définissez des timeouts appropriés. Les opérations de longue durée devraient avoir des timeouts qui libèrent automatiquement les verrous si le processus se bloque.

L'essentiel à retenir

Le verrouillage d'état n'est pas optionnel. Sans lui, les modifications concurrentes corrompront silencieusement votre état d'infrastructure, et vous ne le saurez pas jusqu'à ce que quelque chose casse en production. Mettez en place le verrouillage avant que votre équipe ne dépasse une personne, et traitez le déverrouillage forcé comme un extincteur : sachez où il est, sachez comment l'utiliser, mais ne prévoyez pas de l'utiliser tous les jours.