Create, Install, Upgrade, and Rollback a Helm Chart (Part 1)

gowebing

In this post we will explain how we can use Helm for installing our application. In part 1 we will take a look at how we can create a Helm Chart for our application and how to package it. In part 2 we will cover how to install the Helm package to a Kubernetes cluster, how to upgrade our Helm Chart and how to rollback our Helm Chart.

Create a Helm Chart

A prerequisite for what we are going to do in this post is an installed Helm Client and Server (Tiller). We explained in a previous post how to do this.

We can create the required files for a Helm Chart manually, but the easiest way is to create it with the following Helm command where myhelmchartplanet is the name of your Helm Chart:

helm create myhelmchartplanet

This will generate a default directory structure with default files in it:

We will push this configuration to a GitHub repository (see tag v0.1.0). Next step is to adapt the default files to our needs. The application we will package and deploy is a simple Spring Boot application which prints a hello message when accessing the /hello URL. We used it before in a previous post and created a Docker image for it (we will use version 0.0.2-SNAPSHOT) which comes very handy at this moment.

Chart.yaml

So, first step is to adapt the Chart.yaml as follows:

apiVersion: v1 
appVersion: "0.0.2-SNAPSHOT" 
description: A Helm chart for Kubernetes 
name: myhelmchartplanet 
version: 0.1.0

Let's take a look at the different items:

With this configuration, our Helm Chart will be named myhelmchartplanet-0.1.0.

values.yaml

With the values.yaml file, we can adapt several values which are used in the Kubernetes templates files. We will change the following default values:

The values.yaml file has the following content after our adaptations:


replicaCount: 1

image:
    repository: mydeveloperplanet/mykubernetesplanet
    tag: 0.0.2-SNAPSHOT
    pullPolicy: IfNotPresent

nameOverride: ""
fullnameOverride: ""

service:
    type: NodePort
    port: 8080
    nodePort: 30036

ingress:
    enabled: false
    annotations: {}
    path: /
    hosts:
        - chart-example.local
    tls: []

resources: {}
nodeSelector: {}
tolerations: []
affinity: {}

service.yaml

Because we are using the service type NodePort , we have to change something to the service.yaml:

Our adapted service.yaml is the following:


apiVersion: v1
kind: Service
metadata:
    name: {{ include "myHelmChartPlanet.fullname" . }}
    labels:
        app: {{ include "myHelmChartPlanet.name" . }}
        chart: {{ include "myHelmChartPlanet.chart" . }}
        release: {{ .Release.Name }}
        heritage: {{ .Release.Service }}
spec:
    type: {{ .Values.service.type }}
    ports:
        - port: {{ .Values.service.port }}
          targetPort: {{ .Values.service.port }}
          protocol: TCP
          name: http
          nodePort: {{ .Values.service.nodePort }}
    selector:
        app: {{ include "myHelmChartPlanet.name" . }}
        release: {{ .Release.Name }}

deployment.yaml

In the deployment file, we have to put the livenessProbe  and readinessProbe   in comments. These will check our application whether it is ready and alive, but we did not include the Spring Boot Actuator plugin in our application which will provide the URL to check the readiness and liveness of our application.

Check the Correctness of Your Chart

In order to check whether the changes you made to the different configuration files, you can issue the following command which will check the formatting and information:

helm lint myhelmchartplanet

I don't know exactly what is being checked, but it once gave no issues when the deployment to Kubernetes went wrong. It is therefore not a complete check on a correct Kubernetes configuration. Just be aware of that.

Package the Helm Chart

Now that we have adapted the chart configuration to our needs and that we have pushed everything to a git repository, it is time to package our Helm Chart. Execute the following command from outside your git repository, the command will search for a directory with the name of the Helm Chart from where it is issued:

helm package myhelmchartplanet

The package is being created (a tar gz file) and the following response is shown:

Successfully packaged chart and saved it to: /home/developer/myhelmchartplanet-0.1.0.tgz

As we said before, the name of our Helm Chart will be myhelmchartplanet-0.1.0 and here we can clearly see that.

Chart Repository

Before we can install the Helm package we created, we must make it downloadable. This is done by means of a Chart Repository. A Chart Repository contains packaged Helm Charts. It is not much more than a website containing an index.yaml and the Helm packages. When you browse to your home directory to the directory .helm/repository/local, then you notice that our packaged Helm Chart is added to this directory. The index.yaml file is automatically updated and contains metadata about the packages. It looks like the following:


apiVersion: v1
entries:
  myhelmchartplanet:
  - apiVersion: v1
    appVersion: 0.0.2-SNAPSHOT
    created: 2018-09-16T14:51:02.933628266+02:00
    description: A Helm chart for Kubernetes
    digest: sha256:a9c44411c15b7aa980f1c2d2f8deb29a82fcbb98eebdfc4ccecbf0910bf8e051
    name: myhelmchartplanet
    urls:
    - http://127.0.0.1:8879/charts/myhelmchartplanet-0.1.0.tgz
    version: 0.1.0
generated: 2018-08-26T18:01:30.000450767+02:00

In a production environment, you must ensure that your Helm packages are not stored on your local machine but are placed in a "real" repository. E.g. Google Cloud Storage, Artifactory, GitHub Page or just an ordinary webserver.

Summary

In part 1 of this post, we created our own Helm Chart, explained some of the files that are required, packaged our Helm Chart and made it available in a Chart repository. Next time we will continue with installing our Helm package to our Kubernetes cluster, upgrade it and execute a rollback.

 

 

 

 

Top