HashiCorp Terraform is a great Infrastructure as Code (IaC) tool that helps you deploy and manage IT Resources using declarative code written in HCL (HashiCorp Configuration Language). Terraform allows you to managed these resources through the use of Terraform Providers that encapsulate all the REST API calls to manage those resources. There are many providers, including Azure providers, that enable the management of many different types of Resources across your project from within a single Terraform Project.

This article provides an overview of what Terraform Providers and other tools are available to manage resources using Terraform. Let’s dig in!

Why use Terraform with Azure?

While tools like Azure Bicep and ARM Templates are built by Microsoft to natively support Microsoft Azure resource management, these tools will only enable you to manage Azure resources. By using HashiCorp Terraform, you can use the same tools and language to manage Microsoft Azure resources, as well as any other resources within your environments from a single Terraform Project. Also, with Terraform, your SREs or DevOps Engineers will be leveraging the same skillsets and HCL language understanding to manage all your resources, so you will have some efficiency benefits there as well.

There are several benefits to using Terraform to manage your resources that apply to Azure as well as other resources you need to manage in your environments:

• Platform agnostic – Terraform is an IaC tool that is platform agnostic allowing you to manage Microsoft Azure resources along with other types of resources (such as K8s, Helm, AWS, Google, etc) from a single project.
• Version Control of Infrastructure – By using Terraform code to deploy and manage resources, the standard best practice is to check the Terraform code into version control, such as a Git repository.
• Change Plan Validation – Terraform allows you to run a Plan before Applying the infrastructure changes, so you can inspect the plan and ensure that only the changes you intend to make are actually applied to your environments.
• Easy to Manage Deploy – A declarative language and tool like Terraform make it easier that using a scripting language to deploy and manage Azure resources through the use of automation. You can run the Terraform Plan and Apply multiple times on your environment without it breaking the environment like an imperative scripting language likely would, all without making any code changes.

Related: If you are just getting started with Terraform on Azure, please check out the “Get Started with Terraform on Azure” article written by Chris Pietschmann.

What Terraform Providers are Available for Azure?

Terraform being a platform agnostic toolset uses Terraform Providers to enhance the tool with the ability to manage different technology resources; like Microsoft Azure Resources, Microsoft Azure AD Resources or even non-Microsoft technology resources as well.

Before you can use Terraform to manage resources, you must include a block of HCL code in your Terraform Project that tells it to download and allow you to manage resources that provider supports. Below is an example of that block to include the AzureRM provider for managing Microsoft Azure resources:

# The recommended to use the required_providers block.
# Specify the Azure Provider source and version
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "=3.0.0"
    }
  }
}

# Configure the Microsoft Azure Resource Manager Provider
provider "azurerm" {
  features {}
}

The azurerm Terraform Provider enables the management of Microsoft Azure resources. However, there are several Terraform Providers for the various types of Microsoft Azure resources:

• azurerm – The AzureRM Provider enables the management of resources within the Microsoft Azure cloud.
• azuread – The AzureAD Provider enables the management of resources within Microsoft Azure Active Directory.
• azuredevops – The Azure DevOps Provider enables the management of resources within Microsoft Azure DevOps.
• azapi – The AzAPI Provider is built on top of the Azure ARM REST APIs and enables management of Microsoft Azure Preview resources and properties that are not supported yet or wont be supported by the AzureRM Provider.
• azurestack – The Azure Stack Provider enables the management of resources in Microsoft Azure Stack.

As an Infrastructure as Code (IaC) tool, the infrastructure managed by Terraform the infrastructure configuration is written in HCL (HashiCorp Configuration Language) code, and is usually checked into source control (like Git) and integrated with CI/CD deployment pipelines for deployment automation.

Terraform uses a provider model to integrate multi-cloud and other third-party platform support. This enables an extensibility of Terraform to enable it to support any platform there is a provider for. Microsoft Azure is supported through an Azure provider for Terraform that makes REST API calls to the Azure ARM REST API to instrument the management and deployment of Microsoft Azure resources.

Developing Terraform with Visual Studio Code

There are several extensions to install to support Terraform development using the ever so popular Visual Studio Code editor. These extensions will add all the helpful features to VS Code that will make developing Terraform Projects using VS Code and HCL (HashiCorp Configuration Language) easier.

These are the Visual Studio Code extensions you’ll want to install:

• HashiCorp Terraform extension – Adds syntax highlighting and autocompletion for Terraform.
• Azure Terraform extension – Increases developer productivity authoring, testing, and using Terraform with Azure by adding command support, resource graph visualization and CloudShell integration inside VS Code.
• Azure Account extension – Provides a single Azure sign in and subscription filtering experience for all other Azure extensions and makes Azure Cloud Shell available inside VS Code.

Related: Learn about Terraform variables from the “Use Terraform Input Variables to Parameterize Infrastructure Deployments” article written by Chris Pietschmann.

About the Author