Working with Helm Basics

In this blog, we will see what we can do once Helm is installed.

Using Helm’s Built-In Help

First, we need to know: What can we do with the Helm command? And this is where the built-in help is very useful.

To understand Helm’s basic concepts, check out this video.

To start out and get an idea about the (sub)commands it supports, we can type

helm --help

This can serve as a quick way to remember what the right command is, to do something. For example, say we want to restore a release to a previous version, after a failed upgrade. We might wonder, Wait, what was the command to do that? helm restore?. And we then see in this list that the correct command is actually helm rollback. It’s much faster than looking on the Internet for the answer since it’s immediately accessible from the command line.

We can also use this help feature for subcommands. For example, if we want to see what repository-related actions we can take

helm repo --help

And we can even dig deeper and learn about what a sub-sub-command does and what parameters it supports:

helm repo update --help

After using Helm’s built-in help a couple of times, it will become easy to memorize the correct commands for all the actions you usually need.

Searching for Helm Charts on ArtifactHub.io

So let’s assume we are in a scenario where we need to launch a WordPress website in Kubernetes. Doing it without Helm, while not really hard, still involves many more steps. You can check out an example here: https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/. We can see it’s quite a long list of actions we need to take. We need to create each Kubernetes object, one by one until we get all components ready. We’ll need persistent volumes to store the database. We’ll need to define a service to expose the website to the outside world. We then need to define deployment objects to launch our pods that actually run the MySQL database and Apache web server applications. Now let’s see how much easier it is to do this with Helm.

We’ll first need to find a chart for the WordPress structure we want. We can actually use the helm command itself to search for this:

helm search hub wordpress

But this is a bit limited. We can’t really see a lot about how these are built and what exactly they contain. There are actually commands (e.g., helm show readme bitnami/wordpress) to get more details about a chart, right in your terminal window, but it’s a bit hard to read in this restricted environment. So we can instead visit this search engine that lists all kinds of Kubernetes resources, and, what’s of interest to us, the repositories that contain the charts we need: https://artifacthub.io/.

With software, in general, especially what we use in a commercial/corporate environment, there’s always the issue of Can we trust this code? Is it non-malicious? Is it of good quality? To ensure we get a high-quality chart, we can try to find one that has the Official or Verified Publisher badge. If we click on this result we’ll see a detailed page with all the info we may want to know about this chart. It starts out with the exact commands we need to use to install the chart into our Kubernetes cluster, continues with what software components this uses, and further down the page, we can even see some of the most important configurable settings we can tweak. It’s up to chart developers to mention what they think is important on the description page.

Deploying a Helm Chart

There will be cases where the packages we install with Helm require no tweaks, and we can just get them up and running with two simple helm repo add and helm install commands. Let’s assume our WordPress app fits in this scenario and install it into our Kubernetes cluster.

First, we tell Helm about this new repository of charts that we want to use:

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

This way, it knows the address from where it can pull in the charts we’ll need.

We’ve named this repository bitnami. We can choose any name we want, after the add command, but we’ll need to use this same name when installing our chart.

It’s worth mentioning here that, from time to time, we’ll also want to use this command:

helm repo update

This is somewhat equivalent to what a sudo apt-get update command does on some Linux-based operating systems. In a nutshell, the info that Helm has about that repository is stored locally. With time, repository maintainers make changes, update stuff, and so on, so our local copy of this info gets stale, outdated. The command above refreshes the info that Helm has, by pulling it in from the online repository, to our local computer. This way, we get the latest data available.
Finally, we can install our WordPress chart. Notice how we use the same name we chose for the repository we added earlier. bitnami/wordpress in the next command is basically a way of saying, install the chart called WordPress from the repository we named bitnami.

helm install my-release bitnami/wordpress

And boom! With one single command, Helm does all the heavy lifting and is getting everything ready behind the scenes. In the end, we even get some useful information about how we can use this WordPress install.

[email protected]:~$ helm install my-release bitnami/wordpress
NAME: my-release
LAST DEPLOYED: Wed Jun 30 17:26:36 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
** Please be patient while the chart is being deployed **

Your WordPress site can be accessed through the following DNS name from within your cluster:

    my-release-wordpress.default.svc.cluster.local (port 80)

To access your WordPress site from outside the cluster follow the steps below:

1. Get the WordPress URL by running these commands:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace default -w my-release-wordpress'

   export SERVICE_IP=$(kubectl get svc --namespace default my-release-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
   echo "WordPress URL: http://$SERVICE_IP/"
   echo "WordPress Admin URL: http://$SERVICE_IP/admin"

2. Open a browser and access WordPress using the obtained URL.

3. Login with the following credentials below to see your blog:

  echo Username: user
  echo Password: $(kubectl get secret --namespace default my-release-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)

This text is actually generated by instructions included in the chart. This way, users get an idea about how they can continue with their newly installed Kubernetes package. We’ll learn about how we can do the same (generate output at the end of the install) with the charts we build.

Now if you want to actually see that the WordPress website is actually running, it depends where your Kubernetes cluster is hosted. Normally, you can just follow the instructions in your terminal and access WordPress through the external IP displayed in this command:

kubectl get svc --namespace default my-release-wordpress

But if after you gave Helm a few minutes to install everything, you still get the output showing the EXTERNAL-IP in a pending state, you might not have this option available out-of-the-box. For example, this can happen if you’re running your cluster locally, with Minikube. In Minikube, a quick workaround is to open up another terminal window, and use this command:

minikube tunnel

You will need to provide a sudo user password in a few seconds. Leave the terminal window open as this needs to keep running in the background.

Return to your old terminal window, then enter

kubectl get svc --namespace default my-release-wordpress

again until you see an EXTERNAL-IP listed. Enter that in the address bar of your browser and voila, we can see that Helm really did all of its magic and installed a complex app for us into our cluster, without much effort on our part.

Pretty easy, right? We basically used just two commands to install a complex WordPress website that needs a lot of Kubernetes objects to get up and running.

If you used the minikube tunnel command, go back to that terminal window, press CTRL+C and then close the window.

Deleting Release

Now we want to remove all traces of this app. Imagine doing that by hand.  We would have to delete a lot of objects from our cluster, one by one, to get rid of all WordPress-related components. But with Helm, this is again easily done with a single command.

To see all releases installed:

helm list

This is very useful, not only to track what has been installed but also to see what hasn’t been updated in a long time.

Since we now have the name of the release, we can remove all Kubernetes objects added by this WordPress website, with one simple command.

helm uninstall my-release

Again, very easy. We can really begin to see the power of Helm as a package manager for Kubernetes.

Customising Chart Parameters at Install Time

For the sake of simplicity, we went through an example of how to install a Helm chart with its default settings. Normally, charts give multiple ways to users to specify their own desired settings, by editing a special values.yaml file or by providing their desired preferences on the command line. But charts are cleverly built, so that if the user does not specify any preferences, default values are used instead.

With some simpler apps, we’ll sometimes use the defaults, as there aren’t many interesting things we may want to tweak, and the general defaults are good enough. But in the case of something like WordPress, it may be useful to choose some custom settings we desire, before everything gets installed. WordPress is a very complex app, with hundreds of such customizable settings, from simple things, such as website title, to security-related things like administrator password or TLS certificate that would be used to provide HTTPS connections to website visitors. Of course, there’s also the option to adjust these settings later, from within WordPress’s admin interface, or, with kubectl commands to edit Kubernetes objects. Nonetheless, it’s very useful to know how we can customize our Helm releases, at install time. There are generally three ways to do this:

1. Specifying our custom parameters in the command line directly
If there are just a couple of things we want to customize, we can just specify our desired custom values directly in the command line, by adding --set parameters. For example, this chart lets us specify the title for our WordPress site. We could use a command like this to choose a specific title:

helm install --set wordpressBlogName="Helm Tutorials" my-release-2 bitnami/wordpress

If we need to specify multiple custom values for our chart, we just use the --set parameter multiple times.

helm install --set wordpressBlogName="Helm Tutorials" --set wordpressEmail="[email protected]" my-release-3 bitnami/wordpress

2. Creating a “values.yaml” file where we specify all of our desired custom values.

When there are just too many values we want to set, using 30 –set parameters in a single command would make it very long, tedious to write, and just plain ugly to look at, not to mention hard to edit if we need to reinstall our app with different settings. So, the cleaner way is to create a file where we list the values we want to set.

Let’s create this file:

nano values.yaml

In this file, instead of specifying a value in the form of wordpressBlogName="Helm Tutorials" we will use a different notation. Add this content to the values.yaml file.

wordpressBlogName: Helm Tutorials 
wordpressEmail: [email protected]

We’re basically using “:” instead of “=” and adding a space after those “:” to set the value we desire.

Press CTRL+X, then y and then ENTER to save this file.

So how do we tell Helm to use these custom values when installing the chart? By adding the –values command line parameter and specifying the path to our values.yaml file.

helm install --values values.yaml my-release-4 bitnami/wordpress

3. Downloading the entire chart locally and then editing the included values.yaml file

This method is usually recommended if we really want to dig deep into customizing the app we install with this chart. And it does have one big advantage. Complex, professionally-developed charts have many comments inside the values.yaml file, which helps us understand better what we can change and what the effect would be. Let’s go through an example.

We can download a chart with this command:

helm pull --untar bitnami/wordpress

Normally, the chart would be downloaded in an archived form (called TAR archive). But the --untar parameter we added, automatically extracts this file’s contents.

Here’s how part of values.yaml file looks like

wordpressUsername: user
## @param wordpressPassword WordPress user password
## Defaults to a random 10-character alphanumeric string if not set
##
wordpressPassword: ""
## @param existingSecret Name of existing secret containing WordPress credentials
## NOTE: Must contain key `wordpress-password`
## NOTE: When it's set, the `wordpressPassword` parameter is ignored
##
existingSecret:
## @param wordpressEmail WordPress user email
##
wordpressEmail: [email protected]
## @param wordpressFirstName WordPress user first name
##
wordpressFirstName: FirstName
## @param wordpressLastName WordPress user last name
##
wordpressLastName: LastName
## @param wordpressBlogName Blog name
##
wordpressBlogName: User's Blog!

We can edit everything we want in here, and when we’re done, save the file and then use this command:

helm install my-release-5 ./wordpress

Checkout the Helm for the Absolute Beginners course here

Checkout the Complete Kubernetes learning path here