Understanding Helm: Benefits, Core Concepts, and Using Helm with Docker, CI/CD, and Nexus Repository

Why Use Helm?

Helm simplifies templating, enables version control of Kubernetes applications, promotes reuse and sharing of charts, streamlines deployment, manages dependencies, and enforces standards for manifest quality.

Helm Makes Templating Easy

Instead of duplicating YAML files for each instance, you create a single chart with variables and deploy multiple releases from it.

Helm Enables Versioned Releases

Charts are packaged with version metadata, allowing you to store multiple versions in a Helm repository, roll back, or upgrade without rebuilding from source.

Helm Facilitates Reuse and Sharing

Public Helm repositories let you share Kubernetes applications the way Docker Hub shares container images, providing standard charts for consumers.

Helm Simplifies Deployment

Commands such as helm install and helm uninstall replace complex kubectl workflows, making installations concise and repeatable.

Helm Handles Dependency Management

For example, a LAMP stack chart can declare a MySQL dependency, ensuring Apache is only installed when MySQL is available.

Helm Promotes Standards

Chart developers start from vetted templates, learning best‑practice manifest patterns while meeting minimum Kubernetes standards.

Helm’s Three Core Concepts

Helm Charts

A chart is a packaged collection of Kubernetes manifests, similar to an RPM or DEB, containing a version, templates, and dependencies.

Helm Release

A release is a concrete instance of a chart running in a cluster; the same chart can produce many releases.

Helm Repository

Repositories store charts like package managers store binaries; they can be hosted on any web server or on a Nexus repository.

CI/CD Pipeline with Docker and Helm

Typical steps:

DevOps engineers create Dockerfiles and Helm charts, push them to source control.

CI tools (e.g., Jenkins) build Docker images, push them to a Docker registry, package Helm charts, and push them to a Helm repository.

After the Nexus repository updates its index, helm repo update is run, followed by helm upgrade --install to deploy or upgrade the application in Kubernetes.

Hosting a Helm Repository on Sonatype Nexus

Nexus supports many repository formats, including Helm (built‑in from version 3.21+). Install the nexus-repository-helm plugin for older versions.

Adding the Nexus Repo to Helm

# helm repo add nexus http://admin:[email protected]:8081/repository/myhelm/
"nexus" has been added to your repositories
# helm repo list
NAME        URL
stable      http://mirror.azure.cn/kubernetes/charts/
gitlab      https://charts.gitlab.io
mattermost  https://helm.mattermost.com
nexus       http://admin:[email protected]:8081/repository/myhelm/

Packaging and Uploading a Chart

# helm package ./gitlab-runner
Successfully packaged chart and saved it to: /root/new-k8s-runner/custom-gitlab-runner-0.15.0.tgz
# curl -v -F [email protected] -u admin:admin123 http://192.168.1.200:8081/service/rest/v1/components?repository=myhelm

Installing the Chart from Nexus

# helm repo update
# helm search repo -l custom-gitlab-runner
NAME                        CHART VERSION  APP VERSION  DESCRIPTION
nexus/custom-gitlab-runner   0.15.0         12.9.0       GitLab Runner
# helm fetch nexus/custom-gitlab-runner --version 0.15.0
# helm install my-runner nexus/custom-gitlab-runner --version 0.15.0

These steps demonstrate a complete end‑to‑end workflow for managing Kubernetes applications with Helm, Docker, and a Nexus Helm repository.