Packaging Kubernetes Applications

Using YAML files to install or upgrade applications in a Kubernetes cluster works well only for static definitions. The moment we need to change an aspect of an application we are bound to discover the need for templating and packaging mechanisms.

We faced quite a few challenges thus far. The good news is that we managed to solve most of them. The bad news is that, in some cases, our solutions felt sub-optimum (politically correct way to say horrible).

We spent a bit of time trying to define Jenkins resources while we were in the Chapter 1, Deploying Stateful Applications at Scale. That was a good exercise that can be characterized as a learning experience, but there's still some work in front of us to make it a truly useful definition. The primary issue with our Jenkins definition is that it is still not automated. We can spin up a master...

Creating a cluster

It's hands-on time again. We'll need to go back to the local copy of the vfarcic/k8s-specs (https://github.com/vfarcic/k8s-specs) repository and pull the latest version.

All the commands from this chapter are available in the 04-helm.sh (https://gist.github.com/vfarcic/84adc5ad977f5c1a682bed524b781e0c) Gist.

 1  cd k8s-specs
 2
 3  git pull

Just as in the previous chapters, we'll need a cluster if we are to execute hands-on exercises. The rules are still the same. You can continue using the same cluster as before, or you can switch to a different Kubernetes flavor. You can keep using one of the Kubernetes distributions listed as follows, or be adventurous and try something different. If you go with the latter, please let me know how it went, and I'll test it myself and incorporate it into the list.

Cluster requirements in this chapter are...

What Is Helm?

I will not explain about Helm. I won't even give you the elevator pitch. I'll only say that it is a project with a big and healthy community, that it is a member of Cloud Native Computing Foundation (CNCF) (https://www.cncf.io/), and that it has the backing of big guys like Google, Microsoft, and a few others. For everything else, you'll need to follow the exercises. They'll lead us towards an understanding of the project, and they will hopefully help us in our goal to refine our continuous deployment pipeline.

The first step is to install it.

Installing Helm

Helm is a client and server type of application. We'll start with a client. Once we have it running, we'll use it to install the server (Tiller) inside our newly created cluster.

The Helm client is a command-line utility responsible for the local development of Charts, managing repositories, and interaction with the Tiller. Tiller server, on the other hand, runs inside a Kubernetes cluster and interacts with Kube API. It listens for incoming requests from the Helm client, combines Charts and configuration values to build a release, installs Charts and tracks subsequent releases, and is in charge of upgrading and uninstalling Charts through interaction with Kube API.

Do not get too attached to Tiller. Helm v3 will remove the server component and operate fully from the client side. At the time of this writing (June 2018), it is still unknown when will v3...

Installing Helm Charts

The first thing we'll do is to confirm that Jenkins indeed exists in the official Helm repository. We could do that by executing helm search (again) and going through all the available Charts. However, the list is pretty big and growing by the day. We'll filter the search to narrow down the output.

 1  helm search jenkins

The output is as follows.

NAME           CHART VERSION APP VERSION DESCRIPTION            
stable/jenkins 0.16.1        2.107       Open source continuous integration server. It s...

We can see that the repository contains stable/jenkins Chart based on Jenkins version 2.107.

A note to minishift users
Helm will try to install Jenkins Chart with the process in a container running as user 0. By default, that is not allowed in OpenShift. We'll skip discussing the best approach to correct the permissions in OpenShift. I'll...

Customizing Helm installations

We'll almost never install a Chart as we did. Even though the default values do often make a lot of sense, there is always something we need to tweak to make an application behave as we expect.

What if we do not want the Jenkins tag predefined in the Chart? What if for some reason we want to deploy Jenkins 2.112-alpine?

There must be a sensible way to change the tag of the stable/jenkins Chart.

Helm allows us to modify installation through variables. All we need to do is to find out which variables are available.

Besides visiting project's documentation, we can retrieve the available values through the command that follows.

 1  helm inspect values stable/jenkins

The output, limited to the relevant parts, is as follows.

...
Master:
  Name: jenkins-master
  Image: "jenkins/jenkins"
  ImageTag: "lts"
...

We can see that...

Rolling back Helm revisions

No matter how we deploy our applications and no matter how much we trust our validations, the truth is that sooner or later we'll have to roll back. That is especially true with third-party applications. While we could roll forward faulty applications we developed, the same is often not an option with those that are not in our control. If there is a problem and we cannot fix it fast, the only alternative is to roll back.

Fortunately, Helm provides a mechanism to roll back. Before we try it out, let's take a look at the list of the Charts we installed so far.

 1  helm list

The output is as follows.

NAME    REVISION UPDATED     STATUS   CHART          NAMESPACE
jenkins 2        Thu May ... DEPLOYED jenkins-0.16.1 jenkins

As expected, we have only one Chart running in our cluster. The critical piece of information is that it is the second revision...

Using YAML values to customize Helm installations

We managed to customize Jenkins by setting ImageTag. What if we'd like to set CPU and memory? We should also add Ingress, and that would require a few annotations. If we add Ingress, we might want to change the Service type to ClusterIP and set HostName to our domain. We should also make sure that RBAC is used. Finally, the plugins that come with the Chart are probably not all the plugins we need.

Applying all those changes through --set arguments would end up as a very long command and would constitute an undocumented installation. We'll have to change the tactic and switch to --values. But before we do all that, we need to generate a domain we'll use with our cluster.

We'll use nip.io (http://nip.io/) to generate valid domains. The service provides a wildcard DNS for any IP address. It extracts IP from the...

Creating Helm Charts

Our next goal is to create a Chart for the go-demo-3 application. We'll use the fork, you created in the previous chapter.

First, we'll move into the fork's directory.

 1  cd ../go-demo-3

To be on the safe side, we'll push the changes you might have made in the previous chapter and then we'll sync your fork with the upstream repository. That way we'll guarantee that you have all the changes I might have made.

You probably already know how to push your changes and how to sync with the upstream repository. In case you don't, the commands are as follows.

 1  git add .
 2
 3  git commit -m \
 4      "Defining Continuous Deployment chapter"
 5
 6  git push
 7
 8  git remote add upstream \
 9      https://github.com/vfarcic/go-demo-3.git
10
11  git fetch upstream
12
13  git checkout master
14
15  git merge upstream/master...

Exploring files that constitute a Chart

I prepared a Chart that defines the go-demo-3 application. We'll use it to get familiar with writing Charts. Even if we choose to use Helm only for third-party applications, familiarity with Chart files is a must since we might have to look at them to better understand the application we want to install.

The files are located in helm/go-demo-3 directory inside the repository. Let's take a look at what we have.

 1  ls -1 helm/go-demo-3

The output is as follows.

Chart.yaml
LICENSE
README.md
templates
values.yaml

A Chart is organized as a collection of files inside a directory. The directory name is the name of the Chart (without versioning information). So, a Chart that describes go-demo-3 is stored in the directory with the same name.

The first file we'll explore is Chart.yml. It is a mandatory file with a combination of compulsory...

Upgrading Charts

We are about to install the go-demo-3 Chart. You should already be familiar with the commands, so you can consider this as an exercise that aims to solidify what you already learned. There will be one difference when compared to the commands we executed earlier. It'll prove to be a simple, and yet an important one for our continuous deployment processes.

We'll start by inspecting the values.

 1  helm inspect values helm/go-demo-3

The output is as follows.

replicaCount: 3
dbReplicaCount: 3
image:
  tag: latest
  dbTag: 3.3
ingress:
  enabled: true
  host: acme.com
route:
  enabled: true
service:
  # Change to NodePort if ingress.enable=false
  type: ClusterIP
rbac:
  enabled: true
resources:
  limits:
    cpu: 0.2
    memory: 20Mi
  requests:
    cpu: 0.1
    memory: 10Mi
dbResources:
  limits:
    memory: "200Mi"
    cpu: 0.2
  requests:
 ...

Helm vs. OpenShift templates

I could give you a lengthy comparison between Helm and OpenShift templates. I won't do that. The reason is simple. Helm is the de-facto standard for installing applications. It's the most widely used, and its adoption is going through the roof. Among the similar tools, it has the biggest community, it has the most applications available, and it is becoming adopted by more software vendors than any other solution. The exception is RedHat. They created OpenShift templates long before Helm came into being. Helm borrowed many of its concepts, improved them, and added a few additional features. When we add to that the fact that OpenShift templates work only on OpenShift, the decision which one to use is pretty straightforward. Helm wins, unless you chose OpenShift as your Kubernetes flavor. In that case, the choice is harder to make. On the one...

What now?

We have a couple of problems left to solve. We did not yet figure out how to store the Helm charts in a way that they can be easily retrieved and used by others. We'll tackle that issue in the next chapter.

I suggest you take a rest. You deserve it. If you do feel that way, please destroy the cluster. Otherwise, jump to the next chapter right away. The choice is yours.