undefined | Better HN

0 pointsdavidjfelix3y ago0 comments

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.

0 comments

3 comments · 1 top-level

cassianoleal3y ago· 2 in thread

> If you have some thing that doesn't exist in all envs it should be obvious and maybe painful.

Exactly this. In $previous_client we had `snowflake_*.tf` files. Anything that couldn't be specialised using Terraform variable files should go on those. One advantage was that we started finding things that should be commoditised to get rid of the snowflakes. Everything else was very obviously out of shape and seen as generally undesirable - although many times necessary.

> control the creation or non-creation ENTIRELY thru env vars with either boolean or count.

I would also highly discourage this. Counts for different scales across environments, sure. Counts or bools to decide whether or not to deploy something depending on the environment are discouraged and should become a snowflake.

davidjfelixOP3y ago

I want to emphasize that I don't normally use counts, it's just one tool in the toolbox. Normally I try to isolate env specific apps to their own stack and I simply don't have a workspace for the env they're not deployed in. Assuming a traditional 3 tier env setup (which I don't do either -- I only have 2) it might look like:

Workspaces:

- PROD-us-east-1-All-the-VPC-stuff

  - NAT count = 3

- PROD-us-west-2-All-the-VPC-stuff

  - NAT count = 3

- PROD-us-east-1-Enterprise-Network-Tool

  - var instance count = 2

- PROD-us-west-2-Enterprise-Network-Tool

  - var instance count = 2

- STAGE-All-the-VPC-stuff (us-east-1)

  - NAT count = 3

- STAGE-Enterprise-Network-Tool (us-east-1)

  - var instance count = 1

- DEV-All-the-VPC-stuff (us-east-1)

  - NAT count = 0 (maybe since we don't have the network tool we're transit vpcing or something else in dev)

It's a little contrived but the idea is that normally workspaces align to these borders:

- Env

- Cloud region (not always -- and the cross region ones are usually called out)

- Loosely de-coupled app border

Workspaces provide really easy "manholes" for servicing your IaC quickly when there's a mistake. They don't encourage you to manually change resources, but rather work in a smaller area and reduce blast radius. The issue I see with a lot of teams is when they're not sure how to handle cross-stack references or what they should output. I think that's an area for training and leveling up in TF.

cassianoleal3y ago

Yep, mostly agree here.

> The issue I see with a lot of teams is when they're not sure how to handle cross-stack references or what they should output.

Very much agree. What I try to do as much as possible these days is to not cross-reference. I find terraform remote state resources a code smell. Data sources are a better way to go. No code coupling and no terraform versioning dependencies between stacks.

1 more reply

j / k navigate · click thread line to collapse