Infrastructure as Code Grundlagen

Lernziele

Nach dieser Lektion kannst du erklären, welches Problem Infrastructure as Code löst und warum „deklarativ” und „idempotent” mehr als Buzzwords sind. Du kannst Terraform gegen Pulumi, CloudFormation und Crossplane abgrenzen und weißt, warum Terraform einen State braucht — das Fundament für alles, was in diesem Lernpfad folgt.

Das Problem: Infrastruktur aus dem Gedächtnis

Stell dir eine typische Cloud-Umgebung vor, die über zwei Jahre per Web-Console gewachsen ist: ein VPC, das jemand 2023 angelegt hat, Security Groups mit Regeln, deren Zweck niemand mehr kennt, ein S3-Bucket, der „eigentlich nur ein Test” war und jetzt Produktionsdaten hält. Diese Arbeitsweise heißt abwertend ClickOps, und sie hat drei strukturelle Probleme.

Erstens: keine Reproduzierbarkeit. Wenn du dieselbe Umgebung für Staging brauchst, klickst du alles noch einmal zusammen — und vergisst garantiert etwas. Zweitens: keine Historie. Wer hat wann die Firewall-Regel geöffnet, und warum? Die Cloud-Console beantwortet das bestenfalls über mühsame Audit-Logs. Drittens: kein Review. Eine Änderung an der Produktions-Datenbank passiert mit einem Klick, ohne dass ein zweites Augenpaar draufschaut.

Infrastructure as Code dreht das um: Infrastruktur wird in Textdateien beschrieben, die in Git liegen. Damit erbt Infrastruktur automatisch alles, was Software-Entwicklung seit Jahren kann — Versionierung, Pull Requests mit Review, Diffs, Rollback auf einen alten Stand, CI-Pipelines. Eine neue Umgebung entsteht nicht durch Klicken, sondern durch Anwenden derselben Dateien mit anderen Parametern.

Deklarativ statt imperativ: Zielzustand statt Schrittfolge

Der wichtigste konzeptionelle Unterschied, den du im Interview sauber erklären können musst: Ein Bash-Skript mit aws ec2 run-instances ... ist imperativ — es beschreibt Schritte. Führst du es zweimal aus, hast du zwei Instanzen. Schlägt es in der Mitte fehl, hast du einen halbfertigen Zustand, und das Skript weiß beim nächsten Lauf nicht, wo es weitermachen soll.

Terraform ist deklarativ: Du beschreibst den Zielzustand — „es soll genau eine Instanz mit diesen Eigenschaften geben” — und das Tool berechnet selbst, welche Schritte nötig sind, um vom Ist- zum Sollzustand zu kommen. Daraus folgt direkt die zweite Eigenschaft, Idempotenz: Dieselbe Konfiguration mehrfach anzuwenden erzeugt dasselbe Ergebnis. Existiert die Instanz schon und entspricht der Beschreibung, tut Terraform nichts. Weicht ein Attribut ab, ändert es genau dieses Attribut.

Damit das funktioniert, muss Terraform wissen, welche realen Ressourcen zu welchem Codeblock gehören. Genau dafür existiert der State — eine Datei, die das Mapping zwischen deiner Konfiguration und den echten Cloud-Ressourcen festhält. Der State ist das meistgefragte und meistmissverstandene Terraform-Konzept; die Lektionen 5 und 6 widmen sich ihm ausführlich. Für jetzt reicht: Ohne State kann ein deklaratives Tool keinen Diff berechnen.

Die Tool-Landschaft: Terraform, Pulumi, CloudFormation, Crossplane

Die Abgrenzungsfrage kommt in fast jedem Interview. Eine belastbare Einordnung:

• Terraform beschreibt Infrastruktur in der eigenen Sprache HCL, ist Cloud-agnostisch über ein riesiges Provider-Ökosystem und der De-facto-Standard im Platform Engineering. Seit der Lizenzänderung von HashiCorp (weg von Open Source, hin zur BSL) existiert mit OpenTofu ein quelloffener Fork mit kompatibler Sprache — das solltest du erwähnen können, ohne dich in Lizenzdetails zu verlieren.
• Pulumi verfolgt denselben deklarativen Ansatz, aber mit echten Programmiersprachen (TypeScript, Python, Go) statt einer DSL. Stärke: volle Sprachfeatures wie Schleifen, Typen, Tests mit normalen Frameworks. Schwäche: Der Code kann beliebig komplex werden, und Reviews erfordern Programmierkenntnisse im ganzen Team.
• CloudFormation ist AWS-nativ: kein eigener State nötig (AWS verwaltet ihn serverseitig), dafür auf AWS beschränkt und mit deutlich zäherer Entwicklererfahrung (JSON/YAML, langsame Fehlermeldungen).
• Crossplane ist die Kubernetes-native Antwort: Infrastruktur wird als Custom Resources im Cluster beschrieben, ein Controller reconciled kontinuierlich. Das ist der fundamentale Unterschied zu Terraform: Terraform wird nur aktiv, wenn jemand es ausführt; Crossplane korrigiert Drift permanent — kauft sich das aber mit der Komplexität, einen Kubernetes-Cluster als Control Plane zu betreiben.

