Understand your terraform plan

webofmars
3 min readFeb 23, 2021

--

If like me you are a day-to-day user of Hashicorp Terraform, you might have come to the following command that allow to display your resources flow in a pretty way:

terraform graph --type plan | dot -Tsvg > graph.svg

Documentation Reference: https://www.terraform.io/docs/cli/commands/graph.html

This will basically generate a SVG file (thanks to graphviz support) containing all your terraform ressources and the link between them. This is supposed to help you in order to understand your flow and the dependencies between ressources.

But if you are using this in something else than a hello-world project, there is some chances that your pdf look like the following picture …

Photo by Carolina Cossío on Unsplash

A giant plate of Italian’s spaghettis !

This is due to the fact that terraform will trace every single ressource it handles to the graph and does not allow by default any type of filtering.

And to be honest when i see this in a terraform graph i will close it immediately thinking “it’s clearly no help here”

With the time i came accros a neat solution exposed bellow. Simply prepare a script that help you to filter your terraform plan

#!/bin/shterraform graph -type=plan | \
grep -v -E 'provider|var\.|provisioner|output\.' | \
dot -Tsvg > tf-graph.svg
Photo by Julius Drost on Unsplash

Let’s explain it a bit:

The most important part is the grep -v E that is doing the filtering. For this to work you need a recent version of grep with -E support (i guess most of the one you can find have it).

  • The -v option is used to filter out the results instead of printing it
  • The -E option allow to use pure Regular Expressions in grep filtering (which is not the case without it)

So we will filter out some regular expressions with this command.

Most of the time you want to focus on ressources like aws_instance for exemple and forget about

  • providers which you already know about since you declared them
  • variables that you can check in the code if needed
  • provisioners that are triggered after the creation of a resource
  • output that you will get only if executing an apply

So this should print you an understandable plan (still big but looking neat) that you can follow and dig into if you really need to understand some timings or ordering issues.

That’s it enjoy !

--

--

webofmars
webofmars

Written by webofmars

DevOps coach & specialist. ☸️ CKA | ☁️ AWS solutions architect. Containers enthusiast | 🐶 Datadog Partner. #French, #Geek, #Dad, #Curious

No responses yet