Why we need automated deployments

Over the last decade, there has been a paradigm shift in the way applications are written, deployed, and managed. Businesses had adopted cloud native as their strategy for dealing with applications. As a result, applications have shifted to a microservices architecture. The deployment platforms are now managed clouds or Kubernetes.

When applications are written in a microservices way, a single application is broken into many small applications. Each one of these small applications is fully independent. They might have their own DB, cache server, messaging queues, and any such enterprise infrastructure. 

With such changes, the load on an operations engineer increases manifold. The apps may be granular, but he must deploy and manage numerous ones as opposed to just one. Automating the task is the most effective technique to make it easier. If you decide to deploy your applications using Kubernetes, there will be more justifications for doing so. For each application that is to be deployed in Kubernetes, you need to write many manifest files. Again, each application contains numerous deployable components, such as a database, an API, a frontend, a database access layer, and many others. For each component, there would be one or more manifest files. So for one microservice suite, one might end up deploying hundreds of Kubernetes manifest files. Each of these files has to be deployed in a particular sequence, without fail. Otherwise, the deployment may become corrupt or fail. 

So, what is needed is a tool that could do the following:

• Understand the microservices and manifest files
• Understand the order of pushing the files to Kubernetes
• Think the complete microservices suite as one application
• Rollback, and Upgrade the application as a single unit with almost ease
• Do it in a secure way.

There are multiple tools available for accomplishing this. The most popular among them is Helm.

What is Helm

Helm is an open source software that helps in installing, upgrading, rolling back, and uninstalling Kubernetes workloads in a Kubernetes cluster. Helm does it almost effortlessly. It is also called the package manager for Kubernetes. With Helm, complex Kubernetes deployments could be installed with utmost ease. A very large microservices suite could be installed, uninstalled, and managed with just a single command. Helm also supports running smoke tests before or after installation.

Just notice that the term \”installation\” is being used in place of \”deployment.\” That is because Helm sees the deployments as applications being installed on a platform, just like any other package manager installs packages on a platform. For example, yum, and apt are popular package managers for Linux distributions, and they install packages.

To use Helm, we need to store our Kubernetes manifest files in a specific folder structure. This folder structure is treated as one package. Helm packages are called charts. Charts could be nested to help install multiple applications using a single folder structure. For convenience in managing the chart as well as several versions of the same chart, the folders may also be archived and stored in a repository.

Most businesses are now releasing their Kubernetes artifacts in the form of charts and uploading them to public CNCF artifact repositories like Artifacthub. The charts could be stored locally in a file folder, in a local private chart repository, or in a public chart repository. Helm is capable of reading the charts stored on any of the three and is capable of pulling and installing them.

How Helm Works

We should have some idea how helm works. Before that we will know a little about helm architecture and components. Then it will be easier to know how helm works.

Architecture

Helm contains three key concepts with which we must become familiar.

Chart: 

As we know, a chart is a package that contains all necessary Kubernetes artifacts and a few Helm-specific files in a certain folder structure. All these files are necessary to install a Kubernetes application.

Config: 

The config consists of one or more yaml files and contains necessary configuration information for deploying a Kubernetes application. These configurations are merged into the chart during helm operations.

Release: 

A release is called the running instance of a chart. The chart is merged with the config and that successfully installs an application as a release. One chart can have multiple releases.

Components

Helm up to version 2 worked with a client-server model. However, with the most recent version, Helm 3, Helm works with a client + library model. Helm is written in the GO language. When we install Helm, we are installing both the Helm library and the client.

Helm Client

Helm client is the command line interface to work with the Kubernetes cluster. It reads the Rathercluster information from the ~/.kube/.config file and always points to the current cluster. Any operation the user has to invoke needs to be pushed through the Helm client.

The Helm client is responsible for local chart development, managing chart repositories, managing releases, interacting with the Helm library, and finally installing, upgrading, rolling back, and uninstalling applications.

Helm Library

The Helm library is the actual Helm engine. It stores the logic for all Helm operations invoked through the Helm client. As previously stated, the logic is written in GO. It interacts with the Kubernetes API server to invoke Helm operations. It uses REST+JSON for its interactions with the Kubernetes API server. It doesn’t use its own database. Rather, it stores all configuration information in Kubernetes ETCD. 

