KodeKloud Notes

The Include Block in Terragrunt enables you to integrate external HCL files or entire directories into your configuration, promoting reusability, reducing duplication, and ensuring consistency across your infrastructure.

Include Block Attributes

Attribute	Description
`path`	Relative or absolute filesystem path to the Terragrunt configuration file or directory.
`find_in_parent_folders()`	Searches parent directories for a matching configuration when set to `true` or used as a function.

The image is an infographic titled "Include Block" showing two attributes: "Path," which defines the location of external config, and "Find_in_parent," which searches for included config in parent folders.

Key Benefits

Reusability
Integrate shared HCL files to avoid rewriting the same remote-state or provider settings.
Consistency
Enforce uniform patterns (naming conventions, tags, backends) across modules.
Efficiency
Follow the DRY principle by centralizing common logic in one place.

The image is an infographic titled "Include Block" that outlines three benefits: promoting reusability through external config, reducing duplication, and ensuring consistency across infrastructure.

Considerations

Override Conflicts
Understand how included blocks inherit or override values in child configurations.
Directory Hierarchy
Deep folder structures with multiple includes may become hard to trace without clear naming.

Warning

Avoid overly complex include hierarchies. Always document your folder layout and include points to prevent configuration drift.

The image is an informational graphic titled "Include Block," highlighting considerations such as being mindful of potential conflicts and how configurations inherit and override settings.

Best Practices

Extract shared logic (remote-state, provider blocks, common locals) into dedicated HCL files.
Use expose = true to make outputs or locals from an included file available to child modules.
Leverage find_in_parent_folders() to avoid hard-coding relative paths.

Note

Place a common.hcl at your repo root for project-wide settings (e.g., tags, metadata) so that every module can include it.

The image features a graphic with a puzzle piece icon, labeled "Include Block," and text stating it is used for organizing and modularizing configs, along with a "Best Practices" button.

Example: Centralizing Remote State

In your root terragrunt.hcl, define the S3 backend:

# root terragrunt.hcl
remote_state {
  backend = "s3"
  config = {
    encrypt        = true
    bucket         = "kodekloud-terragrunt-remote-state"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
  }

  generate = {
    path      = "backend.tf"
    if_exists = "overwrite_terragrunt"
  }
}

In vpc/terragrunt.hcl, include the root remote state:

# vpc/terragrunt.hcl
terraform {
  source = "tfr://terraform-aws-modules/vpc/aws//?version=5.8.1"
}

include "root" {
  path   = find_in_parent_folders()
  expose = true
}

When running terragrunt apply in vpc/, Terragrunt will:

Locate and include the root remote_state block.
Generate backend.tf with the S3 backend settings.
Deploy the VPC module using the shared backend configuration.

Create a common.hcl at the repository root:

# common.hcl
locals {
  project = "KodeKloud"
  owner   = "DevOps Team"
}

Then in each module (e.g., vpc2/terragrunt.hcl):

# vpc2/terragrunt.hcl
terraform {
  source = "tfr://terraform-aws-modules/vpc/aws//?version=5.8.1"
}

include "root" {
  path   = find_in_parent_folders()
  expose = true
}

include "common" {
  path   = find_in_parent_folders()
  expose = true
}

inputs = {
  project = local.project
  owner   = local.owner
}

This approach ensures both remote-state settings and shared locals (like project and owner) are available across modules without repetition.

Links and References

Watch Video