Skip to main content

Using Azure DevOps and Terraform to deploy infrastructure

Terraform has been gaining more and more traction throughout 2019. With version 0.12, it gained even more traction. With it's bracket-based syntax and large library of providers (providers are what APIs you can hit. Azure, AWS, etc.), it provides a plethora of options for automating your infrastructure.

This example will be a very basic example of using Terraform, but if you would like something more sophisticated (building a certain piece of infrastructure, tfvars, Terraform variables, Terraform state, etc.) please feel free to reach out and ask.

Pre-requisites

1. An Azure DevOps account
2. A repo that's ready to commit your Terraform code and YAML pipeline to. I'm using Azure Repos.
3. The Terraform extension in Azure DevOps. For directions please visit: https://docs.microsoft.com/en-us/azure/devops/marketplace/install-extension?view=azure-devops&tabs=browser
4. An Azure DevOps project that you have access to.
5. A storage account to hold your Terraform state.


provider "azurerm" {
  version = "1.38.0"
}

resource "azurerm_app_service_plan" "newServicePlan" {
  name                = "mjl-appserviceplan"
  location            = "eastus"
  resource_group_name = "dev2"

  sku {
    tier = "Standard"
    size = "S1"
  }
}

resource "azurerm_app_service" "newAppService" {
  name                = "mjlappservice92"
  location            = "${azurerm_app_service_plan.newServicePlan.location}"
  resource_group_name = "${azurerm_app_service_plan.newServicePlan.resource_group_name}"
  app_service_plan_id = "${azurerm_app_service_plan.newServicePlan.id}"

  site_config {
    dotnet_framework_version = "v4.0"
    scm_type                 = "LocalGit"
  }
}


As you can see from the above, this is a very basic Terraform template. The first thing you see is the provider, which is to call Azure. The second is to create an App Service Plan. The third is to create the actual app with .NET 4.0.


As you can see from the above screenshot, I've committed and pushed my code to Azure Repos. Now we're ready to start with the YAML. I have enabled the multi-stage pipelines feature, so I'm going to click on Pipelines > Pipelines > New pipeline.



For the "Where is your code?" portion, I'll choose Azure Repos Git and select my repository.



I'll choose "Starter pipeline" as I'll be creating my own YAML pipeline.

trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: CopyFiles@2
    inputs:
      SourceFolder: 'Terraform'
      Contents: '**'
      TargetFolder: '$(Build.ArtifactStagingDirectory)'

  - task: PublishBuildArtifacts@1
    inputs:
      ArtifactName: 'drop'


Let's take a look at the first pieces of my YAML pipeline before adding in Terraform.

- My trigger is master. That means whenever I push new code to the master branch, my pipeline will deploy.
- My first task in my step is to copy my files. This copies my code from my repo so I can build an artifact out of it.
- My second task is my step is to publish my copied code as an artifact.

Now that I have my tasks to create my artifact, I'm ready to start on my Terraform tasks.

My first task will be to install Terraform on my Ubuntu build agent.

      - task: ms-devlabs.custom-terraform-tasks.custom-terraform-installer-task.TerraformInstaller@0
        displayName: 'Install Terraform 0.12.3'


My second task will be to initialize my Terraform environment.

      - task: ms-devlabs.custom-terraform-tasks.custom-terraform-release-task.TerraformTaskV1@0
        displayName: 'Terraform : init'
        inputs:
          backendServiceArm: '$(subscription)'
          workingDirectory: '$(Build.ArtifactStagingDirectory)'
          backendAzureRmResourceGroupName: '$(resourceGroup)'
          backendAzureRmStorageAccountName: '$(storageAccount)'
          backendAzureRmContainerName: '$(containerName)'
          backendAzureRmKey: tf/terraform.tfstate


As you can see on the above, I have a lot of variables. Within your variables, you can set up these values or you can hard-code them.  At scale, it's not good to hard-code anything because we want our code to be re-usable. Below are a list of my variables in my pipeline.



After my Terraform environment is initialized, I'm ready for the Terraform Plan. The plan is to ensure everything is ready to be deployed and to tell you what will be deployed.


  - task: ms-devlabs.custom-terraform-tasks.custom-terraform-release-task.TerraformTaskV1@0
    displayName: 'Terraform : plan'
    inputs:
      command: plan
      workingDirectory: '$(Build.ArtifactStagingDirectory)'
      environmentServiceNameAzureRM: '$(subscription)'


My third and final task is for the Terraform Apply which will create my infrastructure.

  - task: ms-devlabs.custom-terraform-tasks.custom-terraform-release-task.TerraformTaskV1@0
    displayName: 'Terraform : apply'
    inputs:
      command: apply
      workingDirectory: '$(Build.ArtifactStagingDirectory)'
      environmentServiceNameAzureRM: '$(subscription)'


The entire YAML configuration should look like the below.

trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: CopyFiles@2
    inputs:
      SourceFolder: 'Terraform'
      Contents: '**'
      TargetFolder: '$(Build.ArtifactStagingDirectory)'

  - task: PublishBuildArtifacts@1
    inputs:
      ArtifactName: 'drop'

  - task: ms-devlabs.custom-terraform-tasks.custom-terraform-installer-task.TerraformInstaller@0
    displayName: 'Install Terraform 0.12.3'

  - task: ms-devlabs.custom-terraform-tasks.custom-terraform-release-task.TerraformTaskV1@0
    displayName: 'Terraform : init'
    inputs:
      backendServiceArm: '$(subscription)'
      workingDirectory: '$(Build.ArtifactStagingDirectory)'
      backendAzureRmResourceGroupName: '$(resourceGroup)'
      backendAzureRmStorageAccountName: '$(storageAccount)'
      backendAzureRmContainerName: '$(containerName)'
      backendAzureRmKey: tf/terraform.tfstate

  - task: ms-devlabs.custom-terraform-tasks.custom-terraform-release-task.TerraformTaskV1@0
    displayName: 'Terraform : plan'
    inputs:
      command: plan
      workingDirectory: '$(Build.ArtifactStagingDirectory)'
      environmentServiceNameAzureRM: '$(subscription)'
   
  - task: ms-devlabs.custom-terraform-tasks.custom-terraform-release-task.TerraformTaskV1@0
    displayName: 'Terraform : apply'
    inputs:
      command: apply
      workingDirectory: '$(Build.ArtifactStagingDirectory)'
      environmentServiceNameAzureRM: '$(subscription)'


We're now ready to click "Save and run".



Please Note: If you see the error like the one in the screenshot below, please authorize the resources. This is due to the Terraform tasks needing access to your subscription.






Once we run our pipeline, we should see that everything has passed successfully.


If I go into my Azure portal under my "dev2" resource group, I should see my new app service and app service plan.



You have now successfully deployed resources with Terraform using Azure DevOps! Thanks for reading.

Comments

Popular posts from this blog

Run PowerShell code with Ansible on a Windows Host

Ansible is one of the Configuration Manager kings in the game. With it's easy-to-understand syntax and even easier to use modules, Ansible is certainly a go-to when you're picking what Configuration Management you want to use for your organization. Your question may be "but Ansible is typically on Linux and what happens when I'm in a Windows environment?". Luckily I'm here to tell you that Ansible will still work! I was pleasantly surprised with how easy it is to use Ansible on Windows with a little WinRM magic. Let's get started.

Pre-requisites for this post:
1) WinRM set up to connect to your Windows host from Ansible
2) Ansible set up for Windows Remote Management
3) SSH access to the Ansible host
4) Proper firewall rules to allow WinRM (port 5985) access from your Ansible host to your Windows host
5) Hosts file set up in Ansible that has your IP or hostname of your Windows Server.
6) At least one Linux host running Ansible and one Windows Server host …

Running PowerShell commands in a Dockerfile

As Docker continues to grow we are starting to see the containerization engine more and more on Windows. With the need for containers on Windows, we also need the same automation we get in Linux with Dockerfiles. Today we're going to create a Dockerfile that runs PowerShell cmdlets.
Prerequisites; 1. Docker for Windows
2. A code editor (VSCode preferred)

Let's go ahead and get our Dockerfile set up. Below is the Dockerfile I used for this post.

from mcr.microsoft.com/windows/servercore:1903 MAINTAINER Michael Levan RUN powershell -Command Install-WindowsFeature -Name Web-Server RUN powershell -Command New-Item -Type File -Path C:\ -Name config
As you can see from the above, this is a tiny Dockerfile. What this will do is install the IIS Windows 

Feature and create a new file in C:\ called "config".
You should see something very similar to the below screenshot;

Next let's create a running container out of our image. First we'll need to run docker container ls to

 get o…

DevOps tooling in the Microsoft realm

When I really started to dive into automation and practicing DevOps with specific tooling, there were a few key players. At the time Microsoft was not one of them. They were just starting to embrace the open source world, including the art and practice of DevOps. Since then Microsoft has went all in and the tech giant has made some incredible tooling. Recently I switched to a Microsoft-heavy environment and I love it. I went from AWS/Python/Ansible/Jenkins to Azure/PowerShell/ARM/Azure DevOps. My first programming language was PowerShell so being back in the saddle allowed me to do a full circle between all of the different types of tooling in both worlds. Today I want to share some of that tooling with you.

The first thing I want to talk about is ARM. What is ARM? ARM is a configuration management tool that allows you to perform software-defined-infrastructure. Much like Ansible and Terraform, ARM allows you to define what you want your environment to look like at scale. With ARM, yo…