How to call multiple terraform modules in a single terragrunt file

in Terragrunt, you can call multiple Terraform modules from a single Terragrunt configuration file by using the terraform block in combination with child configurations. This is typically done by organizing your Terragrunt configuration into a hierarchy where each module is referenced in its own Terragrunt file, but managed centrally using a parent Terragrunt file.

Here’s a basic outline of how you can structure this:

1. Create a Parent Terragrunt File: This file won’t directly deploy any resources but will be used to configure common settings and orchestrate module deployment.
2. Create Child Terragrunt Files for Each Module: Each module will have its own Terragrunt configuration file that specifies the source of the Terraform module and any necessary inputs.

Example Structure

Here’s an example directory structure:

/terraform-live
|-- terragrunt.hcl  # Parent configuration
|-- network
|   |-- terragrunt.hcl  # Module configuration for network
|-- app
|   |-- terragrunt.hcl  # Module configuration for app

Parent Terragrunt.hcl

# /terraform-live/terragrunt.hcl
remote_state {
  backend = "s3"
  config = {
    bucket         = "my-terraform-state"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = "us-west-1"
    encrypt        = true
    dynamodb_table = "my-lock-table"
  }
}

# Include all child configurations
include {
  path = find_in_parent_folders()
}

Child Terragrunt.hcl (e.g., for Network)

# /terraform-live/network/terragrunt.hcl
terraform {
  source = "git::https://example.com/network-module.git?ref=v1.0"
}

# Inputs specific to the network module
inputs = {
  vpc_id = "vpc-123456"
}

Usage

To apply all modules, you would typically navigate to each module directory and run Terragrunt commands, like terragrunt apply. You can also automate this with scripts or CI/CD workflows that iterate through module directories and execute Terragrunt commands.

This setup allows you to maintain a clear separation of concerns, reusable code, and consistency across environments while managing the deployment of multiple modules from a centralized configuration.