Xylos brands

How to automate rolling out containers with Azure DevOps

In the previous blog post in our ‘6 steps to the cloud’ series, we discussed ARM templates and Kubernetes manifests. In this post, we’ll use templates to roll out the Kubernetes infrastructure and our applications in Azure. We’ll need the following Azure components:

  • Azure Virtual Network: this network contains the servers that are part of the Kubernetes cluster.
  • Azure Load Balancer: the load balancer spreads traffic across our web application’s containers. It’s automatically created and configured by Kubernetes.
  • Azure Kubernetes Service (AKS): Kubernetes as a service.
  • Azure Container Registry (ACR): a place to store container images.

1. What is Azure DevOps?

Azure DevOps includes a broad range of services to support developers and operational teams. In this post, we’ll use Azure DevOps to carry out the following tasks:

  • Storing the application code in a version control system.
  • Building a new container image.
  • Rolling out the new container image without impacting the end users.

We’ll use an internal Xylos application that’s a little more complex than the previous blog posts’ web application as an example. Don’t worry, though: the steps in this post are generic and can be applied to almost any scenario.

2.What about our code’s version control?

Azure DevOps allows you to store code in e.g. git repositories. The image below shows the content of the xci-fe repository. This repository contains the application’s frontend code, which was written in JavaScript with Angular. Another repository (xci-be) contains the backend code, which was written in Node.js.

As you’ve probably noticed, this is the developer’s area of expertise. They can write the application on their own workstation and regularly upload changes to the code to the git repository. To do this, they’ll use the git commit and git push commands or their preferred code editor.

The Kubernetes manifests and code are all in the repository (charts/xcife folder). This isn’t always the case. Even though we use Kubernetes manifests (see the previous blog post for more information), we’ll roll out the manifests with Helm. Helm lets us add parameters to Kubernetes manifests, such as the container image’s name and version.

The ARM template to roll out Azure Kubernetes Service is located in another repository.

You can use the ARM template to roll out and adjust AKS.

2.2 Build pipelines

When you edit the application code, you’ll need a new container image. The Docker file with the recipe to build the image is stored along with the code and looks like this:

We’ll use a build pipeline to instruct Azure DevOps to build the image. A pipeline consists of one or several steps. In this case, the pipeline will be executed automatically if you save its code in a certain way. You can also request permissions, e.g. from the application’s owner or release manager.

The image below shows you the steps to build the frontend image.

The first two steps are obvious: we’ll build the image and store it in an Azure Container Registry titled xyloscloudincentive. Kubernetes will download the image from this registry later because the image name and version will be in the Kubernetes manifest.

In the last steps, we’ll build a Helm package. This is an archive (similar to a zip file) that contains the Kubernetes manifests as per Helm’s specifications. The Helm package is published in an artifact.

An action, such as building an image, has to be performed somewhere. For this application, we’ll use the build servers Microsoft offers as a service. Of course, you can use your own build servers with Azure DevOps – it doesn’t matter if they’re located in the cloud or on-premises.

We now have a new container image and a Helm package. The question is: how do we use these components to roll out the application? The answer to that question: with a release pipeline.

2.1 Using release pipelines

A release pipeline rolls out infrastructure and applications in various environments, such as development, testing and production. The image below shows the release pipeline that rolls out the application we built earlier.

Because we’re using Helm, the release pipeline is fairly straightforward: we can just use the Helm package from the build pipeline and upgrade it. If the application hasn’t been rolled out before, it’ll be installed for the first time. Parameters are an important aspect of the rollout. The Helm upgrade step uses the following parameters from the Set Values textbox:

  • image.repository=xyloscloudincentive.azurecr.io/$(Build.Repository.Name)
  • image.tag=$(Build.BuildId)
  • azure.clientsecret=$(dns-secret)
  • ingress.loadbalancerip=$(ip)

Azure DevOps offers a host of ways to define variables and parameters. $(dns-secret) and $(ip) are self-made variables. With $(Build.Repository.Name) and $(Build.BuildId), we’ll fetch the ACR name and the image tag from the build pipeline. After that, we’ll inject the image name into the Kubernetes manifest. Kubernetes now knows it’ll need to use a new container image.

3. Conclusion

Azure DevOps is a powerful as-a-service solution to roll out a broad range of infrastructure and applications, in the cloud as well as on-premises. In this post, we used Azure DevOps to build a container image and roll it out in Azure Kubernetes Service. Based on the information in this blog post, Xylos recommends its customers to automate as much as possible. You can also do this without containers, and it’ll help you avoid errors and increase quality and security.

In the next and final blog post of the ‘6 steps to the cloud’ series, we’ll handle the last, but certainly not the least important aspect: security.

Share this blogpost


aws devops certification

nice post!
thanks for sharing

Leave a reply

Your email address will not be published. Required fields are marked.