Terraform and Azure DevOps
Tags: terraform, azure, azuredevops
Published: 2020-10-20 13:14:26

#### Purpose of this article

The main purpose of this article is to show you how to deploy your infrastructure using Terraform on Azure DevOps and deploy a sample application on multiple environments. 

I've been working on terraform for a while now and as a part of my learning process, thought I should write a blog post to show how to work with terraform on Azure DevOps and deploy an application into multiple environments.

In this post, we'll spin up our infrastructure on Azure by setting up the build & release pipelines and We'll also take a look at what each of the tasks in the build & release pipelines does.

#### Things you need to follow along

If you would like to do this on your own, following are the prerequisites you need:

* Azure Subscription
* Azure DevOps Account

#### Assumptions

This blog assumes that you have fair understanding of Azure, Azure DevOps & Terraform. Initially, we'll go through the setup required and then I'll discuss in detail about each of the pipeline steps.

Ok, lets dive right in.

As you may have already known, terraform is one of the infrastructure as code tools that enables us to deploy your landing zones in your respective cloud environments like Azure, AWS, GCP, soon. 

Terraform is considered as one of the tools in DevOps toolset.

So, we’ll take a look at how we can deploy our landing zone to different environments using Azure DevOps and deploy a sample application to it.

I’ve taken a Microsoft’s demo application PartsUnlimted and added my terraform code to it. 

It also contains the build and release pipeline json files you can import to follow along and replicate the same in your own subscription.

Here are the steps that we’ll do as a part of this our implementation:
1.	Import the code from my [github] (https://github.com/vivek345388/PartsUnlimited.git) repo to Azure DevOps
2.	Setup build pipeline
3.	Setup release pipeline
4.      Access the application in Dev
5.	Deploy the application to PreProd, Prod
6.      Walk-Through of terraform code, tasks in build & release pipelines

#### Code import from GitHub & Project Setup

Login to [Azure DevOps] (https://dev.azure.com/) and create a new project.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ascjawdfmazuocgljdgj.png)

Click on ‘Repos’ -> files and import the code. Click on the 3rd option, import

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/dx5txtzwd55p7elj0h51.png)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/4djoxrbgrkbk93jk3j1z.png)

Copy/Paste the following URL in clone URL https://github.com/vivek345388/PartsUnlimited.git and click on import

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/casxir5y48du6gh8cumy.png)

Once it’s done, it will show that the code is now imported and you will be able to see the repo with code.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/1mmv0345p0wi0qeph1bk.png)

In the above folder,
1.	Infra.Setup folder contains the terraform files that we will be using to deploy our infrastructure.
2.	Pipeline.Setup folder contains the build &release pipelines json files. Download both the json files from Build Pipeline & Release Pipeline to your local folder

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/8yydx32qwrk98ik3b7il.png)

>   Repeat the same step to download release pipeline json file from the code ReleasePipeline->PartsUnlimitedE2E_Release.json as well to your local folder.

#### Build Pipeline Setup

Now, let’s setup the build pipeline. Click on pipelines -> pipelines

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/crldnokfw55ie3w3nprq.png)

Click on ‘Import Pipeline’

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/46ne72fwxxqelej257i9.png)

Click on browse and select the downloaded build Json file.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/m7k3g5hn3y1vpa9chshx.png)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/9f1udiy27ki8f9gk3w4x.png)

Once import is successful, you will see below screen where it says some settings needs to attention

For the agent pool,  Choose ’Azure Pipelines’

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/6kbrnnurqfhe2kpwp5th.png)

In the agent specification, choose ‘vs2017-win2016’

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/c83o3mby8u8b7rn4py5g.png)

Click on ‘Save & queue’ to queue a new build.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/v3n07fsm98vt9hg70c0f.png)

Choose the defaults and click on ‘save and run’

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ayhh7c7lq5dgel44d3h5.png)

Once its complete, you should be able to see the pipeline run and its results.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/tn2q63b2numzhwadno2i.png)

