Terraform einfach erklärt – Provider, State und Module

Mit Terraform beschreibst du Infrastruktur als Code. Du legst in HCL fest, welche Ressourcen du brauchst, und Terraform erstellt, ändert oder löscht sie reproduzierbar. Das reduziert Fehler, schafft Transparenz und ermöglicht Reviews wie bei normalem Code.

Damit der Einstieg gelingt, solltest du drei Bausteine verstehen: Provider verbinden Terraform mit deiner Cloud, der State speichert den Ist-Zustand deiner Ressourcen und Module machen dein Setup wiederverwendbar. In diesem Guide gehen wir das Schritt für Schritt durch – einfach, praxisnah und mit klaren Beispielen.

Was Terraform für dich macht

Terraform vergleicht deinen gewünschten Zustand aus den .tf Dateien mit dem tatsächlichen Zustand im State. Daraus erzeugt es einen Plan und führt ihn mit Apply aus. Der Clou: Änderungen sind nachvollziehbar, idempotent und lassen sich bei Bedarf zurückrollen.

Minimaler Ablauf

1. terraform init lädt Provider und initialisiert das Backend.
2. terraform plan zeigt was geändert wird.
3. terraform apply setzt Änderungen um.
4. terraform destroy räumt alles auf, wenn du es brauchst.

Provider – die Brücke zur Plattform

Was ist ein Provider

Provider sind Plugins, die Terraform mit APIs sprechen lassen, z. B. AWS, Azure, Google Cloud, Cloudflare, GitHub. Du definierst, welcher Provider in welcher Version verwendet wird und wie er sich authentifiziert.

Beispiel providers.tf

terraform {
  required_version = ">= 1.6"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
  # Auth per env vars: AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY
}

Wichtig: Lege Versionen fest, damit Builds reproduzierbar sind. Hinterlege Credentials nicht im Code, sondern per Umgebungsvariablen oder Profile.

State – der Gedächtnisspeicher deiner Infrastruktur

Warum der State zentral ist

Der State (terraform.tfstate) merkt sich, welche Ressourcen Terraform verwaltet. Ohne ihn kann Terraform Drift nicht erkennen. Der State enthält oft sensible Daten. Behandle ihn wie ein Secret.

Remote Backend und Locking

Speichere den State nicht lokal im Repo. Nutze ein Remote Backend mit Locking, z. B. AWS S3 plus DynamoDB.

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

Vorteile: Zentrale Ablage, Teamzugriff, Locking gegen Parallel-Apply, Verschlüsselung.
Praxis-Tipp: Nutze separate Buckets/Keys pro Umgebung und setze IAM-Policies restriktiv.

Ressourcen, Variablen, Outputs – die Basiselemente

Einfache Ressource

resource "aws_s3_bucket" "logs" {
  bucket = "my-logs-${var.env}"
  tags = {
    app = "demo"
    env = var.env
  }
}

Variablen und Standards

variable "env" {
  description = "Zielumgebung"
  type        = string
  default     = "dev"
}

variable "aws_region" {
  type    = string
  default = "eu-central-1"
}

Outputs für Weitergabe

output "logs_bucket_name" {
  value       = aws_s3_bucket.logs.bucket
  description = "Name des Log-Buckets"
}

Merke: Variablen erleichtern Reuse, Outputs sind die Schnittstelle zu anderen Modulen oder Tools.

Abhängigkeiten und Änderungen verstehen

Implizite Abhängigkeiten

Terraform erkennt Abhängigkeiten, wenn du auf Attribute verweist.

resource "aws_iam_user" "u" { name = "reporter" }

resource "aws_iam_access_key" "k" {
  user = aws_iam_user.u.name
}

Hier weiß Terraform: Key erst nach dem User.

Explizite Abhängigkeiten

Wenn nötig, nutze depends_on:

resource "aws_s3_bucket_policy" "p" {
  bucket     = aws_s3_bucket.logs.id
  policy     = data.aws_iam_policy_document.logs.json
  depends_on = [aws_s3_bucket.logs]
}

Plan lesen

Achte im Plan auf create, update in-place und destroy-recreate. Letzteres bedeutet: Ressource wird ersetzt. Prüfe, ob das gewollt ist.

Module – Struktur und Wiederverwendung

Warum Module

Module kapseln wiederkehrende Muster, z. B. ein VPC, ein S3 Log-Bucket oder ein K8s-Cluster. Du definierst Variablen, Ressourcen und Outputs einmal und nutzt sie in vielen Projekten.

Modul-Struktur

modules/
  s3-logs/
    main.tf
    variables.tf
    outputs.tf

Modul nutzen

module "logs" {
  source = "./modules/s3-logs"
  env    = var.env
}

Versionierte Registry-Module

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"
  name    = "main-${var.env}"
  cidr    = "10.0.0.0/16"
}

Vorteile: Konsistenz, kürzerer Code, schnellere Reviews.
Hinweis: Dokumentiere Inputs/Outputs und halte Module klein und fokussiert.

Workspaces und Umgebungen

Wann Workspaces helfen

Workspaces trennen State logisch innerhalb eines Backends, z. B. default, staging, prod.

terraform workspace new staging
terraform workspace select staging

Gut für Experimente und kleine Setups. Für größere Teams sind separate Backends oder getrennte Ordner pro Umgebung klarer und sicherer.

Sicherheit und Hygiene

Secrets schützen

• State kann Secrets enthalten. Nie ins Repo committen.
• Variablenwerte über Env Vars oder CI Secrets injizieren.
• State im Backend verschlüsseln und Zugriff einschränken.

Qualität sichern

• terraform fmt -check und terraform validate im CI.
• Optionale Tools wie tflint und tfsec helfen bei Best Practices und Security Checks.
• Changelogs und Code Reviews für Module pflegen.

Typische Stolperfallen und schnelle Lösungen

Drift zwischen Realität und State

Manuelle Änderungen in der Cloud führen zu Drift. Nutze terraform plan regelmäßig und terraform import, um bestehende Ressourcen unter Terraform zu stellen.

Zuviel in einem Apply

Halte Änderungen klein. Kleine Pläne sind verstehbar und risikoärmer. Nutze Tags und Namen konsistent.

Provider- oder Modul-Updates

Aktualisiere schrittweise und lege Versionen fest. Prüfe Release Notes und lies den Plan genau.

Mini-Beispiel: Vom Nichts zu einem Bucket

# main.tf
module "logs" {
  source = "./modules/s3-logs"
  env    = "dev"
}

# modules/s3-logs/main.tf
resource "aws_s3_bucket" "logs" {
  bucket = "my-logs-${var.env}"
  force_destroy = false
}

# modules/s3-logs/variables.tf
variable "env" {
  type = string
}

# modules/s3-logs/outputs.tf
output "name" {
  value = aws_s3_bucket.logs.bucket
}

Jetzt terraform init, terraform plan, terraform apply – und dein Bucket steht.

Fazit

Mit Terraform baust du Infrastruktur planbar und wiederholbar. Provider verbinden dich mit der Zielplattform, der State hält den Überblick und Module sorgen für Ordnung und Wiederverwendbarkeit. Wenn du Remote State mit Locking nutzt, kleine Pläne fährst und Versionen sauber fixierst, wird dein Setup stabil, sicher und skalierbar.