Helmis 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 organisations 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. The obvious question is: Why do we need Helm? Let’s find out. 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. 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. For Docker images, you can share your images on DockerHub — the same wasn’t possible for Kubernetes. With public Helm repositories likeKubernetes 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. With Helm, you can run simple commands, such as You don’t have to worry about finding the manifest files and running 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 allows chart developers to start with standard templates, and they customise 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. I’ve introduced a lot of jargon in the previous section — let’s find out what they mean. 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 standardise and distribute your applications. Why Helm?
Helm makes templating applications easy
Helm makes the versioning of Kubernetes applications possible
Helm makes reusing and sharing possible
Helm makes deploying Kubernetes applications concise
helm installandhelm del, to install and delete releases.kubectl delete. Everything is so dynamic with Helm.Helm makes dependency management possible
Helm helps enforce standards
The Three Big Concepts of Helm
Helm charts
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 anindex.yamlfile within thechartsdirectory, which you create in thepublicfolder 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 organisations at the moment use some form of artifact repository manager, such as Nexus Repository Manager, which integrates with their CI/CD pipeline.
The three big concepts of Helm
CI/CD With Docker and Helm
A typical continuous integration and continuous deployment (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
- Packages the Helm chart and pushes it to the Helm repository in Sonatype Nexus
It then updates the index with the latest package from Nexus usinghelm repo updateand triggers Kubernetes to run ahelm upgrade --installto either upgrade an existing release or install a new one based on the latest chart available in Nexus.
Hosting a Helm Repository on Sonatype Nexus
Nexus makes organising 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 organisations that use Sonatype Nexus already, it makes sense for them to host their Helm repositories within Nexus.
Sonatype doesn’t officially support Helm repositories. However, there have been community efforts to build a capability for hosting Helm repositories.
I’ll demonstrate how to use the project to enable Nexus to store Helm charts.
Installing the nexus-repository-helm plugin on Nexus
Identify the version of your Nexus installation, and use the correct version of the plugin usingthistable. Then, run the following commands to generate the plugin Jar file.
Copy the generated Jar from thenexus-repository-helm/targetdirectory to the Nexus plugins directory at<nexus_dir>/system/org/sonatype/nexus/plugins/nexus-repository-helm/<plugin_version>/nexus-repository-helm-<plugin_version>.jar.
Edit thefeatures.xmlfile to include the plugin in the Nexus configuration.
If you’re using Nexus 3.21 and 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 Nexus.
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 calledhelm-hostedon Nexus using the Helm (hosted) recipe.
Select recipe
Create repository
Helm-hosted repository
Testing the Setup
Now that we’ve successfully configured thehelm-hostedrepository on Nexus, it’s time to test it on your Kubernetes cluster.
Accessing the Helm repository
Add the Nexus repository to your Helm config using the below command:
You can then access the Nexus repository using Helm.
Pushing Helm charts to Nexus
To push your helm chart to Nexus, we’d first package the chart and then upload the chart using curl to thehelm-hostedrepository.
Browse thehelm-hostedrepository to see your asset uploaded.
Asset uploaded
Check theindex.yamlfile, and you’ll find it’s been autoupdated.
Installing Helm charts from Nexus
To install your Helm chart from Nexus, you need to update your local repo index with the latest packages on Nexus usinghelm repo updateand then runhelm installto create a new release from the Chart.
If everything goes well, Helm will download the chart from Nexus and install it on your Kubernetes cluster.
Originally published on Medium
Written by Gaurav Agarwal
Certified Enterprise Cloud, Integration and DevOps Architect, Tech Enthusiast, and Author.
Tags
Nexus Repository Product Helm
