État Terraform sur S3 : adieu DynamoDB, bonjour use_lockfile

Pendant des années, verrouiller un état Terraform sur S3 imposait une table DynamoDB à côté du bucket. Depuis Terraform 1.11, le backend S3 sait poser son verrou directement dans le bucket, grâce aux écritures conditionnelles d’S3.

La configuration

terraform {
  required_version = ">= 1.11.0"
  backend "s3" {
    bucket       = "acme-tfstate-123456789012"
    key          = "production-main-blog.tfstate"
    region       = "eu-west-3"
    encrypt      = true
    use_lockfile = true
  }
}

Pendant une opération, Terraform crée un objet <key>.tflock à côté de l’état et le supprime à la fin.

Le piège de la version

Avant 1.11, l’option use_lockfile est acceptée sans erreur… et ignorée. Toutes les commandes tournent alors sans verrou. Contraindre required_version = ">= 1.11.0" dans le root module n’est donc pas un détail : c’est ce qui transforme une option silencieuse en garantie.

Un bucket par compte

Plutôt qu’un bucket central, un bucket d’état par compte AWS :

• les états de preprod restent dans le compte preprod, ceux de prod dans le compte prod ;
• les droits sur l’état suivent les droits sur le compte ;
• un incident sur un compte n’expose pas les états des autres.

Le bucket est versionné, chiffré, bloqué en accès public et refuse toute requête non TLS.

Migrer un état existant

1. Sauvegarder l’état actuel (terraform state pull > backup.tfstate).
2. Copier l’objet vers la nouvelle clé, sans le modifier.
3. Changer la configuration du backend dans une MR.
4. Vérifier que le plan de la MR affiche No changes.
5. Garder l’ancienne clé jusqu’au premier apply réussi : c’est le rollback.