Image result for Terraform Logo

I feel like I have gone back to the 90’s where every developer needed to know how everything worked in the infrastructure.  I guess that it is true that everything goes in cycles.  DevOps has many faces and lately I have been working with Terraform to implement infrastructure as code.  Below I will give a brief (maybe not so brief) overview of this tool and how to get started with it.  In part this post is because I found both the documentation and online tutorial lacking in even the simple explanations.


One of the first things I noticed about Terraform was the install process. It is simply a single executable with no actual installer. It isn’t horrible, but I can’t remember the last time I had to set the PATH environment variable so that I could get an application to run.

The product works by keeping track of the “state” of your environment and comparing it to the script that you are telling it to run.  On the surface this is just what you want, but you can end up fighting the implementation if you are not careful.

You need to also get up to speed with their reuse of terminology.  They call your main script file (.tf extension) a configuration file.  Given that we are configuring system resources it makes sense, but we already have the concept of configurations in development and this overload of the team can be confusing at first.

State is the term used to describe what Terraform believes is the current configuration of your infrastructure environment.  It refreshes that state each time you apply a new configuration and is the base of comparison for your plan.

The plan is a list of proposed changes based on your definition and the saved state of your infrastructure.  Anything in the plan marked with a plus sign (+) will be created.  Anything with a minus sign (-) will be destroyed.

Writing Code

The script is fairly simple. I was surprised to learn after working with it for a while that it is implemented in Go lang.  Since this is a language I have not used before I will reserve judgement until I further investigate it.

Variables files contain the definition of variables.  It has a .tf extension just like the configuration file, and seems to be pull together just by the fact that it is in the same directory.  Each variable is defined by a name, a type and a description.

variable “variable_name”
     type = string
     description = “Some description”

Variable value files hold the testing values for your Terraform variables.  They are simply a list of assignment statements as shown below.

variable_name1 = "variable 1 value"
variable_name2 = "variable 2 value"
variable_name3 = "variable 3 value"

Configurations use providers and resources for each platform and platform resource that you wish to instantiate.  For Azure the provider is azurerm.  Each of the resources is prefixed with the provider designation and you follow it’s name with an identifying string that can be used for the remainder of the configuration. In the example below “rg” is the identifier.  Below is the absolute minimum configuration for a new resource group.  There are other optional sections like “locals” which setup variables, but that is for another post.

provider “azurerm”
     version = "=2.2.0"
     features {}

resource “azurerm_resource_group” “rg” {
      name = “resourcegroupname”
     location = “azure region name”

Testing The Code

When it comes to running your Terraform configuration script I would suggest using PowerShell and the Azure AZ CLI.  This will allow you to easily log into your Azure account for testing specify which subscription you want to use as this is assumed to already be in place in just about any Terraform example you will find.

You then need to understand the lifecycle of Terraform: Init,Plan,Apply, Destroy.

First navigate to the directory that contains the configuration you want to test.  From this location execute the statement terraform init.  This will read the current state of your subscription and store it in a hidden state directory.

Next execute the terraform plan statement.  This will check your configuration for error and compare it to the state of your subscription. As described above you will get a list of each change that is calculated to be made.

In order to commit your configuration to the default subscription execute the terraform apply statement.  This will give you an output detailing each operation and a confirmation of the original plan.

Lastly, if you want to remove the resources created by your configuration execute the terraform destroy statement.


This post covered only the most basic aspects of Terraform.  It should be enough to get you started and hopefully covers some of the explanations that most people leave out.  From here you should refer to the developer documentation for details on each of the resources that can be used and some of the optional sections not included here..

In a future post I will describe how to integrate Terraform with your Azure DevOps pipeline