Terraform & Azure ❤ GitLab CI — Part 1: Basic Concepts

Rudy van Sloten
3 min readJul 31, 2020

In this series, we’ll go through the basics of using Terraform and GitLab CI to create a simple infrastructure-as-code (IaC) pipeline. We’ll be using Microsoft Azure for our infrastructure, but this can be applied to any other platform. (AWS, OpenStack, VMWare, etc.)

This article is part of a series:

Be aware that this requires a basic level of familiarity with the following:

  • Linux
  • Virtualization/cloud platforms
  • Scripting and git repositories
  • Terraform 0.12+

The co-founder of HashiCorp made a short, useful video about the basic of Terraform.

Software Requirements

To follow this guide, you’ll need the following software:

What is…

Terraform

Terraform is an open source tool that allows you to define your infrastructure as code. It leverages its own language, HCL, which resembles a mixture of JSON and YAML. What separates Terraform from similar tools, is the presence of state. Terraform saves your desired configuration to a file and compares the file and your existing environment during each run. This allows for very precise control over what is allowed to exist and eliminates the need for writing logic for dealing with creating/updating/deleting/editing.

Let’s grab a practical example. I’ll define a Virtual Network in Microsoft Azure. This is usually done through the Azure CLI (and ARM Templates) or Azure Portal. ARM Templates are very cumbersome and hard to read, a problem that is much less prevalent in Terraform HCL.

# Create a Resource Group
resource "azurerm_resource_group" "myRG" {
name = "myResources"
location = "West Europe"
}
# Create a Virtual Network
resource "azurerm_virtual_network" "myVNet" {
name = "myNetwork"
address_space = ["10.0.1.0/24"]
location = azurerm_resource_group.myRG.location
resource_group_name = azurerm_resource_group.myRG.name
}

It’s fairly simple. You define a block of code, starting with the type of resource you want and how it can be referred to. In Microsoft Azure, each resource starts with a Resource Group. Resource Groups are akin to folders on a computer. Everything you create has to be inside one.

Part of the elegance of Terraform is the ease of referencing other parts of the configuration. Instead of typing out the name and region of the Resource Group I want my Virtual Network to be in, I can simply reference it with a variable.

Microsoft Azure

Microsoft Azure is a cloud platform, which allows you to create compute, databases, serverless apps and many more resources. There are several free/cheap offerings, and the trial account gives you $200 worth of resources/minutes to play with. If you’re familiar with AWS, this is similar. You can sign up here.

GitLab

GitLab is a web-based DevOps tool that provides git repositories, authentication and CI pipelines. For those unfamiliar with the concept, pipelines will allow you to automate deployments of anything you submit into a git repository, through a dedicated YAML file that defines what should happen after new code is pushed. For example, it can boot up a Docker image and do some installation tasks via something like Ansible:

image:
name: ansible/ansible

stages:
- deploy

deploy:
stage: deploy
script:
- apt update
- eval $(ssh-agent -s)
- mkdir -p ~/.ssh
- ssh-add <(echo "$PRIVKEY")
- mv ansible.cfg /etc/ansible/ansible.cfg
- ansible-playbook deploy.yml -v

GitLab uses Runners to execute your pipeline. By default, shared runners are assigned to your project. This is free infrastructure with limited functionality that will suffice for most small projects. No installation required, It Just Works. For bigger and/or private projects, you can assign your own servers or Kubernetes cluster to do the heavy lifting.

Next up…

Once you’re finished with the basics, you are ready to proceed with:
Terraform & Azure ❤ GitLab CI — Part 2: Preparing your project

--

--