Fiabiliser l’utilisation de Terraform avec les Backend

Terraform est un outil très puissant et assez simple à utiliser. Il a l’avantage de pouvoir manipuler un grand nombre de providers d’infrastructure avec une syntaxe commune. Pourtant, Terraform a un point faible : afin de rester agnostique au maximum avec les infrastructures qu’il va manipuler, il centralise l’état des ressources dans un fichier : le fameux .tfstate, créé par défaut en local. Ce fichier étant central et très sensible (une corruption ou un déphasage avec la réalité ne pardonne pas), comment faire pour le rendre résilient tout en permettant le travail collaboratif inhérent au monde professionnel ?

Sommaire

• Le fonctionnement de base
• Les backends “standards”
• Les backends “avancés”
• Exemple
  • Contexte
  • Configuration de notre environnement
• Conclusion

C’est pour répondre à ces besoins que Hashicorp (l’éditeur de Terraform) permet l’utilisation de différents Backends. L’idée étant de “déporter” ces fameux fichiers .tfstate dans un espace de stockage plus fiable, partagé, etc…

Le fonctionnement de base

Comme nous l’avons vu dans le précédent article sur le déploiement de VM dans Azure avec Terraform , la commande terraform va créer et maintenir un fichier terraform.tfstate pour y stocker “la description” des ressources qui sont gérées par elle.

Par défaut et sans plus de précision au niveau des options de la commande, ce fichier (et un backup) est créé dans le dossier local courant.

Cela soulève des limitations évidentes :

• Il est impossible de partager simplement ce fichier qui doit rester [u]unique[/u] depuis un poste de travail, consistance de la “seule source de vérité” oblige
• Il est impossible de garantir la pérennié de ce fichier sur un poste de travail (disque non redondé, pas de sauvegarde, etc…)

Quand on dépasse le stade de travailler seul sur son poste de travail, on va naturellement chercher à “externaliser” les fichiers .tfstate.

Pour cela, Terraform propose un système de “Backend”, dont il existe deux types.

Les backends “standards”

Ces backends centralisés sont capables de gérer les opérations suivantes :

• stocker les fichiers .tfstate de manière centralisée
• gérer les locks lors de l’exécution de Terraform
• gérer les opérations de push/pull manuelles

Actuellement, un douzaine de plateformes sont disponibles :

https://www.terraform.io/docs/backends/state.html

Les backends “avancés”

En plus des fonctionnalités des backends standards listés précédement, les backends dits “avancés” permettent l’exécution de Terraform.

Les plus perspicaces l’auront deviné : l’exéxution locale est rentre dans la catégorie des backends “avancés”.

Il existe pour l’instant un seul autre backend de ce type : le backend remote.

Celui-ci permet de déporter l’exécution de Terraform à une instance privée de Terraform Enterprise (version v201809-1 or supérieure) ou à un compte Enterprise sur https://app.terraform.io.

Il est recommandé par l’éditeur d’utiliser Terraform v0.11.13 ou supérieur pour utiliser les backends “remote”.

Exemple

Contexte

Pour notre exemple, nous allons repartir du même contexte que dans l’article sur le déploiement de VM dans Azure avec Terraform et ainsi reprendre les mêmes fichiers, plutôt que de repartir de zéro.

Nous allons aussi profiter du fait qu’il est possible de créer gratuitement un compte Terraform Cloud Free Tier sur https://app.terraform.io pour y centraliser nos fichiers .tfstate.

Pour pouvoir bénéficier aussi de la fonctionnalité d’exécution du code Terraform, il faut impérativement un compte Enterprise payant. </br > Pour notre exemple, un compte gratuit suffit pour simplement centraliser les fichiers .tfstate : https://www.terraform.io/docs/enterprise/free/.

Configuration de notre environnement

Pour pouvoir utiliser ce backend, nous allons avoir besoin :

• d’un compte Enterprise Cloud Free Tier
• d’une Organisation au sein de ce compte
• d’un token d’accès à créer via https://app.terraform.io/app/settings/tokens

Avec ces informations, nous pouvons configurer notre accès en ajoutant au fichier ~/.terraformrc (%APPDATA%\terraform.rc sous windows) les lignes suivantes en prenant bien soin de remplacer la valeur avec le token qu’on a généré à l’instant :

credentials "app.terraform.io" {
  token = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

Cette configuration permet d’utiliser la plateforme Cloud https://app.terraform.io pour toutes les configuration Terraform faisant appel au backend remote.

Nous allons à présent pouvoir modifier le fichier main.tf en ajoutant le bloc suivante en renseignant votre nom d’Organisation et le nom du Workspace :

Le Workspace sera créé automatiquement s’il n’existe pas.

terraform {
  backend "remote" {
    organization = "Arcanexus"

    workspaces {
      name = "demo"
    }
  }
}

Nous pouvons maintenant lancer la commande d’initialisation :

Si des fichiers .tfstate sont détectés dans le dossier courant, Terraform propose de les copier dans le nouveau backend.

Quand on se connecte à , nous pouvons voir que le nouveau workspace a bien été crée :

Dans lequel on retrouve notre .tfstate actuel :

Celui-ci ne contenant pour l’instant aucune ressource :

Le contenu dépend de l’état dans lequel est votre plateforme. Elle est vide ici suite au nettoyage effectué à la fin du précédent article.

Maintenant, amusons-nous à relancer une VM avec la commande Terraform :

terrform apply

Lorsqu’une commande Terraform est en cours, nous voyons apparaître le message suivant nous informant que le fichier est locké : </br >

Une fois la commande terminée, nous voyons un nouvel état :

Celui-ci contenant bien les ressources que nous venons de créer :

Si nous voulons détruire les ressources nous utilisons la commande suivante :

terraform destroy

Le fichier va de nouveau le verrouiller pendant l’exécution, puis va créer un nouvel état visible dans le workspace ne contenant aucune ressource.

Conclusion

Avec ce backend, il devient possible de suivre l’évolution de vos ressources, mais aussi les partager. En effet, chaque utilisateur avec un token (et des droits qui vont bien, je n’ai pas détaillé cette partie) peut donc effectuer des action sur ces ressources tout en gardant une traçabilité constante. Chaque changement étant centralisé, tracé, etc …

Ce fonctionnement permet à mon sens de limiter les risques lié au fait que le fichier .tfstate est véritablement le SPOF de Terraform. D’autant plus maintenant que l’éditeur a permis l’utilisation de sa plateforme Cloud gratuitement (hors fonctions d’exécution, réservées aux comptes payants). Ceci permettant d’éviter d’avoir à maintenir une autre plateforme soi-même (AWS S3, Consul, etcd, Artifactory, etc…).