In this article I will describe how to use Azure DevOps to:
- build a docker image of your application,
- push this image to Azure Container Register,
- release your kubernetes deployment to Azure Kubernetes Service.
If you don’t have any basic knowledge about docker, kubernetes, and Azure CLI please check out my previous article Deploying .NET Core Application to Azure Kubernetes Cluster.
The Benefits of Automating Continuous Integration and Delivery Processes
Automating CI/CD processes allows you to:
- save a lot of time
- eliminate bugs that happen when you do the same job over and over again
- deliver your product much faster
Azure DevOps can help you with that.
Azure DevOps can automate your Continuous Integration and Delivery processes. It can get access to your git repository (Azure Repos Git, GitHub, and other git repositories). It can automatically react to your activity in your repository:
- run tests when you create a pull request
- build a docker image when you merge your pull request to a selected branch and push it to Azure Container Register (ACR)
- when everything is ok, it can apply changes to your Azure Kubernetes Service (AKS)
You can use docker images from your ACR to create as many release configurations as you need. For example, one for dev, test, stage and production environment and decide when you want to release them.
If you don’t have your Azure Container Register and Azure Kubernetes Service, you can use necessary Azure CLI commands from my previous article:
#Create temp variables: $projectName="shkube" $argName=$projectName+"RG" $acrName=$projectName+"ACR" $aksName=$projectName+"AKS" $region="northeurope"
We are going to use them to create ACR and AKS in Azure Resource Group (ARG).
Login to azure:
And lets create everyting you will need later:
# Create resource group az group create -n $argName -l $region # Create azure container register az acr create -n $acrName -g $argName --sku standard # Create azure kubernetes service az aks create -n $aksName -g $argName --generate-ssh-keys --node-count 1 --node-vm-size Standard_B2s --enable-addons monitoring # Get AKS Client Id and AKS Id $CLIENT_ID=$(az aks show -g $argName -n $aksName --query "servicePrincipalProfile.clientId" --output tsv) $ACR_ID=az acr show --name $acrName --resource-group $argName --query "id" --output tsv # Give AKS access to ACR az role assignment create --assignee $CLIENT_ID --role acrpull --scope $ACR_ID # Get credential to your AKS az aks get-credentials -g $argName -n $aksName
Now we can begin to work with your CI/CD.
If you are reading this article, then you probably already have your application up and running inside Docker Container or even Kubernetes. If not, then you need three additional files to do that:
If you don’t have them you can use the ones from this project.
Go to your Azure DevOps website and create a new project.
Create a new pipeline:
I’m going to use a classic editor and select Github repository. Pick your repository and a branch that you are going to use to build a container from this project.
If you see Docker Compose on
a list, you can use it, but I will pick
Use + button to add the
first step of your pipeline! In this step we build a new docker image with your
application. We use
Docker Compose step that will use your
Now there are a few things to do:
- select your Azure Subscription
- select Azure Container Register
- put a path to your
- change Action
Build service image
$(Build.BuildId) as Additional Image Tags (without this, we won’t be able
to determine which image version to deploy later).
Great! Now we have to push
this image to our ACR. Let’s add second
Docker Compose step. The only difference is the Action
field: now pick
Push service image.
The third step is optional but recommended. Lock an image version or a repository so that it can’t be deleted or updated.
As before, add
step. The only difference is the Action field. Now pick
Lock image service.
Output Docker Compose
File will fill automatically.
There are two more steps to follow.
Copy Files step.
Contentsput a name or a path to your
deployment.ymlfile (we will use this file during Release)
Publish build artifacts step.
Leave it as it is.
We will use
during Release. If you want your pipeline to trigger automatically after each merge, go to
tab and select
Enable continuous integration.
Agent Specification to use Ubuntu (if you prefer Windows then you will
have to change all paths to match Windows).
Now we can test our
Save & queue.
Go to Pipelines, select the pipeline you have created and pick the newest Run. If it’s green, everything is ok.
If not, then you have to check which step went wrong and fix it.
Congratulations! We’re halfway through. We have an image and it’s available on your ACR. Let’s check it out. Please login to your Azure Portal and check if it’s there (please notice that it’s also tagged by its build number).
Now we can configure new Release.
Release tab and create a new
Similarly to pipeline
configuration, I have select
Empty job. Now click on
Add an artifact, select your project
Tasks tab add
- change Service connection type,
- select Azure subscription,
- select resource group,
- select Kubernetes cluster,
- pick Apply Command,
- check Use configuration.
And pick your
file in File path.
Advance and choose
that matches the version of Kubernetes on Azure. You can use this command to check the
az aks show -g $argName -n $aksName --output table
(we will have to replace the name of your docker image to match the one on ACR).
Set everything as before but
Arguments input to
This command is tricky, we have to navigate by name to deployment, and then to container image.
We specify the image version here. It’s a better practice than just using latest because the latest image always points to the newest one (created after each merge). It could be ok for your dev environment but not for the production one.
Create release (top right) and
go to Release to check if everything’s alright.
Ok, let’s go to console and check your services and pods.
And navigate to IP of your service to check if it’s up and running.
It’s working! Congratulations!
Your Continuous Integration and Delivery setup is ready. You can now use your pipeline to create another Release configuration for your test, stage, or production environment.
Read more articles like this in our Tech category.