#terragrunt - December 2018

The icon is Gruntwork logo, not terragrunt product ;) There is an open issue about missing logo for terragrunt

Haha yea

I guess I should rename the icon

It was a compromise

Yeah, np really

Do you need icon for modules.tf ? I will make one :))

haha, go for it

There's a #terragrunt channel!! 😳😍

But of course! We don’t discriminate :P

LOL

So, I’m just starting out with Terraform. There is not a lot of complexity in our stack, but I want to get off on the right foot and keep things simple. So far, I’m not a big fan of having nearly identical backend configs everywhere, and also I don’t really feel comfortable with the notion of workspaces. Seems like Terragrunt could address these concerns, but it’s a wrapper and I don’t know if it’s a good idea for me to be starting off with it. Thoughts? Should I try to incorporate Terragrunt in to the solution, or keep to Terraform for now and come back when I have more experience and legitimate issues that need to be solved?

Good questions… so I think that it’s a good idea to first master the fundamentals of terraform before relying on terragrunt. It’s possible to keep things dry without needing to use the wrapper approach. I’m also not keen on relying on terragrunt as a wrapper, but have used it in a few circumstances.

I don’t like how the varfiles are overloaded with interpolations which make them non-portable

Have you seen https://github.com/uber/astro?

We’re not currently using it, but it’s an interesting alternative

We’re using mostly Makefiles if we need any more complex orchestration

We’re using this script to initialize state: https://github.com/cloudposse/geodesic/blob/master/rootfs/usr/local/bin/init-terraform

that way we don’t need to hardcode any backend configs in source control

Also terragrunt it might take some time before terragrunt supports terraform 0.12 , but that might not matter

Thanks, this is helpful. There is this temptation to try to set everything up perfectly from the get-go, but ultimately it’s a process, and I feel like it’s not healthy to try to skip too many steps in the evolution.

Haha, I can relate to that.

I don’t think you can necessarily go wrong with using terragrunt.

The good thing is you’ll decompose everything nicely into lots of modules and organize things as you should.

You can remove terragrunt as well, down the road.

….that said, have you seen our strategy?

We use docker and multi-stage builds to keep things dry

run everything in containers

…that is, we run even our “infrastructure as code” in containers

Great, more late night reading material for the holidays! Haha, thanks for that, it looks interesting. And thanks for addressing my Terragrunt question; I agree - seems like the key is to get the modules in place and I’ll have flexibility to adjust my approach in the future.

exactly - that’s the most important thing

write small reusable, composable modules that build on each other

do not embed any stage or environment specific settings - those should be inputs (variables)

consider using terraform-null-label to consistently generate resource name

look into chamber for secrets

look into aws-vault for assuming roles

also, recommend studying a lot of other modules to see how they are organized and broken down

Yes, great advice, much appreciated.