Enhancing the Terraform Experience: Why We Use Terragrunt

https://transcend.io/blog/why-we-use-terragrunt

by Sephr • 6 years ago

59 8 6 years ago

transcend.io

ndomer• 6 years ago

Hello! I authored this post, and would love to get some community feedback.

I've really enjoyed using both Terraform and Terragrunt, and think you and your company would as well.

Please let me know if there are any questions I can answer

expialidocious• 6 years ago

I was wondering what Terragrunt is and now I know, sort of, so thanks.

This is not a space I know much about and I have nothing intelligent to ask, but since you know this space and you're soliciting questions, I'll just ask you to confirm or correct a suspicion I have about "devops" in general.

It seems to me there are currently two competing, mutually exclusive paradigms for deployment at scale. One is to develop and deploy microservices in Docker containers and deploy using Kuberneres, and the other is to deploy cloud images using Terraform and config management tools.

It seems to me that these two approaches are pretty much incompatible, and I must choose one or the other, and there's very little overlap, if any. Do you think this is so, or am I missing something important?

thrixton• 6 years ago

Infrastructure as Code, of which Terraform / Terragrunt is one tool, definitely has its place in the Kubernetes / Docker ecosystem too.

You're right that it's somewhat of an afterthought and most IaC tools are focused on native cloud infrastructure though.

Check out Pulumi, they're doing amazing work extending Terraform (utilizing terraform itself, it's open source), as well as bringing kubernetes support for major cloud provider flavours as well as managing service deployments.

svenwltr• 6 years ago

Well, we deploy our Kubernetes cluster with Terrafprm and then use Kubernetes to deploy our "miniservices".

I do not see why they could be mutually exclusive, but deploying some services via Docker/Kubernetes and some via Config Management is probably less efficient, because one would have to maintain two separate deployment methods.

nikolay2• 6 years ago

Terragrunt should turn polyamorous. Its monogamy with AWS goes against its wider adoption.

hedwall• 6 years ago

Huh? Terragrunt has support for the same things that Terraform supports, a wide variety of different cloud providers (and other API enabled services).

nikolay2• 6 years ago

I guess they no longer have the remote state locking with DynamoDB. Anyway, I see a lot of AWS IAM stuff with no Azure and GCP support equivalent.

vr46• 6 years ago

Terraform has needed a wrapper or helper script to make it properly useful and compatible since the beginning, yet in recent years is becoming more functional to need less wrapping.

Terragrunt, is however, completely the wrong way to go about it and is far from a thin wrapper, but a prescriptive way to go about writing and organizing and managing Terraform code that makes it awkward to retro-fit into existing codebases. We have tried.

If you are starting from zero, that would be a good time to start with Terragrunt, but on the other hand, you probably don’t need it and the added overhead these days.

Toolchains get convoluted, and Terragrunt is an example of the JavaScript kool-aid leaking into Infra, and I would not advise touching it unless you understand what it does and why you need it, which is a good adage for a lot of stuff, as it happens.

Enhancing the Terraform Experience: Why We Use Terragrunt

Related Stories