A CI/CD pipeline using VSTS to deploy containerized applications to Kubernetes - Part 1

Do you run containerized applications on Kubernetes?

If You are someone who is interested in containers & orchestration tools, you probably would have used Jenkins 2.0 (pipeline as code) to manage your builds and deployments to Kubernetes cluster.

But does Jenkins give you means to secure the sensitive data related to your cluster, kubeconfig for example. Well, that’s a topic of debate for another day!

The good news is that Microsoft’s VSTS is now tightly integrated with Kubernetes which allows to manage and monitor deployment of any containerized application on the cluster. We create a build definition in VSTS which is synonymous with the term continuous integration, Then, a release definition which takes care of continuous deployment.

Now that I got your attention, in this post, I will walk you through creating an automated build/release pipeline using VSTS to deploy containerized applications to Kubernetes. I am going to split this article into three parts, first part explains a high level picture of the CI/CD pipeline. In the second part, we will see how to setup build & Release definitions. Third and the final part will take it to the next level where you will understand how the entire process can be automated using APIs.

Below is a block diagram of the pipeline to give you a high level picture of what we are going to do.

Prerequisites

· Sign up for a free VSTS account

· A containerised application ready for deployment to Kubernetes. We are going to use helm for deployment. Click here to view the sample code

· A Docker hub account, which will serve as an image registry. Private registries such as nexus repository manager, AWS ECR or Azure container registry can be used if needed.

· A private helm repository to which helm packages from the build will be pushed. We used a helm-local repo in Jfrog Artifactory

· A Kubernetes Cluster

Namespaces

Before we actually create the build and release for our container apps, let’s consider the promotion model. Typically, there’s Dev->Staging->Prod or something similar. In the case of Kubernetes, minikube/docker host is the local dev environment.

So what about Staging & Prod? You could spin up separate clusters, but that could end up being expensive. Namespaces in Kubernetes can be security boundaries, but they can also be isolation boundaries.

When you spin up a Kubernetes cluster, besides kube-system and kube-public namespaces (which house the k8s pods) there is a “default” namespace. If you don’t specify otherwise, any services, deployments or pods you create will go to this namespace.

We don’t have to create these namespaces beforehand, because our pipeline will create them if not already created.

VSTS pipeline — An Overview

Build definition:

1. Build Image
2. Deploy the application locally
3. Perform local tests
4. Push the image to Docker hub
5. Install helm & kubectl binaries on the agent machine & initialize helm
6. Package helm charts and publish to Jfrog Artifactory repository

Release Definition

Release Definition

1. Create namespace
2. Install helm & kubectl binaries on agent machine, initialize helm
3. Import the packaged helm charts from helm repository
4. Deploy application
5. Perform tests on Dev environment

Same is repeated on staging & production environments. Release promotion on completion of the previous stage.

Now, in the next article Part 2, we will see how to set up build & release definitions and what are all the tasks required to setup CI/CD.