Blog

Terraform on Azure: Platform-Agnostic Automation in the Cloud

Terraform by HashiCorp is an open-source Infrastructure as Code tool (IaC). You can use Terraform to build, change, and version cloud and on-premise infrastructure. Terraform codifies infrastructure into configuration files, which define usage of cloud resources such as virtual machines (VMs) and storage accounts.

In today’s multi cloud environment, it is beneficial to use automation patterns you can repeat across multiple environments. In this post, we’ll examine three main benefits of building Infrastructure as Code on Azure with Terraform, including its platform agnostic aspect, and explain how you build and deploy Terraform on Azure. We will also explain how NetApp Cloud Volumes ONTAP can help simplify cloud storage automation, ensuring the continual health and optimization of storage workloads.

In this article, you will learn:

Terraform on Azure: Benefits

There are several benefits to using Terraform on Azure, particularly if you are already using Terraform to manage other infrastructures. Below are a few of the benefits you can expect to gain.

Automate infrastructure management
One of the most significant benefits of Terraform is the ability to automate your infrastructure management tasks. With Terraform, you can use template-based configuration files to define, provision, and modify your resources.

Automation enables you to: 

  • Reduce the risk of deployment and configuration errors
  • Easily deploy many duplicate environments for development, testing, and production
  • Reduce costs by provisioning and destroying resources as needed

Learn more about Azure automation in our articles explaining how to efficiently automate your pipeline with Azure Resource Manager and Azure Resource Manager Templates.

Platform-agnostic automation across multiple clouds
Terraform is possibly the only full-featured automation system that is completely platform agnostic, and can be used to automate systems on-premise, on Azure or on any other cloud using infrastructure as code. Most organizations use cloud services from multiple providers, so this is an important advantage.

Terraform plans can be created as frameworks for general resources. This enables teams to provision and deploy resources in a standardized way across cloud services and platforms. Additionally, since Terraform is not a proprietary tool, teams can use it to manage infrastructures consistently and from a centralized platform.

Understand infrastructure changes before adoption
Terraform plans can serve the dual purpose of configuration and documentation. This helps you ensure that your team understands exactly how your infrastructure is configured and how changes can affect it.

Terraform also enables you to preview and validate changes before modifications are applied. This validation enables operations teams to collaborate more effectively. It also helps prevent downtime or vulnerabilities created by unintentional or problematic changes.

Build Infrastructure on Azure with Terraform: An Example

To understand how Terraform and Azure can work together, it helps to understand the steps required for building infrastructure. The following walkthrough can help you understand how to leverage Terraform for Azure infrastructure.

Initialize your Terraform configuration
To get started with a new configuration, the first step is to run terraform init. This command initializes your Terraform directory and creates a hidden directory (.terraform) that any plugins you’re using are downloaded to. It also configures the backend for your Terraform state. 

Initialize your directory:

$ terraform init

Plan your Terraform run
Next, you need to generate an execution plan. This plan defines the actions that Terraform needs to take to configure your infrastructure and the order actions are taken in.

You can view the current execution plan for your configuration with the following command:

$ terraform plan

You should then see something similar to the following output. These outputs are similar in format to the diff format used by Git. Items with a + in front are to be created. Indented items indicate attributes of the parent item.

+ resource "azurerm_resource_group" "rg" {
     + id       = (known after apply)
     + location = "westus"
     + name     = "myTFResourceGroup"
     + tags     = (known after apply)
   }
Plan: 1 to add, 0 to change, 0 to destroy.

When you run a plan, it verifies the configuration syntax and compares the intended new state to the current configuration. Generally, you should export your plan to carefully review it and save an artifact of the plan before executing it. You can do this with the -out argument.

Apply your Terraform configuration
After your plan is confirmed, you are ready to apply it. You do this by traveling to the same directory that your main.tf is stored and running the following command:

$ terraform apply

Once again, your Terraform plan is displayed, and you are prompted for approval. As long as everything looks correct, you can confirm the plan. After confirmation, the plan is applied, and your specified resources are created. 

Terraform state
Your Terraform state tracks all of your managed resources and the values of associated properties. It is defined when your resources are created and added to the terraform.tfstate file. This state manages the changes to your infrastructure over time and must be preserved for the life of your resources. Generally, this requires storing your state file in secure, backend storage.

You can review your current Terraform state with the following command:

$ terraform show

You should then see an output similar to the following:

id       = /subscriptions/<subscription-id>/resourceGroups/myTFResourceGroup
location = westus
name     = myTFResourceGroup
tags     = 0

Moving to Production: Storing Terraform State in Azure Storage

By default, your Terraform state data is saved locally after running the apply command. For test or development environments, this may be fine. For production, however, it is problematic because:

  • Local states cannot be easily shared in distributed or team environments
  • Sensitive information may be exposed by less secure storage
  • When the state is stored locally, it is more likely to be accidentally deleted

To counteract these issues, Terraform enables you to persist states remotely, such as in Azure Storage service. To use this method, you need to either create or already have an Azure storage account. 

Configure your back end
To attach your remote storage, you need to supply Azure details when you initialize. These details include: 

  • storage_account_name—your account name.
  • container_name—your blob resource that you want to use for storage.
  • key—your state storage file name.
  • access_key—the access key to your storage.

You can define these values in your configuration file or through the CLI. For your access key, remember to use secrets. You don’t want to write your credentials to your storage. You can do this by creating an environmental variable like so:

export ARM_ACCESS_KEY=<storage access key>

Once your variable is created, you can secure your access key in the Azure Key Vault. Then, to set the variable, you can use a command like the following:

export ARM_ACCESS_KEY=$(az keyvault secret show --name terraform-backend-key --vault-name myKeyVault --query value -o tsv)

Next, you’re ready to attach back end storage to Terraform. This requires defining an azurerm back end configuration block. Then, you can add your storage_account_name, container_name, and key values to your configuration block. Once done, you can initialize and apply your configuration.

You can use the following code when configuring a Terraform backend, as well as creating an Azure resource group:

terraform {
 backend "azurerm" {
   resource_group_name   = "tstate"
   storage_account_name  = "tstate09762"
   container_name        = "tstate"
   key                   = "terraform.tfstate"
 }
}

resource "azurerm_resource_group" "state-demo-secure" {
 name     = "state-demo"
 location = "eastus"
}

To initialize the code, you should first run the init command, and then run the apply command. After running through these commands, you’ll find the state file in the Azure Storage blob.

When using Azure storage for Terraform states, there are two features to be aware of. These features help make your state storage more secure and reliable. 

  • State locking—your blob is locked automatically before state operations are written. This prevents simultaneous operations and reduces the chance of corruption.
  • Encryption—before writing, your data is encrypted. Then, when your state data is required, Terraform retrieves the state and stores it locally in memory. This prevents your state from ever being written to local disks.

Managing Terraform on Azure with Cloud Volumes ONTAP

NetApp Cloud Volumes ONTAP, the leading enterprise-grade storage management solution, delivers secure, proven storage management services on AWS, Azure and Google Cloud. Cloud Volumes ONTAP supports up to a capacity of 368TB, and supports various use cases such as file services, databases, DevOps or any other enterprise workload, with a strong set of features including high availability, data protection, storage efficiencies, Kubernetes integration, and more.

In particular, Cloud Volumes ONTAP provides Cloud Manager, a UI and APIs for management, automation and orchestration, supporting hybrid & multi-cloud architectures, and letting you treat pools of storage as one more element in your Infrastructure as Code setup.

Cloud Manager is completely API driven and is highly geared towards automating cloud operations. Cloud Volumes ONTAP and Cloud Manager deployment through infrastructure- as- code automation helps to address the DevOps challenges faced by organizations when it comes to configuring enterprise cloud storage solutions. When implementing infrastructure as code, Cloud Volumes ONTAP and Cloud Manager go hand in hand with Terraform to achieve the level of efficiency expected in large scale cloud storage deployment in Azure.

New call-to-action

-