Einführung in Terraform

Infrastructure as Code beschreibt Infrastruktur deklarativ in versionierbarer Konfiguration. Sie vergleichen Terraform mit Ansible, CloudFormation und Pulumi und ordnen Provisionierung, Konfigurationsmanagement sowie plattformspezifische Ansätze anhand typischer Einsatzgrenzen im Team ein. Die Gegenüberstellung umfasst OpenTofu und unterschiedliche Governance- sowie Lizenzmodelle, ohne daraus eine pauschale Produktempfehlung abzuleiten.

Eine Terraform-Konfiguration verbindet Blöcke, Argumente und Ausdrücke in HCL. Sie untersuchen resource- und data-Blöcke, Attribute sowie Referenzen und nutzen den Local Provider für einen überschaubaren Einstieg. Dabei durchlaufen Sie terraform init, plan und apply und verfolgen, welche Dateien und Zustände Terraform dabei erzeugt.

Provider übersetzen Konfiguration in API-Aufrufe für die jeweils angebundene Plattform. Sie definieren required_providers, setzen nachvollziehbare Versionsgrenzen und lesen die Dependency-Lock-Datei. Anschließend vergleichen Sie Plan und Apply als getrennte Schritte und behandeln einen Plan als Änderungsvorschau, die vor der tatsächlichen Ausführung erneut geprüft werden muss.

Eingabevariablen machen Konfigurationen anpassbar, benötigen aber klare Typen und Grenzen. Sie definieren skalare und strukturierte Typen, Defaults sowie Validierungsregeln und nutzen Outputs für ausgewählte Ergebnisse und klare Modulübergaben. Mit Locals bündeln Sie abgeleitete Werte und refaktorieren die bisherige Konfiguration, ohne ihre Schnittstellen unnötig zu vergrößern.

Das DevNinjas Dojo, unsere Cloud-Lernumgebung, verbindet Provider, Variablen und Referenzen an einem Cloud-Szenario. Sie modellieren eine VM, eine Security Group und eine öffentliche beziehungsweise elastische IP und nutzen Outputs für ausgewählte Verbindungsdaten. Die Terraform-Dokumentation und Plan-Ausgabe unterstützen die Arbeit, ersetzen aber keine fachliche Freigabe.

State ordnet konfigurierte Ressourcen ihren entfernten Objekten zu und kann sensible Daten enthalten. Sie konfigurieren ein S3-Backend, aktivieren Versionierung und stellen die aktuelle Lockfile-Sperre mit use_lockfile der veralteten DynamoDB-basierten Sperre gegenüber. Anschließend trennen Sie State nach Umgebungen und Komponenten und prüfen Zugriffsrechte, Wiederherstellung sowie die Grenzen dieser Isolation.

Bestehende Ressourcen, geänderte Adressen und bewusste Entkopplungen benötigen nachvollziehbare State-Operationen. Sie arbeiten mit import-, moved- und removed-Blöcken und prüfen deren Wirkung zunächst im Plan. Imperative Befehle wie terraform import und terraform state mv ordnen Sie als gezielte Werkzeuge ein, nicht als Standard für jede Änderung.

Module kapseln Ressourcen hinter definierten Eingaben und Ausgaben. Sie entwickeln ein eigenes Modul, trennen interne Logik von seiner öffentlichen Schnittstelle und binden einen Baustein aus der Terraform Registry ein. Versionsgrenzen und terraform-docs helfen anschließend, Abhängigkeiten und Dokumentation nachvollziehbar zu halten, ersetzen aber keine Kompatibilitätsprüfung.

Größere Konfigurationen benötigen erkennbare Zuständigkeiten statt nur weitere Dateien. Sie ordnen main.tf, variables.tf, outputs.tf und providers.tf, wenden Module zur Wiederverwendung an und erproben CLI Workspaces. Dabei grenzen Sie Workspaces von getrennten Backends, Berechtigungen und Zugangsdaten für komplexere Deployments ab und betrachten Terragrunt als möglichen Orchestrierungsansatz.

Ein zusammenhängendes Szenario verbindet Modulgrenzen, Remote State und Netzwerkkonzepte. Sie entwerfen eine VPC mit öffentlichen und privaten Subnetzen, Security Groups sowie einer VM im privaten Netz und verteilen Verantwortlichkeiten auf Module. In der Lernumgebung prüfen Sie Schnittstellen, Versionen und Abhängigkeiten, ohne eine übertragbare Referenzarchitektur vorwegzunehmen.

Expressions steuern, wie Terraform Werte ableitet und wiederholte Ressourcen beschreibt. Sie vergleichen for_each und count, erzeugen verschachtelte Blöcke dynamisch und formulieren bedingte Ausdrücke. Mit lookup, merge, flatten und templatefile bearbeiten Sie unterschiedliche Datenstrukturen und diskutieren, wann zusätzliche Dynamik eine Konfiguration verständlicher oder schwerer wartbar macht.

Terraform-Tests beschreiben Ausführungen und Assertions in .tftest.hcl-Dateien. Dabei vergleichen Sie Plan- und Apply-Läufe und nutzen ab Terraform 1.7 Provider-Mocking für geeignete Modultests. terraform validate und TFLint ergänzen diese Tests um Syntax-, Schema- und statische Prüfungen, decken jedoch nicht jede Laufzeitwirkung ab.

Als sensitive markierte Werte werden in Ausgaben verdeckt, können aber weiterhin im State stehen. Sie prüfen die ab Terraform 1.10 verfügbaren Ephemeral Values und Ephemeral Resources sowie die ab 1.11 verfügbaren Write-only-Argumente und berücksichtigen, welche Typen beziehungsweise Argumente der jeweilige Provider unterstützt. Ergänzend setzen Sie Checkov und Trivy für Konfigurations-Scans ein und ordnen Befunde als Prüfsignale statt automatische Freigaben ein.

CI kann wiederholbare Prüfungen bereitstellen, benötigt aber bewusste Berechtigungs- und Freigabegrenzen. Sie skizzieren einen Ablauf mit GitLab CI oder GitHub Actions, veröffentlichen Plan-Ausgaben für Reviews und trennen freigegebene Apply-Schritte. HCP Terraform und Atlantis dienen als Vergleichspunkte für Ausführung, State und Zusammenarbeit, nicht als pauschale Zielarchitektur.

Zum Abschluss verbinden Sie Module, Remote State, Umgebungsvariablen, Tests und einen CI-gestützten Plan in einem gemeinsamen Szenario. Sie ordnen den Ablauf von Provider, Plan und Pipeline ein und prüfen, welche Entscheidungen projektspezifisch bleiben. Die Übung dient der Übertragung der Konzepte und ist kein produktionsfertiges System oder verbindliches Betriebsmodell.