Terraform

Mit dem Provider lionbackup legen Sie Projekte und Backup-Token als Infrastruktur-Code an. Er verwendet die öffentliche API und damit dieselben Rechte wie Ihr Dienstkonto im Portal. Der Provider läuft mit Terraform ab 1.9 und mit OpenTofu.

Bezugsquelle

Der Provider wird nicht über die öffentliche Terraform-Registry verteilt, sondern über einen Network Mirror von lionbackup. Tragen Sie ihn einmalig in Ihre CLI-Konfiguration ~/.terraformrc ein (oder in die Datei, auf die TF_CLI_CONFIG_FILE zeigt):

provider_installation {
  network_mirror {
    url     = "https://git.prod.lionbackup.cloud/terraform/providers/"
    include = ["git.lionbackup.cloud/*/*"]
  }
  direct {
    exclude = ["git.lionbackup.cloud/*/*"]
  }
}

Getestet mit Terraform 1.16 und OpenTofu 1.12. OpenTofu liest dieselbe Konfiguration aus ~/.tofurc oder, falls die fehlt, aus ~/.terraformrc.

Der direct-Block sorgt dafür, dass Terraform den lionbackup-Provider ausschließlich vom Mirror bezieht; alle anderen Provider laden weiterhin wie gewohnt aus ihren Registries.

Provider einbinden

Die Quelladresse ist git.lionbackup.cloud/lionbackup/lionbackup. Verwenden Sie den Provider ab Version 0.1.1:

terraform {
  required_providers {
    lionbackup = {
      source  = "git.lionbackup.cloud/lionbackup/lionbackup"
      version = "~> 0.1.1"
    }
  }
}

provider "lionbackup" {
  # Der API-Schlüssel kommt aus der Umgebung:
  #   export LIONBACKUP_API_KEY=...   (Portal → Entwickler)
  # environment = "prod"   # Standard; "dev" für die Entwicklungsumgebung
}

Den API-Schlüssel legen Sie im Portal unter Entwickler an (siehe API) und übergeben ihn als Umgebungsvariable LIONBACKUP_API_KEY. Das Attribut api_key gibt es ebenfalls, doch ein Schlüssel in der Konfiguration landet leicht in der Versionsverwaltung.

Beispiel

Das Beispiel ermittelt Ihre Organisation, legt darin ein Projekt in der Zone de01-1 an, erzeugt ein Write-Token und gibt dessen Geheimnis als sensiblen Output aus:

data "lionbackup_organizations" "mine" {}

locals {
  organization_id = one([
    for o in data.lionbackup_organizations.mine.organizations : o.id
    if o.name == "Beispiel GmbH"
  ])
}

resource "lionbackup_project" "backup" {
  organization_id   = local.organization_id
  name              = "web-servers"
  availability_zone = "de01-1"
  alert_email       = "ops@example.com"
}

resource "lionbackup_project_token" "writer" {
  project_id = lionbackup_project.backup.id
  type       = "write"
}

output "backup_token" {
  value     = lionbackup_project_token.writer.secret
  sensitive = true
}

Die Organisation wird über ihren Namen gewählt, nicht über die Position in der Liste: Ein Dienstkonto kann mehrere Organisationen sehen, und die Reihenfolge ist nicht garantiert. one() bricht bei mehreren Treffern ab; gibt es keinen, bleibt organization_id leer und Terraform verweigert den Plan. In keinem Fall entsteht das Projekt still in der falschen Organisation.

availability_zone erwartet den Namen der Zone, wie ihn die Seite Regionen und die Data Source lionbackup_zones nennen; die Auflösung zur Kennung übernimmt der Provider.

Anwenden:

export LIONBACKUP_API_KEY=...
terraform init
terraform apply
terraform output -raw backup_token

terraform init lädt den Provider vom Mirror und prüft ihn gegen die dort hinterlegten Prüfsummen. Die Ausgabe sollte so enden:

- Installing git.lionbackup.cloud/lionbackup/lionbackup v0.1.2...
- Installed git.lionbackup.cloud/lionbackup/lionbackup v0.1.2 (verified checksum)

Die Prüfsumme landet in .terraform.lock.hcl. Nehmen Sie diese Datei in die Versionsverwaltung auf, dann installiert jeder Lauf exakt dieselbe Provider-Version.

Was Sie wissen sollten

