Conseils Terraform Plan B : Stratégies de secours et de reprise après sinistre pour l'IaC

Même les pipelines d'Infrastructure as Code (IaC) les mieux conçus peuvent échouer. Qu'il s'agisse d'une corruption accidentelle du state, d'une limitation de débit (rate limit) de l'API d'un fournisseur en plein incident, d'un crash brutal de pipeline en cours d'application ou d'une panne généralisée du fournisseur cloud, se reposer uniquement sur le flux linéaire du « happy path » est la recette idéale pour une indisponibilité catastrophique.

Lorsque la production est interrompue et que terraform apply se termine par des erreurs fatales, vous avez besoin d'un Plan B immédiatement exploitable. Ce guide détaille des conseils pratiques et éprouvés pour parer aux imprévus avec Terraform, des mécanismes de secours architecturaux et des modèles de reprise pour protéger vos systèmes lorsque l'automatisation principale fait défaut.

---

1. Mettre en œuvre le versioning d'objets S3/GCS et les snapshots d'état automatisés

Votre fichier d'état Terraform (terraform.tfstate) est l'unique source de vérité reliant votre configuration déclarée aux ressources cloud en production. En cas de corruption de l'état, votre plan de récupération par défaut doit être instantané et non destructif.

Conseils pratiques :

• Activer le versioning d'objets : Assurez-vous que le bucket de votre backend distant (AWS S3, Google Cloud Storage ou Azure Blob) intègre impérativement le versioning des objets.
• Snapshots à un instant T (Point-in-Time) : Mettez en place un job CI planifié ou un hook de cycle de vie au niveau du bucket pour générer des copies de snapshot horodatées avant les fenêtres de déploiement à fort impact.
• Isoler les tables de verrouillage : Si vous utilisez AWS DynamoDB pour le verrouillage d'état (state locking), configurez la récupération à un instant T (PITR) automatisée pour la table de verrou afin de parer à son épuisement ou à sa corruption.

# AWS S3 Backend with Mandatory Versioning and Encryption
resource "aws_s3_bucket" "terraform_state" {
  bucket        = "company-production-tfstate"
  force_destroy = false

  lifecycle {
    prevent_destroy = true
  }
}

resource "aws_s3_bucket_versioning" "state_versioning" {
  bucket = aws_s3_bucket.terraform_state.id
  versioning_configuration {
    status = "Enabled"
  }
}

---

2. Réduire le rayon d'impact grâce aux architectures de micro-états

Les fichiers d'état monolithiques représentent la première cause d'échecs d'infrastructure irrécupérables. Si votre réseau, vos bases de données, vos accès IAM et vos clusters de conteneurs cohabitent au sein d'un unique fichier d'état, un simple conflit de verrouillage ou une suppression de ressource en échec peut paralyser l'intégralité de votre chaîne de livraison.

Stratégie Plan B :

