Introduction

In this article, I will introduce Terragrunt a widely-used tool that enhances Terraform by promoting DRY practices. I will also show you how to deploy resources on the Google Cloud Platform (GCP) using Terragrunt.

By walking through a practical example, you’ll learn how to streamline your Terraform configurations, improve code maintainability, and efficiently manage your cloud infrastructure in GCP.

Notice: Before proceeding with this article, ensure you have a basic understanding of Terraform.

Terraform is an Infrastructure as Code (IAC) tool that provisions and manages infrastructure (resources) in any cloud or data center. It’s a powerful tool for IAC, but it can encounter many challenges as projects grow. For example, Terraform configurations can become repetitive and duplicated, especially when handling multiple environments and components, leading to maintenance difficulties.

Additionally, Terraform modules can depend on each other, complicating management and increasing the risk of errors due to manual oversight.

Managing a remote state can also become complex and challenging in large projects, especially when working with multiple environments and different teams. Similarly, provisioning and managing resources across multiple environments and reusing the same components can be tedious and difficult.

Terragrunt offers solutions to all of these challenges.

key features

Keep Terraform DRY

Abstractions, or the “Don’t Repeat Yourself” (DRY) principle, is a well-known software engineering pattern that aims to reduce duplicated code to avoid managing extra configurations and to simplify making changes across the system, which can otherwise be error-prone.

Terragrunt allows you to share configurations across multiple Terraform modules or environments by defining for example the backend configurations, provider configurations, and variables at the root level. This way, all child modules can inherit these settings, eliminating repetition and promoting reusability.

State Management:

Terragrunt stores state files remotely, automatically creating and enabling locking resources (bucket) automatically to manage states. It helps to avoid some manual errors, state overwrites, and shares states across teams. As a result, you can be sure that you are using the correct state configuration without any manual configuration of your modules.

Dependency Management

Usually terraform modules depend on each other; for example, a database or computer instance may depend on the network, requiring you to manage the order in which modules are deployed. Terragrunt allows you to manage dependencies between modules explicitly, ensuring resources are provisioned in the correct order. Additionally, the outputs of modules can be passed to others, streamlining the process.

Environment Management

Managing multiple environments with Terraform requires additional configuration and management through workspaces and variables, which can be tedious and error-prone. Terragrunt simplifies this process by allowing you to define separate configuration files for each environment, reducing code duplication and minimizing errors.

Clarity and Workflow

In large projects with many teams, modules, and resources, Terraform can make it challenging to manage the workflow (init, plan, apply, etc.) across different environments, teams, and modules. Additionally, the configuration files can become cluttered and difficult to maintain. Terragrunt simplifies this by automatically running Terraform commands in the correct order across modules, eliminating the need for manual executing and keeping files organized.

Uses Case

This example is not intended for production use; it demonstrates key features of Terragrunt. It helps keep your terraform code DRY, remote state configuration DRY, and Terragrunt architecture DRY.

This project deploys (a GCE, a MySQL database, an Instance Template, and a VPC) in three environments (dev, stage, and prod)

This project utilizes public Terraform modules for GCP and is inspired by the official Terragrunt documentation.

Source Code:

GitHub - Moncif1/hello_terragrunt

This project organizes and manages different environments and modules, leveraging Terragrunt’s capabilities to simplify the configuration and promote DRY (Don’t Repeat Yourself) principles.

The configuration is designed to be modular and reusable, with a central configuration inherited across different environments or modules.

This setup allows for centralizing configurations, making managing and maintaining common settings across multiple environments and modules easier. Any variables, remote state configurations, or other settings defined in the parent `terragrunt.hcl` will be applied to the module.

Keep Your Terraform DRY

├── development
│   ├── db
│   │   └── terragrunt.hcl
│   │   └── module-vars.hcl
│   ├── gce
│   │   └── terragrunt.hcl
│   │   └── module-vars.hcl
│   ├── template
│   │   └── terragrunt.hcl
│   │   └── module-vars.hcl
│   ├── vpc
│   │   └── terragrunt.hcl
│   │   └── module-vars.hcl
│   └── env-vars.hcl
│    ...   
├── production
│   ├── db
│   │   └── terragrunt.hcl
│   │   └── module-vars.hcl
│   ├── gce
│   │   └── terragrunt.hcl
│   │   └── module-vars.hcl
│   ├── template
│   │   └── terragrunt.hcl
│   │   └── module-vars.hcl
│   ├── vpc
│   │   └── terragrunt.hcl
│   │   └── module-vars.hcl
│   │   └── Readme.md
│   └── env-vars.hcl
└── terragrunt.hcl
└── Readme.md       
└── common-vars.hcl