• terraform destroy schließt ein Projekt, es löscht es nicht. Das ist die Semantik der Plattform: Write-Token werden sofort widerrufen, gespeicherte Backups bleiben bis zum Ende der Vorhaltezeit lesbar. Ein geschlossenes Projekt verschwindet aus dem Terraform-State. Token, die dieselbe Konfiguration verwaltet, widerruft destroy dabei ebenfalls, auch Read-Token. Soll ein Read-Token den Abbau überleben, nehmen Sie es vorher aus dem State (terraform state rm <Adresse>) oder legen es im Portal an.
• Jede Änderung an einem Token ersetzt es. Alle Attribute eines lionbackup_project_token sind nur beim Anlegen wählbar; wer eines ändert, bekommt ein neues Token (altes widerrufen, neues erzeugt) — und damit ein neues Geheimnis.
• Das Geheimnis liegt im State. Die API liefert ein Backup-Token genau einmal aus; der Provider bewahrt es als sensibles Attribut secret im Terraform-State auf. Schützen Sie die State-Datei wie ein Passwort — etwa in einem verschlüsselten Remote-Backend.
• Zone, Organisation und Unveränderbarkeit sind Anlage-Entscheidungen. Eine Änderung von organization_id, availability_zone, immutable_storage, retention_days oder auto_delete_after_retention ersetzt das Projekt (Plan: must be replaced). Im laufenden Betrieb änderbar sind name, alert_email und billing_reference.
• Ratenbegrenzung. Die API erlaubt 60 Anfragen pro Minute je Dienstkonto und je IP-Adresse. Der Provider wiederholt 429 und 503 bis zu dreimal und wartet dabei die angekündigte Retry-After-Zeit ab; ein großes apply wird dadurch langsamer, nicht abgebrochen.
• Rechte. Der Provider kann genau das, was der Mensch darf, dem das Dienstkonto gehört. Projekte anlegen und schließen setzt die Rolle owner oder admin in der Organisation voraus.

Referenz

Provider

Attribut	Bedeutung
api_key	API-Schlüssel; besser über LIONBACKUP_API_KEY in der Umgebung
environment	prod (Standard) oder dev; wählt API- und Token-Endpunkt
api_url	eigene Basis-URL der API, überschreibt environment
token_url	eigener Token-Endpunkt, überschreibt environment

Ressource lionbackup_project

Attribut	Pflicht	Bedeutung
organization_id	ja	Kennung der Organisation (Data Source lionbackup_organizations)
name	ja	Projektname, höchstens 100 Zeichen
availability_zone	ja	Name der Zone, zum Beispiel de01-1
alert_email	nein	Adresse für Benachrichtigungen
billing_reference	nein	freier Text für Ihre Abrechnung
immutable_storage	nein	unveränderbare Ablage, Standard false
retention_days	nein	Vorhaltezeit bei unveränderbarer Ablage; ohne Angabe der Plattformstandard
auto_delete_after_retention	nein	Standard true
id, status	—	werden von der Plattform vergeben

Ressource lionbackup_project_token

Attribut	Pflicht	Bedeutung
project_id	ja	Kennung des Projekts
type	nein	write (Standard) für Backups, read für Wiederherstellungen
operating_system	nein	Linux (Standard), Windows oder macOS (macOS: Vorschau)
usage_count_limit	nein	höchstens so viele Verwendungen
rate_limit_per_minute	nein	Anfragen je Minute für dieses Token
rate_limit_per_hour	nein	Anfragen je Stunde für dieses Token
id	—	wird von der Plattform vergeben
secret	—	das Backup-Token, sensibel, nur im State

Data Sources

lionbackup_organizations liefert organizations mit id, name, status und role (Ihre Rolle in der Organisation). lionbackup_zones liefert zones mit id, name, status, provider, location_city und storage_type; buchbar sind Zonen mit status = active.

Dazu lionbackup_projects (alle Projekte einer Organisation, organization_id angeben, geschlossene eingeschlossen), lionbackup_project (ein Projekt über seine id) und lionbackup_whoami (das handelnde Dienstkonto, sein Besitzer und dessen Rolle je Organisation).

OpenTofu

OpenTofu verwendet dieselbe Konfiguration. Legen Sie den provider_installation-Block in ~/.tofurc ab (fehlt die Datei, liest OpenTofu auch ~/.terraformrc) und ersetzen Sie in den Befehlen terraform durch tofu. Auch tofu init meldet verified checksum.

Entwicklungsumgebung

Für Tests gegen die Entwicklungsumgebung setzen Sie im Provider environment = "dev" und verwenden einen dort angelegten Schlüssel. Der Provider selbst kann zusätzlich vom Mirror der Entwicklungsumgebung bezogen werden; dazu tauschen Sie in ~/.terraformrc die URL:

url = "https://git.dev.lionbackup.cloud/terraform/providers/"

Die Quelladresse git.lionbackup.cloud/lionbackup/lionbackup bleibt in beiden Fällen gleich.