How To Structure Terraform Project (3 Levels) 

🔴 - To support my channel, I’d like to offer Mentorship/On-the-Job Support/Consulting - me@antonputra.com 👉 Terraform Tutorials for Beginners: ru-vid.com/group/PLiMWaCMwGJXmJdmfJjG3aK1IkU7oWvxIj 👉 Kubernetes Tutorial for Beginners [Full Course]: ru-vid.com/group/PLiMWaCMwGJXkYKFa_x0Ch38uznuv-4c3l 👉 AWS EKS Tutorial for Beginners [Full Course]: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-kwq9EfELYII.html 👉 Other Kubernetes Tutorials: ru-vid.com/group/PLiMWaCMwGJXnKY6XmeifEpjIfkWRo9v2l

Anton, you and Cloud Champs youtube channels are seriously holding it down for the DevOps learning community. Im constantly bouncing between the channels because the content is practical and great.

Dude you're putting serious quality content with these videos. Liking before seeing and already saving this on my watchlist ... THANKS

Thank you so much for making such a thorough yet simplified video about this, I'm new to TF and have been experimenting with so many different ideas. I've been running into a lot of the issues you covered, consistently, this is such a great help.

What a awesome lesson! I was looking for that info 1 month ago because changed my job place and needed to create terraform repo from a scratch. Very useful

I found that Terragrunt method which you uploaded here is the best for me. I hope you extend about Terragrunt more. Thanks Anton

Thank you for this kind of video. There are thousands of Terraform videos in youtube but it is hard to find one that show how to use it professionally.

I was waiting for that video!

Amazing video Anton! I saw a lot of companies trying to scale with V2 version and is impossible! Other common mistake is use one repository for the entire IaC, with the same life cycle for a VPC and a simple resource(S3 for audit team, DynamoDB for specific API...)

Thank you so much for this video! It's a great reference.

Thank you so much for this incredible vidéo. I'm going to watch to Terragrunt to get more deeper on the subjet. Much appreciate

Thanks, awesome content.

Wonderful thanks. Спасибо

Hi Anton, Great video as always! I went through a similar evolutionary process to what you described. I started with a very basic setup, and as the infrastructure grew, the problems you mentioned arose. Eventually, I ended up with a structure like yours, except I set up a private Terraform registry to manage the modules more efficiently and conveniently. I use Terrareg, which I believe is the ultimate option. I have a few questions: 1. Do you think it's correct to manage the providers as a separate module instead of creating a file for each project? 2. You mentioned that some resources can be put in the global folder. What do you think should go there? Thanks!

Having one root module per environment (e.g. dev, stg, prd) makes sense to me, as you definitely want those to be different terraform states and be able to run in parallel, but I simply can't wrap my head around why you'd want to have a root module for each service as well (e.g. envs/dev/subnet, envs/dev/vpc as opposed to a single envs/dev that has all services). I know Google suggests a similar thing for their terraform guide, as it helps keep the state file and thus blast radius small and makes terraform plan run fast. However, you no longer manage dependencies between services in terraform and have to move to bash scripts with specific order in them. As a developer you then need to be extremely mindful in which order you've applied things as it's no longer as simple as running one single `plan` or `apply`. The number of root modules also rises significantly, and becomes a product of `envs` and `services` - which can lead to a large amount of boilerplate code one has to manage. It seems that the reason you'd want a state file per envⓧservice pair is due to terraform's limitations - if it could impute which part needs to be re-planned / fetched, it wouldn't really matter how big your state file is. Kinda how git & web state management frameworks can be pretty efficient and spot diffs accurately. Any advice on this would be appreciated, still learning how to do this best.

Thank you, consider a blog with some of the slides or ReadMe to the same git repo...just a thought...thx

can you do please a deep full course on ecs like you did on eks with terraform and all the concepts that would help a lot because you have a way of teaching so great ! cuz sometimes you don't need eks for simple projects , ecs would satisfy the need ! thnks in advance

It would be very cool to learn more about terragrunt =)

Nice video. What about using git submodules? i think you can create git repo and store all modules there and then add this repo as git submodule to your project. After that you can simple reference module in submodule folder. Also you can switch between branches in this submodule so you can test changes or deploy different configurations

Thank you for the awesome video! What do you think about terraform workspaces? Any pluses/minuses to using them instead of splitting the environments into folders?

Hi , thank you very much for this great effort , does it mean vpc-02 folder will replace the /modules/vpc ? coz you mentioned that will act like versioning

I am looking forward some lessons

Nice Video, Thanks! One question when i store my module in a private repo and i run my terraform deployment in a cicd pipeline like github action, how would you configure the github action to be able to pull the module repo? Whats the best approach here?

Better use terraform workspace and stop managing directory structure :)

Why are you creating different environments instead of having the logic in the terraform files and let runtime variables from files and environment variables (secrets). This reduces the complexity significantly instead of having to maintain so many different directories and files. Also, don't read outputs from state file, use a data source directly to your provider. That is how hashicorp suggest, and for good reason. It will query your endpoint for a resource that is live rather than your state, which could be corrupted, or the resource could've been changed outside of Terraform.

yeah, that's three ways to do it but... terraform "state" is ephemeral and therefore "state" should be relative!

Bro, this is too much just to create an image. Just because we can doesn't mean we should.

Everything before 4:35 is a bad practice and shouldn't be even mentioned as "evolution". Beginners should learn how to write reusable, composable, and fully parameterized code (with full separation of code and data) from the start. Hence splitting your code by "environments"/regions etc. is also a bad idea. Common fallacies, again...