Im Interview punktest du mit Kriterien statt Tool-Religion: Team-Skills, bestehende Landschaft, Single- vs. Multi-Cloud, und ob kontinuierliche Reconciliation gebraucht wird.

Praxis: vom Klick zum Code

Du brauchst keinen Cloud-Account — der local-Provider reicht, um den Kern von IaC zu erleben:

mkdir iac-demo && cd iac-demo
cat > main.tf <<'EOF'
resource "local_file" "hello" {
  filename = "${path.module}/hello.txt"
  content  = "Verwaltet von Terraform - nicht manuell editieren!"
}
EOF

terraform init     # Provider herunterladen
terraform apply    # Zielzustand herstellen (mit "yes" bestätigen)
cat hello.txt

Jetzt teste die Idempotenz und die Drift-Erkennung:

terraform apply                       # nichts zu tun: "No changes"
echo "manuell geändert" > hello.txt   # Drift simulieren
terraform plan                        # Terraform erkennt die Abweichung
terraform apply                       # stellt den Sollzustand wieder her
terraform destroy                     # räumt auf

Schau dir danach die Datei terraform.tfstate an — dort siehst du das Mapping zwischen Code und realer Ressource mit eigenen Augen.

Typische Stolperfallen

„IaC = Automatisierung”: Ein Bash-Skript automatisiert auch. Der Kern von IaC ist Deklarativität plus Idempotenz plus Versionierung — wer im Interview nur „Automatisierung” sagt, bleibt an der Oberfläche.

Code geschrieben, aber weiter geklickt: Der häufigste Praxis-Fehler. Sobald jemand an Terraform vorbei in der Console ändert, entsteht Drift — der State stimmt nicht mehr mit der Realität überein, und der nächste apply macht die manuelle Änderung womöglich rückgängig. IaC funktioniert nur als verbindliche Arbeitsweise, nicht als Zusatzdokumentation.

Den State ignorieren: Wer Terraform einführt, ohne früh über State-Speicherung und Locking nachzudenken, holt sich die Probleme später in größer (Lektion 6).

Alles in ein Projekt packen: Eine einzige Konfiguration für die gesamte Firma bedeutet riesigen Blast Radius bei jedem Apply. Sinnvolles Schneiden lernst du in den Lektionen 7 und 8.

Interview-Vorbereitung

Die Standardfrage „Was ist Infrastructure as Code und warum nutzt man es?” beantwortest du problem-first: Problem (manuelle Infrastruktur ist nicht reproduzierbar, nicht nachvollziehbar, nicht reviewbar) → Definition (Infrastruktur als versionierte, deklarative Beschreibung des Zielzustands) → Mechanik in einem Satz (Tool vergleicht Soll und Ist und wendet nur den Diff an) → eine Grenze (Drift durch manuelle Änderungen, State als neue Betriebsverantwortung).

Typische Follow-ups:

• „Was heißt deklarativ konkret?” — Zielzustand statt Schrittfolge; das Tool berechnet die Schritte selbst und ist dadurch idempotent.
• „Warum braucht Terraform einen State, CloudFormation aber nicht?” — CloudFormation verwaltet den Zustand serverseitig bei AWS; Terraform ist Cloud-agnostisch und muss das Mapping selbst führen.
• „Terraform oder Pulumi?” — HCL ist bewusst eingeschränkt und gut reviewbar; Pulumi bietet volle Sprachmacht für Teams, die sie brauchen und beherrschen.
• „Was ist Drift?” — Abweichung zwischen State/Code und Realität, meist durch manuelle Änderungen; erkennbar per terraform plan.

Zusammenfassung

Infrastructure as Code macht Infrastruktur reproduzierbar, nachvollziehbar und reviewbar, indem der Zielzustand deklarativ in versionierten Dateien beschrieben wird. Idempotenz sorgt dafür, dass wiederholtes Anwenden gefahrlos ist; der State macht den Soll-Ist-Vergleich technisch möglich. Terraform ist der Standard im Multi-Cloud-Umfeld, Pulumi setzt auf echte Programmiersprachen, CloudFormation bleibt AWS-only, Crossplane bringt kontinuierliche Reconciliation auf Kubernetes-Basis.

In der nächsten Lektion lernst du die Sprache, in der Terraform-Code geschrieben wird: HCL mit Resources, Data Sources, Variables und Outputs.