Comment gérer l’état Terraform ?

Note de la rédaction : Ce post a d’abord été publié sur CloudSkiff.com. CloudSkiff a rejoint Snyk en octobre 2021.

Comment gérer l’état Terraform ? Et au fait, qu’est-ce qu’un fichier TFState ? En quoi distingue-t-il le code Terraform des autres outils de gestion de configuration et quelles sont les bonnes pratiques à suivre ?

Comment gérer l’état Terraform ?

Il est essentiel de savoir gérer l’état Terraform. Tout d’abord, qu’est-ce qu’un TFState exactement ?

Le fichier TFState de Terraform est ce qui le distingue vraiment des autres systèmes. Vous pouvez créer et déployer des infrastructures avec d’autres outils de gestion de configuration comme Chef, SaltStack et Ansible, mais la principale différence avec Terraform tient à cet état.

Vous pouvez voir votre fichier TFState comme une grande structure JSON qui représente la réalité de votre infrastructure. Elle fonctionne avec le code Terraform pour déclarer ce que l’on appelle l’« état souhaité » que vous voulez atteindre.

Cet état souhaité est déclaratif : lorsque vous indiquez dans votre code que vous voulez une ressource donnée avec une configuration précise, puis que vous apply ce code, Terraform « communique » avec l’API de votre fournisseur cloud et crée toutes ces ressources. Une fois l’opération terminée, il écrit dans ce fichier JSON la réalité du déploiement côté fournisseur cloud.

Au final, vous avez trois éléments en jeu :

• votre code

• la réalité dans votre compte auprès du fournisseur cloud

• le fichier d’état

Le fichier d’état est le reflet exact du dernier apply réussi de votre code. Il fonctionne avec tous les types de ressources : vous pouvez donc l’utiliser avec votre fournisseur cloud si vous souhaitez déployer des ressources d’infrastructure, mais aussi avec n’importe quel type de fournisseur.

Imaginons que vous déployiez des charts Helm avec Terraform. Vous aurez également un fichier d’état pour vos déploiements. C’est pareil avec GitHub. Si vous utilisez le fournisseur GitHub pour définir des utilisateurs, et que le même utilisateur est utilisé pour un projet sur Google Cloud et un IAM sur AWS en tant qu’utilisateur GitHub, ces informations seront consignées pour cet utilisateur précis — le tout étant lié dans le fichier d’état Terraform.

Considérez-le comme la référence de l’état réel de l’infrastructure existante, à laquelle vous pouvez accéder depuis votre code.

En bref, un fichier d’état représente la réalité de votre déploiement chez votre fournisseur cloud, d’après ce que vous avez déclaré dans votre code Terraform.

Comment gérer votre état Terraform et où le stocker ?

Par défaut, aucune option n’est définie. Lorsque vous initialisez pour la première fois votre dépôt Git avec du code Terraform et que vous appliquez un petit bloc de code Terraform, le fichier TFState est créé directement à la racine de votre dépôt GitHub. Vous devez ensuite le stocker quelque part. Par défaut, vous pourriez être tenté de le pousser sur GitHub, comme beaucoup le font, mais ce n’est pas une bonne pratique : il peut contenir des secrets, que vous ne voulez probablement pas publier sur GitHub.

Vous devez tout de même stocker votre fichier d’état, car sans cela, vous perdrez ce que Terraform considère comme l’« infrastructure existante ». Si vous le supprimez et lancez à nouveau un apply, Terraform tentera de redéployer toute l’infrastructure comme si elle était « nouvelle », ce que vous ne voulez probablement pas.

La bonne pratique consiste à le partager quelque part, généralement dans un bucket Amazon S3 ou tout autre bucket de stockage sur AWS, Azure ou Google Cloud :

1resource "aws_instance" "vm" {
2  ami                    = data.aws_ami.amazon-linux.id
3  instance_type          = var.instance_type
4  tags = {
5    Name = "DEMO VM DESTROY ME - ${terraform.workspace}",
6    Terraform = "true"
7  }
8}
9
10data "aws_ami" "amazon-linux" {
11  most_recent = true
12  owners = ["amazon"]
13
14  filter {
15    name   = "name"
16    values = ["amzn-ami-hvm-*"]
17  }
18
19}

Vous déclarez donc votre back-end. Dans cet exemple, le code est très simple et déploie une seule VM. Il s’agit d’une démonstration. Je m’en sers pour tester les espaces de travail Terraform. Ne l’utilisez donc pas pour un projet important.

Vous pouvez configurer Terraform à l’aide du mot-clé Terraform et indiquer : « Pour Terraform, je veux utiliser S3 comme back-end, et le bucket S3 doit être celui-ci. »

Vous indiquez où vous voulez stocker votre fichier d’état. C’est aussi simple que cela. Lors du prochain Terraform apply, Terraform utilisera un fichier d’état temporaire en local, puis le téléversera dans votre bucket S3.

Ensuite, chaque fois que vous voudrez travailler dessus, Terraform utilisera ce fichier.

1terraform {
2  backend "s3" {
3    bucket = "cs-tfstates-demo-sj-frankfurt-1"
4    key    = "tfstates/terraform.tfstate"
5  }
6}

Dernier conseil : n’oubliez pas d’ajouter également un fichier de verrouillage dans une base de données. Ainsi, deux personnes ne pourront pas lancer simultanément une action destructrice ou un apply Terraform si ce verrou est en place.

Sécurisez votre code Terraform

Snyk IaC sécurise vos configurations Terraform (ainsi que vos modèles Kubernetes, CloudFormation et ARM !) pendant que vous codez, et vous propose des correctifs guidés pour vous permettre de fusionner et de poursuivre votre travail. Testez votre code au fur et à mesure, surveillez les modifications dans vos dépôts Git et automatisez les tests dans vos pipelines de build avant le déploiement. Quelques minutes suffisent pour commencer avec l’offre gratuite, tandis qu’une violation due à une mauvaise configuration IaC peut causer des dommages irréversibles. Inscrivez-vous ci-dessous pour commencer à sécuriser vos configurations.