Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] Can you share some thoughts on Terragrunt in the context of upcoming 0.12 and Terraform SaaS? #1

Open
syang opened this issue May 14, 2019 · 6 comments

Comments

@syang
Copy link

syang commented May 14, 2019

Benefits of Terragrunt?

Terragrunt vs. Terraform SaaS?

Sharing some of your thoughts would be helpful

@antonbabenko
Copy link
Owner

Thanks for opening an issue and asking.

Here is an unstructured list of my thoughts :)

Current state

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

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 users:
    • Use Terraform modules by specifying correct values
    • Domain experts
    • May not have "Terraform" in LinkedIn profile
  • Terraform developers:
    • Write and support Terraform modules (in-house, or externally, like me)
    • Implement company’s standards (security, encryption, integrations)
    • Maintain reference architectures (in-house, or externally as this repo)

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.

Future

I believe that most of the features provided by Terragrunt should become part of Terraform CLI at some point.

Available hacks (ideas)

  1. There are hacky ways like converting from Terragrunt to Terraform code on each push which is prone to errors and bugs. Developers work with Terragrunt configs, which is being converted into Terraform.

@antonbabenko
Copy link
Owner

@syang @abrabah @StevePorter92 👆

@robcxyz
Copy link

robcxyz commented Sep 5, 2019

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.

@antonbabenko
Copy link
Owner

antonbabenko commented Sep 5, 2019

@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
.

@joshuabalduff
Copy link

2 years later thoughts?

@antonbabenko
Copy link
Owner

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:

  1. I hope to have @brikis98 (Yevgeny Brikman is the original creator of Terragrunt) on my YouTube channel talking about Terragrunt and answering some of the questions live during Q1 2022. Subscribe here - http://bit.ly/terraform-youtube
  2. I personally believe that in many cases Terragrunt is not as much needed anymore and using Terraform 0.13+ with proper tooling (shell scripts, workflow engine, specialized CI/CD, etc) often gives better results.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants