Manage Your Cloud Infrastructure As Code With Terraform.io

To kick things off, we need to login to create these service principal credentials, for that, we will use the Powershell script attached to this article.

Note the param 'setup' after the script. After running this command, you are asked to accept or reject data collection, and then login to your Azure account,

Once you log in, you are prompted to enter a NAME for your app, and a password. When this is complete, you will be given a response in JSON that details settings you need for the Terraform setup config.

Terraform Azure config

Having created our service principal and received the settings we need from the script, we then start to build up our configuration file that Terraform will use to create the resources. If we refer back to what was auto created for us by the Azure portal click/build earlier, we get a fair idea of what we need to put in our config,

The Terraform config file consists a number of sections. At the top, we declare the 'Provider'. This is the cloud host in our case. In here we give details that we received as JSON output when we ran the Powershell setup script above...

Terraform config files have a '.tf. extension. I created my first one simply called 'sample.tf'. Its a simple text file, and the format is very basic.

Provider details

At the top of the file I give the details for the provider, together with the details from JSON,

# Core init provider "azurerm" { 
client_id = "your client id in here" 
client_secret = "your secret in here" 
subscription_id = "your subscription value in here" 
tenant_id = "your tenant id in here" }   

(clearly you need to input your own values where indicated!)

Note the provider name 'azurerm". The format for other providers is different. You can get the full details of these on the Terraform docs page on providers.

From the top down, we then start building up a collection of particulars of what we want Terraform to create. If you already have resources existing with the same name/type, they will be skipped, else created. You can also force an over-write/re-build of virtual resources (check documentation for details).

Resource group

The top level placeholder for all things Azure is the 'Resource group'.

# Setup resource group resource "azurerm_resource_group"   
"Alias_RG" {      
 name = "Terraform-resource-group"       
location = "North Europe" }   

Lets talk about some of the settings. On the top line, we have a comment, denoted by '#'. Next we have the first token which tells Terraform what itype follows, in this case a 'resource'. As the previous section informed Terraform that follows is an Azure configuration, it then understands that the resource is related to this, and type declared is 'azurerm_resource_group'. Straight after this, we can give the item an alias, in this case I name it 'Alias_RG' (for resource group). The 'name' gives the resource geting created a title, and the 'location' refers to the zone on the cloud provider where the resources should be created. I'm pretty sure all of the cloud providers have the concept of a location zone.

Network settings

We next have a group of settings that refer to items needed to create the network resources required to sit the Virtual Machine we are building into. As before, you can use pre existing resources if you wish, I am simply creating everything from scratch here to show the build out of detail. Most of the individual values are self explanatory.

# Create virtual network within the group resource "azurerm_virtual_network" "Alias_VN" {   
name = "Terraform-virtual-network"   
resource_group_name = "${azurerm_resource_group.Alias_RG.name}" address_space = [    "10.0.0.0/16"]   
location = "North Europe" } 

One key item to note above, is how we are using a template to reference the ALIAS we created for the resource group. I have highlighted this in bold.

Each alias is prefixed with the type that should be referenced,

# Create subnet resource "azurerm_subnet" "Alias_SubNet" {       
name = "subn"       
resource_group_name = "${azurerm_resource_group.Alias_RG.name}"     
virtual_network_name = "${azurerm_virtual_network.Alias_VN.name}"     
address_prefix = "10.0.2.0/24" }  

and after the alias the object member/property that should be referred to,

# create public IP  
resource "azurerm_public_ip" "Alias_PubIP" {  
    name = "TestPublicIP"   
    location = "North Europe"  
    resource_group_name = "${azurerm_resource_group.Alias_RG.name}"  
    public_ip_address_allocation = "dynamic"  
  
    tags {  
        environment = "TerraformDemo"  
    }  
} 

We can also use variables in the script (same as declaring an Alias). This is very useful where we want to declare some top level naming convention and have this cascade through our template.

