Terragrunt for DRY configurations in Terraform - Deep Dive

Overview - Terragrunt for DRY configurations

What is it?

Terragrunt is a tool that helps you write Terraform configurations more efficiently by avoiding repetition. It allows you to keep your infrastructure code clean and organized by sharing common settings across multiple Terraform projects. Instead of copying the same code again and again, Terragrunt lets you write it once and reuse it everywhere.

Why it matters

Without Terragrunt, managing many Terraform configurations can become messy and error-prone because you have to repeat the same code in many places. This repetition wastes time and can cause mistakes when updating infrastructure. Terragrunt solves this by making your code easier to maintain, saving time and reducing errors, which is crucial for reliable cloud infrastructure.

Where it fits

Before learning Terragrunt, you should understand basic Terraform concepts like modules, variables, and state management. After mastering Terragrunt, you can explore advanced Terraform workflows, multi-environment setups, and automation with CI/CD pipelines.

Mental Model

Core Idea

Terragrunt is like a smart organizer that lets you write shared Terraform code once and reuse it everywhere to keep your infrastructure clean and simple.

Think of it like...

Imagine you are cooking several meals that share many ingredients. Instead of buying and preparing each ingredient separately for every meal, you prepare a big batch once and use it in all your recipes. Terragrunt does the same for Terraform code by preparing shared parts once and reusing them.

┌─────────────────────────────┐
│       Terragrunt Layer       │
│  (Shared Configurations)     │
└─────────────┬───────────────┘
              │
  ┌───────────┴───────────┐
  │                       │
┌─▼─┐                   ┌─▼─┐
│TF1│                   │TF2│
│(Uses shared configs)   │(Uses shared configs)
└───┘                   └───┘

Build-Up - 7 Steps

1

Foundation

Understanding Terraform Basics

Concept: Learn what Terraform is and how it manages infrastructure as code.

Terraform lets you write code to create and manage cloud resources like servers and networks. You write configuration files describing what you want, and Terraform makes it happen. It uses modules to organize code and state files to track resources.

Result

You can create and update cloud infrastructure using code instead of manual steps.

Understanding Terraform basics is essential because Terragrunt builds on top of Terraform to improve code reuse and organization.

2

Foundation

Recognizing Repetition in Terraform Code

Concept: Identify why repeating code in Terraform projects is a problem.

When managing multiple environments or projects, you often copy the same Terraform code with small changes. This repetition leads to more work and risks mistakes when updating shared parts.

Result

You see that managing many similar Terraform configurations by copying code is inefficient and error-prone.

