The primary thing terragrunt was designed to do was let you dynamically render providers.
Terraform still does not let you this.
It becomes very problematic when using providers that are region specific, amongst other scenarios.
That being said I don’t like the extra complexity terragrunt adds and instead choose to adopt a hierarchical structure that solves most of the problems being able to dynamically render providers would solve.
Each module is stored in its own git repo.
Top layer or root module contains one tf file that is ONLY imports with no parameters.
The modules being imported are called “tenant modules”. A tenant module contains instantiations of providers and modules with parameters.
The nodules imported by the tenant modules at the ones that actually stand up the infrastructure.
Variables are used, but no external parameters files are used at any level (except for testing).
All of the modules are versioned with git tagged releases so the correct version can easily be imported.
Couple this with a single remote state provider in the root module and throw it in a CI/CD pipeline and you have a gitops driven infrastructure as code pipeline.
What do you mean by 'dynamically render providers'?
I assume you're aware you can instantiate multiple versions (different params) of a provider and pass them to child modules, e.g. you can instantiate a module once for each of a several AWS regions/accounts?
Do you mean that something like the region/account param would be set on the basis of a computed value from some other resource (because we created the account, say, or listed all regions satisfying some filter with a data source)?
Let's say you need to configure a provider for 3 different regions. The natural way you want to do this is store the regions in a variable, and iterate over the variable using "for_each".
What you are referring to are called "provider aliases" and they work well for _avoiding_ using terragrunt (not very DRY though).
Terraform still does not let you this.
It becomes very problematic when using providers that are region specific, amongst other scenarios.
That being said I don’t like the extra complexity terragrunt adds and instead choose to adopt a hierarchical structure that solves most of the problems being able to dynamically render providers would solve.
Each module is stored in its own git repo.
Top layer or root module contains one tf file that is ONLY imports with no parameters.
The modules being imported are called “tenant modules”. A tenant module contains instantiations of providers and modules with parameters.
The nodules imported by the tenant modules at the ones that actually stand up the infrastructure.
Variables are used, but no external parameters files are used at any level (except for testing).
All of the modules are versioned with git tagged releases so the correct version can easily be imported.
Couple this with a single remote state provider in the root module and throw it in a CI/CD pipeline and you have a gitops driven infrastructure as code pipeline.