# create network interface  
resource "azurerm_network_interface" "Alias_NIC" {  
    name = "tfnetinterface"  
    location = "North Europe"  
    resource_group_name = "${azurerm_resource_group.Alias_RG.name}"  
  
    ip_configuration {  
        name = "testconfiguration1"  
        subnet_id = "${azurerm_subnet.Alias_SubNet.id}"  
        private_ip_address_allocation = "static"  
        private_ip_address = "10.0.2.5"  
        public_ip_address_id = "${azurerm_public_ip.Alias_PubIP.id}"  
    }  
}

Storage account settings

After the network settings, we then setup configuration for where both data and the virtual machine itself will be stored.

# create storage account  
resource "azurerm_storage_account" "Alias_StorageAccount" {  
    name = "tfstorage1234xx"  
    resource_group_name = "${azurerm_resource_group.Alias_RG.name}"  
    location = "North Europe"  
    account_type = "Standard_LRS"  
  
    tags {  
        environment = "staging"  
    }  
}  

We use the same alias naming convention throughout. Also of interest is we can introduce the concept of dependencies.

# create storage container  
resource "azurerm_storage_container" "Alias_Storage" {  
    name = "vhd"  
    resource_group_name = "${azurerm_resource_group.Alias_RG.name}"  
    storage_account_name = "${azurerm_storage_account.Alias_StorageAccount.name}"  
    container_access_type = "private"  
    depends_on = ["azurerm_storage_account.Alias_StorageAccount"]  
}   

Virtual machine settings

Finally, we come down to setting out what we want for the virtual machine itself. As before, here we link this new item to other aliases for the resource group, networks, storage accounts etc. In the operating syste, profile, we also give the initial username/password credentials the machine should be setup with. We can use these later to test of everything worked. Note also the 'storage image reference' I am sending it to pick from, here we can be quite specific in our requirements, and use our own images as well as those predefined by the cloud host.

# create virtual machine  
resource "azurerm_virtual_machine" "Alias_UBuntuVM" {  
    name = "terraformvm"  
    location = "North Europe"  
    resource_group_name = "${azurerm_resource_group.Alias_RG.name}"  
    network_interface_ids = ["${azurerm_network_interface.Alias_NIC.id}"]  
    vm_size = "Standard_A0"  
  
    storage_image_reference {  
        publisher = "Canonical"  
        offer = "UbuntuServer"  
        sku = "14.04.2-LTS"  
        version = "latest"  
    }  
  
    storage_os_disk {  
        name = "myosdisk"  
        vhd_uri =   
           "${azurerm_storage_account.Alias_StorageAccount.  
               primary_blob_endpoint}${azurerm_storage_container.Alias_Storage.name}/somevmdisk.vhd"  
        caching = "ReadWrite"  
        create_option = "FromImage"  
    }  
  
    os_profile {  
        computer_name = "hostname"  
        admin_username = "testadmin"  
        admin_password = "Password1234!"  
    }  
  
    os_profile_linux_config {  
        disable_password_authentication = false  
    }  
  
    tags {  
        environment = "staging"  
    }  
}

Terraform execution

We have our configuration complete, the next thing is to have Terraform set things up, and apply the config remotely for us. This is a two step process, first we 'plan' the job, then we 'apply' it.

At the command line, enter terraform.exe sample.tf(or whatever you name your config file).

After a second or so, Terraform will have pre-planned the job with output that should look similar to the following:

The last main step (fingers crossed!) is to 'apply' the plan to the cloud host. The 'apply' action works through the planned job, connects to the specified cloud host, and uses the config plan to execute and create/modify the resources as required. When complete, the output should look something like the following,

So, did it work? Let's take a look in the Azure portal...

Looking good! ... Ok, so that's the basics of Terraform. Further articles in this series will look at how we can automate and harness this using a .NET Core API, and then further extend orchestration using Docker and Kubernates.

If you want to learn more about the information in this article., here are some great links for you to start with!

Official documentation for Terraform.io
Microsoft labs for Terraform.io on Azure
Video - Azure With Terraform: Provider 2.0 Update