Zum Inhalt springen
≈ 1 minNeuTerraformIaCCloudAzure

Best Practices für Terraform

Terraform- und OpenTofu-Code, der sicher, wiederverwendbar und teamfähig ist – Module, Remote State mit Locking, gepinnte Versionen und keine Secrets im Code.

In 30 Sekunden

  1. 01

    Der State gehört in ein Remote Backend mit Locking, etwa einen Azure Storage Account – nie ins Git-Repo.

  2. 02

    Wiederkehrende Bausteine werden zu Modulen, und Provider-Versionen werden gepinnt.

  3. 03

    Jede Änderung läuft durch plan in der CI und wird erst nach Review per apply ausgerollt.

Die wichtigsten Regeln

Remote State + Locking

backend "azurerm" mit Storage Account – der Blob-Lease verhindert parallele Applies. Ein State pro Umgebung.

Versionen pinnen

required_version und required_providers mit ~>-Constraints, .terraform.lock.hcl committen.

Module

Wiederkehrendes (z. B. „App Service + Key Vault + Identity“) als Modul mit klaren Variablen und Outputs.

Keine Secrets im Code

Secrets in Key Vault, Zugriff per Managed Identity. Variablen mit sensitive = true markieren.

Variablen beschreiben & prüfen

Jede Variable mit type, description und validation – Fehler fallen beim Plan auf, nicht in Produktion.

fmt, validate, lint

terraform fmt -check, validate und tflint in der CI. plan als Kommentar am Merge Request.

for_each statt count

Nicht so

resource "azurerm_resource_group" "rg" {
  count    = length(var.envs)
  name     = "rg-app-${var.envs[count.index]}"
  location = "westeurope"
}
# Element aus der Mitte entfernen → alle danach neu

So

resource "azurerm_resource_group" "rg" {
  for_each = toset(var.envs)
  name     = "rg-app-${each.key}"
  location = "westeurope"
  tags     = local.common_tags
}

Der sichere Ablauf

  1. 01

    Format & Validierung

    terraform fmt · validate

    Syntax und Stil prüfen – schnell und lokal.

  2. 02

    Plan im Merge Request

    terraform plan -out=tfplan

    Die CI zeigt genau, was erstellt, geändert oder gelöscht wird.

  3. 03

    Review

    4-Augen-Prinzip

    Ein Mensch prüft den Plan – besonders Zeilen mit „destroy“.

  4. 04

    Apply des geprüften Plans

    terraform apply tfplan

    Ausgerollt wird genau der reviewte Plan, authentifiziert per Managed Identity oder OIDC.

Merksatz

„Der State ist die Wahrheit über deine Infrastruktur – schütze ihn wie eine Produktionsdatenbank.“

Selbsttest

Erst selbst überlegen, dann aufklappen.

01Warum ist for_each meist besser als count?

count adressiert Ressourcen per Index. Entfernt man ein Element aus der Mitte, verschieben sich alle folgenden Indizes und Terraform will sie neu erstellen. for_each adressiert per stabilem Schlüssel.

02Warum gehört der State nicht ins Git-Repo?

Er kann Secrets im Klartext enthalten, und ohne Locking überschreiben sich parallele Läufe gegenseitig.

Quellen & Weiterlesen

Verwandt