Infrastructure as Code (IaC)

Tools: Terraform, Ansible, CloudFormation, Pulumi. Beispiel Terraform (main.tf):

resource "aws_instance" "web" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"
}

resource "aws_s3_bucket" "b" {
  bucket = "my-bucket"
}

Befehl: terraform apply. Terraform redet mit der AWS API und erstellt genau das. Wenn du den Typ auf "t2.large" änderst und nochmal ausführst, updated er den Server.

1. Declarative vs. Imperative

• Imperativ (Ansible/Bash): "Geh zu Server X. Installiere Y. Starte Z." (Anweisungen). Wie ein Kochrezept.
• Deklarativ (Terraform/K8s): "Ich will 3 Webserver haben." (Zustandsbeschreibung). Wie eine Bestellung. Terraform prüft: "Es gibt schon 2. Also muss ich 1 erstellen." In modernen Clouds gewinnt Deklarativ, weil es Drift besser handhabt.

2. State Management (Die tfstate Datei)

Woher weiß Terraform, was es schon erstellt hat? Es speichert eine terraform.tfstate Datei (Mapping: "Code Resource 'web' = AWS ID 'i-012abc'"). Diese Datei ist heilig. Wenn du sie löschst, "vergisst" Terraform deine Server und erstellt neue (Duplikat) oder weigert sich weiterzumachen. Im Team muss der State zentral gesperrt werden (S3 Bucket + DynamoDB Lock), damit nicht zwei Leute gleichzeitig apply machen (Race Condition).

3. Modularisierung

Du schreibst nicht 1000 Zeilen Code. Du baust Module. Modul "Standard-Webserver" (enthält VPC, Security Group, EC2, Monitoring). Das Team nutzt nur noch:

module "my-app" {
  source = "./modules/standard-web"
  name   = "shop"
}

Das ermöglicht "Platform Engineering". Ein Team baut die Module (Lego-Steine), die anderen Teams bauen daraus Apps.

State File Locking & Remote Backends

Das absolut kritischste Bauteil in Terraform ist das Remote Backend (die Ablage der .tfstate-Datei). Liegt der State lokal beim Entwickler auf dem Rechner, überschreiben sich Teams gegenseitig die Infrastruktur. Best Practice in AWS ist ein S3-Bucket für den State-File plus eine DynamoDB-Tabelle für das State Locking. Tippt Alice terraform apply, schreibt Terraform einen Lock in die DynamoDB. Tippt Bob zeitgleich apply, prüft sein Terraform die DynamoDB, blockiert und wirft einen Error. Das verhindert radikal Split-Brain-Situationen und zerfetzte Cloud-Ressourcen.

Provider Architecture & API Abstraction

Terraform an sich weiß nichts über AWS, Azure oder GCP. Es baut auf einer Plugin-Architektur auf: Den Providers (meist geschrieben in Go). Der AWS-Provider übersetzt den deklarativen HCL-Code in hunderte sequentielle imperative API-Aufrufe an die Amazon-Schnittstellen. Die echte Schwierigkeit für Provider-Entwickler ist das Status-Polling ("Eventual Consistency"). Wenn der Code eine EC2-Instanz fordert, sendet der Provider ein POST. Da die Instanz 3 Minuten bootet, muss der Provider asynchron auf API-Queries warten, bevor er die Instanz als "Ready" im State verbucht, um darauf aufbauende Ressourcen (z.B. Load Balancer) weiter bauen zu lassen.

Die Zukunft: Crossplane & KRM

Das "Terraform applies from CI/CD"-Modell (CLI-Push) altert. Moderne Infrastruktur-Teams adaptieren Crossplane (Kubernetes Resource Model - KRM). Anstatt Terraform auszuführen, verwaltest du AWS RDS-Datenbanken als Kubernetes-Custom-Resources (kubectl apply -f postgres.yaml). Der Crossplane-Operator dröhnt im Kubernetes-Cluster, redet mit der AWS-API und erzeugt die DB. Der monströse Vorteil: Kontinuierliche Drift-Reconciliation (GitOps). Löscht ein böser Admin in der Cloud-Console einen Port, merkt Crossplane die Diskrepanz innerhalb von Sekunden und patcht via K8s Operator-Loop den Cloud-Zustand gegen den Code sofort zurück (ohne auf den nächsten manuellen Terraform-Run warten zu müssen).