Open syang opened 5 years ago
Thanks for opening an issue and asking.
Here is an unstructured list of my thoughts :)
Terragrunt is the 3rd-party tool which is often looked as incomplete, "not-solid-enough-for-us", unfortunately. I have been using it for many years in dozens of projects - so far so good, believe me :)
In order to orchestrate Terraform modules, some companies develop their own ~terragrunt-killer~ similar tools which are often worse but they now own it and have to maintain. I think they are doing it wrong in most cases. One of the best alternatives I saw was a Makefile
with dozens of commands.
HashiCorp offers two paid Terraform offerings - Terraform Cloud and Terraform Enterprise.
Both of these offerings are using Terraform CLI and there is no way to integrate with Terragrunt in a native way (you can't provide your own binary yet, for example).
Also, both Terraform Saas offerings almost require developers to use workspaces while Terragrunt allows developers to keep code DRY and easier to understand without using workspaces.
Note that Terraform workspaces in CLI and in Saas offerings are not a one-to-one match.
Once started with Terraform, it is possible to upgrade configurations from using Terraform open-source to any Terraform Saas offering or to use Terragrunt.
On the opposite side, it can be pretty hard to convert from Terraform Saas to Terragrunt (workspaces, opinionated code structure).
Terraform 0.12 release did not affect the need for Terraform module orchestrator (eg, Terragrunt), because always there is a need to handle infrastructure configurations differently at least between these groups of people:
Terraform 0.12 helps Terraform developers very much. For example, now there is Terraform S3 Bucket module, which creates S3 buckets in ANY configuration (see main.tf). Terraform users can just use it and they don't have to know how does it work and why it is so complicated inside.
Terraform users got nice HCL2 syntax (short and correct). That's it. They should not be overexcited with for_each
and dynamic
features which Terraform 0.12 has.
I believe that most of the features provided by Terragrunt should become part of Terraform CLI at some point.
@syang @abrabah @StevePorter92 👆
Just leaving my 2 cents, the new Terragrunt v19.0+ I think is a game changer in the way that you are now able pull in dependencies dynamically through the dependency
block (just introduced a month ago) so now you don't need to spend all that time writing data.remote_state....
references between all the connecting modules. This allows you to call the most widely used open source modules like the ones @antonbabenko release directly in the configuration and pipe data around like this.
dependency "vpc" {
config_path = "../../network/vpc"
}
inputs = {
vpc_id = dependency.vpc.outputs.vpc_id
}
Before you were always put in the awkward position of where to situate the remote state references. Now you can do a lot of that within the terragrunt or you can drop raw terraform in to the module level config directly to give extra levels of control.
@robc-io I agree that having a solution for dynamic dependencies is a good thing. This was exactly the reason why I started tfvars-annotations - update values in terraform.tfvars using annotations.
2 years later thoughts?
This is a good question and thanks for the reminder of the existence of this repository! :)
I don't have enough time to express my complete point of view on this right now but there are a couple of points:
I don't want to go into more details right now but I will make a more thorough breakdown with some alternatives during Q1-Q2 2022.
Benefits of Terragrunt?
Terragrunt vs. Terraform SaaS?
Sharing some of your thoughts would be helpful