We can also see the published artifacts in the results.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/q3vaa49rk518t913u8ux.png)

Now this completes the build pipeline setup. Let’s also configure release pipeline. 

#### Release Pipeline Configuration

Click on ‘releases’ and click on 'New pipeline'

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/p64y7hjxsk11rzww8at9.png)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ejtexdfxjhv4hz4y2d9a.png)

> Quick Note: At the time of writing this article, we don't have an option to import an existing pipeline from new release pipeline page when you don't have any release pipelines. Hence we have to create a new empty pipeline to get to the screen where we can import the downloaded release pipeline json file.

Choose ‘empty job’ and click on ‘save’

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/oaxc3eq5g2lcvshulfg4.png)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/4ijk7extck7e8rqqjn1q.png)

Now, come back to the releases page and click on the releases one more time and choose import pipeline.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/1nz0yc0kcpzy0jnlap78.png)

Choose release pipeline json that’s downloaded in the beginning.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/g4ewrio1s1sf4o7a7c7h.png)

It would look like below after the pipeline has been imported. Click on ‘Dev’ of the stage to configure the settings.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/7bejjxuxzx69uucydc9y.png)

>    Quick note: You need to have following tasks installed from Azure Market Place. if you don't have them in your subscription, please get them from here.
1.	[Replace tokens](https://marketplace.visualstudio.com/items?itemName=qetza.replacetokens)
2.	[Terraform](https://marketplace.visualstudio.com/items?itemName=ms-devlabs.custom-terraform-tasks)

Click on ‘Azure cli’ & ‘App service deploy’ tasks and choose the subscription to authorize. 

>  Quick Note: I’m not using service principals/connections here to keep it simple for the purpose of this blog post.


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/j3b60y33mtzlt2d2wpm7.png)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/1p6uvc9vbs0z8tt3kcq7.png)

Repeat the same steps for rest of the stages ‘PreProd’ & ‘Prod’. Once you complete all the tasks that needs attention, click on save at the top of the screen to save the pipeline.
Here is how the pipeline should look like after you complete everything.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/zqv3m1bomax3hlej6zfl.png)

After you have saved everything, click on ‘Create release’ in above screen.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/7cn447vl318qkcybx436.png)

Click on ‘logs’ option to view the logs for each of the tasks. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/npripbtzob69e6ulig7v.png)

After successful deployment to Dev, it would look like this.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/x2jzu8rg721kvgs95hqv.png)

Once everything is done, you would see that code is deployed successfully to dev and you can browse the page by accessing the webapp link.

Go to your Azure portal and grab your webapp link and access it.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ntxs39u2lsgf5tupa7hh.png)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/y6o0o0duawhkjw2d9bof.png)

Back in your Azure DevOps release pipeline, As continuous deployment is enabled, it deploys the code to all the environments one after the other once the deployment is successful.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/9ruxmzj2us8qsxyeo81u.png)

Now let’s take a minute to examine what each of the files in our Infra.Setup folder does. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/2f2ty38men8m2x8lpxhv.png)

I’ve used the concept of modules in terraform to isolate each of the components we are deploying. This is similar to linked templates in ARM templates. 

Every terraform file that we author is considered as a module.

In a simple Terraform configuration with only one root module, we create a flat set of resources and use Terraform' s expression syntax to describe the relationships between these resources:

````
resource "azurerm_app_service_plan" "serviceplan" {
  name                = var.spName
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  sku {
    tier = var.spTier
    size = var.spSKU
  }
}

resource "azurerm_app_service" "webapp" {
  name                = var.webappName
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  app_service_plan_id = azurerm_app_service_plan.serviceplan.id
}
```


In the above code block, we declare two resources, app service and service plan in a single file. Later, app service is referencing the app service plan in the same file. while this approach is fine for smaller deployments, when the infrastructure grows, it would be challenging to maintain these files.

When we introduce module blocks, our configuration becomes hierarchical rather than flat: each module contains its own set of resources, and possibly its own child modules, which can potentially create a deep, complex tree of resource configurations.

However, in most cases terraform strongly recommend keeping the module tree flat, with only one level of child modules, and use a technique similar to the above of using expressions to describe the relationships between the modules.


```

