Infrastructure as Code -- Warum Terraform unseren Ansatz zur Infrastruktur verändert hat

Vor einem Jahr haben wir Infrastruktur von Hand gebaut. Klicken in der AWS-Konsole, Notizen in Confluence und beten, dass niemand diese Security Group löscht. Heute ist alles in Terraform – versioniert, reviewt, automatisch deployt. Hier ist unsere Geschichte.

Das Problem: Snowflake-Server¶

Jeder Server war einzigartig. Die Entwicklungsumgebung unterschied sich vom Staging, Staging von der Produktion. Niemand wusste genau, welche Konfiguration auf welchem Server lief. Dokumentation war am Tag nach dem Schreiben veraltet. Wenn ein Server ausfiel, dauerte die Wiederherstellung Stunden – weil sich niemand an alle Schritte erinnerte.

Das ist das klassische Anti-Pattern, bekannt als “Snowflake Server”. Jeder ist besonders, jeder ist anders, und keiner lässt sich einfach reproduzieren. Bei drei Servern geht es noch. Bei dreißig ist es ein Albtraum. Bei dreihundert ist es unmöglich.

Warum Terraform und nicht CloudFormation oder Ansible¶

CloudFormation ist AWS-only. Wir betreiben Infrastruktur auf AWS und in On-Premise-Umgebungen (VMware). Wir brauchten ein Tool, das beides kann. Terraform hat Provider für AWS, Azure, GCP, VMware, Consul und Dutzende weiterer Services.

Ansible ist ein Konfigurationsmanagement-Tool, kein Provisioning-Tool. Hervorragend für die Konfiguration bestehender Server, aber für die Erstellung von Infrastruktur (VPCs, Subnetze, Load Balancer, RDS-Instanzen) ist Terraform die bessere Wahl. In der Praxis nutzen wir beides – Terraform erstellt die Infrastruktur, Ansible konfiguriert sie.

Terraform verwendet einen deklarativen Ansatz: Sie beschreiben, wie die Infrastruktur aussehen soll, und Terraform ermittelt, was geändert werden muss. Im Vergleich zu einem imperativen Ansatz (mache Schritt 1, dann Schritt 2, dann Schritt 3) ist es grundlegend einfacher zu pflegen.

Projektstruktur¶

Nach mehreren Iterationen haben wir uns auf folgende Struktur festgelegt:

infrastructure/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── ecs-cluster/
│   ├── rds/
│   └── monitoring/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── terraform.tfvars
│   │   └── backend.tf
│   ├── staging/
│   └── production/
└── README.md

Module definieren wiederverwendbare Komponenten. Das VPC-Modul erstellt die Netzwerktopologie, das ECS-Modul konfiguriert den Container-Cluster, das RDS-Modul die Datenbank. Jedes Modul hat klar definierte Eingaben (Variables) und Ausgaben (Outputs).

Environments sind konkrete Deployments von Modulen mit unterschiedlichen Parametern. Dev hat kleinere Instanzen, Staging spiegelt die Produktion in kleinerem Maßstab wider, Produktion hat ein Multi-AZ-Setup mit höherer Redundanz.

State Management – Ein Schlüsselkonzept¶

Terraform speichert den Infrastrukturzustand in einer terraform.tfstate-Datei. Diese Datei ist kritisch wichtig – verlieren Sie sie, weiß Terraform nicht mehr, was es verwaltet. Deshalb sollten Sie State niemals lokal speichern.

# Infrastructure as Code -- Warum Terraform unseren Ansatz zur Infrastruktur verändert hat
terraform {
  backend "s3" {
    bucket         = "core-terraform-state"
    key            = "production/terraform.tfstate"
    region         = "eu-central-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

Das S3-Backend mit DynamoDB-Locking stellt sicher, dass nicht zwei Personen gleichzeitig die Infrastruktur ändern können. Verschlüsselung at Rest für die State-Datei, da sie sensible Informationen enthält (RDS-Passwörter, API-Schlüssel). S3-Bucket-Versionierung als Schutz gegen versehentliches Überschreiben.

Code Review für Infrastruktur¶

Hier zahlt sich Infrastructure as Code wirklich aus. Jede Infrastrukturänderung durchläuft einen Pull Request. Vor dem Merge führen wir terraform plan aus und hängen die Ausgabe an den PR an. Der Reviewer sieht genau, was sich ändern wird:

$ terraform plan
~ aws_instance.api_server
    instance_type: "t2.medium" => "t2.large"

+ aws_cloudwatch_metric_alarm.cpu_high
    alarm_name:          "api-cpu-high"
    comparison_operator: "GreaterThanThreshold"
    threshold:           "80"

Plan: 1 to add, 1 to change, 0 to destroy.

Keine Überraschungen. Kein “Wer hat am Freitagabend diese Security Group geändert.” Alles ist in der Git-Historie nachvollziehbar – wer, wann, warum. Für Audit und Compliance ist das Gold wert.

Module – Das DRY-Prinzip für Infrastruktur¶

Unser VPC-Modul wird in allen Projekten verwendet. Es definiert eine Standard-Netzwerktopologie: öffentliche und private Subnetze über drei Availability Zones, NAT Gateway, Route Tables, Flow Logs. Parametrisierter CIDR-Block und Tagging.

# environments/production/main.tf
module "vpc" {
  source = "../../modules/vpc"

  environment = "production"
  cidr_block  = "10.0.0.0/16"
  azs         = ["eu-central-1a", "eu-central-1b", "eu-central-1c"]

  tags = {
    Project = "client-x"
    ManagedBy = "terraform"
  }
}

Wenn wir einen Bug oder eine Verbesserung in einem Modul finden, beheben wir es einmal und propagieren es in alle Umgebungen. Wir versionieren Module mit Git-Tags – Produktion verwendet eine bewährte Version, Dev kann die neueste testen.

Fallstricke und Lessons Learned¶

Drift-Erkennung. Jemand ändert etwas manuell in der Konsole – und Terraform weiß nichts davon. Beim nächsten terraform apply wird die Änderung überschrieben. Lösung: regelmäßiges terraform plan in der CI-Pipeline, das Drift erkennt und das Team benachrichtigt.

Destruktive Änderungen. Einige Terraform-Änderungen erfordern Destroy + Recreate. Das Ändern der AMI einer EC2-Instanz bedeutet einen neuen Server. Das Ändern der engine_version bei RDS kann Downtime bedeuten. Lesen Sie den Plan immer sorgfältig – rote Zeilen mit Minuszeichen sind eine Warnung.

Secrets Management. Legen Sie niemals Passwörter in .tf-Dateien ab. Wir verwenden AWS Secrets Manager mit Data-Source-Referenzen. Alternativ HashiCorp Vault – aber das ist ein Thema für einen eigenen Artikel.

Import bestehender Infrastruktur. terraform import existiert, ist aber nicht schmerzfrei. Für jede Ressource müssen Sie die Konfiguration manuell schreiben und dann importieren. Bei größerer Infrastruktur sind das Wochen Arbeit. Lektion: Beginnen Sie so früh wie möglich mit Terraform.

IaC ist keine Wahl, es ist eine Notwendigkeit¶

Infrastructure as Code ist nicht nur ein Buzzword. Es ist ein fundamentaler Wandel in der Art, wie wir mit Infrastruktur umgehen – von handwerklicher Arbeit zu einem Engineering-Prozess. Terraform gab uns Reproduzierbarkeit, Nachvollziehbarkeit und Geschwindigkeit. Heute erstellen wir eine vollständige Produktionsumgebung in 20 Minuten mit einem einzigen Befehl. Vor einem Jahr brauchte das zwei Tage und drei Personen.