Remote Backend State with Terraform and Azure Storage

Creating Infrastructure as Code (IaC) is commonly a group project. In this video, we learn about the Terraform state file, terraform.tfstate and how to store the state file in a shared Azure Storage Account accessible by a group of users. We create a new storage account with the Azure CLI, and then create a deployment using the Backend block in Terraform to use a remote, shared state file.
00:00 - Start
02:24 - Create the Storage Account
04:25 - Storage Account Key
05:26 - Create the Backend Block
07:34 - View Least Status
07:52 - Deploy the Resource
Links:
Zero to Hero with Azure Virtual Desktop
www.udemy.com/course/zero-to-...
Hybrid Identity with Windows AD and Azure AD
www.udemy.com/course/hybrid-i...
Terraform Playlist
• Getting Started with T...
Code on GitHub
github.com/tsrob50/TerraformE...
Blog
www.ciraltos.com/remote-backe...
Terraform Provider Site registry.terraform.io/

[@xGomo]

Thank you, Travis. I'm recently learning Terraform and I could never get my head around remote states until now.

[@zimek]

thanks for sharing your knowledge Travis!

[@marcussantos7195]

In the beginning, you said that state file is created after terraform init, but it is created after terraform apply.
Great video, though! Love this playlist!

[@mloskot]

Instead of bootstrapping the storage with Azure CLI commands, any particular reason why don't you use Terraform to create those resources?

[@ncvman]

Very nice video and example Travis. If using terraform cloud could I store state in the cloud and the tfstate.backup in azure storage for better redundancy and DR scenario?

[@indranilmondal5509]

how to run this through release pipeline? it asks for input yes/no which is not possible to provide through pipeline

[@mosksky]

Happy new year Travis and ty for your knowledge transfer! I think state file is the "Achilles' heel" of TF, as in AWS you would need to setup dynamodb to lock the state file in S3. In Azure blob that is happening by default as you shoed in the demo. However, the worse part of the state file is if there were changes in the portal (not by TF) statefile is out of sync and that would cause different type of issues to get them in sync again. Where in ArmTemplate (BICEP) i could run complete mode and make sure everything is matched what is in the code. What-If is similar to TF Plan. Same would go for CloudFormation. Travis, what are you thoughts about it?

[@Ciraltos]

Happy new year to you as well! That is the big limitation, or feature, of Terraform. If all is done with TF, things go well. But problems start when changes are made outside of TF. FWIW, one of the selling points to TF is it prevents configuration drift. So, removing changes made outside of TF is what it is expected to do.
I prefer ARM templates or Bicep over Terraform. Not that there is anything wrong with TF, I am fortunate to work in an Azure only environment and TF seems like another layer of complexity. I would think differently with a multi-cloud environment. Customers like Terraform, that is the motivation to the videos. Also, most of the information available is on Terraform with AWS. I though it would help to create content focused on Azure.

[@valp8198]

Does anyone know what the environment variable name should be on Linux? it is not ARM_ACCESS_KEY

[@mkraochirumamilla]

Hello Travis, Thanks for your videos and knowledge sharing. What happens if two terraform developers executed terraform apply/destroy concurrently working on the same terraform code base and have two different remote state files in different blob containers?

[@Ciraltos]

Each instance of terraform would act independently and overwrite the other. That's what a central state file is intended to prevent.

[@ArkaSkyburner]

Okay i am able to do this but i want to have a backend with multiple subscriptions along with it cause i tried doing that and got an error saying that i have an undefined provider despite doing the correct syntax for multiple subscriptions according to forums

[@anshuanand7657]

Hi Travis, i hv one query how can we call the same state file from storage account while deploying another resource for example: i hv created one resource group in my infra that is stored in tfstate file. now i wants to create one public ip in same resource group and i don't want to write code again to deploy resource group( we can't with same name as well) . Is there any option so we can call the same tfstate file from storage account.

[@PsyberMind]

Could you just run that initial script as a BASH script if you were using Github Actions for CI/CD? I'm still learning, and building a pipeline to AKS for practice, so this is a little new to me

[@PsyberMind]

Actually, disregard that.. I see now that this is a "first run" script, just to set up the storage account

[@jon-paulboyd9984]

I need that t-shirt! Where? Thanks for the vid!

[@Ciraltos]

Shirts by Shane, all proceeds go to Girls Who Code. I see a couple new designs, I may need to place an order. shirtsbyshane.com/

[@VGaming-msv]

what if that storage account goes down?

[@lichardbaliuag4122]

Thank Travis. I've tried to add backend "azurerm" under required providers but I'm getting "Error: Variables not allowed" for all those 4 items - resource_group_name, storage_account_name, container_name, and key. Any idea? Appreciate it, thank you. 🙂