Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Terraform Config Root Setups

resourcely.io

Post reply on HN
Print view View original

41–50 of 53 posts

Re: Terraform Config Root Setups

#41

Post by cruffle_duffle »

Terraform is such a weird product and it’s hard to describe why, really. It has really awesome things about it like a functional way to pull in support for just about any providers crazy thing. And the crazy part is somehow terraform can easily configure local infrastructure, cloud infrastructure on almost any host, set up repos in GitHub, and then create a new auth provider in Auth0. The language is flexible enough to support all of it.

Yet as a language, it’s quirky as heck. For example how modules are basically wrappers on providers and how different modules can all most “see inside” other modules to iron out dependency ordering but yet also can’t. And speaking of, circular dependencies suck to work around in a modular way without tearing half your structure apart.

Like I said, I am not anywhere close to an expert on terraform and can only describe my limited experience building a fairly simple stack on top of it. The whole thing is just… both amazing and also weird and a bit frustrating. And I have yet to “grow” into multiple environments… lots of my complaints are probably down to my limited experience with it and, honestly, not much out there in terms of best practices for maintaining scalable configuration (or maybe my ADD brain refuses to dive into that, who knows?)

My last adventure into infrastructure as code was with Puppet and Salt. All of that was provisioning on top of bare metal. It was all file operations and the “provider specific modules” were really just wrappers to nicely encapsulate things like nginx or apt. Perhaps it is because of Puppet or Salt’s much more limited scope that didn’t have me feeling the same way.

I mean terraform can be used to configure just about anything that has an API if you wanted. Maintaining a declarative language around that is bound to have its quirks.

Re: Terraform Config Root Setups

#42

Post by carty7 »

based2 wrote: post #25
iliaxj wrote: post #10

We use a single codebase to deploy to multiple environments. The setup looks like this: - root -- /envs --- / dev.tfvars --- / prod.tfvars - main.tf When it gets deployed by the CICD, the right tfvars file is passed in via the -var-file parameter. A standard `env` var is also passed in, and used as a basis for a naming convention. Backend is also set by the pipeline. The rationale here is that our environments should…

alt - root -- /envs --- / .dev.env --- / .test.env --- / .prod.env --- / dev.tfvars --- / test.tfvars --- / prod.tfvars - 1_create_network.tf - 2_create_storage.tf - 3_create_service.tf https://www.youtube.com/watch?v=WgPQ-nm_ers Compliance At Scale: Hardened Terraform Modules at Morgan Stanley https://www.weekly.tf/

Thanks for sharing. I’ll add the video to my queue.

Re: Terraform Config Root Setups

#43

Post by cruffle_duffle »

maccard wrote: post #26
dijit wrote: post #12

Earlier quoted context omitted.

I’ve seen things you wouldn't believe. Python deterministically generating terraform HCL files based on yaml. Execution wrappers that encapsulate terraform in CI/CD to parse the json output and prevent database deletion, but apply everything else. Scripts that pull every git repo and execute every terraform file they can find while walking the directory tree. Terraform is about 80% of the way to a good tool, that las…

I agree with your 80/20 take, but I’ve come to the conclusion that the only reason terraform is a good tool is because it leaves the messy stuff (the other 20%) to other tools and pretends it doesn’t exist.

Yeah but it sure feels like what is in that 20% has to be common enough to have good best practices around it?

Or perhaps that 20% is simply the remainder of organizational complexity that cannot be standardized in a single tool like Terraform? Every org and every product have unique enough attributes that it is just not possible.

I dunno. I find terraform a uniquely fascinating product because it does so much yet leaves so much for you to do on your own.

Re: Terraform Config Root Setups

#44

Post by carty7 »

isoprophlex wrote: post #32
carty7 wrote: post #27

Earlier quoted context omitted.

Sorry it feels shallow and that you feel the need to troll. If you read my first post related to this, I was giving myself a refresher to understand different dynamics that people think about. I did not watch one YouTube video or spend 20 minutes on this or create with GPT. The original source of inspiration came from me wanting to understand the examples our Eng team put together on how our config file correlates to…

I think it's perfectly valid to voice an opinion of shallowness. That doesn't automatically make it trolling.

My mistake. Maybe the wrong use of the word.

And yes, it was a shallow article. It was not a deep dive and nor do I have the technical chops to write a deep dive.

Re: Terraform Config Root Setups

#45

Post by TYMorningCoffee »

OJFord wrote: post #14

This is terrible. All options seem to assume state is stored locally (not, say, in S3). Many options are just the same as others but only one environment, or with some project-specific difference like 'there is a backend and a frontend' or 'a few services' which has nothing to do with how you structure the terraform side of it. All of them either don't address or use multiple directories to handle multiple environmen…

Why do you think the article assumes statefile is local? I don't think that assumption was made.

Re: Terraform Config Root Setups

#46

Post by OJFord »

carty7 wrote: post #36
OJFord wrote: post #14

This is terrible. All options seem to assume state is stored locally (not, say, in S3). Many options are just the same as others but only one environment, or with some project-specific difference like 'there is a backend and a frontend' or 'a few services' which has nothing to do with how you structure the terraform side of it. All of them either don't address or use multiple directories to handle multiple environmen…

