Wir verwenden Terraform häufig, sowohl um unsere eigene Infrastruktur zu testen als auch um Projekte innerhalb von DownToZero bereitzustellen.
Da DTZ als provider unterstützt wird, begannen wir, Projekte darauf aufzubauen. Ein Thema, das regelmäßig auftauchte, ist der Speicherort der State-Datei. Das Überprüfen des State im Git-Repository ist normalerweise keine gute Idee (auch wenn es immer noch besser ist, als ihn lokal zu belassen), aber eine Form von Remote-State hilft sehr beim Ausführen von TF in Pipelines und macht den State unabhängig vom Projekt.
Wenn man sich unsere Optionen für remote state ansieht, steckt da eine ziemlich lange Liste dahinter. Leider sind die meisten davon an Cloud-Provider gebunden, was uns momentan nicht wirklich weiterhilft. Es gibt jedoch das generische http-Backend.
Beim Blick auf diesen Provider stellten wir fest, dass wir ihn verwenden können, um uns mit unserem Objectstore zu verbinden und unser eigenes System zum Persistieren der State-Datei zu nutzen.
Und so würde das aussehen.
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
}
}
Leider funktioniert das Locking nicht, da es Implementierungsdetails gibt, die nicht mit unserem Objectstore kompatibel sind.
Der Objectstore unterstützt nicht die LOCK, UNLOCK-http Methoden (obwohl dies im Provider anpassbar ist).
Die andere Einschränkung ist der Rückgabecode: Der Objectstore liefert immer einen HTTP-201 (CREATED) Status, wenn das Objekt persistiert wurde. Der terraform-Provider prüft allerdings nur auf HTTP-200 (OK). Es gibt bereits ein offenes Issue und einen Pull Request dazu, aber beide sind seit Jahren offen. Daher würde ich in naher Zukunft nicht mit einer Behebung rechnen.