Terraform Plan Summarizer · IaC
Terraform Plan Summarizer — den Plan lesen, bevor Sie ihn anwenden
Fügen Sie terraform plan-Ausgabe ein — ANSI-Farben und CRLF aus einem CI-Log inklusive — oder terraform show -json tfplan. Adds, Changes, Destroys und Replacements werden als vier getrennte Zahlen gezählt, jedes forces replacement-Attribut wird an der Ressource benannt, zu der es gehört, und alles Löschende an einer Datenbank, einem NAT Gateway oder einer Cluster-Control-Plane wird nach oben geholt. Danach werden die Summen gegen Terraforms eigene Zusammenfassungszeile geprüft — denn ein Plan-Leser, der still abdriftet, ist schlimmer als gar keiner.
Läuft in Ihrem Browser — nichts, was Sie einfügen, verlässt diese Seite. Wie wir das belegen
Playground für den Terraform Plan Summarizer
Both formats work and the format is detected for you: the human-readable terraform plan transcript (ANSI colour codes and CRLF from a CI log are fine) or terraform show -json tfplan. Up to 2 MiB — roughly a 50,000-line plan. It stays in this tab: there is no server here to send it to, which matters, because plan output is full of account IDs, ARNs, CIDRs and policy JSON.
Results update as you type — press Enter to run now.
By action puts replacements and destroys first, because those are the ones that can take something down. By module follows the code instead, which is what you want when one module call is the thing under review.
Paste a plan to see adds, changes, destroys and replacements counted separately, the replacement-forcing attributes named, and the totals cross-checked against Terraform’s own summary line.
Die Lücke
Das eine -/+, auf das es ankommt, steht in Zeile 310.
Ein echter Plan sind tausende Zeilen Attribut-Diff, und der Teil, der die Produktion umlegen kann, ist drei Zeichen breit. Einen Plan im Pull Request zu prüfen heißt, ein eingeklapptes CI-Log nach einem -/+ zwischen hunderten ~-Tag-Änderungen zu durchsuchen und dann weiterzuscrollen, um den # forces replacement-Kommentar zu finden, der sagt, welches Attribut schuld war. Die Zusammenfassung am Ende hilft nicht: 2 to add liest sich wie zwei neue Dinge — dabei ist eines davon Ihre Datenbank, die gelöscht und neu gebaut wird.
Also fügen Leute den Plan in einen Chatbot ein. Das ist die schlechteste verfügbare Option, und zwar doppelt. Erstens Datenabfluss: Plan-Ausgabe trägt Account-IDs, ARNs, Subnetz- und CIDR-Bereiche, IAM-Policy-Dokumente, Security-Group-Regeln und interne DNS-Namen — ein Dokument über die Form Ihres Netzes, das Sie niemals an ein Ticket hängen würden, übergeben an einen Dritten und, in Consumer-Tarifen, an die Trainingsdaten. Zweitens Genauigkeit: ein Sprachmodell, das einen Plan liest, betreibt Mustererkennung auf Text. Es ordnet einen forces replacement-Kommentar der falschen Ressource zu, lässt bei abgeschnittener Einfügung stillschweigend Ressourcen weg und addiert selbstsicher Zahlen, die es nie gezählt hat.
Diese Seite ist die Ground-Truth-Version derselben Frage, und sie ist bewusst genau bei dem Punkt eindeutig, den eine KI-Antwort nicht liefern kann: einer Aussage darüber, was sie nicht weiß. Terraforms lesbare Ausgabe ist keine stabile Schnittstelle, also wird die geparste Ressourcenliste jedes Mal summiert und mit Terraforms eigener Plan:-Zeile verglichen. Stimmen beide, wird das gesagt. Stimmen sie nicht — so sieht eine abgeschnittene CI-Einfügung aus —, werden beide Zahlen genannt und Terraform als maßgeblich benannt. Der sechste Beispiel-Chip ist genau dieser Fall: ein GitHub-Actions-Log, dessen Mitte der Viewer eingeklappt hat, wo Terraforms Zeile 4 to add, 3 to change und 2 to destroy meldet und nur 2, 1 und 1 die Kopie überlebt haben.
Sie prüfen die Pipeline, die den Plan ausführt, und nicht den Plan selbst? Der GitHub Actions Validator und der GitLab CI Validator prüfen den Workflow, und der .env.example-Checker findet die Variablen, die er nicht weitergegeben hat.
Die Pipeline
So funktioniert es.
Fünf deterministische Schritte, alle in Ihrem Browser-Tab — zwei Parser hinter einem automatisch erkennenden Einstiegspunkt und ein Gegencheck, der aus einem instabilen Eingabeformat eine ehrliche Antwort macht.
-
Format erkennen — und sagen, wenn es die falsche Datei ist.
JSON oder Text wird am ersten Zeichen und den vorhandenen Keys entschieden. Ein State-Dump, ein terraform-validate-json-Ergebnis oder mitten im Array abgeschnittenes JSON werden jeweils benannt, samt dem Befehl, der einen echten Plan erzeugt — nie ein nacktes „ungültige Eingabe“.
-
ANSI entfernen, Zeilenenden normalisieren.
Ein aus GitHub Actions, GitLab oder Jenkins kopierter Plan kommt in Farb-Escapes und CRLF-Enden verpackt an. Beides wird vor dem Parsen entfernt, damit CI-Einfügung und Terminal-Einfügung identische Ausgabe liefern. Die Eingabe ist auf 2.097.152 Zeichen begrenzt — 2 MiB, etwa ein 50.000-zeiliger Plan.
-
Die Ressourcen lesen, nicht das Diff.
Jede „# <Adresse> …“-Kopfzeile trägt Modulpfad und Index — sie ist deshalb die Quelle der Wahrheit für die Adresse; die Symbolzeile darunter liefert die Ersetzungsreihenfolge. Im Block selbst wird nur nach drei Dingen gesucht: „# forces replacement“, „(sensitive value)“ und dem „(because …)“-Grund, den Terraform nennt und der wörtlich übernommen wird.
-
Nach Schaden sortieren, nicht nach Änderung.
Eine Tabelle mit 17 Ressourcentyp-Mustern in vier Klassen — Datenspeicher, Egress-Pfad, Control Plane, Verschlüsselungsschlüssel — markiert ausschließlich löschende Aktionen, mit einem Satz dazu, was konkret verloren geht: die Daten, die öffentliche Egress-IP, die kubeconfigs. Ein Typ, der nicht in der Tabelle steht, ist unklassifiziert — und die Seite sagt das, statt Sicherheit zu suggerieren.
-
Die Summe gegenprüfen und sich weigern, selbstsicher falsch zu sein.
Die geparste Liste wird auf Terraforms Art summiert — jede Ersetzung einmal als add und einmal als destroy — und mit der „Plan:“-Zeile verglichen. Übereinstimmung wird ausgesprochen. Abweichung ist eine Warnung, die beide Zahlen nennt und sagt, Terraform zu vertrauen. Nichts hier rät stillschweigend.
Referenz
Jedes Symbol, das ein Plan ausgeben kann.
Neun Glyphen und Annotationen tragen die ganze Bedeutung eines Plans. Sechs sind Aktionen, drei sind Notizen zu einem Wert — und zwei der sechs unterscheiden sich nur in der Reihenfolge zweier Operationen, was der Unterschied zwischen einer rollierenden Änderung und einem Ausfall ist.
| Symbol | Bedeutung |
|---|---|
| + create | Ein neues Objekt. Noch existiert nichts, also lesen die meisten Attribute (known after apply). |
| ~ update in-place | Das bestehende Objekt wird geändert. Die id bleibt, und alles darauf Gespeicherte auch. |
| - destroy | Das Objekt wird gelöscht und nicht neu erstellt. Achten Sie auf die (because …)-Zeile: sie nennt den Grund. |
| -/+ destroy then create | Eine Ersetzung, altes Objekt zuerst. Es gibt ein Zeitfenster ohne Objekt — der Standardfall, und der, den man genau lesen sollte. |
| +/- create then destroy | Eine Ersetzung mit create_before_destroy = true. Das neue Objekt existiert, bevor das alte verschwindet. |
| <= read during apply | Eine Data Source, die zur Planzeit nicht aufgelöst werden kann. Nie Teil von add, change oder destroy. |
| # forces replacement Attribut-Annotation | Dieses Attribut kann nicht an der Stelle geändert werden, also wird das ganze Objekt ersetzt. Der eine Kommentar, nach dem sich zu greppen lohnt. |
| (known after apply) Wert-Annotation | Der Provider vergibt ihn beim Anlegen, er existiert also wirklich noch nicht. Kein Fehler. |
| (sensitive value) Wert-Annotation | Als sensibel markiert, der Plan verbirgt ihn. Beachten Sie: in der State-Datei steht er trotzdem im Klartext. |
Warum eine Ersetzung doppelt gezählt wird
Terraform zählt Operationen. Diese Seite zählt Ressourcen — und stellt Terraforms Zahlen daneben, damit keine für die andere gehalten wird.
Plan: 2 to add, 0 to change, 1 to destroy.
what Terraform counted what actually happens
──────────────────────── ─────────────────────
+ aws_iam_role.app one NEW role
-/+ aws_db_instance.primary one database replaced
counted as +1 add
counted as +1 destroy
this page shows them apart:
+ add 1 created outright
~ change 0 updated in place
− destroy 0 destroyed outright
± replace 1 destroyed and recreated Die richtige Datei bekommen
show -json gegen einen gespeicherten Plan ist die verlässliche Eingabe; das Textformat ist das, was Sie schon haben. Zwei Beinahe-Treffer werden erkannt und benannt.
# The reliable path: save the plan, then read the machine format
terraform plan -out=tfplan
terraform show -json tfplan > plan.json # paste plan.json above
# The path you already have: the text a pipeline printed
terraform plan -no-color # -no-color if you can; ANSI is fine either way
# What NOT to paste — both are told apart from a plan and named
terraform show -json # this is STATE, it has no resource_changes
terraform validate -json # this is a config check, not a plan Nächster Schritt
Der Plan passt. Jetzt prüfen Sie die Pipeline, die ihn ausführt.
Ein Plan ist nur so vertrauenswürdig wie der Workflow, der ihn erzeugt hat: der GitHub Actions Validator und der GitLab CI Validator fangen die Pipeline-Fehler ab, die einen Plan gegen den falschen State oder die falschen Credentials laufen lassen, und der .env.example-Checker findet die Variable, die Ihr Job nie übergeben hat. Alle laufen, wie diese Seite, vollständig in Ihrem Browser.
+ add 1 ~ change 1 − destroy 0 ± replace 1
read this first — 1 high blast radius
module.data.aws_db_instance.primary data store
forces replacement: engine_version
destroy then create — the database does not exist in between
cross-check: reconciles
Terraform printed: Plan: 2 to add, 1 to change, 1 to destroy.
(the replacement is one of those adds AND the destroy) FAQ
Fragen, beantwortet.
Tippen Sie auf eine Frage, um die Antwort aufzuklappen.
Welche Plan-Formate werden akzeptiert?
Beide — und es wird erkannt, welches Sie eingefügt haben. Das erste ist das lesbare Transkript, das Terraform ausgibt, mit +, ~, - und -/+ am linken Rand, einschließlich der ANSI-Farbcodes und CRLF-Zeilenenden, die beim Kopieren aus einem CI-Log anfallen. Das zweite ist terraform show -json tfplan, das Maschinenformat mit resource_changes, replace_paths, action_reason und output_changes — eine dokumentierte, versionierte Schnittstelle. Das JSON ist verlässlicher und die erste Wahl, wenn Sie eine Plandatei speichern können; der Text ist das, was Sie tatsächlich haben, wenn die Pipeline schon gelaufen ist. Nicht akzeptiert wird terraform show -json Ihres States oder die Ausgabe von terraform validate -json — beides sind häufige Verwechslungen, und beide werden benannt, samt dem Befehl, der das Richtige erzeugt.
Was ist der Unterschied zwischen -/+ und +/- in einem Plan?
Die Reihenfolge der beiden Operationen — und die entscheidet, ob es einen Ausfall gibt. -/+ heißt zuerst löschen, dann anlegen: das alte Objekt ist weg, bevor das neue existiert, alles Abhängige ist für die Dauer dieser Lücke kaputt — Sekunden bei einer Security-Group-Regel, zwanzig Minuten bei einer RDS-Instanz. +/- heißt zuerst anlegen, dann löschen, und genau das kauft Ihnen lifecycle { create_before_destroy = true }: der Ersatz wird gebaut und erst danach das alte Objekt entfernt. Terraform wählt standardmäßig Löschen-zuerst, +/- erscheint also nur dort, wo jemand es angefordert hat. Diese Seite schreibt beide Reihenfolgen in Worten auf jede Ersetzungszeile, statt Sie ein dreizeichiges Glyph entschlüsseln zu lassen.
Was bedeutet „forces replacement“ konkret?
Es markiert genau das Attribut, dessen Änderung nicht an der Stelle angewendet werden kann, sodass der Provider das Objekt löschen und ein neues bauen muss. Es ist attributgenau, und das ist der nützliche Teil: engine_version bei einer aws_db_instance ist ein echtes Upgrade, das Sie beabsichtigt haben, während availability_zone oder name aus Versehen — durch eine umbenannte Variable, ein umformatiertes Tag, einen verschobenen Provider-Default — die klassische Überraschungsersetzung ist. Diese Seite holt jeden dieser Attributnamen aus dem Block, zu dem er gehört, und zeigt ihn als Chip an der jeweiligen Ressourcenzeile, damit Sie nie ein 400-zeiliges Diff nach dem Kommentar durchsuchen müssen.
Warum zählt eine Ersetzung sowohl als „add“ als auch als „destroy“?
Weil Terraform Operationen zählt, nicht Ressourcen — und eine Ersetzung sind zwei Operationen. Ein Plan mit einem reinen Create und einer Ersetzung gibt deshalb „Plan: 2 to add, 0 to change, 1 to destroy“ aus: die Ersetzung geht in beide Zahlen ein. Das ist korrekt, und es ist gleichzeitig die am häufigsten falsch gelesene Zeile der Terraform-Ausgabe, denn „2 to add“ klingt nach zwei neuen Dingen. Diese Seite zeigt stattdessen vier disjunkte Kacheln: „add“ ist direkt angelegt, „replace“ ist gelöscht und neu erstellt, und nichts wird doppelt gezählt. Terraforms eigene Rechnung steht wörtlich darunter, damit man beide vergleichen kann statt sie zu verwechseln.
Ist es sicher, hier einen Plan einzufügen?
Ja — und genau deshalb existiert diese Seite in dieser Form. Es steht kein Server dahinter: der Parser ist JavaScript, das in Ihren Tab lädt und dort läuft, der Plan verlässt Ihren Rechner also nie. Prüfen können Sie das im Netzwerk-Tab Ihres Browsers oder indem Sie die Seite laden und dann offline gehen. Bei Plan-Ausgabe zählt das mehr als bei fast allem anderen, was man in ein Web-Werkzeug einfügt: ein Plan ist voll von Account-IDs, ARNs, Subnetz- und CIDR-Bereichen, IAM-Policy-Dokumenten, Security-Group-Regeln und internen DNS-Namen. Wer das in einen Chatbot einfügt, übergibt all das einem Dritten — und in den Consumer-Tarifen der meisten Assistenten auch den Trainingsdaten.
Die Zahlen passen nicht zusammen — was bedeutet die Abweichungswarnung?
Sie bedeutet, dass die Ressourcen, die diese Seite lesen konnte, nicht zu den Summen auf Terraforms eigener Zusammenfassungszeile addieren — und in neun von zehn Fällen ist die Einfügung unvollständig: ein CI-Log-Viewer hat die Mitte eingeklappt, ein Scrollback-Puffer hat sie abgeschnitten, oder die Kopie begann auf halber Strecke. Die Warnung nennt beide Zahlensätze und sagt Ihnen, Terraform zu vertrauen. Der Grund, dass es sie überhaupt gibt: Terraforms lesbare Ausgabe ist ausdrücklich keine stabile Schnittstelle, ein Textparser wird also irgendwann an einer Formatänderung abdriften — und ein Summarizer, der still abdriftet, würde eine selbstsichere falsche Summe ausgeben, was schlimmer ist als gar keine. Dieser Gegencheck ist erst das, was das Parsen eines instabilen Formats vertretbar macht.
Was bedeutet „(known after apply)“, und warum steht dort kein Wert?
Es bedeutet, dass der Wert noch nicht existiert. Attribute wie ein ARN, eine id, ein generierter DNS-Name oder eine IP-Adresse werden vom Provider beim Anlegen vergeben; zur Planzeit kennt Terraform sie also wirklich nicht und weigert sich zu raten. Das ist kein Fehler und keine Warnung — ein Plan für etwas Neues ist voll davon. Eine praktische Folge hat es doch: eine Ressource, deren Eingabe von einem unbekannten Wert abhängt, kann ebenfalls nicht vollständig ausgewertet werden. Deshalb sehen Sie manchmal eine Data Source als „read during apply“ markiert statt aufgelöst, und deshalb kann ein Apply mehr tun, als der Plan gezeigt hat.
Funktioniert das mit OpenTofu?
Ja. OpenTofu wurde von Terraform 1.5.x abgezweigt und hat beide Ausgabeformate behalten: das Textformat verwendet die gleichen Symbole und die gleiche Zeile „Plan: N to add, N to change, N to destroy“, und tofu show -json liefert dieselbe format_version-Familie mit derselben resource_changes-Struktur. Alles auf dieser Seite gilt unverändert, und die Versionszeile wird als das Produkt gelesen, das sie ausgegeben hat. Dasselbe gilt für die Wrapper, die Terraform-Ausgabe unverändert durchleiten — Terragrunt, Atlantis, Spacelift — solange der Plantext selbst intakt ist.
Gegen welche Terraform-Versionen ist das getestet?
Der JSON-Pfad ist gegen format_version 0.1 bis 1.x geschrieben, was Terraform 0.12 bis 1.9 und aktuelles OpenTofu abdeckt; ein Dokument mit unbekannter Major-Version wird akzeptiert, trägt aber eine Warnung, denn ein umbenanntes Feld würde sonst still Nullen erzeugen. Der Textpfad ist gegen die Formen ab 1.5 getestet — dort kam „N to import“ in die Zusammenfassungszeile, und dort erscheinen moved- und import-Blöcke; ältere Ausgabe parst meist, und was nicht parst, fängt der Zahlen-Gegencheck ab, statt es als Tatsache zu melden. Das Einzige, was diese Seite nie tun wird, ist Kosten schätzen: Preise veralten, und eine veraltete Zahl mit Selbstsicherheit ausgegeben ist genau die Art Antwort, die diese Website ersetzen soll.
More free, private DevOps tools.
Der Terraform Plan Summarizer ist eines der Werkzeuge in OpsCanopy — einem wachsenden Schirm browserbasierter Validatoren, Konverter und Tester, die niemals einen Server berühren.
39 kostenlose Tools, jedes einzelne offlinefähig — opscanopy.com funktioniert ohne Registrierung, und nichts wird hochgeladen.
Verwandte Infrastruktur-Werkzeuge: der docker run → Compose-Konverter, der .env.example-Checker für die Variablen, die ein Deploy vergessen hat, und die Validatoren für GitHub Actions und GitLab CI für die Pipeline, die Ihren Plan ausführt — oder durchstöbern Sie das vollständige Werkzeugverzeichnis.
Bereitgestellt wie besehen zur bequemen Nutzung. Nicht mit HashiCorp verbunden. Diese Seite fasst zusammen, was ein Plan sagt; sie schätzt keine Kosten und wird es nie tun — Preise veralten, und eine veraltete Zahl mit Selbstsicherheit ausgegeben ist die eine Antwort, die ein Ground-Truth-Werkzeug nicht geben kann. Ein Ressourcentyp, der in der Blast-Radius-Tabelle fehlt, ist unklassifiziert, nicht als sicher erwiesen. OpsCanopy ist kostenlos und offen.