Wenn Terraform Apply tatsächlich ausgeführt wird: Was passiert, nachdem Sie den Plan genehmigt haben

Sie haben die Planausgabe geprüft. Sie haben bestätigt, dass Terraform zwei EC2-Instanzen erstellt, die bestehende Datenbank nicht löscht und die richtige Sicherheitsgruppe zuweist. Jetzt geben Sie terraform apply ein und drücken die Eingabetaste. Das Terminal scrollt mit Meldungen wie aws_instance.app_server: Creating... und Sie warten.

Dieser Moment ist der Punkt, an dem Infrastructure-as-Code aufhört, eine Konfigurationsdatei zu sein, und zu echter Infrastruktur wird. Server werden hochgefahren. Netzwerke werden konfiguriert. DNS-Einträge werden erstellt. Aber was genau passiert während terraform apply, und wie stellen Sie sicher, dass dieser Schritt keine Probleme verursacht?

Warum Sie eine gespeicherte Plan-Datei verwenden sollten

Der sicherste Weg, terraform apply auszuführen, ist die Übergabe einer zuvor erstellten Plan-Datei. Nachdem Sie terraform plan -out=plan.tfplan ausgeführt haben, können Sie terraform apply plan.tfplan ausführen. Dies garantiert, dass Terraform genau das anwendet, was Sie geprüft haben, nicht mehr und nicht weniger.

Hier ist die genaue Befehlssequenz zum Erstellen und Anwenden einer gespeicherten Plan-Datei:

terraform plan -out=plan.tfplan
terraform apply plan.tfplan

Das Risiko, terraform apply ohne eine Plan-Datei auszuführen, ist subtil, aber real. Zwischen dem Zeitpunkt, an dem Sie terraform plan und terraform apply ausführen, könnte ein Teammitglied eine Änderung an derselben Konfiguration zusammenführen. Oder Sie ändern unbeabsichtigt eine Variablendatei. Wenn Sie terraform apply ohne gespeicherten Plan ausführen, führt Terraform den Plan mit der aktuell vorhandenen Konfiguration erneut aus. Die Ausgabe könnte sich von dem unterscheiden, was Sie vor zehn Minuten geprüft haben.

Verwenden Sie für Produktionsumgebungen immer eine gespeicherte Plan-Datei. Sie schafft eine Prüfspur: Sie können auf plan.tfplan verweisen und sagen „das ist genau das, was genehmigt wurde“. Für Staging- oder Entwicklungsumgebungen, in denen Änderungen klein und häufig sind, mag die Bequemlichkeit, terraform apply ohne Plan-Datei auszuführen, akzeptabel sein. Seien Sie sich jedoch des Kompromisses bewusst.

Was während des Apply-Prozesses passiert

Wenn terraform apply ausgeführt wird, wendet es nicht einfach „die Konfiguration an“. Es kommuniziert für jede Ressource, die geändert werden muss, mit der API des Providers. Wenn Sie eine aws_instance erstellen, ruft Terraform die AWS-EC2-API auf, um eine Instanz zu starten. Wenn Sie einen google_storage_bucket aktualisieren, wird die Google-Cloud-Storage-API aufgerufen.

Jeder API-Aufruf kann zwischen Millisekunden und mehreren Minuten dauern. Das Erstellen einer virtuellen Maschine dauert typischerweise 30 Sekunden bis einige Minuten. Die Bereitstellung eines verwalteten Kubernetes-Clusters kann 10-15 Minuten dauern. Terraform zeigt den Fortschritt im Terminal an, liefert aber keine Fortschrittsanzeige für einzelne Ressourcen. Sie sehen Meldungen wie:

Das folgende Flussdiagramm fasst den Apply-Ablauf und die Verzweigungen bei Erfolg oder Fehler zusammen:

flowchart TD A[Start terraform apply] --> B[Plan-Datei lesen oder neu planen] B --> C[State-Lock erwerben] C --> D[Für jede Ressource: Provider-API aufrufen] D --> E{Alle Ressourcen erstellt/aktualisiert?} E -- Ja --> F[Vollständigen State in State-Datei schreiben] F --> G[State-Lock freigeben] G --> H[Apply erfolgreich] E -- Nein --> I[Teilweise State für erstellte Ressourcen gespeichert] I --> J[State-Lock freigeben] J --> K[Manuelles Eingreifen erforderlich] K --> L[Problem beheben und erneut anwenden] K --> M[Manuell zerstören oder terraform destroy verwenden] 
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]

Während dieser Zeit hält Terraform den State-Lock. Niemand anderes in Ihrem Team kann terraform apply oder terraform plan ausführen, bis der aktuelle Vorgang abgeschlossen ist oder ein Timeout auftritt. Dies ist beabsichtigt: Es verhindert, dass zwei Personen gleichzeitig dieselbe Infrastruktur ändern.

Was passiert, wenn Apply erfolgreich ist

Nachdem alle Ressourcen erfolgreich erstellt oder aktualisiert wurden, schreibt Terraform den aktuellen Zustand in die State-Datei. Diese State-Datei zeichnet jede Ressource mit ihrer eindeutigen ID, allen Attributen und den Beziehungen zwischen den Ressourcen auf. Wenn Sie beispielsweise eine EC2-Instanz erstellt und eine Sicherheitsgruppe zugewiesen haben, weiß die State-Datei, dass aws_instance.app_server mit aws_security_group.web_sg verknüpft ist.

Diese State-Datei wird zur einzigen Quelle der Wahrheit für Ihre Infrastruktur. Wenn Sie das nächste Mal terraform plan ausführen, vergleicht Terraform Ihre Konfiguration mit der State-Datei, nicht mit den Live-Cloud-Ressourcen. Deshalb verursachen beschädigte oder fehlende State-Dateien so viele Probleme: Terraform verliert seinen Referenzpunkt.

Was passiert, wenn Apply fehlschlägt

Apply-Fehler sind häufig genug, dass Sie wissen sollten, wie Sie damit umgehen. Die Erstellung einer Ressource kann fehlschlagen, weil:

  • Sie ein Kontingentlimit erreicht haben (z. B. zu viele EC2-Instanzen in einer Region)
  • Die Provider-Anmeldeinformationen abgelaufen oder ungültig sind
  • Ein Konflikt mit einer vorhandenen Ressource besteht (z. B. beim Versuch, einen bereits existierenden DNS-Eintrag zu erstellen)
  • Der Cloud-Provider einen Ausfall oder Drosselung hat

Wenn ein Fehler auftritt, führt Terraform kein vollständiges Rollback durch. Es markiert die fehlgeschlagenen Ressourcen und speichert den State für die erfolgreich erstellten Ressourcen. Dies bedeutet, dass Sie in einem teilweisen Zustand enden: Einige Ressourcen existieren, andere nicht. Terraform bereinigt nicht automatisch die Ressourcen, die vor dem Fehler erstellt wurden.

Wenn Sie beispielsweise fünf Ressourcen erstellen und die vierte fehlschlägt, existieren die ersten drei Ressourcen weiterhin in Ihrem Cloud-Konto. Die State-Datei zeichnet diese drei als erstellt auf. Sie müssen entscheiden, wie Sie fortfahren:

  • Beheben Sie das Problem (z. B. eine Kontingenterhöhung beantragen) und führen Sie terraform apply erneut aus. Terraform wird versuchen, die verbleibenden Ressourcen zu erstellen.
  • Zerstören Sie die erstellten Ressourcen manuell und beginnen Sie von vorne.
  • Verwenden Sie terraform destroy, um alles zu bereinigen, aber nur, wenn Sie sicher sind, dass Sie alle Ressourcen entfernen möchten.

Dieses Verhalten des teilweisen Zustands ist einer der Gründe, warum Sie Infrastrukturänderungen zuerst in einer Nicht-Produktionsumgebung testen sollten. Ein fehlgeschlagener Apply in der Produktion kann Ihre Infrastruktur in einem inkonsistenten Zustand hinterlassen, der manuelles Eingreifen erfordert.

Praktische Checkliste vor dem Ausführen von Apply

Bevor Sie terraform apply in einer Umgebung ausführen, die wichtig ist, gehen Sie diese Prüfpunkte durch:

  • Haben Sie die Planausgabe auf unerwartete Änderungen, insbesondere Löschungen, überprüft?
  • Ist die State-Datei gesichert oder in einem Remote-Backend mit Versionierung gespeichert?
  • Haben Sie die Berechtigungen, um bei Problemen ein Rollback durchzuführen?
  • Gibt es ein Wartungsfenster oder eine Benachrichtigung für das Team?
  • Für die Produktion: Haben Sie eine gespeicherte Plan-Datei verwendet (terraform apply plan.tfplan)?
  • Für Datenbankänderungen: Haben Sie einen separaten Migrations-Rollback-Plan außerhalb von Terraform?

Die konkrete Erkenntnis

terraform apply auszuführen ist der Moment, in dem Ihre Konfiguration zu echter Infrastruktur wird. Verwenden Sie für die Produktion eine gespeicherte Plan-Datei, um sicherzustellen, dass Sie genau das anwenden, was geprüft wurde. Verstehen Sie, dass Fehler einen teilweisen Zustand hinterlassen, kein automatisches Rollback. Und wissen Sie immer, wo Ihre State-Datei lebt und wie Sie sie wiederherstellen können, denn ohne sie kann Terraform Ihre Infrastruktur überhaupt nicht verwalten.