Recognizing repetition helps you appreciate why a tool like Terragrunt is needed to keep code DRY (Don't Repeat Yourself).

3

Intermediate

Introducing Terragrunt for Code Reuse

🤔Before reading on: do you think Terragrunt replaces Terraform or works alongside it? Commit to your answer.

Concept: Terragrunt works with Terraform to share common configuration and reduce repetition.

Terragrunt uses special configuration files to define shared settings like backend storage, provider details, and variables. Multiple Terraform projects can reference these shared settings, so you write them once and reuse everywhere.

Result

You can manage multiple Terraform projects with less repeated code and easier updates.

Knowing Terragrunt complements Terraform clarifies that it enhances your workflow without replacing core Terraform functionality.

4

Intermediate

Using Terragrunt's 'include' and 'dependency' Features

🤔Before reading on: do you think Terragrunt can automatically handle dependencies between Terraform modules? Commit to yes or no.

Concept: Terragrunt can include shared configs and manage dependencies between modules.

The 'include' block lets you inherit common settings from a root config file. The 'dependency' block lets one Terraform module use outputs from another, so Terragrunt manages the order and data flow automatically.

Result

Your Terraform projects become connected and share configuration smoothly, reducing manual coordination.

Understanding these features shows how Terragrunt simplifies complex multi-module setups and enforces consistency.

5

Intermediate

Organizing Multi-Environment Infrastructure

🤔Before reading on: do you think you need separate Terraform code for each environment or can Terragrunt help reuse code? Commit to your answer.

Concept: Terragrunt helps manage multiple environments like dev, staging, and prod with shared code and environment-specific settings.

You create a folder structure where each environment has its own Terragrunt config that inherits shared settings but overrides variables like region or instance size. This avoids copying full Terraform code for each environment.

Result

You can deploy consistent infrastructure across environments with minimal duplication.

Knowing how to organize environments with Terragrunt prevents drift and makes scaling infrastructure easier.

6

Advanced

Handling Remote State and Locking with Terragrunt

🤔Before reading on: do you think Terragrunt manages Terraform state files differently or just configures them? Commit to your answer.

Concept: Terragrunt configures remote state storage and locking to keep Terraform state safe and consistent.

Terragrunt lets you define backend settings once, like using an S3 bucket with DynamoDB locking for state files. All Terraform projects use this shared config, preventing conflicts and lost updates.

Result

Your infrastructure state is stored securely and changes are coordinated across teams.

Understanding state management with Terragrunt is key to avoiding common Terraform pitfalls in team environments.

7

Expert

Advanced Terragrunt Internals and Best Practices

🤔Before reading on: do you think Terragrunt executes Terraform commands itself or just generates configs? Commit to your answer.

Concept: Terragrunt wraps Terraform commands, manages config generation, and supports complex workflows with hooks and automation.

Terragrunt runs Terraform commands under the hood, injecting shared configs and managing dependencies. It supports hooks to run scripts before or after Terraform commands, enabling automation like validation or notifications. Experts use Terragrunt to enforce policies and streamline multi-module deployments.

Result

You can build robust, automated infrastructure pipelines that reduce manual errors and speed up delivery.

Knowing Terragrunt's internal command wrapping and hooks unlocks powerful automation and control in real-world infrastructure management.

Under the Hood

Terragrunt works by reading its own configuration files, which specify shared settings and dependencies. When you run Terragrunt commands, it generates temporary Terraform configuration files that include these shared settings. Then it calls Terraform with these generated files. This way, Terraform sees a complete configuration without repeated code. Terragrunt also manages remote state backends and locking by injecting backend configs automatically. It tracks dependencies between modules and runs Terraform commands in the correct order.

Why designed this way?

Terragrunt was created to solve the problem of repeated Terraform code and complex multi-module setups. Instead of changing Terraform itself, which is stable and widely used, Terragrunt acts as a wrapper to add features without breaking compatibility. This design allows teams to adopt Terragrunt incrementally and keep using Terraform's core strengths. Alternatives like copying code or complex scripting were error-prone and hard to maintain, so Terragrunt's approach balances power and simplicity.

┌───────────────┐
│ Terragrunt CFG│
│ (shared code) │
└──────┬────────┘
       │ generates
┌──────▼────────┐
│ Terraform CFG │
│ (combined)   │
└──────┬────────┘
       │ runs
┌──────▼────────┐
│ Terraform CLI │
│ (creates infra)│
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does Terragrunt replace Terraform entirely? Commit to yes or no.

Common Belief: Terragrunt is a replacement for Terraform and you no longer need Terraform if you use Terragrunt.

Reality: Terragrunt is a wrapper around Terraform that helps organize and reuse Terraform code; it does not replace Terraform itself.

Why it matters: Thinking Terragrunt replaces Terraform can lead to confusion and misuse, causing teams to miss out on Terraform's core features and updates.

Quick: Can Terragrunt automatically fix all Terraform code duplication? Commit to yes or no.

Common Belief: Terragrunt automatically removes all code duplication without any manual setup.

Reality: Terragrunt helps reduce duplication by sharing configs, but you still need to organize your code and write reusable modules properly.

Why it matters: Expecting automatic fixes can cause frustration and messy code if you don't plan your infrastructure structure carefully.

Quick: Does Terragrunt manage Terraform state files itself? Commit to yes or no.

Common Belief: Terragrunt stores and manages Terraform state files independently from Terraform.

Reality: Terragrunt configures where Terraform stores its state files but Terraform itself manages the state.

Why it matters: Misunderstanding state management can lead to state conflicts or loss if teams think Terragrunt handles state directly.

Quick: Can Terragrunt run Terraform commands in any order regardless of dependencies? Commit to yes or no.

Common Belief: Terragrunt does not manage the order of Terraform module execution; you must do it manually.

Reality: Terragrunt can manage dependencies and run Terraform modules in the correct order automatically.

Why it matters: Not leveraging Terragrunt's dependency management can cause deployment errors and wasted time.

Expert Zone

1

Terragrunt's use of temporary generated Terraform configs means debugging requires understanding both Terragrunt and Terraform outputs.

2

Terragrunt supports 'locals' and 'inputs' that can be overridden at multiple levels, allowing flexible but complex configuration hierarchies.

3

Hooks in Terragrunt enable integration with external tools for validation, security scanning, or notifications, which is often overlooked but powerful.

When NOT to use

Terragrunt is less useful for very small projects or single-module setups where code reuse is minimal. In such cases, plain Terraform is simpler. Also, if you prefer full control over Terraform commands without wrappers, or use other orchestration tools like Pulumi or CloudFormation, Terragrunt may not fit well.

Production Patterns

In production, teams use Terragrunt to manage multi-account, multi-region infrastructures with shared networking and security modules. They organize environments in folders with Terragrunt configs inheriting from a root config. CI/CD pipelines run Terragrunt commands with hooks for testing and compliance. Dependency blocks ensure modules deploy in the right order, preventing errors.

Connections

Software Design Patterns

Terragrunt's DRY approach builds on the same principle as the 'Template Method' pattern, where common behavior is defined once and reused.

Understanding software design patterns helps grasp why sharing configuration reduces bugs and improves maintainability in infrastructure code.

Makefile Dependency Management

Terragrunt's dependency blocks are similar to how Makefiles specify build order and dependencies between tasks.

Knowing how Makefiles manage dependencies clarifies how Terragrunt ensures Terraform modules run in the correct sequence.

Lean Manufacturing

Terragrunt's elimination of repeated code mirrors Lean principles of reducing waste and improving efficiency.

Seeing Terragrunt as a tool to remove waste in infrastructure code connects cloud engineering to broader efficiency practices.

Common Pitfalls

#1 Copying Terraform code for each environment instead of using Terragrunt.

Wrong approach:

├── prod
│ └── main.tf (copied from dev)
├── dev
│ └── main.tf
# Each file repeats same code with small changes

Correct approach:

├── terragrunt.hcl (shared config)
├── prod
│ └── terragrunt.hcl (overrides variables)
├── dev
│ └── terragrunt.hcl (overrides variables)
# Shared code in root, environments override only needed parts

Root cause:

Not understanding how Terragrunt can share configuration leads to manual copying and duplication.

#2 Running Terraform commands directly without Terragrunt in a multi-module setup.

Wrong approach:

cd moduleA && terraform apply
cd moduleB && terraform apply
# Manual ordering and no shared config

Correct approach:

terragrunt run-all apply
# Terragrunt runs modules in order with shared configs

Root cause:

Ignoring Terragrunt's command wrapping misses its automation benefits.

#3 Defining backend configuration separately in every Terraform module.

Wrong approach:

terraform {
backend "s3" {
bucket = "my-bucket"
key = "state.tfstate"
region = "us-east-1"
}
}
# Repeated in every module

Correct approach:

In terragrunt.hcl:
remote_state {
backend = "s3"
config = {
bucket = "my-bucket"
key = "state.tfstate"
region = "us-east-1"
}
}
# Defined once and reused

Root cause:

Not using Terragrunt's remote_state block causes repetition and risk of inconsistent state configs.

Key Takeaways

Terragrunt helps keep Terraform code DRY by sharing common configuration across projects.

It works as a wrapper that generates combined Terraform configs and manages dependencies automatically.

Using Terragrunt reduces errors, saves time, and makes multi-environment infrastructure easier to manage.

Understanding Terragrunt's internal command wrapping and hooks unlocks powerful automation capabilities.

Misconceptions about Terragrunt replacing Terraform or managing state directly can cause serious mistakes.

Practice

1. What is the main purpose of using Terragrunt with Terraform?

easy

A. To reuse Terraform configurations and avoid repeating code

B. To replace Terraform with a new tool

C. To write Terraform code in a different programming language

D. To deploy applications without infrastructure

Solution

1. Step 1: Understand Terragrunt's role

   Terragrunt is designed to help reuse and share Terraform code, making it easier to manage infrastructure without repeating code.

2. Step 2: Compare options

   Options B, C, and D describe incorrect uses or misunderstandings of Terragrunt's purpose.

3. Final Answer:

   To reuse Terraform configurations and avoid repeating code -> Option A

4. Quick Check:

   Terragrunt = DRY Terraform code reuse [OK]

Hint: Terragrunt helps avoid repeating Terraform code [OK]

Common Mistakes:

• Thinking Terragrunt replaces Terraform
• Believing Terragrunt changes Terraform language
• Confusing Terragrunt with application deployment tools

2. Which of the following is the correct way to include a Terraform module using Terragrunt?

easy

A. module "app" { source = "./app" }

B. include { path = find_in_parent_folders() }

C. terraform { backend = "s3" }

D. resource "aws_instance" "web" {}

Solution

1. Step 1: Identify Terragrunt syntax for including configs

   Terragrunt uses the include block with path = find_in_parent_folders() to reuse parent configs.

2. Step 2: Differentiate from Terraform syntax

   Options A, C, and D are Terraform syntax: A is a module block, C is backend config, D is a resource block, not Terragrunt includes.

3. Final Answer:

   include { path = find_in_parent_folders() } -> Option B

4. Quick Check:

   Terragrunt include uses find_in_parent_folders() [OK]

Hint: Terragrunt includes parent config with include + find_in_parent_folders() [OK]

Common Mistakes:

• Using Terraform module syntax instead of Terragrunt include
• Confusing backend config with include
• Writing resource blocks inside Terragrunt files

3. Given this Terragrunt configuration snippet:

include {
  path = find_in_parent_folders()
}

inputs = {
  region = "us-east-1"
  env    = "prod"
}

What will happen when you run terragrunt apply in this folder?

medium

A. Terragrunt will apply Terraform code without any variables

B. Terragrunt will fail because inputs cannot be used with include

C. Terragrunt will ignore the inputs block and only use parent config

D. Terragrunt will apply Terraform code using the parent config and inputs region=us-east-1, env=prod

Solution

1. Step 1: Understand include and inputs usage

   The include block imports parent config. The inputs block adds or overrides variables for this folder.

2. Step 2: Predict Terragrunt behavior on apply

   Terragrunt merges parent config with local inputs, so region and env variables are set as given.

3. Final Answer:

   Terragrunt will apply Terraform code using the parent config and inputs region=us-east-1, env=prod -> Option D

4. Quick Check:

   Include + inputs = merged config applied [OK]

Hint: Inputs override or add variables when using include [OK]

Common Mistakes:

• Thinking inputs are ignored with include
• Assuming inputs cause errors
• Believing variables are not passed to Terraform

4. You wrote this Terragrunt config:

include {
  path = find_in_parent_folders()
}

inputs = {
  region = "us-west-2"
  env = "dev"
}

terraform {
  source = "../modules/app"
}

When running terragrunt apply, you get an error: "Error: Unsupported block type". What is the likely cause?

medium

A. The terraform block cannot be nested inside the inputs block

B. The inputs block must come before include

C. The source path is incorrect

D. The region variable is invalid

Solution

1. Step 1: Check Terragrunt config block usage

   Terragrunt requires the terraform { source = ... } block at the root level. It cannot be nested inside other blocks like inputs.

2. Step 2: Identify error cause

   The error "Unsupported block type" usually means the block is misplaced or invalid in Terragrunt config.

3. Final Answer:

   The terraform block cannot be nested inside the inputs block -> Option A

4. Quick Check:

   Misplaced terraform block causes error [OK]

Hint: Terraform block must be correctly placed in Terragrunt config [OK]

Common Mistakes:

• Placing terraform block inside inputs or include
• Wrong order of blocks causing syntax errors
• Incorrect source path causing unrelated errors

5. You manage multiple environments (dev, staging, prod) with Terragrunt. You want to avoid repeating the backend configuration for each environment. Which approach best follows DRY principles?

hard

A. Define backend only in Terraform modules, not in Terragrunt

B. Copy the backend block into each environment's Terragrunt config

C. Create a root Terragrunt config with backend settings and use include in each environment folder

D. Use different backend types for each environment

Solution

1. Step 1: Understand DRY with Terragrunt

   Terragrunt allows sharing common config via a root config and include blocks in child folders.

2. Step 2: Evaluate options for backend reuse

   Create a root Terragrunt config with backend settings and use include in each environment folder uses root config for backend, avoiding repetition. Copy the backend block into each environment's Terragrunt config repeats code, violating DRY. Define backend only in Terraform modules, not in Terragrunt is incorrect because backend is configured in Terragrunt for remote state. Use different backend types for each environment adds complexity without reuse.

3. Final Answer:

   Create a root Terragrunt config with backend settings and use include in each environment folder -> Option C

4. Quick Check:

   Root config + include = DRY backend config [OK]

Hint: Put shared backend in root config, include it in environments [OK]

Common Mistakes:

• Copying backend config to each environment
• Configuring backend only in Terraform modules
• Using different backends unnecessarily