module "appServicePlan" {
    source  = "./modules/appServicePlan"
    spName  = var.spName
    region  = var.region
    rgName  = var.rgName
    spTier  = var.spTier
    spSKU   = var.spSKU
}

module "webApp" {
    source         = "./modules/webApp"
    name           = var.webAppName
    rgName         = var.rgName
    location       = var.region
    spId           = module.appServicePlan.SPID
    appinsightskey = module.appInsights.instrumentation_key
}
```

Here you can see that both app service plan and app service are called as modules by main.tf file

> Definition Credits: Terraform.io

#### Benefits of modular based templates

Modules or Linked Templates yields us following benefits:
1.	You can reuse the individual components for other deployments.
2.	For small to medium solutions, a single template is easier to understand and maintain. You can see all the resources and values in a single file. For advanced scenarios, linked templates enable you to break down the solution into targeted components.
3.	You can easily add new resources in a new template and call them via main template.

Following are the resources that we deployed as a part of this blog post.

1.	App service plan – To host the Webapp
2.	App Service – Webapp to host the application.
3.	Application insights – To enable monitoring.

Its hierarchy looks like this.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/nrwruxhd501rsgfy2byb.png)

In general when we have a single file for deployments, we pass the variables in the same file or use a .tfvars file to pass the variables.

> Variables are same as Parameters in ARM templates

 In the above file structure, each individual template for example: webapp.tf will have its variables that it needs. The values have to be passed to it when this module is called. Remember that each terraform file that we create is considered as a module.

```
variable "name" {}
variable "location" {}
variable "rgName" {}
variable "spId" {}
variable "appinsightskey" {}

resource "azurerm_app_service" "webApp" {
  name                = var.name
  location            = var.location
  resource_group_name = var.rgName
  app_service_plan_id = var.spId
  app_settings = {
    "APPINSIGHTS_INSTRUMENTATIONKEY" = var.appinsightskey
  }
}

resource "azurerm_app_service_slot" "webApp" {
  name                = "staging"
  app_service_name    = azurerm_app_service.webApp.name
  location            = azurerm_app_service.webApp.location
  resource_group_name = azurerm_app_service.webApp.resource_group_name
  app_service_plan_id = azurerm_app_service.webApp.app_service_plan_id

  app_settings = {
    "APPINSIGHTS_INSTRUMENTATIONKEY" = var.appinsightskey
  }

}
```
Now lets see how the values are passed and modules are called in individual templates.

There are two main files that control the entire deployment.

1.  main.tf     -  Contains the code to call all the individual resources.
2.  main.tfvars -  Contains variables that are consumed by main.tf file

in the main.tf file, each of the modules will be called as follows:

```
module "appServicePlan" {
    source  = "./modules/appServicePlan"
    spName  = var.spName
    region  = var.region
    rgName  = var.rgName
    spTier  = var.spTier
    spSKU   = var.spSKU
}

module "webApp" {
    source         = "./modules/webApp"
    name           = var.webAppName
    rgName         = var.rgName
    location       = var.region
    spId           = module.appServicePlan.SPID
    appinsightskey = module.appInsights.instrumentation_key
}
```

the variables are declared in the same file in the variables section.


```
variable "region" {}
variable "rgName" {}
variable "spName" {}
variable "spTier" {}
variable "spSKU" {}
variable "webAppName" {}
variable "appInsightsname" {}
variable "AIlocation" {}
```
The values for above variables will be passed from main.tfvars file.

We use the same templates for deployment to all the environments. so how does Azure DevOps handles deployments to different environments? 

We keep place holders `#{placeholdername}#` for each of these values passed in our main.tfvars file.

