Où stocker l'état de votre infrastructure ? Guide pratique

Vous venez de terminer une configuration Terraform qui provisionne quelques serveurs et une base de données. Vous exécutez terraform apply sur votre machine, tout fonctionne. Votre collègue, qui doit ajouter un load balancer, exécute la même configuration depuis sa machine. Soudain, la base de données disparaît. Pas parce que le code était erroné, mais parce que le fichier d'état local de votre collègue ignorait que la base de données existait déjà.

Ce scénario n'est pas hypothétique. Il se produit tous les jours dans les équipes qui stockent l'état de l'infrastructure sous forme de fichier local sur la machine de chaque développeur. Le problème est simple : lorsque plusieurs personnes gèrent la même infrastructure, l'état local de chacune devient rapidement obsolète. Les ressources sont écrasées, dupliquées ou accidentellement détruites. La solution est tout aussi simple : stocker l'état dans un emplacement partagé et sécurisé, accessible à toute l'équipe.

Qu'est-ce que l'état et pourquoi est-il important ?

L'état est l'enregistrement de tout ce que votre outil d'infrastructure a créé. Il contient les identifiants de ressources, les adresses IP, les valeurs de configuration, et parfois même des mots de passe ou des clés API stockés en texte clair. Lorsque vous exécutez terraform plan, l'outil lit l'état actuel pour comprendre ce qui existe déjà et ce qui doit changer. Sans état précis, l'outil ne peut pas savoir si une ressource doit être créée, mise à jour ou laissée telle quelle.

Si l'état est perdu ou corrompu, l'outil perd la trace de votre infrastructure. Vous vous retrouvez avec des ressources orphelines qui coûtent de l'argent mais ne sont plus gérées. Ou pire, vous recréez accidentellement des ressources déjà en cours d'exécution, provoquant des interruptions de service.

Le piège du fichier local

La façon la plus simple de stocker l'état est de le faire sous forme de fichier sur votre propre machine. Pour l'apprentissage ou les projets personnels, cela fonctionne très bien. Vous êtes la seule personne à toucher à l'infrastructure, il n'y a donc pas de conflit.

Mais dès qu'une deuxième personne rejoint l'équipe, l'état local ne fonctionne plus. Voici ce qui se passe :

  • Vous créez un serveur. Votre fichier d'état l'enregistre.
  • Votre collègue exécute la même configuration. Son fichier d'état est vide, donc l'outil tente de créer un autre serveur avec le même nom.
  • Le fournisseur cloud rejette le doublon, ou pire, l'outil écrase le serveur existant parce qu'il ne sait pas qu'il existe.

Même si vous partagez le fichier d'état via le contrôle de version, vous rencontrez des conflits de fusion. Deux personnes ne peuvent pas modifier le même fichier d'état en même temps sans écraser les modifications de l'autre. C'est pourquoi les équipes qui gèrent l'infrastructure ensemble doivent utiliser un backend distant.

Pour vous aider à choisir l'approche adaptée à votre situation, voici un organigramme de décision :

flowchart TD A[Combien de personnes gèrent l'infra ?] --> B[Une seule] A --> C[Plusieurs] B --> D[Fichier local OK] C --> E[Backend distant nécessaire] E --> F[Choisir le type de backend] F --> G[S3 + DynamoDB] F --> H[GCS] F --> I[Azure Storage] F --> J[Terraform Cloud] F --> K[Consul] G --> L[Verrouillage et versioning] H --> L I --> L J --> M[Géré, moins d'ops] K --> M L --> N[Mettre en place le contrôle d'accès] M --> N N --> O[Prêt pour l'équipe]

Backend distant : la source de vérité partagée

Un backend distant stocke l'état dans un emplacement accessible à tous les membres de l'équipe. Les choix courants incluent un bucket S3 sur AWS, un bucket GCS sur Google Cloud ou un conteneur Azure Storage. Chacun pointe son outil d'infrastructure vers le même backend, de sorte que l'état est toujours cohérent.

Voici une configuration minimale de backend Terraform qui utilise un bucket S3 pour le stockage d'état et une table DynamoDB pour le verrouillage :

terraform {
  backend "s3" {
    bucket         = "mon-entreprise-terraform-state"
    key            = "production/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-locks"
    encrypt        = true
  }
}

Avant d'utiliser cette configuration, créez le bucket S3 avec le versioning activé et une table DynamoDB avec une clé primaire nommée LockID (type String). Le paramètre encrypt = true garantit que le fichier d'état est chiffré au repos.

Mais un backend distant n'est pas qu'un simple dossier partagé. Vous devez réfléchir à plusieurs choses avant d'en choisir un.

