7. Terraform with Pipeline on Terraform Basics on Azure Training

7.1. Introduction to GitLab CI/CD

Mon, 01 Jan 0001 00:00:00 +0000

Building Blocks of a GitLab Pipeline

Before writing any Terraform CI/CD configuration, let’s understand the key concepts.

A GitLab pipeline is defined in a file called .gitlab-ci.yml at the root of your repository.

Concept	Description
Pipeline	The top-level process triggered by a git push or manually
Stage	A named phase (`build`, `test`, `deploy`). Stages run sequentially
Job	A unit of work inside a stage. Jobs in the same stage run in parallel
Runner	An agent (VM or container) that executes job scripts
Variable	A key/value pair, either defined in `.gitlab-ci.yml` or in GitLab project settings

Preparation

Create a new GitLab project and clone it:

7.2. Azure Credentials for CI/CD

Mon, 01 Jan 0001 00:00:00 +0000

Terraform needs an Azure service principal to authenticate from a pipeline runner — a non-interactive identity with scoped permissions. In this lab you create the service principal with the Azure CLI and store the resulting credentials as masked GitLab CI/CD variables.

Preparation

Make sure you are logged in to the Azure CLI and have the correct subscription selected:

az login
az account show

If you need to switch subscription:

az account set --subscription "<your-subscription-id>"

Step 7.2.1: Create a service principal

Create a service principal scoped to your subscription with the Contributor role:

7.3. GitLab Runner on Azure

Mon, 01 Jan 0001 00:00:00 +0000

Shared GitLab runners work for many scenarios, but teams that deploy to Azure often need a self-hosted runner that:

Has network access to private Azure resources
Can cache Terraform provider plugins locally to speed up pipelines
Can be tagged so only specific pipelines use it

In this lab we provision a dedicated GitLab Runner on an Azure Linux VM using Terraform. The overall flow looks like this: a local Terraform apply bootstraps an Azure VM, registers a runner token with GitLab, and then uses SSH provisioners to install Docker and start the GitLab Runner container on the VM.

7.4. Build a Pipeline Image with Kaniko

Mon, 01 Jan 0001 00:00:00 +0000

Building a custom Docker image inside a CI pipeline — without access to a Docker daemon — is a common requirement when using container-based runners. Kaniko solves this by executing each Dockerfile instruction in user-space, writing directly to container filesystem layers instead of relying on the host Docker socket.

In this lab you:

Extend the Terraform code from Lab 7.3 to grant the service principal AcrPush access on the Azure Container Registry created in Chapter 6.
Create a dedicated GitLab repository for the builder image — separate from the Terraform pipeline repository used in Chapters 7.1–7.3.
Write a Dockerfile that bundles terraform and tflint for use in pipeline jobs.
Add a simple .gitlab-ci.yml that uses Kaniko to build and push the image to ACR whenever the Dockerfile changes.

Keeping the image repository separate from the Terraform code repository is a common practice: the two repositories have different lifecycles (the image changes when tool versions change; Terraform code changes when infrastructure changes) and different access-control requirements.

7.5. Linting in CI

Mon, 01 Jan 0001 00:00:00 +0000

Code quality checks catch mistakes early. For Terraform we can run three levels of linting:

Tool	What it checks
`terraform fmt -check`	Canonical formatting (whitespace, indentation)
`terraform validate`	Syntactic and semantic validity
`tflint`	Provider-specific rules, best practices, unused variables

In this lab we run these checks locally and wire them up as a GitLab CI linting stage using the Docker image built and pushed to ACR in Lab 7.4.

flowchart LR
 user --> |run|fmt
 user --> |run|tflint
 subgraph local
 fmt(terraform fmt)
 tflint
 end
 subgraph pipeline
 linting
 end
 local --> |automate|pipeline

Preparation

Navigate to your existing Terraform working directory: