Wenn Terraform vom Laptop nicht mehr ausreicht

Bisher hast du deine Infrastruktur mit Terraform von deinem Terminal aus verwaltet. Das funktioniert gut, solange du der Einzige bist, der Änderungen vornimmt. Du führst terraform plan aus, prüfst die Ausgabe, führst terraform apply aus und machst weiter. Die State-Datei liegt auf deinem Rechner, und du weißt genau, was du wann geändert hast.

Dann kommt ein Kollege zum Projekt dazu. Er klont das Repository, führt terraform init aus und erhält einen anderen Plan als du gestern gesehen hast. Die State-Datei auf seinem Laptop ist veraltet. Jemand wendet eine Änderung an, ohne jemanden zu informieren. Eine Woche später kann sich niemand mehr daran erinnern, wer die Security-Group-Regeln geändert hat oder warum.

Das ist der Moment, an dem der Laptop-basierte Workflow zerbricht. Die Probleme liegen nicht an Terraform selbst. Sie betreffen Koordination, Transparenz und Nachvollziehbarkeit. Wenn Infrastruktur gemeinsam genutzt wird, führen Befehle von einzelnen Rechnern zu Verwirrung, Risiken und stiller Drift.

Den Workflow in eine Pipeline verlagern

Anstatt terraform plan und terraform apply von jedem Laptop aus auszuführen, kannst du diesen Workflow in eine CI/CD-Pipeline verlagern. Jede Infrastrukturänderung durchläuft dann denselben Pfad, wird aufgezeichnet und kann vom Team überprüft werden, bevor sie wirksam wird.

Der Pipeline-Ansatz macht Infrastrukturänderungen ähnlich wie Code-Änderungen. Du schreibst die Konfiguration, eröffnest einen Pull Request, erhältst Feedback, und erst nach der Freigabe wird die Änderung angewendet. Der Unterschied ist, dass Terraform einen Planungsschritt hinzufügt, der genau zeigt, was mit deinen Cloud-Ressourcen passieren wird, bevor etwas ausgeführt wird.

Das folgende Beispiel zeigt eine generische CI-Pipeline-Konfiguration, die den Write-Plan-Apply-Workflow umsetzt:

stages:
  - validate
  - plan
  - apply

validate:
  stage: validate
  script:
    - terraform fmt -check
    - terraform validate
  only:
    - merge_requests

plan:
  stage: plan
  script:
    - terraform plan -out=plan.tfplan
  artifacts:
    paths:
      - plan.tfplan
  only:
    - merge_requests

apply:
  stage: apply
  script:
    - terraform apply plan.tfplan
  when: manual
  only:
    - main

Die drei Phasen: Write, Plan, Apply

Der gängigste Weg, Terraform in eine Pipeline zu integrieren, besteht darin, den Workflow in drei Phasen zu unterteilen, die dem natürlichen Ablauf einer Änderung entsprechen.

Das folgende Sequenzdiagramm zeigt, wie die drei Phasen interagieren:

Write: Probleme vor dem Review erkennen

Die Write-Phase beginnt, wenn jemand Terraform-Konfigurationsdateien ändert und einen Pull Request eröffnet. An diesem Punkt kann die Pipeline automatisch grundlegende Prüfungen durchführen. terraform fmt stellt sicher, dass der Code der Standard-Formatierung entspricht. terraform validate prüft, ob die Konfiguration syntaktisch korrekt ist und alle erforderlichen Argumente vorhanden sind.

Diese Prüfungen sind das Infrastruktur-Äquivalent zum Ausführen eines Linters für Anwendungscode. Sie fangen einfache Fehler frühzeitig ab, bevor ein menschlicher Reviewer Zeit damit verbringt, den Pull Request zu begutachten. Wenn die Formatierung falsch ist oder ein Pflichtfeld fehlt, schlägt die Pipeline sofort fehl, und der Autor behebt es, bevor sich jemand anderes damit befasst.

Plan: Zeigen, was sich ändern wird

Nachdem der Pull Request geöffnet ist, führt die Pipeline automatisch terraform plan aus. Die Ausgabe des Plans wird dann als Kommentar im Pull Request veröffentlicht. Hier wird das Review aussagekräftig.

Die Plan-Ausgabe zeigt genau, was Terraform tun wird: welche Ressourcen erstellt, welche geändert und welche gelöscht werden. Ein Reviewer kann sehen, dass ein Pull Request den Server-Instanztyp von klein auf mittel ändert, eine neue Firewall-Regel hinzufügt oder eine alte Datenbank-Subnetz-Gruppe löscht. Wenn etwas falsch aussieht, lehnt der Reviewer den Pull Request ab, bevor eine Änderung die Produktion erreicht.

