Any tips/best practices for maintaining/promoting configs in infrastructure-live?

[eoliphan]

Hi, I've been wondering about the best way to consistently handle moving stuff across envs in my infrastructure-live repo. We're following the suggested //terraform.hcl structure. So, let's say we've added a module, and changed and existing terraform.hcl in dev and it's good to go. Now we're promoting that to test.

Right now we're just sorta doing a manual reconciliation with diff and our trusty Mark 1 eyeballs to ensure that the new/changed stuff in was moved over, and repeat for each 'promotion'. Is this what most people do? I've done a little experimentation around being very strict with making sure that all the env specific stuff is in the env-level .hcl and using a script to copy all the module stuff 'forward'. It's working'ish, but there's still a need to reconcile env-level .hcl's to account for say new vars and what have you. And I've been looking at ways to check for module level vars that should be pulled 'up'

[brikis98]

Terraform and Terragrunt are flexible tools, so the answer to this is, of course, "it depends."

That said, what you're aiming for is:

If you have, say, infra-live/stage/xxx/vpc/terragrunt.hcl and infra-live/prod/xxx/vpc/terragrunt.hcl, then these files contain solely:

1. A source URL pointing to the same underlying vpc module, but potentially at different versions (different ref= params).
2. An inputs = { ... } block that solely contains settings that different in each environment. E.g., In stage you might have cidr_block = 10.0.0.0/16 and in prod, you might have cidr_block = 10.2.0.0/16.

If you have that, then to promote a new version of the module from environment to environment, you are solely updating the ref= param. So there's no need to reconciliate anything or pull anything "up."

If you are seeing such a need, could you provide an example so we can go into more detail?

[trallnag]

@eoliphan, could it be that your infrastructure modules have a lot of different variables and therefore your inputs block as well?

From what I understand the HCLs in infrastructure-live should mostly be used to set parameters that are different between environments (or global stuff like tags and regions). But I'm also not super sure about that.

For example there are really complicated modules in the TF registry like terraform-aws-eks. Following the recommend approach you wouldn't reference this module directly in infra-live but actually wrap it with an infrastructure-module (or add it to an existing one?) and then reference to that one from infra-live.

@brikis98, please correct me if I got it wrong

[brikis98]

@trallnag Yup! Ideally, each terragrunt.hcl is as tiny as possible.

BTW, see this comment for a more DRY structure we've been considering. It's still experimental, but it gives you the idea of what to aim for.

[eoliphan]

Thanks guys. Yes @trallnag, after re-reviewing some of our setup, I see how I can do some cleanup to get things more inline with you guys' suggestions here