The entirety of this research was about structure of directories. Storing state in S3 or TFC or Spacelift or somewhere else is out of scope. S3 is where 90% of the world stores their state and writing those configuration lines is not in scope. You can find other resources on that. I struggled to find an exhaustive list of how people manage their directory structures and hence the focus of this piece. If you’d like to…

Sorry, I assumed this wasn't author-shared; I wouldn't have phrased it like that if I'd realised, or on a 'Show HN'.

It just struck me as a collection of ways you could split your configuration where none of them is something I would suggest. You could split your frontend/backend or services I guess sure, but then why are you assuming it's in the same repo, and why does that matter anyway, it has nothing to do with Terraform.

Why have dev & prod as different projects, assuming they're supposed to look the same? Use workspaces or different state or terra grunt. Ditto regions; use provider aliases.

If you say Well I'm not assuming they are the same, this is about structuring directories on the basis that they are already isolated Terraform configurations... Ok sure, but why does how you do that matter and what does it have to do with Terraform? It's the same as talking about structuring the directories for their application code isn't it?

Re: Terraform Config Root Setups

#47

Post by OJFord »

TYMorningCoffee wrote: post #45
OJFord wrote: post #14

This is terrible. All options seem to assume state is stored locally (not, say, in S3). Many options are just the same as others but only one environment, or with some project-specific difference like 'there is a backend and a frontend' or 'a few services' which has nothing to do with how you structure the terraform side of it. All of them either don't address or use multiple directories to handle multiple environmen…

Why do you think the article assumes statefile is local? I don't think that assumption was made.

#2 splits the configuration into 'dev' & 'prod' duplicates, describes it as 'with separate state files', and from there they're all different ways of splitting the project for some reason.

If the state isn't local, then if you want that split in order to apply them separately, there would be no reason to physically separate & duplicate them into different directories.

Re: Terraform Config Root Setups

#48

Post by maccard »

cruffle_duffle wrote: post #43
maccard wrote: post #26

Earlier quoted context omitted.

I agree with your 80/20 take, but I’ve come to the conclusion that the only reason terraform is a good tool is because it leaves the messy stuff (the other 20%) to other tools and pretends it doesn’t exist.

Yeah but it sure feels like what is in that 20% has to be common enough to have good best practices around it? Or perhaps that 20% is simply the remainder of organizational complexity that cannot be standardized in a single tool like Terraform? Every org and every product have unique enough attributes that it is just not possible. I dunno. I find terraform a uniquely fascinating product because it does so much yet le…

> Or perhaps that 20% is simply the remainder of organizational complexity that cannot be standardized in a single tool like Terraform

I think this is what it is in practice. My opinion is that if these organisations had slightly less opinions terraform could probably solve another 15% and just leave the 5% that is _definitely_ organizational complexity.

Re: Terraform Config Root Setups

#49

Post by baby_souffle »

bloopernova wrote: post #35
baby_souffle wrote: post #24

Earlier quoted context omitted.

+1 for this. Do as much as you can in modules and write each of your modules to have a simple enable or disable input.

I just wanted to clarify: are you referring to this pattern? module "cool_name" { count = var.create_cool_name ? 1 : 0 } I've always wanted a simple enable/disable syntax for modules in tf.

> I just wanted to clarify: are you referring to this pattern?

Does TF support count on modules now?! The pattern I was referring to is akin to having an `enabled` var that you define in _every_ module (there are ways to make this easier to do [0]) and inside of each module you have a

    local {
        make_the_s3_bucket = var.enabled && var.make_s3_bucket
        make_the_rds_instance = var.enabled && var.enable_rds
    }
Then you use the typical `count: foo == bar ? 1:0` trick where some part of the `foo/bar` conditional ropes in local.make_the_rds_instance

[0]: https://github.com/cloudposse/terraform-null-label/tree/main

Re: Terraform Config Root Setups

#50

Post by spicyusername »

slillibri wrote: post #33
spicyusername wrote: post #13

Earlier quoted context omitted.

I didn't understand the benefit of using terragrunt. Modern terraform supports all of the features terragrunt was originally designed to work around way back when. Outside of being able to use variables in very niche places that you can't in terraform (and can easily work around, and that last I heard is on the road map for open tofu), what does terragrunt do that using regular module imports in terraform don't? This…

1) I use terragrunt to generate all the 'boilerplate' files, for example the backend configuration to ensure they are all in spec. 2) I use terragrunt to provide inherited values, such as region, environment, etc. I have a directory tree of `dev/us-west-2/` I can set a variable in my `dev/environment.hcl` that is inherited across everything under that environment. This is useful if you have more than one dev, prod, e…

This is exactly what I'm talking about.

Using variables isn't supported in backends - e.g. "niche places" (although it sounds like it is in OpenTofu)

And #2 and #3 are exactly the use-case for just regular old tfvars files and module imports.

Terragrunt encourages you to abstract things way, way too far, until you have an absolute mess of tangled imports and deeply nested directories.

Nothing wrong with having a root module, some child modules, and a single tfvars file being fed in on the front end.

Post reply on HN