How to structure repo without repeating terragrunt code? about terragrunt HOT 5 CLOSED

Hi,
some ideas can be collected from:
https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example
https://github.com/gruntwork-io/terragrunt-infrastructure-live-example

from terragrunt.

Hi @denis256,

Thank you for the links. Most of my current terragrunt structure came up from your live example repo but I find out the same problem.

All my modules are separated in different repos. So I don't need to be worry about its Terraform content in the Terragrunt project, just applying the correct git tag for each module declaration on the clients folder. My problem remains with the live example. As you suggest, I will have something similar as the environment splitting that you have in the live-example but with different clients (we don't manage different environment per client)

In the live-example you have declared the mysql module three times, one per environment. The three files mostly have the same content on each (except prod where you declare some inputs) As I will have more than 20 clients, I would like to avoid creating the same module declaration on each client folder as right now we declare more than 15 modules per client.

Most of the problems I have are with folder disposition as Terragrunt is looking for child folders and my module declaration structure is at the same level as the client/environment folder level, not inside the environments/clients (like the second example I put in the first comment) As I said I tested with symlinks but I was not able to pass the vars and locals from client folder to live folder as "find_in_parent_folders" won't work as espected because they are not under client/envs folder.

I don't know if right now is possible to call to parent folders and read the vars/locals from it.

├── live
│ ├── app
│ │ └── terragrunt.hcl
│ ├── mysql
│ │ └── terragrunt.hcl
│ └── vpc
│ │ └── terragrunt.hcl
├── clients
│ ├── terragrunt.hcl <- provider/state config for all clients
│ ├── client1
│ │ └── vars.hcl
│ │ └── terragrunt.hcl <- live folder call and pass vars/locals to live folder
│ ├── clientX
│ │ └── vars.hcl
│ │ └── terragrunt.hcl

Thank you again for the time and the support.

from terragrunt.

Hey @i2sarroyo ,

Please take a look at the following issue.

Note how in that example, code is accessed from sibling or cousin directories without having to find the folder via find_in_parent_folders. This is how Terragrunt code can be re-used efficiently for the same use-case.

Typically, a pattern we've seen for large codebases is to have a directory of shared configurations (let's call this directory _shared) with files that pertain to repeated configuration (let's say _shared/app.hcl).

From the client1 directory in your example, you would have an app directory with a terragrunt.hcl file within it that has two include blocks:

1. A root include, which looks like the following:

include "root" {
    path = find_in_parent_folders()
}

This will pull in the terragrunt.hcl file currently located under clients (you can have it at the root of your repo if you would prefer that), and that will setup the provider/state config for all terragrunt.hcl files.

2. Another include for the relevant shared configuration:

include "app" {
    path = "${get_repo_root()}/_shared/app.hcl"
}

This will pull in the shared configurations for apps, and if a particular client has configurations that need to override the shared configurations, you can also specify value in inputs in the app/terragrunt.hcl file for that client.

Note that this will require copying and pasting the same app/terragrunt.hcl file into each of your clientX folders, but this is the most sustainable way Terragrunt can currently handle this kind of pattern, while maintaining its flexibility.

Please let me know if that would meet your needs.

from terragrunt.

Hi @yhakbar,

Thank you so much for the detailed explanation. I was doing something similar that I take from the live-example with the _envcommon folder, but with your explanation everything is much clear.

The last part that you mention about copying and pasting the folders for the module is what I wanted to avoid. I'm afraid that our modules are not design to work "by default", they wait for specific configuration as they don't work with a "standar" config so it implies I need to create a folder + terragrunt.hcl for each module per client so I can pass them the client config as an input 😔

I think that for now I'm going to keep my current configuration and keep an eye out to Terragrunt project in case in the future it evolve for this kind of pattern.

Thank you again for the help and support, I do really appreciate it.

from terragrunt.

Any time, @i2sarroyo !

If you have a proposal for a better way of handling your use-case, please make your voice heard and create an issue using the feature request template to document how you wish Terragrunt worked.

I'm going to close out this issue, as I think we've addressed your concerns.

from terragrunt.