Helm is the first and the most popular package manager for Kubernetes. It allows DevOps teams to version, distribute, and manage Kubernetes applications.
Although one can live with standard kubectl commands and Kubernetes manifest YAML files, when organizations work on microservice architecture — with hundreds of containers interacting with each other — it becomes a necessity to version and manage the Kubernetes manifests.
Helm is now becoming a standard for managing Kubernetes applications and a necessary skill for anyone working with Kubernetes.
Why Helm?
The obvious question is: Why do we need Helm? Let's find out.
Helm makes templating applications easy
A Docker image forms a template for a Docker container. You can use one Docker image to create multiple containers from it.
The same wasn't true for Kubernetes. You can't reuse the manifest files easily. For instance, if you have to deploy two instances of PostgreSQL, you have to duplicate your manifest files.
Helm helps you manage it using charts and variables. You just need to create a generic PostgreSQL chart and use variables to deploy different instances in the form of releases.
Helm makes the versioning of Kubernetes applications possible
Developers initially used to create Kubernetes manifests using YAML files, which they then stored in source-code repositories.
The issue with this approach is the manifest isn't semantically versioned. A source-code repository isn't the right place to version your releases. You should always version your releases as packages. Helm solves this problem by packaging your application in a Helm chart, which makes it possible to have multiple versions of your chart stored in the Helm repository, and you can quickly rollout or rollback a release without building from a source.
Helm makes reusing and sharing possible
For Docker images, you can share your images on DockerHub — the same wasn't possible for Kubernetes. With public Helm repositories like Kubernetes charts, this is now possible. Public Helm repositories allow the reuse of Kubernetes applications, enable vendors to provide standard Helm charts for consumers, and make life simple for both of them.
Helm makes deploying Kubernetes applications concise
With Helm, you can run simple commands, such as helm install and helm del, to install and delete releases.
You don't have to worry about finding the manifest files and running kubectl delete. Everything is so dynamic with Helm.
Helm makes dependency management possible
Let's take, for example, a LAMP stack. There's an explicit dependency of Apache on MySQL. You shouldn't install Apache without MySQL.
With Helm, you can add a dependency of MySQL on the Apache chart to allow this to happen, something you wouldn't be able to do with pure Kubernetes manifests.
Helm helps enforce standards
Helm allows chart developers to start with standard templates, and they customize them according to their application requirements.
Standard templates will enable them to meet the minimum standards of developing an application with Kubernetes. The manifest templates generated by Helm is of some quality, and developers learn from it.
The three big concepts of Helm
I've introduced a lot of terms in the previous section — let's find out what they mean.
Helm charts
A chart is a Helm package. If you understand Linux, a Helm chart is the Kubernetes equivalent of an RPM or DEB. A Helm chart wraps up your Kubernetes manifests into dynamic templates with a chart version and all of the needed dependencies, which allows you to standardize and distribute your applications.
Helm release
A Helm release is an instance of a Helm chart on a Kubernetes cluster. The Helm chart acts as a template for the release, while a release is an actual running Helm application.
You can use the same Helm chart to create multiple releases. Say, for instance, you want to install two separate PostgreSQL instances — you can use the PostgreSQL Helm chart to create two releases with different variables.
Helm repositories
Helm repositories store Helm charts like Yum repositories store RPMs. Anyone who needs to install the application on Kubernetes can download the app from Helm repositories using simple Helm commands.
A Helm repository can run on any web server, and, therefore, it's simple to host one. The traditional method involves creating an index.yaml file within the charts directory, which you create in the public folder of your web server, and updating the file manually when you push a chart into the repository. Below is an example structure of what the web-server directory structure looks like:
charts/
|
|- index.yaml
|
|- alpine-0.1.2.tgz
|
|- alpine-0.1.2.tgz.prov
However, mature organizations at the moment use some form of artifact repository manager, such as Sonatype Nexus Repository, which integrates with their continuous integration and continuous deployment (CI/CD) pipeline.
The three big concepts of Helm
CI/CD with Docker and Helm
A typical CI/CD pipeline with Docker and Helm looks like this:
Continuous deployment (CI/CD) pipeline with Docker and Helm
DevOps engineers create Docker files and the required dependencies (along with a Helm chart of the application) and push it to a source-code repository.
The source-code repository has a post-commit hook to a CI/CD tool such as Jenkins, which:
-
Builds the Docker image using the Docker file and pushes it to the Docker repository in Sonatype Nexus Repository
-
Packages the Helm chart and pushes it to the Helm repository in Sonatype Nexus Repository
It then updates the index with the latest package from Sonatype Nexus Repository using helm repo update and triggers Kubernetes to run a helm upgrade --install to either upgrade an existing release or install a new one based on the latest chart available in Sonatype Nexus Repository.
Hosting a Helm repository on Sonatype Nexus Repository
Nexus makes organizing and managing repositories easy, as they provide support for multiple types of repositories for various technologies, such as Maven, Yum, Go, Python, npm, Docker, and many others.
For organizations that use Sonatype Nexus Repository already, it makes sense for them to host their Helm repositories within Sonatype Nexus Repository.
Sonatype doesn't officially support Helm repositories. However, there have been community efforts to build a capability for hosting Helm repositories.
One such project is here.
I'll demonstrate how to use the project to enable Sonatype Nexus Repository to store Helm charts.
Installing the nexus-repository-helm plugin on Sonatype Nexus Repository
Identify the version of your Sonatype Nexus Repository installation, and use the correct version of the plugin using this table. Then, run the following commands to generate the plugin JAR file.
Copy the generated JAR from the nexus-repository-helm/target directory to the Sonatype Nexus Repository plugins directory at <nexus_dir>/system/org/sonatype/nexus/plugins/nexus-repository-helm/<plugin_version>/nexus-repository-helm-<plugin_version>.jar.
Edit the features.xml file to include the plugin in the Sonatype Nexus Repository configuration.
If you are using Sonatype Nexus Repository 3.21 or newer, edit <nexus_dir>/system/org/sonatype/nexus/assemblies/nexus-cma-feature/3.x.y/nexus-cma-feature-3.x.y-features.xml.
For older OSS versions, edit <nexus_dir>/system/com/sonatype/nexus/assemblies/nexus-oss-feature/3.x.y/nexus-oss-feature-3.x.y-features.xml.
For older Pro versions, edit <nexus_dir>/system/com/sonatype/nexus/assemblies/nexus-pro-feature/3.x.y/nexus-pro-feature-3.x.y-features.xml.
Add the following lines marked with + to the file. Save the file, and restart Sonatype Nexus Repository.
If everything looks good, then Helm (hosted) and Helm (proxy) will be featured in the repository recipe.
Creating the Helm-hosted repository
Create a helm repository called helm-hosted on Sonatype Nexus Repository using the Helm (hosted) recipe.
Select recipe
Create repository
Helm-hosted repository
Testing the setup
Now that we've successfully configured the helm-hosted repository on Sonatype Nexus Repository, it's time to test it on your Kubernetes cluster.
Accessing the Helm repository
Add the repository to your Helm config using the below command:
You can then access the repository using Helm.
Pushing Helm charts to Sonatype Nexus Repository
To push your helm chart to Sonatype Nexus Repository, we'd first package the chart and then upload the chart using curl to the helm-hosted repository.
Browse the helm-hosted repository to see your asset uploaded.
Asset uploaded
Check the index.yaml file, and you will find it's been auto-updated.
Installing Helm charts from Sonatype Nexus Repository
To install your Helm chart from Sonatype Nexus Repository, you need to update your local repository index with the latest packages on Sonatype Nexus Repository using helm repo update and then run helm install to create a new release from the chart.
If everything goes well, Helm will download the chart from Sonatype Nexus Repository and install it on your Kubernetes cluster.
