Search⌘ K
AI Features
Home
Courses
The Complete Guide to DevOps in Azure

Introduction to Terraform

Explore Terraform fundamentals to streamline Azure infrastructure management. Understand configuration files, HCL language, providers, and how Terraform automates resource creation. This lesson equips you to write and use Terraform code for consistent, efficient Azure deployments.

We'll cover the following...

Terraform

Have you ever tried to create a ton of infrastructure resources on-prem or in Azure manually like virtual machines (VMs) or any kind of Azure resource with the Azure portal?

There are three primary problems when manually creating resources:

  • The task is error-prone. As humans, we make mistakes. Pointing and clicking in a UI opens up a whole new world of making mistakes because it’s incredibly simple to click a wrong button or type in a wrong IP address.

  • The task is cumbersome. Creating multiple resources manually is simply annoying and takes forever.

  • Even if you create the right components now, configuration drift is bound to happen. If you ask three engineers to create two virtual machines, chances are all three will create the VMs differently. Some may use the CLI and others may use the UI. This approach opens up opportunities for non-standard configuration.

How do we resolve these problems? We write code, specifically, Terraform code.

Terraform is an Infrastructure-as-Code (IaS), immutable programming language created by Hashicorp that defines infrastructure components as code whether they are on-prem or in the cloud.

Code isn’t cumbersome, and if it’s written correctly and in a reusable way, chances are it only has to be done once. Since the code is being used across the environment, you don’t have to worry about configuration drift because the code doesn’t change.

Many IaS tools exist already ranging from open-source, closed-source, and vendor-specific. Each IaS tool has its pros and cons, but Terraform is quickly becoming the standard in many Azure deployments. In fact, Microsoft is basing a ton of documentation off of Terraform.

Terraform simplifies the way that you can deploy Azure resources. In this chapter, you will learn the core fundamentals of Terraform to prepare you to take the experience you’ve learned and start building Azure resources with Terraform.

Configuration files

One of the most important concepts to understand in Terraform is the concept of a configuration file. Terraform configuration files (files with the tf extension) are the foundational component of Terraform. Configuration files provide instructions to the Terraform binary on what infrastructure to build and how to build it. These configuration files ultimately become a Terraform configuration.

Terraform has several configuration files, but the main (pun intended) configuration file is called main.tf. The main.tf configuration file holds what resources or services in Azure that you will be creating.

Although you can call the “main” configuration file something other than main.tf, it’s common practice to call it main.tf.

For example, perhaps you are creating a virtual network. The code to create the virtual network resource will be stored in the main.tf configuration file. You can see below what a main.tf configuration file may look like.

Shell
resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}
resource "azurerm_network_security_group" "example" {
  name                = "acceptanceTestSecurityGroup1"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
}
resource "azurerm_network_ddos_protection_plan" "example" {
  name                = "ddospplan1"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
}
resource "azurerm_virtual_network" "example" {
  name                = "virtualNetwork1"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  address_space       = ["10.0.0.0/16"]
  dns_servers         = ["10.0.0.4", "10.0.0.5"]
  ddos_protection_plan {
    id     = azurerm_network_ddos_protection_plan.example.id
    enable = true
  }
  subnet {
    name           = "subnet1"
    address_prefix = "10.0.1.0/24"
  }
  subnet {
    name           = "subnet2"
    address_prefix = "10.0.2.0/24"
  }
  subnet {
    name           = "subnet3"
    address_prefix = "10.0.3.0/24"
    security_group = azurerm_network_security_group.example.id
  }
  tags = {
    environment = "Production"
  }
}

Under the resource configuration file to create a virtual network, you will see arguments. Arguments contain values like the name of the virtual network, the location or region of the virtual network, IP addresses associated with the virtual network, and many other components, depending on what type of resource you are creating.

Hashicorp Configuration Language (HCL)

In a sense, Terraform is code. Where there’s code, there’s a language. Sometimes that language is a programming language, and other times it’s some sort of data serialization language. All Terraform configuration files are written in a language called HCL.

HCL code gets stored in configuration files and the configuration files are defined using Terraform configurations. When you run Terraform configuration files (you will learn more about running Terraform configuration files in later sections), the code inside of the configuration files will be triggered to create Terraform resources.

HCL is a programming language created by Hashicorp to be both human-readable and for a machine to quickly compile. HCL’s original design was to be geared towards DevOps tooling around automation of infrastructure and services, which still very-much holds true.

Shell
name                = var.name
location            = var.location
resource_group_name = var.resourceGroup
dns_prefix          = "..."
default_node_pool {
    name = "default"
    node_count = 1
    vm_size = "Standard_D2_v2"
}

You may notice that HCL configurations look very much like JSON or key-value pairs. Hashicorp made HCL in such a way that it is fully compatible with JSON and JSON can be used as an input system.

Providers and resources

Terraform isn’t just a tool to deploy Azure resources, it can also work with on-prem, AWS, and other providers. To support each of those providers, Terraform has a concept called providers.

Example Azure provider in a Terraform configuration file

Think of a Terraform provider like the medium between Terraform and Azure. For Terraform to communicate with Azure, it needs a path to get there. It needs to understand how Azure works. Terraform creates and maintains this “path”. But how does the provider know how to communicate with Azure?

Hashicorp builds the Azure provider (and all other providers for that matter) in a way for Terraform to make API calls to Azure. Because the provider is conducting API calls, Hashicorp needs access to Azure backend resources like virtual machines, web apps, and serverless, etc. Once Hashicorp receives access from Microsoft, they are then able to start creating resources against that particular provider.

Resources are how Terraform creates services and infrastructure. For example, to create a virtual machine using Terraform, you would use the azurerm_virtual_machine resource. The resource consists of several parameters that are passed in when you create the virtual machine. These parameters include things like the virtual machine name, what resource group the virtual machine will reside in, and so on.