Seminar OpenTofu – Module, State und produktiver Betrieb

Der Aufbaukurs behandelt die Probleme, die nach den ersten erfolgreichen Bereitstellungen auftreten: mehrere Teams, unterschiedliche Umgebungen, langlebige Ressourcen und steigende Anforderungen an Wiederherstellbarkeit. Modulgrenzen und State-Aufteilung werden anhand von Zuständigkeiten, Änderungsrhythmus und möglichen Fehlerfolgen entworfen. Eine bloße Vergrößerung eines einzigen Root-Moduls wird bewusst fachlich bewertet.

Die Übungen arbeiten mit bestehenden Ressourcen und gezielt vorbereiteten Störungen. State-Verschlüsselung, Backend-Zugriffe und Sicherungsstände werden gemeinsam betrachtet, weil ein vorhandenes Backup ohne passende Schlüssel oder konsistenten Ressourcenbestand keine verlässliche Wiederherstellung garantiert. Refactoring und Imports erfolgen mit Planvergleich und Abbruchkriterien. Vier Tage schaffen Raum für diese aufeinander aufbauenden Betriebsfälle.

Inhaltsübersicht

1. Modulverträge und Projektarchitektur
2. Backends, Locking und Zugriffsgrenzen
3. Verschlüsselung und Schlüsselwechsel
4. Bestandsübernahme und Refactoring
5. Tests, Abhängigkeiten und Updates
6. Drift, Teilfehler und Recovery

Seminarinhalte

Modulverträge und Projektarchitektur

• Modulgrenzen nach Verantwortung und Lebenszyklus festlegen; Eingaben und Ausgaben bewusst klein halten.
• Versionierte Module, Abhängigkeiten und kompatible Änderungen im Team organisieren.
• Separate Root-Module und Zustände gegenüber bloßer Workspace-Nutzung abwägen.

Backends, Locking und Zugriffsgrenzen

• Ein geeignetes Remote-Backend mit tatsächlich unterstützter Sperrfunktion konfigurieren.
• Zugriff auf State und das Ausführen von Änderungen getrennt berechtigen.
• Gleichzeitige Läufe, verwaiste Sperren und die Risiken eines erzwungenen Entsperrens im Labor untersuchen.

Verschlüsselung und Schlüsselwechsel

• State- und Planverschlüsselung mit einer geeigneten, festgelegten Methode konfigurieren.
• Vorhandenen unverschlüsselten Zustand kontrolliert umstellen und lesbare Sicherungen geschützt behandeln.
• Schlüsselrotation, Fallback und Wiederherstellung unter Erhalt benötigten Schlüsselmaterials erproben.

Bestandsübernahme und Refactoring

• Importierbare Bestandsressourcen mit ihrer vorgesehenen Adresse und tatsächlichen Konfiguration abgleichen.
• Ressourcenadressen mit unterstützten Verschiebungsmechanismen ändern und unbeabsichtigte Neuerstellung verhindern.
• Eine Übernahme in Etappen planen und jede Etappe mit einem erwarteten Änderungsplan absichern.

Tests, Abhängigkeiten und Updates

• Modulschnittstellen und kritische Planmerkmale mit passenden Tests prüfen.
• Providerupdates in einer isolierten Umgebung prüfen und Schemaänderungen berücksichtigen.
• Referenzen zwischen getrennten Zuständen auf notwendigen Datenumfang und Zugriffsfolgen untersuchen.

Drift, Teilfehler und Recovery

• Konfigurationsabweichungen und teilweise ausgeführte Änderungen anhand von API, Plan und State zusammenführen.
• Einen konsistenten Wiederanlauf planen; fehlende Zustandsdaten nicht durch unkontrolliertes Neuerstellen ersetzen.
• Ein Recovery-Verfahren mit Sicherung, Schlüsselzugriff und Ressourcenabgleich praktisch durchspielen.

Praxisübungen

1. Ein größeres Übungsprojekt in klar abgegrenzte Module und Zustände aufteilen. Die Zugriffsrechte trennen und nach der Umstrukturierung einen Plan ohne unerwartete Ressourcenersetzung nachweisen.
2. State-Verschlüsselung aktivieren, einen Schlüsselwechsel mit vorgesehenem Übergang konfigurieren und einen gesicherten Zustand in einer isolierten Umgebung wieder lesbar machen.
3. Einen Sperrkonflikt und einen partiellen Bereitstellungsfehler untersuchen. Reale Ressourcen und State abgleichen und einen kontrollierten Wiederanlauf mit dokumentierten Abbruchkriterien ausführen.

Technische Übungsumgebung

Vorbereitete Zielplattform mit bestehenden Testressourcen, geeignetes Remote-Backend mit Sperrfunktion, getrennte Zugänge und geschütztes Schlüsselmaterial.

Weiterführende Seminare

Passende fachliche Ergänzungen sind Infrastructure as Code – Tests und Policy as Code, Infrastructure as Code – CI/CD mit GitLab. Die jeweiligen Voraussetzungen bleiben maßgeblich.