Nous utilisons beaucoup Terraform, que ce soit pour tester notre propre infrastructure ou déployer des projets au sein de DownToZero.
Depuis que DTZ est pris en charge comme fournisseur, nous avons commencé à développer des projets dessus. Une problématique qui revenait régulièrement concerne l’emplacement du fichier d’état. Conserver le fichier d’état dans le dépôt git n’est généralement pas une bonne idée (bien que ce soit encore mieux que de le laisser local), mais disposer d’un état distant aide grandement pour exécuter Terraform dans des pipelines et rendre l’état indépendant du projet.
En regardant nos options pour l’état distant, il y a toute une liste. Malheureusement, la plupart sont liées à des fournisseurs cloud, ce qui ne nous aide pas vraiment pour le moment. Il existe toutefois le backend générique http.
En examinant ce provider, nous avons constaté que nous pouvions l’utiliser pour nous connecter à notre objectstore et employer 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 mécanisme de verrouillage ne fonctionne pas, car il comporte des détails d’implémentation qui ne sont pas compatibles avec notre objectstore.
L’objectstore ne prend pas en charge les méthodes HTTP LOCK et UNLOCK (bien que cela soit ajustable 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 les deux sont ouvertes depuis des années. Je n’attendrais donc pas de correction de sitôt.