Infrastructure as Code mit STACKIT: Terraform-Einstieg, State-Management und Project-ID-Best-Practices
Im modernen Cloud-Betrieb ist Infrastructure as Code (IaC) kein „Nice-to-have“ mehr, sondern das Fundament für Compliance, Sicherheit und Skalierbarkeit. Als deutscher Cloud-Provider bietet STACKIT mit seinem dedizierten Terraform Provider ein mächtiges Werkzeug, um digitale Souveränität mit moderner Automatisierung zu vereinen.
Doch der Einstieg birgt architektonische Hürden: Wie gehe ich sicher mit dem State um? Wie löse ich das Bootstrapping-Dilemma? Und wie verwalte ich die project_id, ohne im Chaos zu versinken? In diesem Guide erfährst Du, wie Du Dein STACKIT-Setup professionell aufsetzt.
1. Das Fundament: Der STACKIT Provider
Bevor wir Code schreiben, müssen wir den Provider konfigurieren. STACKIT nutzt zur Authentifizierung Dienstkonten (Service Accounts).
Wichtig: Speichere niemals Credentials (Tokens) im Code! Nutze stattdessen Umgebungsvariablen wie STACKIT_SERVICE_ACCOUNT_TOKEN.
terraform {
required_providers {
stackit = {
source = "stackitcloud/stackit"
version = "~> 2.0" # Immer auf die Major-Version fixieren
}
}
}
provider "stackit" {
# Die Authentifizierung erfolgt automatisch über Umgebungsvariablen
}
2. State Management: Das Gedächtnis Deiner Infrastruktur
Der Terraform-State (terraform.tfstate) mappt Deine Konfiguration auf die realen Ressourcen bei STACKIT. In einer DevSecOps-Umgebung ist ein Remote State (zentrale Speicherung) Pflicht, um State-Locking und Team-Kollaboration zu ermöglichen.
Der klassische Weg: STACKIT Object Storage (S3)
Da STACKIT S3-kompatiblen Object Storage anbietet, kannst Du diesen als Backend nutzen. Doch hier gibt es zwei wichtige Punkte zu beachten:
Das „Henne-Ei-Problem“ (Bootstrapping)
Du möchtest den State in einem S3-Bucket speichern – aber wer erstellt den Bucket? Terraform kann den Bucket nicht erstellen, wenn es selbst noch keinen Ort hat, um seinen eigenen State zu sichern.
- Lösung: Erstelle den Bucket manuell über das Portal oder via lokaler Terraform-Initialisierung. Sobald der Bucket steht, konfigurierst Du das Backend und migrierst den State mit
terraform init -migrate-state.
Kosten-Check: AWS vs. STACKIT
Anders als bei AWS S3, wo oft nur minimale Gebühren pro GB anfallen, ist der Object Storage bei STACKIT häufig mit einer monatlichen Basisgebühr pro Instanz verbunden.
- Best Practice: Erstelle einen zentralen Management-Bucket in einem Admin-Projekt und nutze verschiedene Pfade (
key), um die States mehrerer Projekte darin zu trennen. So vermeidest Du unnötige Fixkosten für Dutzende Einzel-Buckets.
terraform {
backend "s3" {
bucket = "zentraler-tf-state-bucket"
key = "projekte/projekt-a/prod.tfstate"
region = "eu01"
endpoint = "https://object.storage.eu01.stackit.cloud"
skip_credentials_validation = true
skip_region_validation = true
skip_metadata_api_check = true
use_path_style = true # Wichtig für S3-Kompatibilität
}
}
3. Die pragmatische Alternative: Managed HTTP Backends
Wenn Du das Henne-Ei-Problem und die S3-Fixkosten umgehen möchtest, bieten GitLab oder GitHub (via Terraform Cloud oder http-Backend) exzellente Alternativen.
- Vorteil: Der State-Speicher ist Teil Deiner CI/CD-Plattform. Du benötigst keine zusätzliche Infrastruktur bei STACKIT, nur um den State zu verwalten.
- GitLab Integration: Mit dem Managed HTTP Backend von GitLab wird der State direkt im Repository-Kontext gespeichert. Das ist oft die effizienteste Lösung für kleine bis mittlere Setups.
| Methode | STACKIT S3 Bucket | GitLab / GitHub HTTP |
|---|---|---|
| Henne-Ei-Problem | Vorhanden | Gelöst |
| Kosten | Basisgebühr pro Bucket | Inklusive |
| Souveränität | Höchste (Daten bleiben bei STACKIT) | Abhängig vom Git-Hoster |
4. Best Practice: Management der project_id
Die project_id ist der Dreh- und Angelpunkt fast jeder STACKIT-Ressource. Vermeide Hardcoding um jeden Preis!
Strategie A: Injektion via Variablen (Empfohlen)
Nutze eine Variable, die je nach Umgebung (Dev/Stage/Prod) unterschiedlich befüllt wird.
variable "stackit_project_id" {
type = string
description = "Die Ziel-Projekt-ID in der STACKIT Cloud"
}
resource "stackit_object_storage_credentials_group" "example" {
project_id = var.stackit_project_id
name = "my-creds"
}
Strategie B: Data Sources zur Validierung
Falls das Projekt bereits existiert, kannst Du eine Data Source nutzen. Dies stellt sicher, dass Terraform abbricht, falls die ID falsch ist oder das Projekt nicht existiert:
data "stackit_resourcemanager_project" "current" {
container_id = var.stackit_project_id
}
Fazit & Ausblick
Der STACKIT Terraform Provider ist ein mächtiges Werkzeug, erfordert aber ein klares Design-Pattern für State und Identitäten. Für den Start empfiehlt sich:
- Zentralisiere Deinen State: Nutze entweder einen einzelnen Admin-S3-Bucket bei STACKIT oder das native Backend Deiner CI/CD-Plattform.
- Entkopple IDs: Arbeite mit Variablen und
.tfvars-Dateien, um Deinen Code zwischen Projekten wiederverwendbar zu machen. - Security First: Nutze Service Accounts mit “Least Privilege” und scanne Deinen Code regelmäßig mit Tools wie
trivy.