6. Azure Workshop on Terraform Basics on Azure Training

6.1. Kubernetes / AKS

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

Step 6.1.1: Provision the first resource

Create a new file named main.tf and add the following content:

provider "azurerm" {
 subscription_id = var.subscription_id
 features {
 resource_group {
 prevent_deletion_if_contains_resources = false
 }
 }
}

resource "azurerm_resource_group" "default" {
 name = "rg-${local.infix}"
 location = var.location
}

data "azurerm_subscription" "current" {}

Create a new file named variables.tf and add the following content:

locals {
 infix = "${var.purpose}-${var.environment}"
}

variable "subscription_id" {}
variable "purpose" {}
variable "environment" {}
variable "location" {}

Create a new configuration file file named config/dev.tfvars and add the following content:

subscription_id = "c1b34118-6a8f-4348-88c2-b0b1f7350f04"
purpose = "YOUR_USERNAME"
environment = "dev"
location = "westeurope"

Note: Please replace YOUR_USERNAME with the username assigned to you for this workshop.

6.2. Remote State

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

Step 6.2.1: Create a storage

The Azure storage account and storage container to store the Terraform state are not managed by Terraform; it is a chicken and egg problem we resolve by using the az CLI as followed:

export NAME=YOUR_USERNAME
export ACCOUNT=tfstate$RANDOM

az group create --location westeurope --name rg-terraform-$NAME
az storage account create --name $ACCOUNT --resource-group rg-terraform-$NAME
az storage container create --resource-group rg-terraform-$NAME --account-name $ACCOUNT --name terraform-state --public-access off --auth-mode login
echo $ACCOUNT

Note: Please replace YOUR_USERNAME with the username assigned to you for this workshop.

6.3. Load Balancer

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

Step 6.3.1: Create a kubernetes namespace

flowchart LR
 classDef red fill:#f96;
 aad(AD Group) --> |permission|aAks
 aNode --> |use|dSub
 subgraph rg: aks
 aAks(aks) --> |logs|aLaw(law)
 aAks --> aNode(nodes)
 aAcr(acr) --> |images|aNode
 end
 subgraph rg: net
 dNet(vnet) --> dSub(subnet)
 end
 aAks --> aks
 subgraph aks
 cIngress(ns: nginx-ingress):::red
 end

Add the following content below the existing provider block of main.tf:

provider "kubernetes" {
 host = azurerm_kubernetes_cluster.aks.kube_admin_config.0.host
 client_certificate = base64decode(azurerm_kubernetes_cluster.aks.kube_admin_config.0.client_certificate)
 client_key = base64decode(azurerm_kubernetes_cluster.aks.kube_admin_config.0.client_key)
 cluster_ca_certificate = base64decode(azurerm_kubernetes_cluster.aks.kube_admin_config.0.cluster_ca_certificate)
}

Create a new file named nginx_ingress.tf and add the following content:

6.4. SSL Certificates

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

Step 6.4.1: Cert Manager installation

flowchart LR
 classDef red fill:#f96
 subgraph rg: aks
 aAks(aks)
 aIp(public ip)
 end
 dDns --> aIp
 subgraph rg: dns
 dDns(dns)
 end
 aAks --> aks
 subgraph aks
 aIp --> sNg
 subgraph ns: nginx-ingress
 sNg(service) --> pNg(pod)
 end
 subgraph ns: tests
 sTst(service) --> pTst(pod)
 pNg --> iTst(ingress) --> sTst
 end
 subgraph ns: cert-manager
 sCm(service):::red --> pCm(pod):::red
 end
 end

Create a new file named cert_manager.tf and add the following content:

6.5. MySQL

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

Step 6.5.1: Configure AKS egress IP

By default, AKS routes traffic to the internet via a (randomly assigned) Azure public IP. For some scenarios like our MySQL instance, we want to whitelist the source IP to restrict access to the services.

Add the following content below the resource azurerm_public_ip.aks_lb_ingress in aks.tf:

// optional: only needed to control AKS egress IP(s)
resource "azurerm_public_ip" "aks_lb_egress" {
 name = "pip-${local.infix}-aks-lb-egress"
 location = var.location
 resource_group_name = azurerm_resource_group.aks.name
 allocation_method = "Static"
 sku = "Standard"
}

To configure AKS to use a static egress IP, modify the azurerm_kubernetes_cluster.aks resource in aks.tf and replace the network_profile block with the following content:

6.6. Demo App

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

Step 6.6.1: Deploy a workload container

flowchart LR
 classDef red fill:#f96
 subgraph rg: aks
 aAks(aks)
 aIp(public ip)
 end
 dDns --> aIp
 subgraph rg: dns
 dDns(dns)
 end
 aAks --> aks
 subgraph aks
 aIp --> sNg
 subgraph ns: nginx-ingress
 sNg(service) --> pNg(pod)
 end
 subgraph ns: workload
 iAc --> sAc(service):::red --> pAc(pod):::red
 pNg --> iAc(ingress):::red
 end
 end
 pAc --> mFire
 subgraph rg: db
 mServer(mysql) --> mDb(database)
 mFire(firewall) --> mDb
 end

To test the setup end-to-end, we deploy an example application on Kubernetes. The app exposes a web service on port 5000 and writes sample records to the MySQL.

6.7. Container Instances (optional)

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

Sometimes, you need to run a containerized application outside of your AKS cluster—for example, a monitoring dashboard, health checker, or any lightweight utility.
Or, you might just want to run a single container without the complexity and overhead of managing AKS.

For these scenarios, Azure provides Azure Container Instances (ACI)—a serverless container runtime that allows you to run containers in an isolated, standalone environment with minimal setup.

This lab provides a simple example to demonstrate how to achieve this.