In this article, I detail the benefits of using Terragrunt. At the end, I list the reasons why sometimes Terragrunt may not be the right choice for your project.
Intended Audience: Technical team members with some familiarity with Terraform and AWS.
Why use Terragrunt?
The two main benefits of Terragrunt are:
- DRY clean code
- Ease of use
Directly from HashiCorp's Terraform best practices, you should avoid a monolithic configuration and eschew a large Terraform state file . In summary, if you put all your cloud resources like EC2, S3, RDS, etc. into Terraform files under one big directory, modifying a S3 bucket will slowly scan and potentially modify other AWS resources in that directory.
Seasoned Terraform users will group the TF configuration files into its own directory, such as VPC, IAM, EC2 or Frontend-UI, Backend-Service, Databases. In practice, this can lead to many duplicate configuration and variables.
DRY clean code
A fundamental tenet of clean code is Don't Repeat Yourself (DRY). If you duplicate code in more than one place, you must change the code in multiple places when doing fixes and enhancements. When you don't change the code in all the duplicated places, bugs occur.
- DRY Input Variables
You can put all your variables in one file and reuse it via the
You are forced to duplicate your input variables in multiple tfvars files.
- DRY Output Variables
Output values are automatically generated from the Terraform module output variables.
There are multiple outputs.tf files.
- DRY remote state backend
remote_stateblock dynamically generates the Terragrunt remote state configuration in the parent terragrunt.hcl file.
The Terraform remote state configuration is defined via the
backendblock. Even worse, Terraform does not allow the use of variables in the backend block so you have to explicitly hard code everything. You must create multiple backend configuration files with nearly identical configuration.
- DRY CLI arguments
You can define required Terraform CLI arguments via the
extra_argumentsblock in one central terragrunt.hcl.
If you want to always run the
terraformcommand line with certain required arguments, you would have to hack a custom script.
Ease of use
Terragrunt helps using Terraform more convenient for the operators.
This is the killer feature of Terragrunt.
The primary issue with multiple Terraform state stacks is running it in the right order. For example, you need to apply the VPC stack before the EC2 stack.
You can explicitly define the correct order to apply the stacks via
dependencies. Then executing
terragrunt run-all applywill execute the resource creation in the correct order.
To apply the Terraform stacks in the proper order, you would have to code and maintain your own script.
- Before/After/Error hooks
You may want to run an external program like Slack before and after running Terragrunt. This is accomplished via the
To accomplish the above hooks in Terraform, it would be a custom wrapper script.
- Auto-create remote state resource
If the remote state backend store (S3 and DynamoDB in AWS) does not exist, Terragrunt will automatically create it for you with the correct security settings.
Before you can start using Terraform, you either have to create the remote state backing store manually or create the store via Terraform using local state then migrate.
Cloud providers can be finicky or slow. You can configure Terragrunt to automatically retry after a failure with the
Terraform has no built-in auto-retry setting.
It's a small annoyance, but in Terraform you must manually execute
terraform initonce on a new stack before you can
terraform plan/apply. Terragrunt is smart enough to recognize that an init is needed during the plan/apply phase and will automatically execute it for you.
Why not to use Terragrunt
Yet another tool
DevOps already has a lot of tools to learn. If your team is already overwhelmed, it may not be the right time to introduce yet another tool.
Terragrunt does not work well with Terraform Cloud. Terraform Cloud competes with Terragrunt, offering many of the same clean code and ease of use features.
Large Terraform codebase
Refactoring a large Terraform codebase into Terragrunt is a pain, involving many tedious
terraform import. It's more prudent to introduce Terragrunt on a new project codebase instead.
Final thoughts on Terragrunt vs Terraform
I enjoy using Terragrunt on my projects and I wholeheartedly recommend it. Terragrunt offers so many additional benefits on top of the already wonderful Terraform.
If you enjoyed this article, come back next week for my article on "How to layout your Terragrunt project."
A preview can be found at GitHub