Introduction to Helm

Ed LeGault - Sep 17 '20 - - Dev Community

If you have been looking to migrate to containers, or are already running an application using containers, you have probably heard of Kubernetes. Kubernetes is orchestration software that allows all sorts of awesome enterprise level functionality such as fail-over, rolling updates, networking between distributed nodes, etc. At the time of this writing Kubernetes adoption stands at 86%. All resources required to orchestrate an application in Kubernetes can be configured using YAML files. Helm is software that provides the ability to template, distribute and even handle deployment of those application configuration files.

Helm Template

In the vast majority of cases your YAML files that represent your Kubernetes configuration need to have different values in them between the different environments that you need to deploy your application. Helm provides the ability to define your Kubernetes configuration files as templates that can be used to generate the full output YAML based on a set of default values or custom values. For example, given the following deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
Enter fullscreen mode Exit fullscreen mode

The most common case of needing to change values is to change the image tag. For this example we will also make the number of replicas dynamic just in case we don't need as many replicas in dev or test environments. We are going to change the deployment to this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: {{ .Values.replicas }}
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:{{ .Values.dockerTag }}
        ports:
        - containerPort: 80
Enter fullscreen mode Exit fullscreen mode

Helm Packaging and Distribution

Helm provides the ability to package, version and distribute your Kubernetes configuration YAML files in something called a Chart. A Helm Chart consists of all of the templates and default values needed to orchestrate an application in Kubernetes. Charts can be pushed and pulled to and from a repository, similar to maven or docker repositories. The helm package command will create an archive file that can then be pushed to a helm chart repository. That chart can then be pulled down and used to deploy the application. These charts can also be versioned so when something changes in the Kubernetes configuration of your application you can distribute that as a new version of your chart.

Helm Deployment Management

Charts can be installed, upgraded, rolled-back or deleted from a Kubernetes instance via helm commands. Installation metadata is handled internally by helm and each upgrade of your chart is treated as a new "release". This means that you can roll-back releases simply by executing a helm command to put your Kubernetes configuration back to the previous state. This is particularly useful if you are updating your application with a change to a configuration value but the actual chart contents did not change.

Conclusion

If you are orchestrating your containerized application with Kubernetes you are quickly going to need features such as templates and deployment distribution and management. Helm easily provides these features and is also heavily documented with easy to follow examples. There is much more in-depth information and documentation about the functionality and features of Helm here - https://helm.sh/docs/


Smart EDJE Image

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .