Working with Helm

In addition to creating and deleting virtual environments (i.e., releases of specific charts), Helm provides many options for analyzing running stacks. The

helm status <release>

command displays information about a release, including its revision number, which shows how many times the release has been modified while running.

At this point, I should point out a circumstance that might already have cost admins who write their own Helm charts too much time: Unless the Helm chart and container image are from the same authors, Helm charts in K8s regularly rely on images different from the vendor's originals. If you use the WordPress chart from Bitnami, for example, you are not using the official WordPress image for containers under the hood, but one that has been modified by Bitnami.

Official images do not support many of the parameters that Helm tends to use in containers, so if you want to produce your own charts, you might face the same problem and have to create your own images of the respective software for containerized operation. Various how-tos online can help you produce containers (e.g., as the result of a CI/CD pipeline).

Helm Example

At the end of this article, after a lot of theory, you are still missing some hands-on insight into what you can actually achieve with Helm. Currently, hardly any software on the market is as suitable as ownCloud. Many an admin who has already had to deal with Helm in the past may be taken aback by this revelation. The large PHP monolith is not usually thought of as being particularly well suited for operation in K8s or management by Helm. However, if you are still in this camp, you are no longer up to date with the latest developments.

ownCloud has practically reinvented itself in recent months. PHP's performance limitations, some of which were inherent, caused recurring difficulties over the years. Many modern programming mantras and techniques, for example, are missing from PHP, partly because they had not yet been invented when the language was launched and partly because retrofitting is not trivial. One good example of this is multithreading, which is cited time and time again.

In the context of ownCloud X, the developers therefore decided to take a radical step and embark on an almost total rewrite. Instead of PHP, the developers now use Go, and they have also waved goodbye to the monolithic programming style of the past. Instead, ownCloud X comprises microarchitecture applications that communicate with each other by defined APIs. Quite remarkably, the ownCloud client protocol has not changed. Existing clients will therefore continue to work, and ownCloud apps such as those for iOS or Android do not need an update either.

This transformation makes another thing clear: ownCloud X offers K8s cluster operators a potential deployment model. Until a few weeks ago, however, getting ownCloud to work in a K8s cluster was a pain in the proverbial backside. The Bitnami project has now put an end to that: ownCloud is now available as a chart for Helm and can be rolled out to any K8s cluster – including, for example, Amazon's Elastic Kubernetes Service (EKS). The power and efficiency that come from intelligently deployed Helm charts immediately become abundantly clear. All it takes is two commands to get a brand-new ownCloud environment up and running on K8s:

# helm repo add bitnami https://charts.bitnami.com/bitnami
# helm install <MyRelease> bitnami/owncloud

Just replace <MyRelease> with an arbitrary name under which the now rolled out stack will later be known in K8s. If you are not quite sure which names have already been assigned, the helm list command conjures up a list on the screen. If you want the Helm chart to disappear from the system later on, the

Helm delete <MyRelease>

command takes care of that.

Admittedly, the Bitnami developers have had things fairly easy because ownCloud provides active support. Since ownCloud X was released for general use, Docker images have also been available. These images in turn form the basis for the Bitnami Helm charts. Bitnami does not directly use the image provided by ownCloud, but it builds on it.

Easy Game

How much work Helm takes off your shoulders can be perfectly illustrated by the ownCloud chart by Bitnami. The developers have built in a number of parameters that can be used to control ownCloud in the container, right down to the smallest detail. Although you can let off steam in values.yaml, it will not be necessary in most cases. That said, you might want to specify a few basic parameters such as the path to the SSL certificate or the public IP addresses you will be using (Figure 5).

Figure 5: Helm charts, like this one for ownCloud, come with a values.yaml file where you can set local parameters.

When making a local change to values.yaml, you need to append -f values.yaml to the helm install call to point to your local file. After a few seconds, ownCloud X will be running across the local K8s instance (Figure 6). Moreover, Helm automatically takes care of issues such as the replicas it needs. The mariadb.architecture=replication parameter will even tell Helm to support a high-availability database, if you need one. Compared with the effort of writing the required pod definitions yourself and matching them with each other, the amount of work involved in the use of Helm is negligible, to all extents and purposes.

Figure 6: ownCloud X (OCIS, i.e., ownCloud Infinite Scale) now comes as a modular application in Go and can easily be rolled out as a Helm chart in Kubernetes.