Einführung in Terraform

Warum klickt man Infrastruktur nicht einfach zusammen? Dieses Modul zeigt den Unterschied zwischen manueller Konfiguration und deklarativem Infrastruktur-Code: reproduzierbar, versionierbar, reviewbar. Sie vergleichen Terraform mit Alternativen wie Ansible, CloudFormation und Pulumi und verstehen, wann welches Tool das richtige ist. Außerdem ordnen wir die aktuelle Lizenz-Situation (BSL) und den Open-Source-Fork OpenTofu sachlich ein.

Statt langer Theorie schreiben Sie direkt Ihre erste HCL-Datei. Sie lernen die Bausteine der HashiCorp Configuration Language kennen: resource Blocks, data Blocks, Attribute und Referenzen. Mit dem Local Provider erstellen Sie Dateien auf Ihrem System und durchlaufen den kompletten Zyklus von terraform init bis terraform apply. Am Ende dieses Blocks lesen Sie HCL wie eine vertraute Sprache.

Provider verbinden Terraform mit der Außenwelt: AWS, Azure, GCP oder Hunderte weitere APIs. Sie konfigurieren Ihren ersten Cloud-Provider, pinnen Versionen im required_providers-Block und verstehen den Lebenszyklus eines terraform plan und terraform apply. Danach wissen Sie, was bei jedem Befehl unter der Haube passiert und warum terraform plan vor jedem Apply Pflicht ist.

Hardcoded-Werte machen Konfigurationen unflexibel. Sie arbeiten mit Input Variables, definieren Typen (string, number, list, map, object) und setzen Defaults und Validierungsregeln. Mit Outputs machen Sie Ergebnisse für andere Module und die Kommandozeile sichtbar, und mit Locals vermeiden Sie Wiederholungen. Am Ende refactoren Sie Ihre erste Konfiguration zu einer sauber parametrierten Version.

Alles Gelernte kommt zusammen: Sie provisionieren eine eigene VM mit Security Group und Elastic IP in der Cloud. Dabei nutzen Sie Variablen für Region und Instanztyp, Outputs für die öffentliche IP und die Terraform-Dokumentation als Nachschlagewerk. Am Ende des Tages läuft Ihre erste per Code definierte Infrastruktur.

Der State ist das Gedächtnis von Terraform: ohne ihn weiß Terraform nicht, was existiert. Sie konfigurieren ein Remote Backend mit S3 und DynamoDB (Locking), aktivieren Versionierung für Rollbacks und verstehen, warum State-Dateien nie in Git gehören. Dann isolieren Sie State nach Umgebung und Komponente, damit ein Fehler in der Staging-Netzwerkkonfiguration nicht die Produktion gefährdet.

Bestehende Infrastruktur übernehmen, Ressourcen umbenennen oder aus dem State entfernen: früher machte man das mit imperativen CLI-Befehlen. Heute geht das besser. Sie arbeiten mit dem import Block, dem moved Block und dem removed Block. Diese deklarativen Operationen sind reviewbar in Pull Requests, wiederholbar und selbstdokumentierend. Die alten CLI-Befehle (terraform import, terraform state mv) kennen Sie als Fallback, aber nicht als Standard.

Module sind der Schlüssel zu wartbarem Terraform-Code. Sie bauen ein eigenes Modul mit Input-Variablen, Outputs und interner Logik. Dann nutzen Sie Module aus der Terraform Registry, pinnen Versionen mit semantischer Versionierung (~> 1.2.0) und generieren mit terraform-docs automatisch eine Dokumentation. Am Ende verstehen Sie das Prinzip "kleine, wiederverwendbare Bausteine" und können es auf Ihre eigenen Projekte anwenden.

Wie organisiert man Terraform-Code, wenn das Projekt über eine einzelne main.tf hinauswächst? Sie arbeiten mit CLI Workspaces zur Umgebungstrennung (dev, staging, prod), lernen gängige Dateistruktur-Konventionen (main.tf, variables.tf, outputs.tf, providers.tf) und wenden DRY-Prinzipien mit Modulen an. Zusätzlich sehen Sie, wie Terragrunt bei größeren Setups als Orchestrierungslayer hilft.

Sie bauen eine vollständige Multi-Tier-Infrastruktur aus wiederverwendbaren Modulen: VPC mit öffentlichen und privaten Subnets, Security Groups und eine VM im privaten Netz. Der State liegt remote, die Module sind versioniert, die Struktur folgt den Konventionen aus dem vorherigen Block. Am Ende haben Sie eine Referenzarchitektur, die Sie in eigene Projekte übernehmen können.

HCL kann mehr als einfache Zuweisungen. Sie arbeiten mit for_each und count für dynamische Ressourcen-Erzeugung, schreiben Dynamic Blocks für wiederholte Nested-Strukturen und nutzen Conditionals (condition ? true : false) für umgebungsabhängige Konfiguration. Dazu kommen Built-in-Funktionen wie lookup, merge, flatten und templatefile. Danach schreiben Sie HCL, das sich an wechselnde Anforderungen anpasst, statt es für jede Änderung umzuschreiben.

Code ohne Tests ist ein Versprechen ohne Beweis. Sie schreiben Ihre ersten .tftest.hcl-Dateien mit command = plan für Unit-Tests und command = apply für Integrationstests. Mit Provider Mocking (seit v1.7) testen Sie Module ohne Cloud-Credentials. Ergänzend setzen Sie TFLint für statische Analyse und terraform validate als Baseline-Check ein. Am Ende läuft eine Test-Suite, die Fehler findet, bevor sie in der Cloud kosten.

Terraform-State enthält sensible Daten, und sensitive = true allein schützt sie nicht: der Wert steht trotzdem im State. Seit v1.10 gibt es Ephemeral Values: temporäre Credentials und Tokens, die den State nie berühren. Dazu kommen Write-only Arguments (v1.11) für Ressourcen-Attribute, die nicht persistiert werden. Sie konfigurieren beide Mechanismen und ergänzen sie durch Checkov und Trivy für automatisiertes Security-Scanning Ihrer Terraform-Dateien.

In produktiven Teams läuft terraform apply nicht vom Laptop. Sie integrieren Terraform in eine CI/CD-Pipeline mit GitLab CI oder GitHub Actions: Plan als PR-Kommentar, Apply nach Approval. Dazu lernen Sie die Grundlagen von HCP Terraform (ehemals Terraform Cloud) als managed Backend und Atlantis als selbstgehostete Alternative. Am Ende haben Sie ein Bild davon, wie Terraform-Workflows in echten Teams aussehen.

Alles zusammen: Sie bauen eine produktionsnahe Infrastruktur mit eigenen Modulen, Remote State Backend, Variablen für Umgebungstrennung und einer Test-Suite. Dazu schreiben Sie ein CI-Pipeline-Skeleton, das terraform plan automatisch ausführt. Das Ergebnis ist ein Terraform-Projekt, das Sie als Vorlage für Ihre eigene Arbeit mitnehmen.