Creating an AKS Release Pipeline in Azure DevOps
Tags: cicdpipeline, kubernetes, azuredevops, cicd
Published: 2024-06-18 08:18:22

---
title: Creating an AKS Release Pipeline in Azure DevOps
published: true
date: 2022-01-31 08:36:09 UTC
tags: cicdpipeline,kubernetes,azuredevops,cicd
canonical_url: https://andyr8939.medium.com/creating-an-aks-release-pipeline-in-azure-devops-2fa14f8fc6ba
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ylnfchbz38jxtd40xlql.jpg
---

AKS and Kubernetes in general is still fairly new to me, but its something I am using more and more every day. One of the challenges I have faced is that the more I have to deploy to is, is the need for a simple way to deploy a set of apps you need on every cluster, that doesn’t involve a complicated solution. I am an ‘Ops’ guy by trade so creating release artifacts and NuGet packages doesn’t come naturally too me. Instead I like to keep things as simple as possible, and one way I have found to do this is using Release Pipelines in Azure DevOps in a GitOps style process, so this is what I’ll explain below.

### Create some AKS Clusters

You are going to need a few clusters for this. I currently have 12 I need to run this on across multiple regions and environments, but for this demo, lets stick to 3 clusters which we can call, dev, stage and prod.

To quick create some you can run the following Azure CLI.

