Kubernetes has quickly become one of the most popular container orchestration platforms used by development and operations teams all over the world. It was open-sourced by Google in 2014, built based on years of learning deploying containers at scale inside the search giant.
Despite Kubernetes’ rapid rise to popularity, deploying and managing applications can be a complex and daunting task, often requiring the operator to write and configure multiple inter-dependent configuration files for various parts of the systems being deployed. As our applications become more complex, more distributed, the difficulty of managing them grows even further.
Originally built by Deis (later acquired by Microsoft), Helm is a package manager for Kubernetes that allows development and operations teams to easily manage and deploy these increasingly complex cloud native applications to their Kubernetes clusters. Helm allows you to manage applications on your Kubernetes cluster in much the same way as you’d manage applications on your Linux server with apt or yum.
Helm works by packaging up a set of YAML definitions along with the necessary configuration to quickly stand up all components of an application in a repeatable way. A single chart can be as simple or complex as necessary, deploying anything from a single container to a full distributed application. Helm combines these application definitions with user-provided configuration to allow simple overriding of configuration where needed, allowing users to concentrate on shipping software and not on the nitty-gritty of configuring every application they need to run.
Helm packages are known as “Charts” and are stored in a “Chart Repository”. By default, Helm comes bundled with the “stable” chart repository, hosted for free by Google. Most public charts are hosted here, mostly provided by vendors packaging their own software for use by others.
The main requirement for using Helm is a working Kubernetes installation. Setup of Kubernetes is outside the scope of this post, but you can get started locally an with installation of minikube.
Once installed you can initialise Helm on your cluster:
$ helm init
This will install Tiller, Helm’s server-side component, responsible for interacting with the Kubernetes API and managing state.
You can then run other Helm commands as needed. To view all available charts you can use the following command:
$ helm search
NAME CHART VERSION APP VERSION DESCRIPTION
stable/acs-engine-autoscaler 2.2.2 2.1.1 DEPRECATED Scales worker nodes within agent pools
stable/aerospike 0.2.3 v220.127.116.11 A Helm chart for Aerospike in Kubernetes
stable/airflow 2.4.0 1.10.0 Airflow is a platform to programmatically author, schedul...
stable/ambassador 2.0.1 0.52.0 A Helm chart for Datawire Ambassador
stable/anchore-engine 0.12.1 0.3.3 Anchore container analysis and policy evaluation engine s...
stable/apm-server 1.0.0 6.6.2 The server receives data from the Elastic APM agents and ...
stable/ark 4.1.0 0.10.1 A Helm chart for ark
You should see a full listing of the built-in “stable” repository which contains all supported public charts. You can install any of the charts from the helm CLI also:
$ helm install stable/dokuwiki
This instructs Tiller to pull the packaged chart from the stable repository, render all the templates contained within, and apply those to the running cluster. You can inspect the status of the application with regular Kubernetes CLI tooling:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
lopsided-cheetah-dokuwiki-85c96f777d-gskjn 1/1 Running 0 13d
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
lopsided-cheetah-dokuwiki 1 1 1 1 13d
Or check the status of the chart installation itself using the helm CLI:
$ helm list
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
lopsided-cheetah 1 Mon Mar 25 17:16:56 2019 DEPLOYED dokuwiki-4.2.0 0.20180422.201901061035 default
Managing Helm With Cloudsmith
If using only public charts to install third-party applications, then the above instructions are enough to get started in most cases. But if you want to install software for which there are no public charts, whether your own or third-party, you can create your own chart and host it using Cloudsmith.
If you’re creating your own chart, you can use one of Helm’s starter templates to quickly scaffold out the directory for you:
$ helm create my-chart-name
This will create a my-chart-name folder containing all the files and folders necessary to build your chart. You can adjust the templates as needed for your application, The Chart Template Developer’s Guide is a really useful resource when building your own chart.
Once you’ve finished adjusting your templates, you can create a Chart package with the CLI:
$ helm package my-chart-name
Successfully packaged chart and saved it to: /home/me/my-chart-name-1.0.tgz
Once built you can push the chart to Cloudsmith. First, ensure you’ve installed the Cloudsmith CLI and configured authentication:
Helm is a powerful tool to help manage the ever-growing complexity of deploying and running cloud native applications on Kubernetes. Like other package managers Helm provides a robust suite of tools for installing, configuring and managing applications on its target platform, Kubernetes.
Cloudsmith provides fully featured Helm repositories on all plans, flexible enough for use whether you’re hosting public charts for an open source project, or private charts for your company’s internal applications.
You can find further, context-specific information, including detailed setup and integration instructions inside each Cloudsmith repository. You can see an example of this documentation in our public examples repository.
Why wait? Get your public and private Helm repository hosting at Cloudsmith now.
A secure, cloud-native repository in minutes. Sign up now.