Terraform Plan Summarizer · IaC
Récapitulatif de plan Terraform — lire un plan avant de l’appliquer
Collez la sortie de terraform plan — couleurs ANSI et CRLF d’un log de CI compris — ou de terraform show -json tfplan. Les adds, changes, destroys et replacements sont comptés comme quatre chiffres distincts, chaque attribut forces replacement est nommé sur la ressource à laquelle il appartient, et tout ce qui détruit une base de données, une NAT gateway ou un control plane de cluster remonte en haut. Ensuite les totaux sont recoupés avec la ligne de résumé de Terraform elle-même — parce qu’un lecteur de plan qui dérive en silence est pire que pas de lecteur du tout.
S’exécute dans votre navigateur — rien de ce que vous collez ne quitte cette page. Comment nous le prouvons
Playground du récapitulatif de plan Terraform
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.
Le manque
Le seul -/+ qui compte est à la ligne 310.
Un vrai plan, ce sont des milliers de lignes de diff d’attributs, et la partie qui peut faire tomber la production tient sur trois caractères. Relire un plan dans une pull request, c’est parcourir un log de CI replié à la recherche d’un -/+ parmi des centaines de changements de tags ~, puis descendre encore pour trouver le commentaire # forces replacement qui dit quel attribut en est la cause. Le résumé du bas n’aide pas : 2 to add se lit comme deux nouvelles choses, alors que l’une des deux est votre base de données détruite puis reconstruite.
Alors les gens collent le plan dans un chatbot. C’est la pire option disponible, et deux fois. D’abord l’exfiltration : une sortie de plan porte des identifiants de compte, des ARN, des plages de sous-réseau et de CIDR, des documents de politique IAM, des règles de security group et des noms DNS internes — un document décrivant la forme de votre réseau que vous n’attacheriez jamais à un ticket, remis à un tiers et, sur les offres grand public, aux données d’entraînement. Ensuite l’exactitude : un modèle de langage qui lit un plan fait de la reconnaissance de motifs sur du texte. Il attribue un commentaire forces replacement à la mauvaise ressource, laisse tomber des ressources en silence quand le collage est tronqué, et additionne avec aplomb des chiffres qu’il n’a jamais comptés.
Cette page est la version « vérité terrain » de la même question, et elle est délibérée précisément là où une réponse d’IA ne peut rien vous donner : une déclaration de ce qu’elle ignore. La sortie lisible de Terraform n’est pas une interface stable, donc la liste de ressources analysée est totalisée et comparée à la ligne Plan: de Terraform, chaque fois. Quand elles s’accordent, c’est dit. Quand elles ne s’accordent pas — ce à quoi ressemble un collage de CI tronqué — les deux chiffres sont nommés et celui de Terraform est désigné comme faisant foi. La sixième pastille d’exemple est exactement ce cas : un log GitHub Actions dont le visualiseur a replié le milieu, où la ligne de Terraform annonce 4 to add, 3 to change et 2 to destroy alors que seuls 2, 1 et 1 ont survécu à la copie.
Vous relisez la pipeline qui exécute le plan plutôt que le plan lui-même ? Le validateur GitHub Actions et le validateur GitLab CI vérifient le workflow, et le vérificateur .env.example trouve les variables qu’il a oublié de passer.
Le pipeline
Comment ça marche.
Cinq étapes déterministes, toutes dans votre onglet — deux analyseurs derrière un unique point d'entrée qui détecte le format, et un recoupement qui transforme un format d'entrée instable en réponse honnête.
-
Détecter le format — et le dire quand ce n'est pas le bon fichier.
JSON ou texte est décidé au premier caractère et aux clés présentes. Un dump d'état, un résultat de terraform validate -json ou du JSON coupé au milieu d'un tableau sont nommés chacun pour ce qu'ils sont, avec la commande qui produit un vrai plan — jamais un « entrée invalide » nu.
-
Retirer l'ANSI, normaliser les fins de ligne.
Un plan copié depuis GitHub Actions, GitLab ou Jenkins arrive emballé dans des séquences de couleur et des fins CRLF. Les deux sont retirés avant toute analyse, si bien qu'un collage de CI et un collage de terminal donnent une sortie identique. L'entrée est plafonnée à 2 097 152 caractères — 2 MiB, soit environ un plan de 50 000 lignes.
-
Lire les ressources, pas le diff.
Chaque ligne d'en-tête « # <adresse> … » porte le chemin de module et l'index : c'est donc elle qui fait foi pour l'adresse ; la ligne de symbole en dessous fournit l'ordre du remplacement. Dans le bloc, seules trois choses sont cherchées : « # forces replacement », « (sensitive value) » et la raison « (because …) » donnée par Terraform, conservée mot pour mot.
-
Classer par ce qui casse, pas par ce qui change.
Une table de 17 motifs de types de ressource en quatre classes — magasin de données, chemin de sortie, control plane, clé de chiffrement — ne marque que les actions destructrices, avec une phrase nommant ce qui disparaît concrètement : les données, l'IP publique de sortie, les kubeconfig. Un type absent de la table est non classé, et la page le dit au lieu de laisser croire qu'il est sûr.
-
Recouper le total et refuser de se tromper avec assurance.
La liste analysée est totalisée à la manière de Terraform — chaque remplacement comptant une fois comme add et une fois comme destroy — puis comparée à la ligne « Plan: ». L'accord est énoncé. Le désaccord est un avertissement qui nomme les deux chiffres et dit de faire confiance à Terraform. Rien ici ne devine en silence.
Référence
Tous les symboles qu’un plan peut imprimer.
Neuf glyphes et annotations portent tout le sens d’un plan. Six sont des actions, trois sont des notes sur une valeur — et deux des six ne diffèrent que par l’ordre de deux opérations, ce qui fait toute la différence entre un changement progressif et une coupure.
| Symbole | Ce que cela signifie |
|---|---|
| + create | Un nouvel objet. Rien n'existe encore, donc la plupart de ses attributs affichent (known after apply). |
| ~ update in-place | L'objet existant est modifié. L'id survit, et tout ce qui y est stocké aussi. |
| - destroy | L'objet est supprimé et non recréé. Cherchez la ligne (because …) : elle en donne la raison. |
| -/+ destroy then create | Un remplacement, ancien objet d'abord. Il existe une fenêtre où il n'y a rien — le cas par défaut, et celui à lire attentivement. |
| +/- create then destroy | Un remplacement avec create_before_destroy = true. Le nouvel objet existe avant que l'ancien disparaisse. |
| <= read during apply | Une data source qui ne peut pas être résolue au moment du plan. Jamais comprise dans add, change ou destroy. |
| # forces replacement annotation d'attribut | Cet attribut ne peut pas changer sur place, donc l'objet entier est remplacé. Le seul commentaire qui mérite un grep. |
| (known after apply) annotation de valeur | Le provider l'attribue à la création : elle n'existe réellement pas encore. Ce n'est pas une erreur. |
| (sensitive value) annotation de valeur | Marquée sensible, le plan la masque. Notez qu'elle reste en clair dans le fichier d'état. |
Pourquoi un remplacement est compté deux fois
Terraform compte des opérations. Cette page compte des ressources, et imprime les chiffres de Terraform à côté pour qu’aucun ne soit pris pour l’autre.
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 Obtenir le bon fichier
show -json sur un plan sauvegardé est l’entrée fiable ; la transcription texte est celle que vous avez déjà. Deux quasi-erreurs sont reconnues et nommées.
# 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 Étape suivante
Le plan est bon. Vérifiez maintenant la pipeline qui l’exécute.
Un plan n’est fiable que dans la mesure où le workflow qui l’a produit l’est : le validateur GitHub Actions et le validateur GitLab CI attrapent les erreurs de pipeline qui font tourner un plan contre le mauvais état ou les mauvaises informations d’identification, et le vérificateur .env.example trouve la variable que votre job n’a jamais passée. Tous, comme cette page, tournent entièrement dans votre navigateur.
+ 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
Vos questions, nos réponses.
Appuyez sur une question pour afficher la réponse.
Quels formats de plan sont acceptés ?
Les deux, et le format collé est détecté pour vous. Le premier est la transcription lisible que Terraform imprime — celle avec +, ~, - et -/+ dans la marge de gauche — y compris les codes couleur ANSI et les fins de ligne CRLF que produit une copie depuis un log de CI. Le second est terraform show -json tfplan, le format machine, qui porte resource_changes, replace_paths, action_reason et output_changes et constitue une interface documentée et versionnée. Le JSON est plus fiable et c'est celui à utiliser si vous pouvez sauvegarder un fichier de plan ; le texte est celui que vous avez réellement une fois la pipeline passée. Ce qui n'est PAS accepté : terraform show -json de votre état, ni la sortie de terraform validate -json — deux confusions courantes, et dans les deux cas on vous dit de quoi il s'agit et quelle commande produit la bonne chose.
Quelle est la différence entre -/+ et +/- dans un plan ?
L'ordre des deux opérations, et c'est lui qui décide s'il y aura une coupure. -/+ signifie détruire puis créer : l'ancien objet a disparu avant que le nouveau existe, donc tout ce qui en dépend est cassé pendant cet intervalle — quelques secondes pour une règle de security group, vingt minutes pour une instance RDS. +/- signifie créer puis détruire, c'est exactement ce que vous achète lifecycle { create_before_destroy = true } : le remplaçant est construit et seulement ensuite l'ancien objet est retiré. Terraform choisit détruire-d'abord par défaut, donc +/- n'apparaît que là où quelqu'un l'a demandé. Cette page écrit les deux ordres en mots sur chaque ligne de remplacement, au lieu de vous faire décoder un glyphe de trois caractères.
Que signifie réellement « forces replacement » ?
Cela marque l'attribut précis dont la modification ne peut pas être appliquée sur place, si bien que le provider doit supprimer l'objet et en construire un nouveau. C'est par attribut, et c'est là tout l'intérêt : engine_version sur un aws_db_instance est une vraie montée de version que vous avez voulue, alors qu'un availability_zone ou un name qui change par accident — variable renommée, tag reformaté, valeur par défaut du provider qui a bougé — c'est le remplacement-surprise classique. Cette page extrait chacun de ces noms d'attribut du bloc auquel il appartient et les affiche en pastilles sur la ligne de cette ressource, pour que vous n'ayez jamais à parcourir un diff de 400 lignes à la recherche du commentaire.
Pourquoi un remplacement compte-t-il à la fois comme « add » et comme « destroy » ?
Parce que Terraform compte des opérations, pas des ressources, et qu'un remplacement fait deux opérations. Un plan avec une création simple et un remplacement imprime donc « Plan: 2 to add, 0 to change, 1 to destroy » : le remplacement alimente les deux chiffres. C'est exact, et c'est aussi la ligne la plus mal lue de toute la sortie de Terraform, parce que « 2 to add » sonne comme deux nouvelles choses. Cette page affiche à la place quatre tuiles disjointes : add, c'est créé directement ; replace, c'est détruit puis recréé ; et rien n'est compté deux fois. La comptabilité propre de Terraform est imprimée en dessous, mot pour mot, pour qu'on puisse comparer les deux au lieu de les confondre.
Est-il sûr de coller un plan ici ?
Oui, et c'est précisément pourquoi cette page existe sous cette forme. Il n'y a pas de serveur derrière : l'analyseur est du JavaScript qui se charge dans votre onglet et s'y exécute, donc le plan ne quitte jamais votre machine — vérifiable dans l'onglet réseau de votre navigateur, ou en chargeant la page puis en passant hors ligne. Cela compte davantage pour une sortie de plan que pour presque tout ce que vous colleriez dans un outil web : un plan est plein d'identifiants de compte, d'ARN, de plages de sous-réseau et de CIDR, de documents de politique IAM, de règles de security group et de noms DNS internes. En coller un dans un chatbot livre tout cela à un tiers et, sur les offres grand public de la plupart des assistants, aux données d'entraînement.
Les chiffres ne collent pas — que signifie l'avertissement d'écart ?
Il signifie que les ressources que cette page a pu lire ne totalisent pas les sommes de la ligne de résumé de Terraform, et neuf fois sur dix le collage est incomplet : un visualiseur de logs de CI a replié le milieu, un tampon de défilement l'a coupé, ou la copie a commencé à mi-chemin. L'avertissement nomme les deux jeux de chiffres et vous dit de faire confiance à Terraform. La raison de son existence : la sortie lisible de Terraform n'est explicitement pas une interface stable, un analyseur de texte finira donc par dériver sur un changement de format — et un récapitulatif qui dérive en silence imprimerait un total faux avec assurance, ce qui est pire que de ne rien imprimer. Ce recoupement est ce qui rend défendable l'analyse d'un format instable.
Que veut dire « (known after apply) », et pourquoi n'y a-t-il pas de valeur ?
Cela veut dire que la valeur n'existe pas encore. Des attributs comme un ARN, un id, un nom DNS généré ou une adresse IP sont attribués par le provider à la création : au moment du plan, Terraform ne les connaît réellement pas et refuse de deviner. Ce n'est ni une erreur ni un avertissement — un plan portant sur du neuf en est rempli. Cela a toutefois une conséquence pratique : une ressource dont l'entrée dépend d'une valeur inconnue ne peut pas non plus être entièrement évaluée, d'où une data source parfois marquée « read during apply » plutôt que résolue, et d'où le fait qu'un apply peut finir par faire plus que ce que le plan montrait.
Est-ce que cela marche avec OpenTofu ?
Oui. OpenTofu a été forké depuis Terraform 1.5.x et a conservé les deux formats de sortie : la transcription texte utilise les mêmes symboles et la même ligne « Plan: N to add, N to change, N to destroy », et tofu show -json émet la même famille de format_version avec la même structure resource_changes. Tout ce qui est sur cette page s'applique sans changement, et la ligne de version est lue selon le produit qui l'a imprimée. Idem pour les surcouches qui font passer la sortie de Terraform telle quelle — Terragrunt, Atlantis, Spacelift — tant que le texte du plan lui-même est intact.
Contre quelles versions de Terraform est-ce testé ?
Le chemin JSON est écrit pour format_version 0.1 à 1.x, ce qui couvre Terraform 0.12 à 1.9 et l'OpenTofu actuel ; un document avec une version majeure inconnue est accepté mais accompagné d'un avertissement, car un champ renommé produirait sinon des zéros en silence. Le chemin texte est testé contre les formes 1.5 et suivantes, là où « N to import » a rejoint la ligne de résumé et où apparaissent les blocs moved et import ; les sorties plus anciennes s'analysent en grande partie, et ce qui ne s'analyse pas est rattrapé par le recoupement des chiffres plutôt que rapporté comme un fait. La seule chose que cette page ne fera jamais, c'est estimer un coût : les prix se périment, et un chiffre périmé imprimé avec assurance est exactement le type de réponse que ce site existe pour remplacer.
More free, private DevOps tools.
Le récapitulatif de plan Terraform est l’un des outils de OpsCanopy — une canopée grandissante de validateurs, convertisseurs et testeurs qui tournent dans le navigateur et ne touchent jamais un serveur.
39 outils gratuits, tous utilisables hors ligne — opscanopy.com fonctionne sans inscription et sans rien téléverser.
Outils d’infrastructure liés : le convertisseur docker run → Compose, le vérificateur .env.example pour les variables qu’un déploiement a oubliées, et les validateurs GitHub Actions et GitLab CI pour la pipeline qui exécute votre plan — ou parcourez l’intégralité du répertoire des outils.
Fourni tel quel, pour votre confort. Sans affiliation avec HashiCorp. Cette page résume ce que dit un plan ; elle n’estime pas les coûts et ne le fera pas — les prix se périment, et un chiffre périmé imprimé avec assurance est la seule réponse qu’un outil de vérité terrain ne peut pas donner. Un type de ressource absent de la table de rayon d’impact est non classé, et non prouvé sûr. OpsCanopy est gratuit et ouvert.