```
region = #{region}#               
rgName = #{ResouceGroupName}#       
spName = #{spName}#                     
spSKU =  #{spSKU}#                
spTier = #{spTier}#             
webAppName = #{webAppName}#         
appInsightsname = #{appInsightsname}#   
AIlocation = #{AIlocation}#
```

when use the same templates for deploying to multiple environments, We use ‘replace tokens’ task in Azure DevOps and place respective values for each environment. This helps us in choosing different values for each environment. 

For example, the value for `#{webAppName}#` will be different per environment.

`app-dev-webapp` for dev
`app-ppd-webapp` for preprod
`app-prd-webapp` for prod

While the main.tfvars file has a place holder `#{webAppName}#` for this, we declare the values for it in our variables section of release pipeline

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/le554ov6poum36z7wr2j.png)

The 'replace tokens' task has an option called token prefix where we can declare the token prefix and suffix for the place holder value in the file we would like to replace in. In the target files, we place the files would like to get targeted for this replacement. Here we gave  **/*.tf and **/*.tfvars as the target as these files have the placeholder content.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/zkye3l3pjt1jg0wgu7rw.png)


#### Build Pipeline

Build pipeline is mostly self explanatory as the first couple of tasks complie the application and publish the code.

Take a look at the Publish Artifact: Artifacts, Publish Artifact: Infra.Setup tasks

Publish Artifact: Artifacts : publishes the compiled code to Azure Pipelines for consumption by release pipelines

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/0lacldmqb5102w46hzmx.png)

Publish Artifact: Infra.Setup tasks : publishes the terraform templates to Azure Pipelines for consumption by release pipelines. As we dont need to compile them we can directly choose them from the repo as path to publish.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ux4yo5iyob2z0h7ve0bl.png)

At the end of the build pipeline, it would publish the artifacts as below:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/kmk5dxi8dorej29sg6uw.png)

These will be consumed in our release pipeline for deployment.

#### Release Pipeline

You can see that the source artifacts are from our build pipeline.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/kwql3dbchgnlvr42wip7.png)

Now lets take a look at each of the release tasks.

1.Create Resource Group and Storage Account: Creates a storage account for storing .tfstate file that terraform stores the configuration of our deployment.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/taee0wi6sdc567ccctpb.png)

2.Obtain access Key and assign to pipeline variable: Retrieves the storage account key and assigns it to a variable in Azure Pipelines.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/6vf9ap663kiimmhjb3sw.png)

3.Replace tokens in **/*.tf **/*.tfvars: 

Remember that we have kept place holders to replace the values per environment, this task is responsible for the same. Values for each of the place holders in main.tf file are in variables section of each stage.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ep0gcpj7u2j9pavvg7rm.png)

4.Install Terraform 0.13.4: Installs terraform on the release agent.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/znrgo65e68g6y722dl92.png)

5.Terraform: init : Initializes the terraform configuration and we also have specified the storageaccount resource group and the storage account for it to place the .tfstate file

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/qc5a0d7ua279686n0b3r.png)

6.Terraform: plan : Runs terraform deployment in dry-run mode

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/5gjddnn0rm8vfewuf9jg.png)

7.Terraform: apply -auto-approve: Applies the configuration based on the dry-run mode in step 6.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/rf3ryfg6m4u9toek2txh.png)

8.Retrieve Terraform Outputs: This task is mainly responsible for retrieving each of the outputs obtained after terraform apply is complete and they are being consumed by the 'App Service Deploy' task. In case of Azure, we have ARM Outputs task readily available for us, here we need to write a small script to get the outputs.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/yl5pixffowk28lz3m5bk.png)


9.Azure App Service Deploy: Deploys the application code into the webapp.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/92egtw93q92g31mfbfa0.png)

### Conclusion

This brings us to the end of the blog post.

Hope this helps you learn, practice and deploy your infrastructure using Terraform via Azure DevOps!!

Thanks for reading this blog post & Happy Learning..