Le contrôle d'accès est non négociable

Les fichiers d'état contiennent des informations sensibles. Les identifiants de ressources, les adresses IP et parfois les identifiants sont stockés en texte clair. Si une personne extérieure à votre équipe obtient un accès en lecture à l'état, elle peut voir les détails de toute votre infrastructure. Si elle obtient un accès en écriture, elle peut corrompre ou supprimer des ressources.

Verrouillez le bucket ou le conteneur où l'état est stocké. Utilisez des politiques IAM ou un contrôle d'accès basé sur les rôles pour garantir que seules les personnes et les systèmes autorisés peuvent lire ou écrire l'état. Traitez le bucket d'état comme vous traiteriez une base de données de production.

Compromis entre vitesse et coût

L'état local est rapide car le fichier se trouve sur votre machine. Les backends distants nécessitent de télécharger l'état avant un plan ou un apply, et de le télécharger ensuite. Pour les petites équipes avec quelques dizaines de ressources, cela ajoute une seconde ou deux. Pour une infrastructure importante avec des milliers de ressources, le téléchargement et l'envoi peuvent prendre plusieurs minutes.

Certains backends facturent par opération ou par gigaoctet de stockage. S3, par exemple, facture les requêtes PUT et GET. Si votre équipe exécute terraform plan des dizaines de fois par jour, ces coûts s'accumulent. Choisissez un backend adapté au modèle d'utilisation de votre équipe.

Le versioning vous sauve des erreurs

Certains backends distants prennent en charge le versioning. S3 peut conserver un historique de chaque modification du fichier d'état. Si quelqu'un applique une modification qui casse quelque chose, vous pouvez revenir à une version précédente de l'état et récupérer.

Le versioning n'est pas activé par défaut. Vous devez l'activer explicitement. Ne supposez pas que votre backend conserve automatiquement l'historique. Consultez la documentation et activez le versioning avant d'en avoir besoin.

Les backends gérés réduisent la charge opérationnelle

Si vous ne voulez pas gérer vous-même un bucket, des politiques d'accès et le versioning, envisagez un backend géré comme Terraform Cloud ou HashiCorp Consul. Ces services sont conçus spécifiquement pour la gestion d'état. Ils incluent le versioning, l'historique, le verrouillage et l'intégration avec les pipelines CI/CD.

Le compromis est le coût et la dépendance vis-à-vis du fournisseur. Les backends gérés facturent par utilisateur ou par workspace. Vous dépendez également de la disponibilité et de l'API du fournisseur. Pour les équipes qui souhaitent se concentrer sur l'infrastructure plutôt que sur la gestion d'état, ce compromis en vaut souvent la peine.

Le verrouillage empêche les modifications concurrentes

Même avec un backend distant, deux personnes peuvent exécuter terraform apply en même temps. Sans verrouillage, les deux opérations lisent le même état, apportent des modifications et écrivent en retour. La deuxième écriture écrase la première, et les modifications de la première personne sont perdues.

La plupart des backends distants prennent en charge le verrouillage. S3 avec DynamoDB, par exemple, utilise une table DynamoDB pour contenir un verrou. Lorsque quelqu'un démarre une opération, l'outil acquiert le verrou. Les autres opérations doivent attendre que le verrou soit libéré. Cela empêche la corruption de l'état due aux écritures concurrentes.

Le verrouillage n'est pas optionnel pour les équipes. Si votre backend ne le prend pas en charge, trouvez-en un qui le fait.

Une liste de contrôle pratique pour le stockage d'état

Avant de décider où stocker l'état, parcourez cette liste de contrôle :

  • Le backend est-il accessible à tous ceux qui en ont besoin ?
  • L'accès est-il limité aux personnes et systèmes autorisés ?
  • Le backend prend-il en charge le versioning ?
  • Le backend prend-il en charge le verrouillage ?
  • Le coût est-il acceptable pour l'utilisation de votre équipe ?
  • La latence est-elle acceptable pour votre flux de travail ?

Si vous répondez oui aux six questions, vous avez un backend d'état solide.

L'essentiel à retenir

Ne stockez pas l'état de l'infrastructure sur votre ordinateur portable. Utilisez un backend distant qui prend en charge le contrôle d'accès, le versioning et le verrouillage. Les quelques minutes nécessaires pour configurer un backend d'état approprié vous éviteront des heures de débogage lorsque quelqu'un supprimera accidentellement une ressource ou écrasera les modifications d'un collègue. Votre infrastructure n'est fiable que dans la mesure où l'état qui la suit est fiable. Assurez-vous que cet état se trouve dans un endroit sûr.