Der Zustand ist das erste Problem
Terraform merkt sich im State, welche realen Ressourcen zu welchem Code gehören. Bei ersten lokalen Versuchen liegt diese Datei häufig auf dem eigenen Rechner. Im Team benötigen alle Läufe Zugriff auf den richtigen Zustand; unkoordinierte gleichzeitige Schreibzugriffe können ihn beschädigen.
Die Antwort ist Remote State: Der Zustand liegt in einem gemeinsamen Backend, etwa Azure Blob Storage oder S3. Dazu gehört ein Backend mit unterstütztem und aktiviertem State-Locking. Beim S3-Backend muss Locking ausdrücklich eingeschaltet werden. Versionierung hilft zusätzlich, versehentlich gelöschten oder beschädigten State wiederherzustellen. Für Terraform und OpenTofu gelten diese Grundsätze; die Einstellungen hängen vom jeweiligen Backend und der Version ab.
State kann sensible Attributwerte enthalten, etwa Datenbankpasswörter oder API-Tokens. Zugriff, Verschlüsselung und Protokollierung des Backends gehören deshalb in den Sicherheitsentwurf. State-Dateien und Plan-Artefakte gehören nicht ins Git-Repository oder in öffentlich lesbare Pipeline-Ausgaben.
Ein Zustand pro Umgebung, nicht einer für alles
Ein einziger State für die ganze Organisation koppelt viele Änderungen und vergrößert die möglichen Auswirkungen eines Fehlers. Sein Zugriff kann auch sensible Produktionsdaten offenlegen. Die Berechtigungen auf den State und die Berechtigungen zum Ändern der Cloud-Ressourcen müssen getrennt abgesichert werden.
Eine sinnvolle Trennung folgt Umgebungen und Verantwortlichkeiten. Entwicklung, Test und Produktion erhalten getrennte Zustände mit passenden Zugriffsrechten. Reguläre Schreibrechte auf Produktions-State und Ressourcen liegen bei der Produktions-Pipeline; Notfallzugänge sind gesondert geregelt. Weitere Zustände etwa für Netzwerk, Cluster und Anwendungen halten Änderungen überschaubar. Gemeinsame Werte sollten gezielt veröffentlicht werden: Die Datenquelle terraform_remote_state benötigt Zugriff auf den gesamten State-Snapshot, auch wenn nur Outputs gelesen werden.
Terraform-CLI-Workspaces trennen zwar ebenfalls Zustände, aber innerhalb derselben Konfiguration und desselben Backends. Für Umgebungen mit unterschiedlichen Zugriffsrechten ist die Trennung über eigene Backends die robustere Wahl.
Module: Git-Quellen oder Registry
Module sind die Einheit, in der sich Wiederholung auszahlt: ein geprüftes Muster für ein VNet, einen Cluster, eine Datenbank, das alle Teams verwenden, statt es je einmal selbst zu erfinden.
Für die Verteilung gibt es zwei gängige Wege. Git-Quellen sind der
einfache Einstieg: Das Modul liegt in einem eigenen Repository, die
Konsumenten referenzieren es über die Quelle und pinnen mit dem
ref-Parameter ein Tag. Wichtig ist genau dieses Pinnen:
Ohne ref zieht Terraform den Standard-Branch, und der
bewegt sich.
Eine interne Registry lohnt sich, sobald mehrere Teams dieselben Module nutzen. Sie bringt Versionsbedingungen statt fester Tags, eine durchsuchbare Übersicht und Dokumentation am Modul. Der Preis ist ein weiteres Stück Infrastruktur, das jemand betreiben muss. Für ein einzelnes Plattformteam sind getaggte Git-Quellen meist genug, für eine Organisation mit vielen Konsumenten kippt die Rechnung.
In beiden Fällen gilt: Module werden wie Software versioniert. Jede Änderung wird getaggt, Konsumenten aktualisieren bewusst, und eine Änderung, die bestehende Aufrufe bricht, bekommt eine neue Hauptversion und einen Hinweis im Änderungsprotokoll.
Review: der Plan gehört in den Merge Request
Ein Code-Review allein reicht bei Terraform nicht. Der Diff zeigt die
Absicht, der Plan zeigt die Wirkung, und die beiden können weit
auseinanderliegen: Eine unscheinbare Änderung an einem Argument kann
ein replace auslösen, das eine Datenbank neu erzeugt.
Die Pipeline erzeugt für jeden Merge Request einen Plan für das Review. Geprüft werden Code und geplante Ressourcenänderungen. Nach dem Merge wendet die Pipeline den freigegebenen, gespeicherten Plan an. Muss wegen Änderungen am Code oder an der Umgebung ein neuer Plan entstehen, wird dieser erneut geprüft. Plan-Artefakte bleiben unter Zugriffsschutz, weil sie sensible Werte enthalten können.
Damit das Review leistbar bleibt, sollten Änderungen klein geschnitten sein: ein Merge Request pro Anliegen. Je mehr Ressourcen ein Plan betrifft, desto schwerer lassen sich Wechselwirkungen beurteilen. Das ist auch ein Grund, Zustände nach Verantwortlichkeiten und Lebenszyklen zu trennen.
Auf dem Plan setzen auch die Policy-Checks auf: Regeln wie erlaubte Regionen, Pflicht-Tags oder verbotene öffentliche IP-Adressen lassen sich mit Werkzeugen wie Open Policy Agent gegen die maschinenlesbare Plan-Ausgabe prüfen, bevor ein Mensch das Review beginnt. Was die Maschine ablehnen kann, muss der Reviewer nicht suchen. Das ist dieselbe Logik wie bei Azure Policy in der Landing Zone, nur eine Stufe früher im Prozess.
Drift: wenn die Realität abweicht
Drift entsteht, wenn jemand Ressourcen am Code vorbei ändert, etwa schnell im Portal während eines Vorfalls. Der Zustand passt dann weder zur Realität noch zum Code, und der nächste Apply kann Änderungen zurückdrehen oder Ressourcen ersetzen, mit denen niemand gerechnet hat.
Ein terraform plan -refresh-only zeigt Änderungen an den verwalteten Ressourcen und Outputs, ohne diese anzuwenden. Ein regelmäßiger Lauf mit Benachrichtigung kann so Drift sichtbar machen. Nicht verwaltete Ressourcen und nicht erfasste Eigenschaften deckt er nicht vollständig ab. Ist eine Abweichung beabsichtigt, werden Code und State kontrolliert abgeglichen; andernfalls wird die Korrektur mit einem normalen Plan geprüft und anschließend angewendet.
Der wirksamste Hebel gegen Drift ist allerdings organisatorisch: Wenn Schreibrechte in der Produktion bei der Pipeline liegen und nicht bei Menschen, gibt es schlicht weniger Wege, an Terraform vorbei zu arbeiten. Notfallzugänge bleiben möglich, aber sie sind dann die dokumentierte Ausnahme statt des Alltags.
Terraform im Team ist weniger ein Werkzeugthema als ein Prozessthema: ein Remote State mit Locking, getrennt pro Umgebung und Baustein, Module mit gepinnten Versionen und ein Plan, den jemand liest, bevor die Pipeline ihn anwendet. Wer diese drei Dinge früh festlegt, hat eine Infrastruktur, die auch nach dem nächsten Teamwechsel noch nachvollziehbar ist.
Was Sie danach entscheiden können
- Wo Ihr State liegt, wie er gesperrt und gesichert wird und wie reguläre sowie Notfallzugriffe geregelt sind.
- Ob getaggte Git-Quellen für Ihre Module reichen oder ob sich eine interne Registry lohnt.
- Wie ein Merge Request bei Ihnen aussehen muss, damit Plan, Review und Apply nachvollziehbar bleiben.
Häufige Fragen
Reichen Terraform-CLI-Workspaces für die Trennung unserer Umgebungen?
Für Umgebungen mit unterschiedlichen Zugriffsrechten nicht. CLI-Workspaces trennen Zustände innerhalb derselben Konfiguration und desselben Backends. Entwicklung und Produktion gehören in eigene Backends mit eigenen Rechten.
Gilt das alles auch für OpenTofu?
Die Grundsätze gelten auch für OpenTofu: gemeinsamer State, aktives Locking, versionierte Module und ein freigegebener Plan. Backend-Einstellungen, Provider-Kompatibilität und verfügbare Funktionen müssen für die eingesetzten Versionen geprüft werden.
Dürfen Entwickler gar nicht mehr lokal arbeiten?
Doch, Entwickler können mit passenden Rechten lokal gegen die Entwicklungsumgebung planen. Reguläre Produktionsänderungen laufen aus der Pipeline mit einem freigegebenen Plan. Notfallzugriffe bleiben möglich, müssen aber dokumentiert und anschließend mit dem Code abgeglichen werden.
Quellen
- Remote State HashiCorp, Terraform-Dokumentation
- Use modules in your configuration (Modulquellen und Versionen) HashiCorp, Terraform-Dokumentation
- Manage resource drift HashiCorp, Terraform-Tutorial
- Remote State (OpenTofu) OpenTofu-Dokumentation
- S3 backend: locking and versioning HashiCorp, Terraform documentation
- Plan and saved plans HashiCorp, Terraform documentation
- Protect sensitive data HashiCorp, Terraform documentation
- Sharing data between configurations HashiCorp, Terraform documentation