This architecture manages different environments (development, stageand production) and various components (db, gce, template, vpc).

• terragrunt.hcl at the root level is used for setting global configurations applicable across all environments and modules.
• common-vars.hcl contains common variable definitions shared among different modules and environments.
• env-vars.hcl contains environment-specific variable definitions.

In each environment, you have different components (e.g., db, gce, template, vpc). Each component directory contains its own terragrunt.hcl and module-vars.hcl files.

Notes:

This Terragrunt Project does the following:

1. Loads Configuration Variables:

• Common Variables: Loads common infrastructure variables from common-vars.hcl.
• Environment Variables: Loads environment-specific variables from env-vars.hcl.
• Module Variables: Loads module-specific variables from module-vars.hcl.

locals {
  # Load Hello World Infra variables
  common_vars = read_terragrunt_config(find_in_parent_folders("common-vars.hcl"))

  # Load Env variables
  env_vars = read_terragrunt_config(find_in_parent_folders("env-vars.hcl"))

  # Load Module variables
  module_vars = read_terragrunt_config("./module-vars.hcl")
  env            = local.env_vars.locals.env
  project_id = local.env_vars.locals.project_id
  module_name    = local.module_vars.locals.module_name
  module_source  = local.common_vars.locals["${local.module_name}_base_url"]
  module_version = local.common_vars.locals["${local.module_name}_base_version"]
}

2. Remote State

• Creates Remote State for each component
• every component state will be managed in a different state file
• Google Cloud Storage (GCS) is the backend for storing Terraform state files.

remote_state {
  backend = "gcs"

  config = {
    project = "${local.project_id}"
    location = "eu"
    bucket   = "hw-tf-backend-${local.env}"
    prefix   = "hw/dsi/${local.module_name}"
    credentials = "${get_env("GOOGLE_APPLICATION_CREDENTIALS")}"
  }

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

3. Inputs

• Merges the variables from the common, environment, and module-specific configurations. (Pay attention to the order, the last value is the module value)

inputs = merge(
  local.common_vars.locals,
  local.env_vars.locals,
  local.module_vars.locals
)

4. Terraform Source

• Specifies the source and version of the Terraform module to be used, which may vary across environments.

terraform {
  source  = "${local.module_source}=${local.module_version}"
}

5. Component

Each component (such as DB or GCE) makes use of Terragrunt’s features, including inheriting parent configurations, managing dependencies, and dynamically passing inputs.

include "root" {
  path = find_in_parent_folders()
}


dependency "vpc" {
  config_path = "../vpc"
  mock_outputs_merge_with_state = true
    mock_outputs        = {
      subnetwork = "hw-network-self-link"
    }

}


inputs = {
  subnetwork = dependency.vpc.outputs.subnetwork,
}

Terragrunt configuration file does the following:

1. Includes Parent Configuration: Inherits configurations from a parent terragrunt.hcl file, enabling consistent settings across environments and avoiding duplication.
2. Manages Dependencies: Defines a dependency to vpc
3. Passes Inputs: Uses the outputs from dependencies as inputs to other modules, allowing dynamic infrastructure management.

By following this setup, you can manage your Terraform infrastructure dynamically and efficiently across different environments and modules, keeping it modular and maintainable.

For more details about the project, please refer to the README file.

Usage:

Basic command:

Most Terragrunt commands use the Terraform command.

• Terragrunt will automatically call Terragrunt init during other commands (e.g. terragrunt plan).

Terragrunt init ===> creates automatically the bucket for remote state
Terragrunt plan 
Terragrunt apply
Terragrunt destroy
# for multiples modules at ones
Terrragrunt run-all plan
Terrragrunt run-all apply 
Terrragrunt run-all destroy

• You can deploy the project (Hello World), by component or at once.

Conclusion:

Through this article, we’ve explored an example of how to use Terragrunt to deploy resources on the Google Cloud Platform with different environments, illustrating the practical benefits of adopting DRY practices in Terraform.

By integrating Terragrunt into your workflow, you can streamline your infrastructure management, making your codebase cleaner, more organized, and easier to maintain over the long term.

Keep Terraform DRY was originally published in Devoteam I Google Cloud Partner on Medium, where people are continuing the conversation by highlighting and responding to this story.