Pourquoi Terraform a besoin d'un fichier d'état (et pourquoi vous ne devriez jamais le stocker sur votre ordinateur portable)

Vous venez d'exécuter terraform apply et avez créé avec succès un serveur et une base de données. Tout fonctionne. Vous fermez votre ordinateur portable, satisfait. Demain, vous devez ajouter un équilibreur de charge. Vous ouvrez la configuration, ajoutez la ressource, et lancez terraform plan.

Terraform vous renvoie un plan qui veut tout recréer depuis zéro.

Que s'est-il passé ? Terraform n'a aucun souvenir de ce qu'il a construit hier. Il ne sait pas que ce serveur existe. Il ne sait pas que cette base de données est en cours d'exécution. Il n'a aucun enregistrement de l'infrastructure qu'il vient de créer.

C'est à ce moment que la plupart des équipes réalisent qu'elles ont besoin d'un fichier d'état.

Ce que fait réellement un fichier d'état

Un fichier d'état est la mémoire de travail de Terraform. Il enregistre chaque ressource que Terraform a créée, y compris les identifiants uniques, la dernière configuration connue, et la façon dont les ressources sont liées entre elles. Lorsque vous exécutez terraform plan, Terraform ne consulte pas votre fournisseur cloud pour demander "qu'est-ce qui existe ?". Ce serait lent, incohérent et peu fiable selon les fournisseurs. Au lieu de cela, il lit le fichier d'état et le compare à votre configuration actuelle.

Considérez-le comme un reçu. Après chaque achat, vous obtenez un reçu qui indique ce que vous avez acheté, quand et pour combien. Sans ce reçu, vous devriez inspecter toute votre maison pour savoir ce que vous possédez. Terraform, c'est pareil. Sans fichier d'état, il doit scanner l'intégralité de votre compte cloud pour déterminer ce qu'il gère. Et même dans ce cas, il ne peut pas être sûr des ressources qu'il a créées par rapport à celles créées manuellement par quelqu'un d'autre.

Voici une comparaison visuelle des deux workflows :

Le fichier d'état contient des informations détaillées sur chaque ressource. Pour un serveur cloud, cela inclut l'ID du serveur, l'adresse IP, le type de machine, la zone de disponibilité et la configuration réseau. Pour une base de données, cela inclut le point de terminaison, le port, la taille de stockage et les paramètres de sauvegarde. Ces informations sont la source de vérité pour la prochaine opération de Terraform.

Le problème de l'ordinateur portable

De nombreux développeurs commencent par stocker le fichier d'état localement. C'est la solution la plus simple. Terraform crée un fichier appelé terraform.tfstate dans votre répertoire de travail, et vous passez à autre chose.

Cela fonctionne jusqu'à ce que :

• Votre ordinateur portable tombe en panne ou soit volé.
• Vous supprimiez accidentellement le fichier.
• Vous changiez d'ordinateur et oubliiez de copier le fichier.
• Un collègue exécute Terraform depuis sa machine et crée un fichier d'état différent.

Lorsque le fichier d'état disparaît, Terraform perd toute connaissance de votre infrastructure. Il pense que rien n'existe. Si vous exécutez terraform apply à nouveau, il essaie de tout créer depuis zéro. Vous vous retrouvez avec des ressources en double, des configurations conflictuelles et une facture cloud qui double soudainement.

Pire encore, si quelqu'un modifie manuellement une ressource dans la console cloud sans mettre à jour le fichier d'état, Terraform se désynchronise. Il pense qu'un serveur a 4 Go de RAM, alors que le serveur réel en a 8 Go. Le prochain terraform plan produit un plan qui ne correspond pas à la réalité.

L'état distant : la seule approche sensée

La solution est simple : stockez le fichier d'état dans un emplacement partagé accessible à toute votre équipe. C'est ce qu'on appelle l'état distant.

L'état distant signifie que le fichier d'état réside dans un service de stockage comme Amazon S3, Azure Storage ou Google Cloud Storage. Chaque membre de l'équipe et chaque pipeline CI/CD lit et écrit dans le même fichier d'état. Cela garantit que tout le monde travaille à partir de la même source de vérité.

La configuration de l'état distant est généralement une opération unique dans votre bloc backend Terraform :

terraform {
  backend "s3" {
    bucket = "mon-equipe-terraform-state"
    key    = "production/terraform.tfstate"
    region = "us-east-1"
  }
}

