But of course! We don’t discriminate :P
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
We’re not currently using it, but it’s an interesting alternative
We’re using mostly
Makefiles if we need any more complex orchestration
I’m not a big fan of having nearly identical backend configs everywhere
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)
terraform-null-label to consistently generate resource name
chamber for secrets
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.