Diese Phase ist entscheidend, weil sie das Infrastruktur-Review von „Vertrau mir, ich habe den Plan ausgeführt“ zu „Hier ist der Plan, überprüfe ihn selbst“ verschiebt. Der Plan wird Teil der Pull-Request-Konversation, und die Entscheidung zur Genehmigung oder Ablehnung basiert auf konkreten Ergebnissen, nicht auf Vertrauen.

Apply: Nur nach Freigabe ausführen

Die Apply-Phase läuft erst, nachdem der Pull Request genehmigt und in den Hauptzweig gemergt wurde. Die Pipeline im Hauptzweig führt dann terraform apply mit dem bereits überprüften Plan aus.

Der sicherste Weg, dies zu tun, ist, die Plan-Ausgabe aus der vorherigen Phase als Datei zu speichern und diese Datei an terraform apply zu übergeben. Diese Technik wird als gespeicherter Plan bezeichnet. Sie garantiert, dass das Apply genau dieselben Änderungen ausführt, die überprüft wurden, und nicht einen neuen Plan, der abweichen könnte, weil jemand zwischen Review und Apply einen weiteren Commit gepusht hat.

Ohne einen gespeicherten Plan würde die Pipeline während der Apply-Phase erneut terraform plan ausführen. Wenn sich die Konfiguration in der Zwischenzeit geändert hat, könnte der neue Plan von dem unterscheiden, was überprüft wurde. Das würde den Zweck eines Reviews zunichtemachen.

State-Management in einer Pipeline

Das State-Management wird unkompliziert, wenn Terraform in einer Pipeline läuft. Die State-Datei muss an einem gemeinsamen Ort gespeichert werden, z. B. in einem Cloud-Storage-Bucket oder einem Terraform-Backend, das das Team einmal konfiguriert. Jedes Mal, wenn die Pipeline Plan oder Apply ausführt, ruft sie den State von diesem gemeinsamen Ort ab, nicht von einer lokalen Kopie, die veraltet sein könnte.

Die Pipeline sollte auch State-Locking aktivieren. Terraform kann die State-Datei sperren, während ein Plan oder Apply läuft, und so verhindern, dass zwei Prozesse gleichzeitig den State ändern. Ohne Locking könnten zwei Pipelines gleichzeitig Apply ausführen, was zu Korruption oder unerwarteten Ergebnissen führen würde.

Was dieser Workflow dir bringt

Sobald der Write-Plan-Apply-Workflow in einer Pipeline läuft, folgen Infrastrukturänderungen derselben Disziplin wie Code-Änderungen. Jede Änderung durchläuft einen Pull Request, wird von Teammitgliedern überprüft, mit einem automatisierten Plan getestet und läuft erst nach Freigabe. Die gesamte Historie der Änderungen wird in Git und in den Pipeline-Logs aufgezeichnet.

Du fragst dich nicht mehr, wer einen Server geändert hat oder wann das passiert ist. Du machst dir keine Sorgen mehr über veraltete State-Dateien auf dem Laptop eines Kollegen. Du hörst nicht mehr „bei mir läuft es“ in Bezug auf die Infrastruktur.

Praxis-Checkliste für die Einrichtung

• Konfiguriere ein Remote-Backend für die State-Speicherung, bevor du die Pipeline einrichtest. Das Backend muss für den Pipeline-Runner erreichbar sein.
• Richte State-Locking ein. Die meisten Backends wie S3 mit DynamoDB oder GCS mit Objektversionierung unterstützen dies nativ.
• Füge terraform fmt und terraform validate als frühe Prüfungen in der Pull-Request-Pipeline hinzu.
• Führe terraform plan bei jedem Pull Request aus und veröffentliche die Ausgabe als Kommentar.
• Verwende gespeicherte Pläne. Speichere die Plan-Datei als Pipeline-Artefakt und übergib sie an die Apply-Phase.
• Beschränke terraform apply so, dass es nur im Hauptzweig nach einem Merge ausgeführt wird.
• Stelle sicher, dass der Pipeline-Runner die minimal erforderlichen Berechtigungen hat, um Plan und Apply auszuführen. Verwende keine Admin-Anmeldedaten.

Was als Nächstes kommt

Nachdem die Pipeline den Write-Plan-Apply-Workflow automatisch handhabt, stellt sich die nächste Frage: Wie verwaltet man verschiedene Umgebungen? Staging und Produktion verwenden selten dieselben Konfigurationswerte. Die Pipeline muss umgebungsspezifische Variablen, State-Dateien und Freigabeschwellen verarbeiten, ohne den gesamten Workflow für jede Umgebung zu duplizieren.

Aber das ist ein Problem für später. Der wichtige Schritt ist jetzt, Terraform nicht mehr von Laptops aus auszuführen und Infrastrukturänderungen wie Code-Änderungen zu behandeln. Die Pipeline liefert eine einzige Quelle der Wahrheit dafür, was geändert wurde, wer es genehmigt hat und wann es angewendet wurde. Das allein beseitigt den Großteil der Verwirrung, die mit gemeinsam genutzter Infrastruktur einhergeht.