Search posts, tags, users, and pages
No mention of environments, modules,zero code re-use and an amateur take on Terraform.
I wouldn't call it best practices
I believe the focus is on how to avoid blast radius. I do agree that having to repeat the provider details in every direction could be annoying.
Oh I know blast radius. It doesn't do anything to help. Consider having an infra or multiple generic projects that have elevated permissions and multiple projects with their own state. Each team has access only to their own state with the pipeline only able to fetch(but not change) remote state from the elevated projects Christopher K.M Etou
Devops, Infrastructure as Code, Cloud Engineering, System Engineering
/dev/null I believe knowledge is a distributed system and the more we all contribute, the we all learn. Leon's article is the first block on how to modularize your terraform code.
The usecase you are describing is a valid one. Is there anything you found somewhere that could help complement Leon's article?
Hey /dev/null thanks for your inputs and yes I'm a newbie in Terraform, my focus was more on splitting your code into smaller pieces, each folder has its own state file so unless you're doing a terraform apply in all folders using something such as a CI/CD platform your code would definitely be much safer in a single repo, could you elaborate on environments, if you're pointing towards workspaces those are being deprecated and will only be available for terraform cloud backend/state, if you're referring to prod/dev env then this folder structure also works. While modules may help, that wasn't the focus of my article.