The introduction of microservice architecture revolutionised the way softwares are developed today. Post microservice architecture replaced monoliths, containers replaced virtual machines. With this transformations, building application became complex due to multiple containers. Container orchestration was a new bottleneck which was solved by Kubernetes.

In the process containers and Kubernetes brought in many new challenges. The most difficult being deploying and managing applications on Kubernetes. An array of open source tools are being developed to ease out the process. One such tool is Helm.

History: Start of Helm 🗽

After being in the community for more than a year, Kubernetes finally made its first general availability release with version 1.0 in the summer of 2015. Deis, a business devoted to supporting the Kubernetes Ecosystem, created Helm in its initial iteration.

Introduced at the inaugural KubeCon. In January of 2016, the project merged with a GCS tool called Kubernetes Deployment Manager, and the project was moved under Kubernetes. Since its beginning, Helm has been intended to function as a package management tool. With Helm V4, Helm is currently on its fourth iteration. With Helm V3, its third iteration, it attracted a lot of adoption due to reduction of security concerns.

What exactly is Helm? 🤔

If you are a javascript or a python developer, you can think Helm to be equivalent to npm or PyPI. The concept of package managers are not new, if you are a linux users I am pretty sure you have used apt/yum for installing and uninstalling softwares.

With the growth of complex services, deploying with only one k8s configuration file was not feasible. Where to even store these YAMLs became a problem as the amount of YAMLs grew. Helm is here to help with these issues.

Suppose we want to implement Elastic Stack for logging. To do it we need to write configmap, secret, stateful set, permissions and more. Writing all of these at times becomes pretty tedious and often increases the chance of error. So bundling is done. These bundles are known as Helm Charts.

Why is Helm so popular? 🔥

The big benefits to using Helm are pretty similar to CI and CD goals: repeatability and consistency. Imagine, a server used by millions of users having reductant code, the amount of cash burn will be insane. Moreover, bundling reduces the chance of errors. Helm also referred as templating engine helps in defining a common blueprint. Dynamic values are replaced by place holders which helps in achieving code consistency and POCs.

Ultimately using Helm saves the development time. It takes care of the CI/CD pipeline where in we can focus on building what matters. With Helm we no longer need to construct individual YAML files for every application in a stack. Helm Charts are highly customisable, we can just download a Helm Chart and combine it with our YAML file, thus no longer we are required to build everything from scratch.

Helm Developer develops the Helm Charts such that it can be used by everyone. Post creating the Chart, it is pushed into the repository which is then further used by developers. Developers pull the image from the repository using Helm, post modifying according to the required value they use it while defining their own clusters.

Not only software developers or open source initiatives can use Helm packaging. Every individual or organisation installing softwares for day to day purpose can use Helm packaging. Using a package manager lowers complexity and duplication in coordinating the procedures specified in the package manager as Kubernetes investments continue. Helm having the feature of Release Management also power rollback add-on incase anything goes wrong.

What are Helm Charts? 📈

Helm charts are bundles or collections of Kubernetes YAML files that make up an application. The main format that Helm operates is a Chart. Helm Charts can be stored in Chart Repositories with ease because they are file-based and adhere to a convention-based directory structure. Charts can be installed and uninstalled into Kubernetes clusters.

A running instance of a Chart is referred to as a Release, just as the relationship between an image and its container.

A Helm Chart is ultimately an executable template that transforms Chart definitions into Kubernetes manifests.

Helm Charts, when created must have a version number. Helm Charts can reference other Charts as dependencies, a core to any package manager. Moreover, there are private and public repositories where in we can store Helm Charts.

Demystifying Helm Charts 💁🏻‍♂️

Using a single Helm Chart, Helm allows us to deploy many configurations for the same application. Helm accomplishes this using a template engine. In response to input parameters that can be modified in a values.yaml file, the template engine generates manifest files.

Application configurations can be created and shared via Helm. We can search for Helm Charts on Artifact Hub or using cli via helm search [keyword] command.

We can also find Helm Charts on GitHub, GitLab, BitBucket and related platforms. Here is the verified Helm Chart for Nginx. Now, that we have an idea on where to find Helm Charts, let's dive in to Helm Chart's skeleton.

Breaking down Helm Charts 🚧

Helm Charts are stored in a modular fashion. All particular charts have similar directories.

| -- Chart.yaml
| -- Charts
| -- templates
|    | -- NOTES.txt     
|    | -- deployment.yaml 
|    | -- ingress.yaml
|    | -- service.yaml
| --values.yaml 

With these pieces out of the way, Helm can execute on our Chart. To understand Helm Charts we need to understand the 4 basic building blocks:

1️⃣ Chart.yaml file : This is where we put all the information about the chart we are packaging. So, for example, the version number, etc. This is where we will put all those details.

2️⃣ Values.yaml file : This is where we define all the values we want to inject into our templates. Values.yaml is similar to variable.tf in terraform.

3️⃣ Charts: This is where we store other charts that our chart depends on. We might be calling another chart that our chart need for functioning properly.

4️⃣ Templates directory : This directory contains the templates files of the chart, and when they combined with values, they generate the valid manifest files.

Walkthrough: Let's see how it works 💥

To install Helm command use supported package manager or simply download the pre-complied binary.

brew install kubernetes-helm

Installing Tiller with the Helm init command, to start deploying applications into pure Kubenetes cluster.

helm init

Now, Helm can be used particularly in two ways. Either modifying post fetching from web or creating from scratch.

Install Charts from Web 💻

For the first way, ie to install Helm chart from web we need to do two things.

Managing remote stable repositories:

helm repo add bitnami https://charts.bitnami.com/bitnami

And then installing the chart:

helm install my-nginx bitnami/nginx 

Now, if we want to use with custom yaml file and override some of the values, we simply need to run

helm install my-nginx bitnami/nginx -f example-config.yaml

Creating Charts locally 👨‍🚒

Using Helm packages is really simple. Writing Helm charts is only a little bit more complex. Creating a Helm chart involves creating the chart itself, configuring the image pull policy, and specifying additional details in the values.yaml file.

Initialising with the create chart command

helm create explore-helm

Post running the command and checking out the starter directory. We can find the chart directory which consists of:

| -- Chart.yaml
| -- Charts
| -- templates
| -- values.yaml 

Post configuring according to requirement, we can deploy. This way, Helm charts simplify application deployment on a Kubernetes cluster.

Outro 💚

Helm is undoubtedly the future of K8s Package Management. Helm not just only helps developers who want to install some apps on it, but it also helps DevOps engineer, they can still create YAML manifest files and use kubectl commands to do deployments. Using the templating engine engineers can focus on what really matters, Helm takes care of code consistency and redundancy.

The bundling of YAML files has ultimately reduced the bundle size of the server application and enhanced the CI/CD flow. Moreover, Helm simplifies the DevOps learning curve: we do not require a full, detailed understanding of the function of each Kubernetes object in order to start developing and deploying container applications. Helm easily integrates into CI/CD pipelines and allows software engineers to focus on writing code not deploying applications.

The purpose of this blog is to create awareness about Helm and similar package managers. It is further recommended to go through Helm's official Documentation. Incase, you have some questions regarding the article or want to discuss something under the sun feel free to connect with me on LinkedIn 💖

If you run an organisation and want me to write or create video tutorials please do connect with me 💪