Comprendre les états et les backends de Terraform

L'un des concepts les plus importants de l'infrastructure en tant que code (IAc) est le concept d'état. Les services IaC conservent l'état, ce qui vous permet de déclarer une ressource dans un fichier IaC sans la recréer à chaque déploiement. Les fichiers IaC documentent l'état de toutes les ressources à la fin d'un déploiement afin de pouvoir ensuite comparer cet état à l'état cible, tel que déclaré lors du déploiement suivant. Ainsi, si l'état actuel contient un compartiment Amazon Simple Storage Service (Amazon S3) my-s3-bucket nommé et que les modifications entrantes contiennent également ce même compartiment, le nouveau processus appliquera toutes les modifications trouvées au compartiment existant plutôt que d'essayer de créer un tout nouveau compartiment.

Le tableau suivant fournit des exemples du processus général d'état de l'IaC.

État actuel	État cible	Action
Aucun compartiment S3 nommé my-s3-bucket	Compartiment S3 nommé my-s3-bucket	Créez un compartiment S3 nommé my-s3-bucket
my-s3-bucketsans configuration de version des compartiments	my-s3-bucketsans configuration de version des compartiments	Aucune action
my-s3-bucketsans configuration de version des compartiments	my-s3-bucketavec configuration du versionnement des compartiments	Configurer my-s3-bucket pour avoir une gestion des versions des compartiments
my-s3-bucketavec configuration du versionnement des compartiments	Aucun compartiment S3 nommé my-s3-bucket	Tentative de suppression my-s3-bucket

Pour comprendre les différentes manières dont AWS CloudFormation Terraform suit l'état, il est important de se rappeler la première différence fondamentale entre les deux outils : il CloudFormation est hébergé dans le AWS Cloud, et Terraform est essentiellement distant. Ce fait permet de CloudFormation maintenir l'état en interne. Vous pouvez accéder à la CloudFormation console et consulter l'historique des événements d'une pile donnée, mais le CloudFormation service lui-même applique les règles de l'État à votre place.

Les trois modes qui CloudFormation fonctionnent pour une ressource donnée sont CreateUpdate, etDelete. Le mode actuel est déterminé en fonction de ce qui s'est passé lors du dernier déploiement, et il ne peut pas être influencé autrement. Vous pouvez peut-être mettre à jour les CloudFormation ressources manuellement afin d'influencer le mode déterminé, mais vous ne pouvez pas passer une commande CloudFormation disant « Pour cette ressource, opérez en Create mode ».

Terraform n'étant pas hébergé dans le AWS Cloud, le processus de maintien de l'état doit être plus configurable. Pour cette raison, l'état Terraform est conservé dans un fichier d'état généré automatiquement. Un développeur Terraform doit traiter avec l'État beaucoup plus directement qu'il ne le ferait avec. CloudFormation Il est important de se rappeler que l'état du suivi est tout aussi important pour les deux outils.

Par défaut, le fichier d'état Terraform est stocké localement au niveau supérieur du répertoire principal qui exécute votre stack Terraform. Si vous exécutez la terraform apply commande depuis votre environnement de développement local, vous pouvez voir Terraform générer le fichier terraform.tfstate qu'il utilise pour maintenir l'état en temps réel. Pour le meilleur ou pour le pire, cela vous donne beaucoup plus de contrôle sur l'état dans Terraform que dans celui-ci. CloudFormation Bien que vous ne deviez jamais mettre à jour directement le fichier d'état, vous pouvez exécuter plusieurs commandes Terraform CLI pour mettre à jour l'état entre les déploiements. Par exemple, l'importation de Terraform vous permet d'ajouter des ressources créées en dehors de Terraform dans votre pile de déploiement. Inversement, vous pouvez supprimer une ressource de l'état en exécutant terraform state rm.

Le fait que Terraform ait besoin de stocker son état quelque part conduit à un autre concept qui ne s'applique pas à CloudFormation : le backend. Un backend Terraform est l'endroit où une pile Terraform stocke son fichier d'état après le déploiement. C'est également là qu'il s'attend à trouver le fichier d'état lorsqu'un nouveau déploiement commence. Lorsque vous exécutez votre stack localement, comme décrit ci-dessus, vous pouvez conserver une copie de l'état de Terraform dans le répertoire local de niveau supérieur. C'est ce que l'on appelle un backend local.

Lors du développement pour un environnement d'intégration et de déploiement continus (CI/CD), le fichier d'état local est généralement inclus dans le fichier .gitignore afin de le soustraire au contrôle de version. Il n'y a alors aucun fichier d'état local présent dans le pipeline. Pour fonctionner correctement, cette étape du pipeline doit trouver le bon fichier d'état quelque part.C'est pourquoi les fichiers de configuration Terraform contiennent souvent un bloc principal. Le bloc principal indique à la pile Terraform qu'elle doit chercher ailleurs que dans son propre répertoire de premier niveau pour trouver le fichier d'état.

Un backend Terraform peut être situé presque n'importe où : un compartiment Amazon S3, un point de terminaison d'API ou même un espace de travail Terraform distant. Voici un exemple de backend Terraform stocké dans un compartiment Amazon S3.

terraform {
  backend "s3" {
    bucket = "my-s3-bucket"
    key    = "state-file-folder"
    region = "us-east-1"
  }
}

Afin d'éviter de stocker des informations sensibles dans les fichiers de configuration Terraform, les backends prennent également en charge les configurations partielles. Dans l'exemple précédent, les informations d'identification nécessaires pour accéder au bucket ne sont pas présentes dans la configuration. Les informations d'identification peuvent être obtenues à partir de variables d'environnement ou par d'autres moyens, tels que AWS Secrets Manager. Pour plus d'informations, consultez Sécurisation des données sensibles à l'aide AWS Secrets Manager de HashiCorp Terraform.

Un scénario de backend courant est un backend local utilisé dans votre environnement local à des fins de test. Le fichier terraform.tfstate est inclus dans le fichier .gitignore afin qu'il ne soit pas transféré vers le référentiel distant. Ensuite, chaque environnement du pipeline CI/CD conserverait son propre backend. Dans ce scénario, plusieurs développeurs peuvent avoir accès à cet état distant. Vous devez donc protéger l'intégrité du fichier d'état. Si plusieurs déploiements sont en cours d'exécution et mettent à jour l'état en même temps, le fichier d'état peut être endommagé. Pour cette raison, dans les situations où les backends ne sont pas locaux, le fichier d'état est généralement verrouillé pendant le déploiement.