Skip to main content
Knowledge Base

Terragrunt architecture best practices?

Answer

I’m getting started with Terragrunt and want to make sure I have this conceptually right. It looks like we can only source a single module from, e.g. `my-app/terragrunt.hcl`. So if my app needs, say, an ASG, a security group, and a load balancer, I might create `modules/my-app/` and source 3 modules from there. Is that right? Having the `terragrunt.hcl` reference a fairly specific module that references 3 other re-usable modules seems a bit odd to me, so I’m not sure I’m thinking about this right. Especially since we’re using Gruntwork modules, so each of those three re-usable modules is really a wrapper for a Gruntwork module. The chain of nested modules seems to get long pretty quickly.

The core of Terragrunt architecture is considering how you want to break apart the Terraform state. While Terraform is optimized for working with a single state file, Terragrunt supports breaking apart your Terraform state into multiple component infrastructure through it's many features like `dependency`. However, since Terragrunt ultimately relies on Terraform under the hood, it is limited by Terraform's ability to have a single root module, and that's why you still need to define a single Terraform module to act as the root module for Terragrunt to invoke at the folder level. The way we at Gruntwork think about this is to differentiate between Services and Modules (See our [blog post on Modules, Services, and Architectures](https://blog.gruntwork.io/introducing-the-gruntwork-module-service-and-architecture-catalogs-eb3a21b99f70) for more details). The Service module is an opinionated, specific way to deploy components that fit the needs of your organization, which is less reusable, but is designed to be directly deployed by Terragrunt. If you look at our Service module for the ASG ([asg-service](https://github.com/gruntwork-io/terraform-aws-service-catalog/tree/master/modules/services/asg-service)), you will see that it combines the Gruntwork modules to construct the deployable ASG unit. Given that, you should be striving for 2 links in your chain: Services and Modules. That is, when extending Gruntwork modules, it is oftentimes much better organizationally to extend them in the Service layer by combining Gruntwork modules with resources and modules to create the deployable unit, rather than extending Gruntwork modules to create more Modules. This should significantly help with the dependency management.