Terraform Code Review: Multi-Tenant App Service Solution PART 2

CODE REVIEW EPISODE 3 - PART II
In this episode, we'll analyze an audience member's Terraform code that provisions a multi-tenant Azure App Service Web Apps using SQL DB and Azure Blob Storage. The solution uses a separate deployment and module structure for the shared infrastructure and uses a re-usable module for each client environment that is deployed.

Follow me on Twitter for quick code snippets and thoughts on Cloud, Automation and other things!

Keep the knowledge flowing!

[sixdoubledeuce]

Glad to see someone else other than me is recommending migrating to objects for input variables. Terraform 1.3 standardized the optional() feature and it’s really sped up my development and allowed for so much more flexibility and easier code re-use. They’re great for outputs too, because you can just dump the object and get everything

[mloskot]

I kind of hoped you will touch on the timeouts block in the azurerm_role_assignment for key vault :)

[artisticcheese]

Hello, my requirement was not having separate state file per customer, I just did not figure out how to make it work with single state across of all customers. I tried to make it work with single state for all customers but failed. How backend shall be structured and how deployment and folder structure shall look like such cases. Probably would be good to have part 3 to showcase how it shall be done in optimized way

[beutlern]

you should not have one state file at all. what is your blast radius there? if you screw up one thing, you screw up all of them. does that require shared remote states? maybe not, but you definitely need to split up your root module A LOT more granular. you cant just have one production/live root module. jm2c