Infrastructure as Code: Terraform, Bicep, Pulumi oder Crossplane richtig auswählen

Fünf Angaben reichen für eine belastbare Vorauswahl: die Zahl der Plattformen, die tatsächlich im Code landen sollen, die Zusammensetzung des Teams, die Menge an bestehender Infrastruktur ohne Code, die Anforderungen an Freigabe und Nachweis sowie die Frage, ob Anwendungsteams sich Infrastruktur künftig selbst anfordern sollen. Der letzte Punkt kippt die Entscheidung am häufigsten, weil Selbstbedienung eine Abstraktionsschicht braucht, die klassische Skripte nicht liefern. Wie diese Schicht aussieht, beschreibt Platform Engineering einführen genauer.

terraform {
  required_version = ">= 1.9"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_storage_account" "artefakte" {
  name                            = "stplattformprod01"
  resource_group_name             = azurerm_resource_group.plattform.name
  location                        = azurerm_resource_group.plattform.location
  account_tier                    = "Standard"
  account_replication_type        = "LRS"
  min_tls_version                 = "TLS1_2"
  allow_nested_items_to_be_public = false

  tags = {
    kostenstelle = "plattform"
    umgebung     = "prod"
  }
}

Die Versionsklammer ~> 4.0 gehört in jedes Projekt. Ohne sie zieht der nächste terraform init in einer frischen Pipeline eine neue Hauptversion des Providers, und ein Lauf, der gestern grün war, will heute Ressourcen ersetzen.

// main.bicep
param location string = resourceGroup().location
param storageName string

resource artefakte 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
  }
  tags: {
    kostenstelle: 'plattform'
    umgebung: 'prod'
  }
}

output blobEndpunkt string = artefakte.properties.primaryEndpoints.blob

Die API-Version steht in Bicep direkt am Ressourcentyp. Das ist unbequemer als eine Provider-Version im Kopf der Datei, macht aber jede Ressource einzeln festnagelbar, was bei Vorlagen mit langer Lebensdauer ein Vorteil ist.

Der sichtbare Unterschied ist gering, der unsichtbare groß. Terraform braucht ein Backend für den State, Bicep nicht, weil der Ist-Zustand im Azure Resource Manager liegt. Dafür kann derselbe Terraform-Bestand im selben Repository auch die DNS-Einträge beim externen Registrar, ein GitLab-Projekt und eine Datenbank bei einem SaaS-Anbieter beschreiben. Wenn die Entscheidung ohnehin auf Terraform fällt, klärt Terraform oder OpenTofu die anschließende Lizenzfrage.

terraform {
  backend "s3" {
    bucket         = "tfstate-plattform-prod"
    key            = "netz/prod.tfstate"
    region         = "eu-central-1"
    encrypt        = true
    dynamodb_table = "tfstate-locks"
  }
}

# Azure-Variante:
# backend "azurerm" {
#   resource_group_name  = "rg-tfstate"
#   storage_account_name = "sttfstateprod01"
#   container_name       = "tfstate"
#   key                  = "netz/prod.tfstate"
#   use_azuread_auth     = true
# }

Aktuelle Terraform- und OpenTofu-Versionen können die Sperre auch ohne DynamoDB direkt im Bucket führen. Prüfe die Fassung, die deine Pipeline nutzt, und stelle bei beiden Backends Versionierung des Speichers an, sonst ist ein zerschossener State nicht wiederherstellbar.

terraform init -reconfigure

# Nur abgleichen, nichts ändern: zeigt Abweichungen zwischen State und Wirklichkeit
terraform plan -refresh-only

terraform state list
terraform state show azurerm_storage_account.artefakte

# Bestehende Ressource übernehmen, ohne sie anzufassen
terraform plan -generate-config-out=uebernommen.tf

Ab Terraform 1.5 beschreibst du Übernahmen als import-Block im Code statt als einmaligen Befehl. Der Plan erzeugt dann mit -generate-config-out einen Entwurf der Ressourcendefinition, den du nachbearbeitest. Das ist deutlich belastbarer als hundert Aufrufe von terraform import in einem Shell-Skript.

terraform plan -out=tfplan
terraform show -json tfplan > tfplan.json

# Sicherheitsregeln gegen den geplanten Zustand, nicht gegen den Quelltext
checkov -f tfplan.json --framework terraform_plan

# Eigene Richtlinien als Code, z. B. erlaubte Regionen und Pflicht-Tags
conftest test tfplan.json --policy policies/

# Kostenvorschau vor der Freigabe
infracost breakdown --path tfplan.json

terraform apply tfplan

Wichtig ist die Reihenfolge: Der Plan wird einmal erzeugt, geprüft und genau so angewendet. Wer terraform apply ohne gespeicherte Plandatei aufruft, wendet einen frisch berechneten Plan an, der von dem geprüften abweichen kann.

az bicep build --file main.bicep

az deployment group what-if \
  --resource-group rg-plattform-prod \
  --template-file main.bicep \
  --parameters storageName=stplattformprod01

az deployment group create \
  --resource-group rg-plattform-prod \
  --template-file main.bicep \
  --parameters storageName=stplattformprod01 \
  --confirm-with-what-if

Der What-If-Lauf ist Bicep-Nutzenden ihr Plan. Mit --confirm-with-what-if zeigt die Bereitstellung die Änderungen und fragt vor der Ausführung nach, was in interaktiven Notfalleingriffen die letzte Bremse ist.

kubectl get providers.pkg.crossplane.io
kubectl get xrd                      # welche eigenen Ressourcentypen gibt es
kubectl get compositions

# Alle von Crossplane verwalteten Fremdressourcen
kubectl get managed

kubectl describe bucket artefakte-prod

Die Spalten SYNCED und READY sind die eigentliche Statusanzeige. SYNCED bedeutet, dass der Controller die Ressource beim Anbieter abgleichen konnte, READY, dass sie dort benutzbar ist. Steht SYNCED dauerhaft auf False, liegt es fast immer an den Rechten der hinterlegten ProviderConfig.

apiVersion: plattform.example.de/v1alpha1
kind: PostgresInstanz
metadata:
  name: shop-prod
  namespace: team-shop
spec:
  groesse: mittel
  region: eu-central-1
  aufbewahrungTage: 14
  compositionRef:
    name: postgres-aws

Genau das ist der Unterschied zur Pipeline: Das Anwendungsteam schreibt kein HCL und bekommt keine Berechtigung beim Anbieter, sondern legt ein Objekt in seinem Namensraum an. Die Übersetzung in konkrete Ressourcen steckt in der Composition, die das Plattformteam pflegt.

Praktisch enden viele Häuser bei einer Kombination: Terraform oder OpenTofu bauen die Grundstruktur mit Konten, Netzen, Identität und Richtlinien, also die Landing Zone, und Crossplane oder ein Werkzeug wie Argo CD stellt Anwendungsteams darauf die einzelnen Bausteine bereit. Diese Trennung hat den Vorteil, dass selten geänderte Grundlagen und täglich geänderte Anwendungsressourcen nicht in derselben Pipeline und nicht im selben State liegen.