You can also find the script and all the YAML Kubernetes files for this blog here [on my GitHub](https://github.com/andyr8939/azure/tree/main/aks)

```
SUBSCRIPTION= "your-subscription-name" 
RSG_NAME= "aks-release-demo" 
LOCATION= "australiaeast" 

az account set --subscription $SUBSCRIPTION 
az group create --name $RSG_NAME --location $LOCATION 

az aks create --name "prod-cluster" --resource-group $RSG_NAME --location $LOCATION --node-count 1 --enable-addons monitoring --generate-ssh-keys 

az aks create --name "stage-cluster" --resource-group $RSG_NAME --location $LOCATION --node-count 1 --enable-addons monitoring --generate-ssh-keys 

az aks create --name "dev-cluster" --resource-group $RSG_NAME --location $LOCATION --node-count 1 --enable-addons monitoring --generate-ssh-keys
```

Give that 10–20 minutes and you’ll have 3x basic AKS clusters ready to use.

### Azure DevOps Service Connections

A Service Connection in Azure DevOps is a way to integrate with your third party services, like Kubernetes, GitHub, Jenkins etc.

Inside your Azure DevOps Project go to **Settings** and **Service Connections** and **Create Service Connection**

![](https://cdn-images-1.medium.com/max/1024/0*An1Gs5oIPFFvSqoe.png)

Select **Kubernetes** and select **Azure Subscription**.

- From the dropdown pick your subscription where you deployed the AKS clusters, then select the first cluster, dev-cluster in this case.
- Namespace you can leave as default as we override this when deploying, but make sure that **Use Cluster Admin Credentials** is checked. If you don’t then you get errors with deploying to anything but the namespace you specify.
- Name the connection **dev-cluster** and grant access to all pipelines, and Save.

![](https://cdn-images-1.medium.com/max/561/0*W7gKy_9lHHCj9G3Z.png)

![](https://cdn-images-1.medium.com/max/379/0*WkLdfBC_d_Whr0SI.png)

### Create a Release Pipeline

From Pipelines / Releases, select **New Pipeline**

![](https://cdn-images-1.medium.com/max/1024/0*joVQpI4kBQdlE3hJ.png)

Start with an **Empty Job**

![](https://cdn-images-1.medium.com/max/1024/0*NdSl33n6-UiAher0.png)

You now create a Stage, so call the first one  **Dev**

![](https://cdn-images-1.medium.com/max/906/0*EGST6c-g0wqZdg0P.png)

Now to deploy anything you need some code. For this example I am just going to deploy some basic nginx and whoami apps that I have created some Kubernetes manifest files for. Select **Add** in the Artifact pane.

![](https://cdn-images-1.medium.com/max/1012/0*x66Vx2WIC41V4cdZ.png)

My code is all in Azure DevOps for this demo, so I have selected my Project (AKS), Source Repo (cicd-blog) and the branch. If you are using GitHub or other this is totally fine, just fill out the relevant details. If you want to use the same files as me, you can grab them [here on my GitHub](https://github.com/andyr8939/azure/tree/main/aks)

![](https://cdn-images-1.medium.com/max/755/0*TosxRyMz-vT2jWpn.png)

Next you need to add a task, to tell the pipeline to do something, so select the task link.

![](https://cdn-images-1.medium.com/max/977/0*wCLGtzMi4dCPFiQe.png)

A few things need to happen in this step, because you are going to be using build agents. The first of which is ensuring **kubectl** is installed so you can execute commands against the cluster. So search for **kubectl** in the **Add Tasks** pane and select **Kubectl tool installer** and Add that.

![](https://cdn-images-1.medium.com/max/1024/0*5KUzU5b_grDrkRx_.png)

Add another task and this time just select **Kubectl** and Add.

![](https://cdn-images-1.medium.com/max/1024/0*8IZf9lCBYsA_bmdb.png)

This is where you configure the meat of the deployment.

- Give your deployment a name (NGINX Deploy)
- Select your Kubernetes Service Connection you created earlier and chose the **dev-cluster**
- Leave namespace blank, as this is created by the manifest file.
- For command, pick **apply** and then select **Use Configuration**. This will give us some extra options.
- File Path is what you want here and you can navigate through your repo to find the deployment file you want. If you have more than one file, you can select the entire folder if that helps.

![](https://cdn-images-1.medium.com/max/1024/0*u9ehnNdoPJ0EmnMG.png)

One thing I like to do as well, is change the Agent Job to use ubuntu-latest, as I find in my region (I live in NZ but use Australia East) that ubuntu starts up much faster than windows agents.

![](https://cdn-images-1.medium.com/max/1024/0*pKAjqs7m67P8wFoL.png)

At this stage you can add more deploy steps if you like. On the screenshot above I have created another **WhoAmI** deployment but this is totally optional.

**Save** your Pipeline and then click **Create Release**

![](https://cdn-images-1.medium.com/max/1024/0*UlQBxWM-n1qJQzJA.png)

At this point you only have 1 stage, so can just click  **Create**

![](https://cdn-images-1.medium.com/max/583/0*lSOK_IRzM1zcEsFF.png)

Everything happens quite quick at this point. The release will be processed so the pipeline pulls down the code you specified in the Artifacts section, then runs through your steps and deploys the manifest to the cluster. In my example this took around 20 seconds for the whole thing, and you can see below a completed release, and the nginx and whoami pods running on my Dev AKS Cluster!

![](https://cdn-images-1.medium.com/max/1024/0*5JW5jDShT_MU-rbM.png)

### Add More Stages for Stage and Prod

It wouldn’t be a release pipeline if you didn’t take the release through to Production, so lets do that :)

Edit your Pipeline

![](https://cdn-images-1.medium.com/max/968/0*qfaz4tbu7A2bVrti.png)

Click on the **Clone** button and this clones that stage to a fresh one.

![](https://cdn-images-1.medium.com/max/1024/0*DnQgA0_-iBv5A5eK.png)

Edit the task on the new stage and change the **Service Connection** on each stage from your **dev-cluster** to the **stage-cluster**. Also rename your cloned stage to Stage and then save.

Repeat that for the prod-cluster stage so they look like below.

![](https://cdn-images-1.medium.com/max/1024/0*nhbOgKAkPoDaiVNR.png)

Save the Pipeline and come back out so you can see all of your stages.

**Optional**  — You might want to have an approval for your Production stage, so for example you auto deploy to all None-Prod, but then want to pause for manual approval for Production, to avoid introducing a breaking change all the way through. To do this, click on the **Pre Deployment Conditions** icon at the start of the Prod Stage.

Enable the Pre Deployment Approvals and put yourself as the approver. In real production you would have others, but this works for this demo.

![](https://cdn-images-1.medium.com/max/1024/0*D701A-NVDbMMd2Jz.png)

Save the pipeline and create a new release.

### Seeing it all in motion

This all happens quite quickly if you only have a really simple webapp to deploy, like I am doing for this demo. But once you create the release you will see the process flow through, deploying first to the dev-cluster, then to stage-cluster and finally **pausing** before it goes to the prod-cluster.

![](https://cdn-images-1.medium.com/max/1024/0*G_L6VuigoUwfG5HQ.png)

That’s it. Congratulations, you have created a release pipeline with continuous integration, so now whenever you make a commit on the main branch you specified in the artifacts section, the release pipeline will run and apply all those manifests. If there are no changes, then kubectl will see that and not change anything. If there are changes, it will apply them, to always match you code base, which is the basis of a GitOps flow like this.

I hope this has helped as a simple overview to release pipelines with AKS.

Andy

_Originally published at_ [_https://www.andyroberts.nz_](https://www.andyroberts.nz/posts/aks-cicd-azuredevops/) _on January 31, 2022._