Quand votre fichier d'état Terraform disparaît : stratégies de récupération qui fonctionnent vraiment

Vous lancez terraform plan et au lieu du résultat habituel, vous obtenez une erreur. Le fichier d'état est manquant. Ou corrompu. Ou verrouillé par un processus mort depuis des heures. Votre premier réflexe pourrait être de paniquer, mais voici ce qu'il faut savoir : votre infrastructure fonctionne probablement encore très bien. Les serveurs, bases de données et équilibreurs de charge sont toujours là. Ce qui est cassé, c'est l'enregistrement de ce que Terraform pense exister.

Cette situation est rare, mais quand elle se produit, les équipes se figent. Vous ne pouvez plus faire de modifications via le code tant que l'état n'est pas restauré. La bonne nouvelle, c'est que la récupération est possible, et avoir un plan fait la différence entre un correctif rapide et une crise de plusieurs heures.

Pourquoi les fichiers d'état se cassent

Les fichiers d'état échouent de quelques manières prévisibles. La plus courante est la suppression accidentelle. Quelqu'un nettoie un bucket S3 sans se rendre compte que le fichier d'état s'y trouve. Un autre scénario est la corruption due à une opération d'écriture interrompue en plein milieu. Des problèmes réseau, des pannes électriques ou des arrêts brusques de processus peuvent laisser un fichier d'état à moitié écrit et illisible.

Il y a aussi le problème de verrouillage. Terraform verrouille les fichiers d'état pour empêcher plusieurs processus d'écrire simultanément. Si un processus meurt sans libérer son verrou, ce verrou reste en place. Chaque plan ou apply suivant échoue car Terraform pense que quelqu'un d'autre travaille encore.

La gravité varie, mais le problème central est le même : vous avez perdu la connexion entre votre code et votre infrastructure en cours d'exécution.

D'abord : ne reconstruisez pas tout

La règle la plus importante est de résister à l'envie de tout démolir et de recommencer. Votre infrastructure est toujours opérationnelle. Le fournisseur cloud connaît toujours chaque ressource que vous avez créée. Ce qui manque, c'est l'enregistrement local de ces ressources par Terraform.

Si vous lancez terraform destroy et recréez tout, vous provoquerez des temps d'arrêt inutiles et risquerez une perte de données. Les bases de données seront effacées. Les volumes persistants seront supprimés. Les enregistrements DNS changeront. La voie de la récupération consiste à restaurer l'état, pas à reconstruire l'infrastructure.

Récupération par gravité

État verrouillé : le correctif simple

Voici un arbre de décision pour vous aider à identifier rapidement votre chemin de récupération en fonction du type de problème de fichier d'état :

