How to keep your Terraform code DRY by using Terramate
blog.mineiros.io
How to keep your Terraform code DRY by using Terramate
1–10 of 17 posts
Re: How to keep your Terraform code DRY by using Terramate
#2I feel like teams should be using tfe workspaces and env vars to instantiate environments rather than having a folder per-environment. It's pretty easy to replicate this workflow and results in substantially less env drift and code duplication when we do it.
Re: How to keep your Terraform code DRY by using Terramate
#3I feel like teams should be using tfe workspaces and env vars to instantiate environments rather than having a folder per-environment. It's pretty easy to replicate this workflow and results in substantially less env drift and code duplication when we do it.
I tend to use a similar approach, though with Terraform var files instead of env vars. It was also possible to have this work with TF Cloud (and presumably Enterprise?) with a single workspace env var specifying the var file. It might have been improved recently to be a first class feature.
I found this to be my favourite workflow for managing workspace variables in a way that was also flexible to being run outside of TFC/TFE for when that makes sense.
Re: How to keep your Terraform code DRY by using Terramate
#4I used to be obsessed with DRY. After having written tens of thousands of terraform lines in the last few years across a multitude of platforms and use cases, I say everything in moderation.
Going DRY is a decision you pay for in complexity, it's the typical programming problem of genericity. Sometimes it absolutely makes sense and you're a mad man if you skip it, but in isolated cases making things DRY just for the sake of it is just as nuts as not doing it when required.
It's a fine line to walk and it requires hands-on experience to know when to employ DRY and when to repeat yourself.
Re: How to keep your Terraform code DRY by using Terramate
#5I feel like teams should be using tfe workspaces and env vars to instantiate environments rather than having a folder per-environment. It's pretty easy to replicate this workflow and results in substantially less env drift and code duplication when we do it.
How do you only deploy certain resources to certain environment this way? We don't always have matching dev/qa/prod environments.
Re: How to keep your Terraform code DRY by using Terramate
#6I've been using Hiera (Puppet yaml data store) to source data for terraform. As a long time puppet user, when I started writing terraform code I really missed hiera. Turns out someone ported it to Go, and someone else turned that into a terraform provider. It's a game changer. No need for terragrunt or terramate. Hiera can return anything from a single value to a very complex data block that can be used to feed a module or a whole stack. Hiera needs some information about where you're deploying to, and it gets this in the in the provider configuration in the form of key/vals: I use environment, region & stack. I decided to use a workspace naming convention that encodes these (eg: prod_use1.network). For each workspace, terraform can automatically figure out exactly what lookups it needs to do, and hiera returns native terraform data relevant to that workspace only. I have 100% dry code, and no need to create a separate directory for each environment/region state. I run my terraform init/apply in the top-level directory no matter where I'm deploying. The result is that once I've written my modules and stacks, I can build out a whole data center by creating few workspaces and running "terraform init && terraform apply" in each one. Zero extra files or directories. Dry as a bone
Re: How to keep your Terraform code DRY by using Terramate
#7I've been using Hiera (Puppet yaml data store) to source data for terraform. As a long time puppet user, when I started writing terraform code I really missed hiera. Turns out someone ported it to Go, and someone else turned that into a terraform provider. It's a game changer. No need for terragrunt or terramate. Hiera can return anything from a single value to a very complex data block that can be used to feed a mod…
Cursory Googling returns two Terraform hiera providers, borh last updated in 2020. Are you using either of these, or something else?
https://github.com/ribbybibby/terraform-provider-hiera https://github.com/lyraproj/hiera_terraform
Re: How to keep your Terraform code DRY by using Terramate
#8I feel like teams should be using tfe workspaces and env vars to instantiate environments rather than having a folder per-environment. It's pretty easy to replicate this workflow and results in substantially less env drift and code duplication when we do it.
How do you only deploy certain resources to certain environment this way? We don't always have matching dev/qa/prod environments.
branch or tag from main if they have different release cadences. control the creation or non-creation ENTIRELY thru env vars with either boolean or count. If you have some thing that doesn't exist in all envs it should be obvious and maybe painful. Having to define it in the vars file makes it clear what differences each env has at a glance.
Re: How to keep your Terraform code DRY by using Terramate
#9I've been using Hiera (Puppet yaml data store) to source data for terraform. As a long time puppet user, when I started writing terraform code I really missed hiera. Turns out someone ported it to Go, and someone else turned that into a terraform provider. It's a game changer. No need for terragrunt or terramate. Hiera can return anything from a single value to a very complex data block that can be used to feed a mod…
Cursory Googling returns two Terraform hiera providers, borh last updated in 2020. Are you using either of these, or something else? https://github.com/ribbybibby/terraform-provider-hiera https://github.com/lyraproj/hiera_terraform
Neither! It's this one:
https://github.com/chriskuchin/terraform-provider-hiera5
On the terraform registry here: https://registry.terraform.io/providers/chriskuchin/hiera5
Re: How to keep your Terraform code DRY by using Terramate
#10I feel like teams should be using tfe workspaces and env vars to instantiate environments rather than having a folder per-environment. It's pretty easy to replicate this workflow and results in substantially less env drift and code duplication when we do it.
How do you only deploy certain resources to certain environment this way? We don't always have matching dev/qa/prod environments.
Alternatively, consider splitting your environment up into multiple stacks which can run independently and deploy each to a workspace per env. If one env lacks the app, don't have a workspace for it.
It sounds like a lot, but it ends up being fewer files to manage and edit and your workflow can be captured in github/terraform rather than in some arbitrary file structure. It also helps prevent mistakes like updating dev and having prod rerun by accident which I've seen happen.