4 ms·
I’ve been using Terragrunt [0] for the past three years to manage loosely coupled stacks of Terraform configurations. It allows you to compose separate configur
by time0ut 3y ago
I’ve been using Terragrunt [0] for the past three years to manage loosely coupled stacks of Terraform configurations. It allows you to compose separate configurations almost as easily as you compose modules within a configuration. Its got its own learning curve, but its a solid tool to have in the tool box.
Gruntwork is a really cool company that makes other tools in this space like Terratest [1]. Every module I write comes with Terratest powered integration tests. Nothing more satisfying than pushing a change, watching the pipeline run the test, and then automatically release a new version that I know works (or at least what I tested works).
[0] https://terragrunt.gruntwork.io/ https://terragrunt.gruntwork.io/
[1] https://terratest.gruntwork.io/ https://terratest.gruntwork.io/
- mike_d 3y agoThey seem very insistent on keeping things DRY but not explaining why. Does Terraform tend to cause water leaks?
- SgtBastard 3y agoDRY = Don’t Repeat Yourself.
- raffraffraff 3y agoTerraform is supposed to let you write modular, reusable code. But because it's a limited DSL that lacks many "proper language" features (and occasionally breaks the rule of least-suprise). There are several major impediments to fully data-driven terraform. These ultimately result in copy/paste code, or tools like terragrunt which essentially wrap terraform and perform the copy/pasta behind your back by generating that code for you. Some minor examples: - calling a module multiple times using `for_each` to iterate over data works, except if the module contains a "provider" block - if you are deploying two sets of resources by iterating over data, terraform can detect dependency cycles where there are not any