• Partitionner par cycle de vie et volatilité : Séparez les ressources qui changent toutes les heures (ex. configurations d'autoscaling, définitions de tâches ECS) des infrastructures qui n'évoluent que rarement (ex. VPCs, sous-réseaux, tables de routage, politiques de confiance IAM).
• Référencer les outputs inter-états en toute sécurité : Utilisez des sources de données terraform_remote_state ou des références à un gestionnaire de paramètres (AWS SSM, HashiCorp Vault) plutôt que de coupler directement les états entre eux.

# Read baseline network attributes without sharing write locks
data "terraform_remote_state" "vpc" {
  backend = "s3"
  config = {
    bucket = "company-production-tfstate"
    key    = "network/vpc/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_security_group" "app_sg" {
  name        = "application-sg"
  vpc_id      = data.terraform_remote_state.vpc.outputs.vpc_id
  description = "Allows ingress from VPC tier"
}

---

3. Préparer le playbook de déverrouillage d'urgence « Break-Glass »

Lors d'incidents critiques, un runner CI/CD qui plante laisse fréquemment un verrou actif dans la base de données du backend. Les ingénieurs exécutant des commandes standard se heurtent alors au message suivant :

Error: Error acquiring the state lock: ConditionalCheckFailedException
Lock Info:
  ID:        1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
  Path:      production-tfstate/terraform.tfstate
  Who:       runner@ci-agent-04
  Created:   2025-02-18 10:14:02 UTC

Sans protocole validé au préalable, les équipes perdent un temps précieux à débattre de l'opportunité de forcer le déverrouillage.

Protocole de secours :

1. Vérifier l'état du processus : Inspectez votre agent CI/CD ou votre serveur d'orchestration pour confirmer que le processus associé au Lock ID est bel et bien arrêté et qu'il n'exécute pas simplement une tâche de provisionnement lente.
2. Exécuter un déverrouillage ciblé : Évitez de supprimer manuellement des entrées en base de données. Exécutez terraform force-unlock avec le Lock ID spécifique :

   terraform force-unlock -force 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
   

3. Récupérer et valider l'état immédiatement :

   terraform state pull > state-backup-$(date +%s).json
   terraform refresh
   

---

4. Concevoir des remplacements de ressources Blue/Green (Le Plan B de Rollback)

Par défaut, Terraform tente une modification sur place (in-place) ou applique un cycle Destroy-then-Create pour les ressources immuables. Si la ressource de remplacement rencontre un dépassement de quota, un refus d'autorisation ou une erreur de syntaxe en cours de création, votre ressource opérationnelle d'origine est déjà détruite.

La solution : create_before_destroy

Intégrez la gestion du cycle de vie pour garantir que les instances secondaires ou de remplacement réussissent leur initialisation avant que les instances actives ne soient détruites.

resource "aws_launch_template" "core_service" {
  name_prefix   = "core-service-"
  image_id      = var.ami_id
  instance_type = var.instance_type

  lifecycle {
    create_before_destroy = true
  }
}

Pour des bascules en production sans aucune interruption de service, déployez des configurations miroirs secondaires à l'aide de flags de workspaces ou d'identifiants de modules distincts. Si le déploiement sur la v2 échoue aux vérifications d'état (healthchecks), le pipeline CI/CD réoriente simplement les cibles de trafic vers la v1 sans avoir à exécuter un rollback précipité et imprévisible.

---

5. Maîtriser les commandes de refactorisation ciblées : moved et state rm

Renommer des modules ou réorganiser l'arborescence de vos répertoires sans stratégie de secours peut amener Terraform à planifier la destruction de chaque ressource renommée lors de l'exécution suivante.

Le problème historique :

Auparavant, le renommage nécessitait des invocations manuelles et risquées de la commande terraform state mv, exécutées sur plusieurs postes différents.

La défense Plan B : Les blocs déclaratifs moved

Intégrez systématiquement des blocs déclaratifs moved dans votre code source avant de refactoriser des identifiants de ressources. Cela garantit que les runners CI/CD tout comme les terminaux locaux des développeurs exécutent la même migration d'état en toute fluidité, sans recréation de ressources.

# Safely rename a module without destroying running databases
moved {
  from = module.legacy_database.aws_db_instance.main
  to   = module.primary_storage.aws_db_instance.postgres
}

Découplage d'urgence avec state rm :

Lorsqu'une ressource doit être retirée de la gestion automatisée pendant un incident sans pour autant déclencher sa suppression réelle chez le fournisseur cloud, retirez-la du suivi de l'état :

terraform state rm module.network.aws_route_table.critical_route

Cette action isole la ressource, autorisant des modifications manuelles pour résoudre les incidents sans interférence des exécutions automatisées.

---

6. Maintenir une détection de dérive automatisée et une validation de plan hors ligne

Lorsqu'une urgence inattendue survient, les équipes interviennent fréquemment manuellement dans les consoles des fournisseurs cloud. Cela introduit une dérive d'état (drift), faisant courir le risque que les exécutions ultérieures de Terraform n'écrasent les correctifs d'urgence ou n'échouent complètement.

Bonnes pratiques :

• Pipelines nocturnes de détection de dérive : Planifiez des exécutions CI sans intervention humaine exécutant terraform plan -detailed-exitcode. Un code de sortie égal à 2 indique une dérive et déclenche des alertes avant que les ingénieurs ne poussent des modifications conflictuelles.
• Plans spéculatifs sur les Pull Requests : Ne fusionnez jamais de pull requests sans tester les plans d'exécution par rapport à l'état réel.
• Mise en cache locale des fournisseurs (Providers) : Empêchez les coupures d'API en amont de bloquer les applications de secours en configurant un cache partagé de plugins de providers dans ~/.terraformrc :

plugin_cache_dir = "$HOME/.terraform.d/plugin-cache"
disable_checkpoint = true

---

Guide de référence rapide : Checklist de secours Terraform

---

Résumé

Disposer d'un « Plan B » efficace pour Terraform consiste à remplacer la panique par des procédures définies et auditables. En imposant le versioning d'état, en divisant les racines monolithiques en sous-états délimités, en exploitant les refactorisations déclaratives avec moved et en préparant des runbooks de déverrouillage d'état d'urgence, vous garantissez que les incidents d'infrastructure peuvent être résolus en quelques minutes plutôt qu'en plusieurs heures.