flowchart TD A[Problème de fichier d'état] --> B{Verrouillé ?} A --> C{Supprimé avec sauvegarde ?} A --> D{Corrompu ou manquant sans sauvegarde ?} A --> E{Perte totale ?} B --> F[Déverrouiller si aucun autre processus actif] C --> G[Restaurer depuis la sauvegarde] D --> H[Importer les ressources une par une] E --> I[Reconstruire depuis zéro] F --> J[Vérifier avec terraform plan] G --> J H --> J I --> J

Si le fichier d'état existe mais est verrouillé, c'est le scénario le plus simple. Trouvez quel processus détient le verrou. Si ce processus est toujours en cours, laissez-le finir. S'il est mort de manière inattendue, utilisez la commande force-unlock :

terraform force-unlock <lock_id>

Mais attention. Force-unlock n'est sûr que si vous êtes absolument certain qu'aucun autre processus n'écrit dans l'état. Si deux processus écrivent simultanément, vous vous retrouverez avec un état corrompu plus difficile à réparer qu'un simple verrou.

État supprimé avec sauvegarde : le scénario idéal

Si le fichier d'état a été supprimé mais que vous avez une sauvegarde, vous êtes en bonne posture. La récupération est simple : restaurez la sauvegarde à son emplacement d'origine.

C'est pourquoi le versionnage de votre backend d'état est crucial. Si vous utilisez S3, activez le versionnage du bucket. Quand un fichier est supprimé, vous pouvez restaurer la version précédente directement depuis la console ou la CLI S3. Aucune gestion de fichier de sauvegarde nécessaire.

Si vous n'avez pas de versionnage, les sauvegardes manuelles vers un emplacement séparé fonctionnent aussi. L'essentiel est d'avoir une copie stockée ailleurs que l'emplacement principal de l'état.

État corrompu ou manquant sans sauvegarde : la voie difficile

C'est là que les choses deviennent douloureuses. Vous n'avez pas de sauvegarde, et le fichier d'état est soit illisible, soit disparu. Mais votre infrastructure fonctionne toujours. La solution est de reconstruire l'état en important chaque ressource une par une.

Terraform a une commande import qui lit l'infrastructure existante et l'ajoute à votre fichier d'état. Pour chaque ressource définie dans votre code, vous exécutez :

Par exemple, pour importer une instance EC2 définie dans votre configuration comme aws_instance.web, vous exécuteriez :

terraform import aws_instance.web i-1234567890abcdef0

L'adresse de la ressource (aws_instance.web) doit correspondre exactement à ce que vous avez dans vos fichiers .tf. Si la ressource est dans un module, utilisez le chemin du module, comme module.my_module.aws_instance.web. Après l'importation, exécutez terraform plan pour confirmer que l'état correspond à votre configuration.

terraform import <type_ressource>.<nom_ressource> <id_ressource>

Le format de l'ID de ressource dépend du fournisseur. Pour AWS, il peut s'agir d'un ID d'instance ou d'un ARN. Pour GCP, c'est généralement le nom de la ressource ou une URL complète.

Ce processus est fastidieux pour les grandes infrastructures. Si vous avez des dizaines d'instances EC2, de bases de données RDS, d'équilibreurs de charge et de groupes de sécurité, vous allez exécuter des commandes d'importation pendant un moment. Mais c'est le seul moyen de réconcilier votre code avec la réalité sans rien détruire.

Perte totale sans voie de récupération : l'option nucléaire

Parfois, l'état est perdu, les sauvegardes n'existent pas, et l'infrastructure est trop complexe ou mal documentée pour être importée pièce par pièce. Dans ce cas, vous avez une option : reconstruire depuis zéro.

Cela signifie détruire toutes les ressources existantes et les recréer à partir de votre code Terraform. Ce n'est pas une décision à prendre à la légère, surtout pour les environnements de production. Mais si la récupération par importation n'est pas réalisable, la reconstruction est souvent plus rapide que d'essayer de reconstruire manuellement l'état pour des centaines de ressources.

Avant d'emprunter cette voie, assurez-vous d'avoir :

  • Un code Terraform complet qui correspond à ce qui est en cours d'exécution
  • Des sauvegardes de données pour les bases de données et le stockage persistant
  • Une fenêtre de maintenance avec l'approbation des parties prenantes
  • Un plan de retour arrière si la reconstruction échoue

Liste de contrôle pratique pour la récupération d'état

Quand l'état se casse, parcourez cette liste de contrôle dans l'ordre :

  1. Confirmez les dégâts - L'état est-il verrouillé, supprimé ou corrompu ? Vérifiez attentivement le message d'erreur.
  2. Vérifiez les sauvegardes - Regardez le versionnage sur votre backend. Vérifiez les emplacements de sauvegarde manuelle.
  3. Restaurez si possible - Si vous avez une sauvegarde, restaurez-la et vérifiez avec terraform plan.
  4. Déverrouillez si verrouillé - Seulement si vous êtes sûr qu'aucun autre processus n'est actif.
  5. Importez les ressources - Si aucune sauvegarde n'existe, commencez à importer les ressources une par une.
  6. Envisagez la reconstruction - Seulement si l'importation est irréalisable et que vous avez une couverture de code complète.

Mieux vaut prévenir que guérir

Le meilleur moment pour se préparer à une défaillance de l'état, c'est avant qu'elle ne se produise. Trois pratiques facilitent grandement la récupération :

D'abord, activez le versionnage sur votre backend d'état. Que ce soit S3, Azure Storage ou GCS, le versionnage vous donne un filet de sécurité en cas de suppression accidentelle ou de corruption.

Ensuite, automatisez les sauvegardes. Même avec le versionnage, stockez des copies de votre fichier d'état dans un emplacement séparé. Un simple cron job ou une étape de pipeline qui copie le fichier d'état vers un autre bucket ou compte de stockage prend cinq minutes à configurer.

Troisièmement, documentez votre infrastructure. Quand vous devez importer des ressources, vous devez savoir ce qui existe et quels IDs elles ont. Un inventaire à jour des ressources, soit dans un README, soit généré à partir de l'API de votre fournisseur cloud, fait gagner des heures lors de la récupération.

Et après

Une fois l'état restauré et que vous pouvez relancer terraform plan, le travail n'est pas terminé. L'incident doit déclencher une révision de la façon dont votre état est géré. Y a-t-il des lacunes dans votre stratégie de sauvegarde ? Devriez-vous ajouter plus de contrôles d'accès pour éviter les suppressions accidentelles ? Avez-vous besoin d'un runbook pour la récupération d'état ?

La récupération d'état ne consiste pas à éviter les erreurs. Il s'agit d'avoir un plan pour quand les erreurs se produisent. Les équipes qui se préparent à une défaillance de l'état récupèrent en quelques minutes. Les équipes qui ne le font pas passent des heures à paniquer, puis des jours à reconstruire manuellement ce qu'elles ont perdu.

L'infrastructure que vous avez construite est toujours là. L'état n'est qu'une carte. Quand la carte est perdue, vous ne brûlez pas la ville. Vous dessinez une nouvelle carte.