Nous utilisons beaucoup Terraform, que ce soit pour tester notre propre infrastructure ou déployer des projets chez DownToZero.
Étant donné que DTZ est pris en charge comme fournisseur, nous avons commencé à implémenter des projets dessus. Une question qui revenait régulièrement concernait l’emplacement du fichier d’état. Garder l’état dans le dépôt git n’est généralement pas une bonne idée (même si c’est quand même mieux que de le conserver en local), mais disposer d’une forme d’état distant aide beaucoup pour exécuter Terraform dans des pipelines et rendre l’état indépendant du projet.
En examinant nos options pour l’état distant, il y a toute une liste. Malheureusement, la plupart sont liées à des fournisseurs cloud, ce qui n’est pas très utile pour nous pour l’instant. Il existe toutefois le backend générique http.
En regardant ce provider, nous avons constaté que nous pouvons l’utiliser pour nous connecter à notre objectstore et utiliser notre propre système pour persister le fichier d’état.
Et voici à quoi cela ressemblerait.
terraform {
required_providers {
dtz = {
source = "DownToZero-Cloud/dtz"
version = ">= 0.1.24"
}
}
backend "http" {
address = "http://objectstore.dtz.rocks/api/2022-11-28/obj/tf-test/state.tfstate"
update_method = "PUT"
username = "apikey"
password = var.apikey
}
}
Malheureusement, le verrouillage ne fonctionne pas, car il comporte des détails d’implémentation incompatibles avec notre objectstore.
L’objectstore ne prend pas en charge les méthodes HTTP LOCK et UNLOCK (bien que cela puisse être ajusté dans le provider).
L’autre limitation concerne le code de retour : l’objectstore renvoie toujours un statut HTTP 201 (CREATED) si l’objet a été persisté. Le provider Terraform, en revanche, ne recherche qu’un HTTP 200 (OK). Il existe déjà une issue et une pull request à ce sujet, mais toutes deux sont ouvertes depuis des années. Je n’attendrais donc pas de correctif dans un avenir proche.