
Infrastructure as Code: Cloud-Ressourcen mit Terraform verwalten
Was Infrastructure as Code mit Terraform oder OpenTofu bringt, wie State, Module und Pipelines zusammenspielen und welche Fehler Sie früh vermeiden sollten.
Kurz gefasst: Infrastructure as Code bedeutet, dass Server, Datenbanken, Netzwerke und DNS-Einträge als Code beschrieben und versioniert werden, statt sie in einer Weboberfläche zusammenzuklicken. Mit Terraform oder dem quelloffenen Ableger OpenTofu wird Ihre Cloud-Umgebung dadurch reproduzierbar, nachvollziehbar und prüfbar. Der Aufwand lohnt sich, sobald mehr als eine Umgebung existiert oder mehr als eine Person an der Infrastruktur arbeitet.
Das Problem mit geklickter Infrastruktur
Viele Projekte starten mit einem Server, der in der Konsole des Hosters angelegt wurde. Später kommen eine Datenbank, ein Load Balancer, ein paar Firewall-Regeln und eine Staging-Umgebung hinzu. Nach einem Jahr weiß niemand mehr genau, welche Einstellung warum gesetzt wurde, und Staging unterscheidet sich auf unklare Weise von Produktion.
Infrastructure as Code löst das, indem der gewünschte Zustand in Dateien steht. Änderungen laufen über Git, werden im Pull Request geprüft und sind jederzeit nachvollziehbar. Eine neue Umgebung entsteht aus demselben Code, statt aus dem Gedächtnis eines Kollegen.
Wie Terraform funktioniert
Deklarativ beschreiben
In Terraform beschreiben Sie in der Sprache HCL, was existieren soll: drei Server dieser Größe, eine verwaltete PostgreSQL-Datenbank, diese DNS-Einträge. Wie die Ressourcen angelegt werden, übernimmt Terraform über sogenannte Provider. Provider gibt es für die großen Clouds ebenso wie für Hetzner, IONOS, Cloudflare, GitHub und viele weitere Dienste.
Plan und Apply
Der Befehl terraform plan vergleicht den Code mit der Realität und zeigt, was sich ändern würde. Erst terraform apply setzt die Änderungen um. Dieser Zwischenschritt ist der eigentliche Sicherheitsgewinn: Sie sehen vorher, dass eine Änderung die Datenbank neu anlegen würde, und können eingreifen.
Der State
Terraform merkt sich in einer State-Datei, welche realen Ressourcen zu welchem Code gehören. Diese Datei ist kritisch. Sie gehört in einen entfernten Speicher mit Sperrmechanismus, etwa einen S3-kompatiblen Bucket oder Terraform Cloud, damit nicht zwei Personen gleichzeitig Änderungen ausführen. Da der State Passwörter und andere Geheimnisse im Klartext enthalten kann, muss er verschlüsselt und zugriffsbeschränkt gespeichert werden.
Terraform oder OpenTofu?
HashiCorp hat die Lizenz von Terraform 2023 auf die Business Source License umgestellt. Daraufhin entstand OpenTofu als quelloffener Fork unter dem Dach der Linux Foundation. Beide sind weitgehend kompatibel und nutzen dieselben Provider. Für die meisten Unternehmen, die ihre eigene Infrastruktur verwalten, ist die Lizenzänderung praktisch ohne Folgen. Wer Wert auf eine offene Lizenz legt oder ein Produkt auf Basis des Werkzeugs anbietet, greift zu OpenTofu. Alternativen wie Pulumi erlauben Infrastruktur in TypeScript oder Python, was Teams ohne HCL-Erfahrung entgegenkommen kann.
Praxisregeln für ein sauberes Setup
Module für Wiederholungen
Wiederkehrende Bausteine, etwa ein Webserver mit Firewall und Monitoring, werden als Modul gekapselt. Staging und Produktion nutzen dasselbe Modul mit anderen Parametern. So bleiben die Umgebungen strukturell gleich.
Änderungen nur über die Pipeline
Wenn jeder lokal apply ausführen darf, entsteht schnell Wildwuchs. Besser: Der Plan wird im Pull Request automatisch erzeugt und kommentiert, angewendet wird nach dem Merge durch die Pipeline. Wie das in eine Deployment-Pipeline passt, beschreiben wir im Beitrag zu CI/CD-Pipelines für Webanwendungen.
Drift erkennen
Manuelle Änderungen in der Konsole führen dazu, dass Code und Realität auseinanderlaufen. Ein regelmäßiger, automatischer plan zeigt solche Abweichungen, bevor sie bei der nächsten Änderung überraschen.
Standort und Kosten im Code festhalten
Region und Rechenzentrum stehen explizit im Code. Das macht prüfbar, dass personenbezogene Daten in der EU bleiben, ein Thema, das wir im Beitrag zu Datenhosting in Deutschland vertiefen. Einheitliche Tags pro Ressource helfen außerdem bei der Kostenkontrolle, wie in unseren Strategien zur Kostenoptimierung in der Cloud beschrieben.
Häufige Fragen (FAQ)
Lohnt sich Terraform auch für kleine Projekte?
Ab dem Moment, in dem es eine zweite Umgebung oder eine zweite Person gibt, meistens ja. Für einen einzelnen Server ohne Staging ist der Nutzen kleiner, aber schon die Dokumentation durch Code ist oft den geringen Aufwand wert.
Können wir bestehende Infrastruktur nachträglich mit Terraform verwalten?
Ja. Mit import-Blöcken übernehmen Sie vorhandene Ressourcen in den State. Das erfordert etwas Sorgfalt, weil der Code danach exakt zur Realität passen muss, ist aber gut machbar und ein häufiger Einstieg.
Was passiert, wenn die State-Datei verloren geht?
Die Ressourcen laufen weiter, aber Terraform weiß nicht mehr, was es verwaltet. Sie müssten alles neu importieren. Deshalb gehört der State in einen versionierten, gesicherten Remote-Speicher.
Ersetzt Terraform Werkzeuge wie Ansible oder Docker?
Nein, sie ergänzen sich. Terraform legt Infrastruktur an, Docker verpackt Ihre Anwendung, und Werkzeuge wie Ansible konfigurieren bei Bedarf Software auf Servern. In vielen modernen Setups reicht die Kombination aus Terraform und Containern.
Fazit
Infrastructure as Code verwandelt Wissen in Köpfen in überprüfbaren Code, und genau das macht Infrastruktur übergabefähig und sicher änderbar. Der Einstieg gelingt am besten mit einer Umgebung, einem Remote State und einer Pipeline, die jeden Plan sichtbar macht. Wenn Sie eine Webanwendung mit sauber verwalteter Infrastruktur aufbauen möchten, sprechen Sie mit uns über Webentwicklung.
Ähnliche Beiträge
- SaaS-Architektur: Entscheidungen, die Sie kaum rückgängig machen
Mandantenfähigkeit, Datenmodell, Authentifizierung, Hosting: Welche Entscheidungen eine SaaS-Architektur prägen und wie Sie sie früh richtig treffen.
- Microservices oder Monolith: die richtige SaaS-Architektur
Microservices oder Monolith für Ihr SaaS-Produkt? Warum ein modularer Monolith meist der bessere Start ist und wann sich das Aufteilen wirklich lohnt.
- CI/CD-Pipeline für Webanwendungen: Praxisleitfaden
So richten Sie eine CI/CD-Pipeline für Ihre Webanwendung ein: Build, Tests, Preview-Umgebungen, Deployment und Rollback. Mit Werkzeugen und typischen Stolpersteinen.
- Serverless-Architektur: Wann sie sich lohnt und wann nicht
Wann Serverless mit AWS Lambda und Co. Kosten spart, wo Kaltstarts, Laufzeitgrenzen und Lock-in Probleme machen und welche Alternativen es gibt.