Storing the State in a Remote Backend
Learn how to create a storage blob to hold and save the state of our cluster.
We'll cover the following...
Creating an Azure storage blob
Terraform maintains its internal information about the current state. That allows it to deduce what needs to be done and converge the actual into the desired state defined in *.tf
files. Currently, that state is stored locally in the terraform.tfstate
file. For now, there shouldn’t be anything exciting in it.
Let’s see the definition of terraform.tfstate
.
{"version": 4,"terraform_version": "0.14.3","serial": 1,"lineage": "eb324741-d3b5-e46a-af3f-774c065df7bf","outputs": {},"resources": []}
The field that really matters is resources
. It’s empty because we didn’t define any. We will, soon, but we’re not going to create anything related to our AKS cluster. At least not right away. What we need right now is a storage bucket, or, to use Azure terms, we need a storage account and a storage container.
Keeping Terraform’s state local is a bad idea. If it’s on a laptop, we won’t be able to allow others to modify the state of our resources. We’d need to send them the terraform.tfstate
file through email, keep it on a network drive, or implement some other similar solution. That’s impractical.
We might be tempted to store it in Git, but that wouldn’t be secure. Instead, we’ll tell Terraform to keep the state in a storage container. Since we’re trying to define infrastructure as code, we won’t do that by executing a shell command nor will we go to the Azure console. We’ll tell Terraform to create the container. It will be the first resource Terraform manages.
Updating storage.tf
We’re about to explore the azurerm_storage_account
and azurerm_storage_container
modules. They allow us to manage Azure storage. More information about this is available in the ... ...