terragrunt Structure + Syntax + Common Commands

Terragrunt Gotchas

Why use terragrunt

• Helps keep code dry

• Automatically sets up remote state and dynamo DB lock tables

  • Check the terragrunt.hcl file at the root of the deployment repo to see how it works

• Builds tree structure of remote state files in an S3 backend

  • After deploy,

• Contains lots of little helper functions to refer to the remoter state

• Helps with modularizing code

  • Terraform will often get you to write very long terraform deployments that are very difficult to debug.
    • You can end up with something like this which is very difficult to use in different contexts, ie you have to be fully bought into the whole architecture
  • When you modularize terraform without terragrunt, you either nest the modules or you refer to the outputs of the other modules through thier remote state.

  Terraform Modularization

  • With terragrunt, you have another option and that is to refer to a file reference with a dependency block. Read more on it here. This is a new feature and something that before it was introduced, you had to deal with via the above two terraform methods embedded in your underlying terraform or with tools like tfvars-annotations.

Important Commands

Terragrunt wraps all terraform commands and exposes additional flags.

terragrunt apply --terragrunt-source-update 
terragrunt apply-all --terragrunt-source-update
terragrunt destroy --terragrunt-source-update 
terragrunt destroy-all --terragrunt-source-update   

How much to modularize your terraform

• There are lots of discussions about how you should modularize your code but not much to consent about how much to modularize it.
• There are a few schools of thought.
  1. Separate your modules and call them independently (1 to 1 approach)
     • Examples of this include Anton Babanko's reference architecture
     • This works well when you have a lot of moving pieces / dynamic relationships and you plan on reusing your modules in multiple places in a predictable way
  2. Consolidate your modules within a single root module (nested approach)
     • Examples of this include what Gruntworks recommends, the company behind terragrunt
     • This well works when you have very reliable and reusable source modules and you know exactly what you are trying to do / don't need to reuse the root module