3 ms·

Everybody in here is recommending tarragrunt, but I'm not sure what value it provides over regular terraform. After using it for a few months all of the featur

Everybody in here is recommending tarragrunt, but I'm not sure what value it provides over regular terraform. After using it for a few months all of the features found in tarragrunt are in terraform.

jbjohns 3y ago
This is my impression as well. As far as I've understood, terragrunt was made back when terraform was missing a lot of key features (I think it maybe didn't even have modules yet) but when I was asked to evaluate it recently for a client I couldn't find a single reason to justify adding another tool.
- linuxdude314 3y ago
  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.
  - OJFord 3y ago
    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)?
    - 333throwaway342 3y ago
      providers do not support `for_each` or `count`
    - deleted 3y ago
      [deleted]
    - linuxdude314 3y ago
      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).
yellowapple 3y ago
Terragrunt shines in cases where you have independent sets of Terraform state, especially if they are dependencies/dependents of one another. For example, say you're using Terraform to manage AWS resources, and you've provisioned an Active Directory forest that you in turn want to manage with Terraform via the AD provider. Terraform providers can't dynamically pull things like needed credentials from existing state, so you end up needing two separate Terraform states: one for AWS (which outputs the management credentials for the AD servers you've provisioned) and one for AD (which accepts those credentials as config during 'terraform init'). Terragrunt can do this in an automated way within a single codebase, redefining providers and handling dependency/dependent relationships. I don't know of a way to do it in pure Terraform that doesn't entail manual intervention.
- nwmcsween 3y ago
  Ideally you decouple this and store the creds in a key vault or whatever, this way you have to explicitly grant access to the service principal to access the kv secret. Decoupling usually fixes other issues as well such as expiring creds from service a to service b will then get coded into terraform to refresh.
maccard 3y ago
We migrated from terragrunt to terraform as we thought the same thing. I'm in half a mind to go back. Managing multiple environments is much easier in TG. State management in TF is kneecapped by the lack of variable support in backend blocks. I can only assume it's to encourage people into using terraform cloud for state management.

Everybody in here is recommending tarragrunt, but I'm not sure what value it provides over regular terraform. After using it for a few months all of the features found in tarragrunt are in terraform.

jbjohns 3y ago

This is my impression as well. As far as I've understood, terragrunt was made back when terraform was missing a lot of key features (I think it maybe didn't even have modules yet) but when I was asked to evaluate it recently for a client I couldn't find a single reason to justify adding another tool.

linuxdude314 3y ago
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.
- OJFord 3y ago
  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)?
  - 333throwaway342 3y ago
    providers do not support `for_each` or `count`
  - deleted 3y ago
    [deleted]
  - linuxdude314 3y ago
    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).

yellowapple 3y ago

Terragrunt shines in cases where you have independent sets of Terraform state, especially if they are dependencies/dependents of one another. For example, say you're using Terraform to manage AWS resources, and you've provisioned an Active Directory forest that you in turn want to manage with Terraform via the AD provider. Terraform providers can't dynamically pull things like needed credentials from existing state, so you end up needing two separate Terraform states: one for AWS (which outputs the management credentials for the AD servers you've provisioned) and one for AD (which accepts those credentials as config during 'terraform init'). Terragrunt can do this in an automated way within a single codebase, redefining providers and handling dependency/dependent relationships. I don't know of a way to do it in pure Terraform that doesn't entail manual intervention.

nwmcsween 3y ago
Ideally you decouple this and store the creds in a key vault or whatever, this way you have to explicitly grant access to the service principal to access the kv secret. Decoupling usually fixes other issues as well such as expiring creds from service a to service b will then get coded into terraform to refresh.

maccard 3y ago

We migrated from terragrunt to terraform as we thought the same thing. I'm in half a mind to go back. Managing multiple environments is much easier in TG. State management in TF is kneecapped by the lack of variable support in backend blocks. I can only assume it's to encourage people into using terraform cloud for state management.