Nous utilisons beaucoup Terraform, que ce soit pour tester notre propre infrastructure ou déployer des projets au sein de DownToZero.
Puisque DTZ est supporté en tant que provider, nous avons commencé à mettre en œuvre des projets dessus. Un point qui revenait régulièrement est la localisation du fichier d’état. Vérifier l’état dans le dépôt git n’est généralement pas une bonne idée (même si c’est encore mieux que de le garder localement), mais disposer d’une forme d’état distant facilite grandement l’exécution de TF dans les pipelines et rend l’état indépendant du projet.
En regardant nos options pour l’état distant, il y a toute une liste derrière cela. Malheureusement, la plupart d’entre eux sont liés à des fournisseurs cloud, ce qui n’est pas très utile pour nous pour le moment. Il existe cependant le provider générique http.
En examinant ce provider, nous avons constaté que nous pouvons l’utiliser pour se connecter à notre objectstore et utiliser notre propre système pour conserver le fichier d’état.
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 certaines particularités d’implémentation qui ne sont pas compatibles avec notre objectstore.
L’objectstore ne supporte pas les méthodes HTTP LOCK, UNLOCK (même si cela est ajustable dans le provider).
L’autre limitation est le code de retour, l’objectstore renvoie toujours un code HTTP-201 (CREATED) si l’objet a été persistant. Cependant, le provider Terraform ne recherche qu’un HTTP-200 (OK). Il existe déjà un problème ouvert et une pull-request à ce sujet, mais les deux sont ouverts depuis des années. Je ne m’attendrais donc pas à une correction de sitôt.