Create a release pipeline and deploy to local Kubernetes cluster with Azure Devops

On a previous article I described how you could create your self hosted agent to run your pipelines on Azure Devops. In this article I will explain how you can use this agent to deploy resources on your local Kubernetes cluster. As a prerequisite you should already have a kubernetes cluster locally. You can do that by installing Docker and enable the option for a kube cluster.

First things first you should connect your local Kubernetes cluster with Azure devops. For that reason you should go on Project settings -> Service connections and select Kubernetes

You can select between three different options. I selected kubeconfig

Get the output of the below command and paste it on the box. Then select untrusted certificates and add press verify and save.

kubectl config view --raw

Then you should go and create a release pipeline. Go on releases tab and press create release.

In the setup of the release pipeline you can change the trigger from automatic to manual. You should select your build pipeline that will trigger the release. In my case I selected the one I created on a previous article.

On the tasks of the release pipeline you should select the agent pool, as a result your self hosted agent. Depending on which pool you placed your agent you should add it appropriately. In my case it was on the default pool.

Then you can go and create the tasks of the release.

I chose two tasks, one for a deployment creation through kubectl commands and another one for a service exposure. You could also apply a .yml config file.

In this deployment I selected a sample image I created on a previous article, selected the namespace, added the requested parameters and selected create as the command. KubernetesConnection is the service connection that you will create and add on the first steps.

When you run the release pipeline you should see that the self hosted agent will be prepared for the run.

The job will start on your locally deployed agent.

The stages will start running.

Taken into account that everything is correct with your commands and configuration the job will be successful.

The green button of result indicate the win of your try.

Create a build pipeline and push Image to external repository with Azure Devops

Azure Devops is the powerful Microsoft product for Devops solutions. In this article I will explain how you can create a build pipeline using predefined actions and tools provided in order to push an image to an external repository like Docker hub.

As a first step you should create two new service connections. As I am using Github, the one will be a github connection and a docker hub connection. To accomplish that you should go to project settings -> service connections and connect your accounts with your password credentials.

When you complete this step, the connected accounts will appear.

Then you should go to pipelines menu and create a new one. My pipeline has the name main-pipeline.

Azure Devops provides a large list of predefined tasks that will make your implementation easier and quicker. In my case I selected the build of a Dockerfile that will be listed in the Github repository.

In more detail the code will be checkout from the repository and the image will be created using a building machine that Azure provides from a shared pool of agents.

You can find the pipeline code below:

# Docker
# Build a Docker image
# https://docs.microsoft.com/azure/devops/pipelines/languages/docker

trigger:
- master

resources:
- repo: self

variables:
  tag: 'latest'

stages:
- stage: Build
  displayName: Build image
  jobs:
  - job: pushToDocker
    displayName: pushToDocker
    steps:
    - task: Docker@2
      displayName: Build an image
      inputs:
        containerRegistry: 'geralexgr-docker-repo'
        repository: 'geralexgr/aksjavarepo'
        command: 'buildAndPush'
        Dockerfile: '**/Dockerfile'
        tags: latest
    - task: PublishBuildArtifacts@1
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'drop'
        publishLocation: 'Container'

A successful run of the pipeline is shown below. As the code indicates the tag of the image should be the latest.

The created image will be stored on docker hub as indicated in the instructions.

You can then go and pull your image locally to test the result. In my case I would use:

docker pull geralexgr/aksjavarepo:latest

Create a self hosted agent on local machine for Azure Devops

Azure Devops services provide great functionality for deployment solutions. One of them is the local agent creation if you do not have a cloud/hosted available server.

In this article I will explain the procedure on how to create one.

Go to your project on your organisation and select agent pools. You can choose either the default or create a new one.

When selecting your agent pool, you should press on new agent. There you can find instructions on how to create your agent. In my case it is a Mac OS X machine

Download the files and follow the instructions. The configuration steps for Mac OS X ask for the server URL. You should input the below:

https://dev.azure.com/Your_Org_Name

Then you should select PAT authentication and generate a new token from your account panel -> personal access tokens.

Input the access permissions for the token and the expiration date. Also copy the key on a safe place. If you do not provide sufficient access on the token, you will get errors during the configuration.

When the configuration is completed agent will try a test connection.

When the above step is finished, try to run the agent.

./run.sh on macosx

If the procedure is succeful you will see your machine ready to accept jobs

Also the agent should appear online under agents tab

Deploy Always Available Infrastructure on Azure

Availability is a critical matter when it refers to systems. The ideal scenario for an administrator would be 100% availability for a virtual server/appliance.

However this is not achievable when we deal with infrastructure as we need to close the systems on purpose (patching, maintenance tasks, etc) but also disasters or other nonphysical causes create a downtime.

When we deal with Azure cloud we have the following options that we can use:

  • Availability sets
  • Availability zone

An Availability Zone is a high-availability offering that protects your applications and data from datacenter failures. Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. To ensure resiliency, there’s a minimum of three separate zones in all enabled regions

Availability sets are another datacenter configuration to provide VM redundancy and availability. This configuration within a datacenter ensures that during either a planned or unplanned maintenance event, at least one virtual machine is available and meets the 99.95% Azure SLA. For more information, see the SLA for Virtual Machines.

When you create a new VM resource on Azure, you should choose between availability sets or availability zone (depending on the region on which you deployed your server)

However as stated in the first article from Microsoft:

To achieve comprehensive business continuity on Azure, build your application architecture using the combination of Availability Zones with Azure region pairs. You can synchronously replicate your applications and data using Availability Zones within an Azure region for high-availability and asynchronously replicate across Azure regions for disaster recovery protection.

So the final image is the below. Based on your needs you could choose whichever option is more appropriate for you. However as recommended from Microsoft, you should use availability zones (newer feature than availability sets)

Below are some very good resources that Microsoft provides:

https://docs.microsoft.com/en-us/azure/availability-zones/az-overview

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/manage-availability

https://docs.microsoft.com/en-us/azure/best-practices-availability-paired-regions