Terragrunt goes a long way to providing a near-perfect way to structure Terraform repos.
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…
Terraform Config Root Setups
21–30 of 53 posts
Re: Terraform Config Root Setups
#22I spend a lot of time speaking with clients and have found myself partially understanding organizational structure so I dove in to collect my thoughts and put myself closer to the customer on what they are navigating. This gave myself a refresher on how they are organizing their cloud infrastructure within their source control systems. I took a lense from the world of terraform since that’s mostly the world i live in…
It'd be nice to show the other dimension of the git branching strategies to apply. Github flow/feature-branches vs per-env branches of main vs git flow. How and when to apply changes in different environments - before vs after PRs, etc.
Re: Terraform Config Root Setups
#23Terragrunt goes a long way to providing a near-perfect way to structure Terraform repos.
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…
With OpenTofu as of the latest release you can already use constant variables in places like module sources and versions, backend configurations, and even in order to for_each on providers!
Disclaimer: involved in OpenTofu
Re: Terraform Config Root Setups
#24Earlier quoted context omitted.
Yeah I'm confused why none of the solutions presented deploy the same TF across the environments: Surely if you have dev vs prod, 90% of dev infra is also needed in prod? Then sure sprinkle a few per-env-toggles `count: 1 if env == dev else 0` (or whatever the latest nicest way to do that is today), but it feels weird to have to set up an artificial TF module around our entire codebase to be able to share the bulk of…
Instead of env conditionals, I strongly recommended feature/functionality conditionals or variables. E.g. var.create_s3 is better than var env == 'prod'
Re: Terraform Config Root Setups
#25We 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…
- 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 StanleyRe: Terraform Config Root Setups
#26What's the craziest terraform repo you have seen? Is it okay to mix code (ex: Java) and terraform in a large mono repo?
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…
Re: Terraform Config Root Setups
#27This 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…
Agreed on the quality of the article, it feels very shallow.
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 what customers are actually using to find any gaps.
https://docs.resourcely.io/concepts/other-features-and-setti...
This is also a part 1 of the article and I clearly asked what was missing.
Re: Terraform Config Root Setups
#28The client I'm contracted to is all-in on Terraform Cloud. (TFC) TFC uses workspaces, which annoyingly aren't the same thing as terraform workspaces. I've divided up our workspaces into dev, qa, staging, and prod, and each group of workspaces has the OIDC setup to allow management of a specific cloud account. So dev workspaces can only access the dev account, etc etc. Each grouping of workspaces also has a specific r…
Re: Terraform Config Root Setups
#29This is ever evolving but we currently do; Composable modules such as `terraform-aws-lambda/modules/standard-function`, `terraform-aws-iam/moduls/role-for-aws-lambda`, etc, which get composed for a specific usecase in a root module (which we call stacks). The stack has directories under it such as `dev/main/primary/` `dev/sandbox-a/primary/` `dev/sandbox-a/test-a/`, etc, where `dev` is environment, `main/sandbox-a` i…
Re: Terraform Config Root Setups
#30The method I go to almost always is > Multi-Environment Setup with Shared Modules But the con of saying versioning is tricky across modules is damn near impossible to reliably manage.. especially because if I'm introducing a new variable to a shared module A) I need to also add this variable in the inputs of each of the environment. I haven't found a way to manage multiple versions of the modules across environments…