Une fois configuré, Terraform récupère automatiquement le fichier d'état depuis le stockage distant avant chaque plan et pousse les mises à jour après chaque apply. Personne n'a besoin de copier manuellement des fichiers ou de se soucier des conflits de version.

Verrouillage d'état : prévenir les collisions

Avec l'état distant, plusieurs personnes peuvent exécuter Terraform en même temps. Cela introduit un nouveau problème : deux personnes exécutant terraform apply simultanément peuvent corrompre le fichier d'état ou créer une infrastructure incohérente.

Le verrouillage d'état empêche cela. Lorsqu'un processus lance terraform apply, il verrouille le fichier d'état. Les autres processus doivent attendre la libération du verrou. La plupart des backends d'état distant prennent en charge le verrouillage. S3 utilise DynamoDB pour le verrouillage. Azure Storage dispose d'un support de bail intégré. Google Cloud Storage utilise des numéros de génération d'objets.

Sans verrouillage, vous risquez des scénarios comme :

• Deux pipelines déployant des changements différents en même temps.
• Un développeur exécutant un apply manuel pendant qu'un pipeline CI/CD est en cours de déploiement.
• Des mises à jour partielles où seule la moitié des changements est enregistrée.

Le verrouillage d'état n'est pas optionnel pour les environnements d'équipe. C'est une exigence.

Données sensibles dans les fichiers d'état

Les fichiers d'état contiennent tout ce que Terraform sait sur votre infrastructure. Cela inclut des informations sensibles comme les mots de passe de base de données, les clés API et les chaînes de connexion. Terraform stocke ces valeurs en texte brut dans le fichier d'état.

Cela signifie que votre fichier d'état est un risque de sécurité. Toute personne ayant accès au fichier d'état peut lire vos secrets. Les backends d'état distant prennent généralement en charge le chiffrement au repos et en transit. S3 prend en charge le chiffrement côté serveur avec KMS. Azure Storage prend en charge le chiffrement au repos par défaut. Activez toujours le chiffrement pour votre stockage d'état.

Certaines équipes séparent également les fichiers d'état par environnement. Le développement, le staging et la production ont chacun leur propre fichier d'état stocké dans des emplacements distincts. Cela empêche les changements dans un environnement d'affecter un autre. Cela limite également l'impact en cas de compromission d'un fichier d'état.

Comment les fichiers d'état fonctionnent dans le CI/CD

Dans un pipeline CI/CD, le pipeline a besoin d'accéder au fichier d'état pour exécuter Terraform. Le pipeline s'authentifie auprès du backend d'état distant à l'aide d'identifiants ou de rôles IAM. Il récupère le fichier d'état, exécute terraform plan, et si approuvé, exécute terraform apply et pousse l'état mis à jour.

C'est pourquoi l'état distant est essentiel pour l'automatisation. Un pipeline CI/CD s'exécutant dans un conteneur éphémère ne peut pas compter sur un fichier d'état stocké sur l'ordinateur portable d'un développeur. Il a besoin d'un emplacement cohérent et accessible qui existe indépendamment de toute machine individuelle.

Liste de contrôle pratique pour la gestion des fichiers d'état

• Stockez les fichiers d'état dans un stockage distant, pas sur des machines locales.
• Activez le chiffrement au repos et en transit pour le backend de stockage.
• Configurez le verrouillage d'état pour empêcher les modifications simultanées.
• Utilisez des fichiers d'état séparés pour chaque environnement.
• Restreignez l'accès aux fichiers d'état à l'aide de politiques IAM ou de contrôles d'accès.
• Ne commettez jamais les fichiers d'état dans le contrôle de version.
• Sauvegardez régulièrement les fichiers d'état, surtout avant les changements majeurs.

Ce que cela signifie pour votre équipe

Les fichiers d'état ne sont pas un détail d'implémentation que vous pouvez ignorer. Ils sont la colonne vertébrale de la capacité de Terraform à gérer l'infrastructure de manière fiable. Sans un fichier d'état correctement géré, vos workflows Terraform produiront des résultats imprévisibles, des ressources en double et des échecs difficiles à déboguer.

Dès que vous avez plus d'une personne exécutant Terraform, ou dès que vous ajoutez un pipeline CI/CD, déplacez votre fichier d'état vers un stockage distant. Cela prend dix minutes à configurer et vous évite des heures de travail de récupération en cas de problème.

Votre infrastructure est trop importante pour la confier à un fichier sur votre ordinateur portable.