When Helm Client issues a command, the library integrates the Kubernetes artifacts and configuration information and generates the final manifest files to be sent as a POST message to the KUBE API server. 

Popular Helm commands

Here we will list the most commonly used and powerful Helm commands. These commands are used by a Helm operator on an everyday basis.

• helm completion – generate autocompletion scripts for the specified shell
• helm create – create a new chart with the given name
• helm dependency – manage a chart\’s dependencies
• helm env – helm client environment information
• helm get – download extended information of a named release
• helm history – fetch release history
• helm install – install a chart
• helm lint – examine a chart for possible issues
• helm list – list releases
• helm package – package a chart directory into a chart archive
• helm plugin – install, list, or uninstall Helm plugins
• helm pull – download a chart from a repository and (optionally) unpack it in local directory
• helm push – push a chart to remote
• helm registry – login to or logout from a registry
• helm repo – add, list, remove, update, and index chart repositories
• helm rollback – roll back a release to a previous revision
• helm search – search for a keyword in charts
• helm show – show information of a chart
• helm status – display the status of the named release
• helm template – locally render templates
• helm test – run tests for a release
• helm uninstall – uninstall a releasefrom
• helm upgrade – upgrade a release
• helm verify – verify that a chart at the given path has been signed and is valid
• helm version – print the client version information

All the above commands are extracted from the Helm documentation. To know more about the commands and other parameters, please click on the commands, and the hyperlink will land you on the specific pages telling you more about the commands.

Basic Helm Tutorials

In this section, we will look at the use case of deploying a Kubernetes application in a Kubernetes cluster. It will demonstrate how to retrieve a chart from a repository and deploy it on your cluster. We will also uninstall the application.

Prerequisites

For this tutorial, we are assuming the user has basic knowledge of Kubernetes and Linux commands. We also assume that you have access to a Kubernetes cluster. If not, create one using Minikube or use Katakoda. For the tutorial, I am using Katakoda.

Steps

Install Helm

Helm could be installed very easily. All the steps are mentioned on the Helm documentation page. There are separate sections for different operating systems. Choose the section according to the OS you are using. Once Helm is installed successfully, test the version and proceed. 

Create a Helm Local Chart

We will create a basic Helm chart using the “helm create” command. This command will create a fully functional Helm chart with all the necessary files and an appropriate folder structure. You will have a visual representation of a Helm chart. This chart will try to deploy an nginx application to the cluster with all required Kubernetes API objects like a deployment, service, configmap, etc. We will not install and then remove the chart. 

Use the following two commands. 

helm create nginx-app

tree nginx-app

You will be able to see a new folder called \”nginx-app\” created with a few files and sub-folders. Open and read the files like Chart.yaml, values.yaml, or deployment.yaml. Describing each file is beyond the scope of this article. Finally, delete the chart by executing the following command.

rm -rf nginx-app

Deploy a Helm Chart from Remote Repository

In this section, we will connect our Helm command-line client to a remote chart repository and pull a chart from the repository to install on our cluster. I will be using Bitnami as my remote chart repository. From the Bitnami repo, I will search for and install MySQL. Use the following commands:

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

helm repo list 

Now that the repo has been added, we will use the following commands to search for MySQL and install the chart.

helm search repo bitnami/mysql

helm install mysql bitnami/mysql

Copy the output of the last command into a file that has instructions on how to connect to the MySQL container, as shown in the below image.

Verify that the release is successful using the below commands.

helm list 

kubectl get all 

The kubectl command will give you the list of API objects the release has created.

Uninstall the Chart

Now uninstall the release by using the command “helm uninstall mysql”. This will remove the release, leaving no trace of it. Use “kubectl get all” to check if any other item was left behind by the release. 

Conclusion

So, it was a short tutorial where we learned what Helm is and how we can install, create, and uninstall Helm charts. Precisely, Helm is the Kubernetes package manager, which constructs packages called charts and installs, updates, and rollbacks, and uninstalls them using the Helm command line. You can try more using the Helm documentation.