Cloud computing and infrastructure-as-code are transforming the way we manage and deploy resources in the IT world. Among the leading tools in this revolution is Terraform. In this post, we'll delve into setting up Terraform with remote state management within an Azure subscription, ensuring a smooth and scalable infrastructure management experience.
This is the second of tree posts about terraform remote state on Azure, AWS and GCP.
Feel free to have a look into the other posts as well, if interested in the other hypervisor setups:
All needed files can be found here as templates: https://github.com/bluetuple/terraform-azure/
Before diving into Azure, ensure you have Terraform installed. Download the appropriate package from the Terraform website and install it.
Explanation: Terraform is a command-line tool, so you need to have it locally installed to run commands against your Azure resources.
Ensure the Azure Command-Line Interface (CLI) is installed. This tool interacts directly with Azure services.
Explanation: While Terraform will handle most tasks, the Azure CLI allows for additional configuration and verification tasks.
Before Terraform can manage resources in Azure, it needs permissions. Use the Azure CLI to log in:
A browser will oben and you have to login to azure. Notice in the terminal the list of available subscriptions. Copy the ID of the subscription you want to use.
Noe set the subscription:
You can verify the actual setting with `az account show`
Now we have to create a Service Principal. A SP is an application in Azure Active Directory (AAD), which will provide the authorization tokens Terraform need to perform actions on your behalf.
It is recommended to NOT safe the provided credentials in any Terraform script, so we will export them as environment variables and store them in a hidden file on the console.
Keep in mind, that everyone who has access to your local console could as well read these variables. So for a production environment this would not be a preferred approach. For any production environment i would recommend to store these variables in a key vault, but this is out of scope for now.
Set the following environment variables and store then in a .secrets file. You can source them afterwards by `source .secrets`.
Create a new hidden secrets file in the actual folder:
```
nano .secrets
```
Copy the following export into the new file, replace the placeholders with your actual values and save the file (`CTRL/Control + O + y`):
Activate the settings by typing `source .secrets` in the terminal
We now have to create a couple of terraform declaration files. In theory it would be possible to place everything despite the variable definition in one file but for readability and modularity reasons we will place the declarations in separate files. Create the following empty files with you preferred code editor:
main.tf
resourcegroups.tf
variables.tf
storage.tf
remotestate.tfvars
We now have to setup an Initial `main.tf` file which will hold the terraform provider information. Place the following code in your `main.tf` file and safe it:
Next we will define a file for variable declaration and for resource groups. Let's start with the variable definition.
Copy the following code into your `variable.tf` file:
Create a new file `resourcegroups.tf` and place the definition of new resource groups for holding the storage-account we will use for remote state in the next steps.
Right after this create a file named `storage.tf` and place the storage account details in there. Keep in mind that a storage account name in azure must be unique worldwide.
With everything in place we now let Terraform download the azure provider and create resource group and storage account. Carry out the following commands, ensuring that you're in the same folder than the .tf files.
terraform init
terraform fmt
terraform validate
terraform plan
terraform apply
With `terraform show` you can check the current setup.
In the main.tf add the following lines:
```
Ensure that the backend configuration is exactly placed inside the terraform{} block at the same indentation as required_providers{}.
As last step you now have to initialize Terraform again:
terraform init
You have to approve ('yes') to have your state file moved to the azure backend.
That's it - you're done. your terraform state is no independent form your local machine. Other team mates now could carry out Infrastructure as Code task with terraform as well (given they have proper access rights).
If you want to clean up the sandbox environment again: with 'terraform destroy' everything we've created above will be deleted...
Call: +49 2151 9168231
E-mail: info(a)bluetuple.ai
47809 Krefeld, Germany
Copyright © All Rights reserved.