Nous utilisons beaucoup Terraform, soit pour tester notre propre infrastructure, soit pour déployer des projets au sein de DownToZero.
Puisque DTZ est supporté en tant que provider, nous avons commencé à implémenter des projets basés dessus. Une chose qui revenait régulièrement était l’emplacement du fichier d’état. Vérifier l’é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 garder local), mais disposer d’une forme d’état distant aide beaucoup pour exécuter TF 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 derrière cela. Malheureusement, la plupart sont liées à des fournisseurs cloud, ce qui n’est pas vraiment utile pour nous à l’heure actuelle. Il existe cependant le provider générique http.
En examinant 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 y a des détails d’implémentation qui ne sont pas compatibles avec notre objectstore.
L’objectstore ne supporte pas les méthodes HTTP LOCK, UNLOCK (bien que cela soit ajustable dans le provider).
L’autre limitation est le code de retour, l’objectstore renvoie toujours un statut HTTP-201 (CREATED) si l’objet a été persisté. Le provider terraform, lui, attend uniquement 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 maintenant. Je ne m’attendrais donc pas à une correction dans un futur proche.