In part 8 of this series on Kubernetes, I’ve used ‘Helm’ and ‘Helm Charts’ as an easy way to deploy a complicated Kubernetes Ingress configuration with a few commands. At the time, I left it at that and decided to come back later and explore ‘Helm’ in more detail. So here we go. In this post, I’ll have a look at what Helm is and show how to create a Helm chart for deploying several WordPress Blogs with a MySQL databases into a managed cluster.
The Helm Elevator Pitch
So here is how I would describe ‘Helm’: In the previous parts of this series, I have shown how to deploy apps into a Kubernetes cluster. In effect, everything is described in yaml text files and for everything but a very trivial app, there will be several yaml files that describe a project. At some point, there are actually quite a lot of them. So far so good.
The first thing Helm does is offer a way to apply all yaml files in a directory to a cluster with a single command. The second thing Helm does is to offer a way to insert variables into those yaml files. This way, names and other things in the description files can be made variable and hence it’s possible to use a single set of configuration files to deploy multiple instances of a project into a cluster. Let’s make a practical example: A WordPress blog consists of one image that contains the web server and the WordPress PHP files, and a second image for the MySQL database. In addition, it requires at least two persistent storage volumes, one for the database and one for uploaded files. These have to be described as well. The pods in which the images are loaded, the persistent storage volumes and many other things have names in the configuration files. Without variables, it would not be possible to create two independent WordPress instances from the same configuration files in a Kubernetes cluster, because their names need to be different. By replacing those names in the yaml files with variables, which are then described in more detail in a Helm ‘values.yaml‘ file, reuse becomes possible.
And the third thing Helm does, is that it allows to zip together all yaml configuration files, the values.yaml file and a couple of other things, to what is called a Helm Chart. This zip file can then be uploaded to what I would call a Helm ‘app store’. From there, anyone can download the Chart again and deploy a WordPress blog in their own clusters with a single command.
Helm does a number of other things, has a lot of options of how variables can be used, and includes more files in a chart, such as Chart.yaml, and a notes file that can be shown to a user. The three things described above, however, are the main thing. You can find out about all these things in the official Helm documentation, which is surprisingly straight forward to understand.
A Practical Example
O.k. so here’s a practical example: In the previous part of this series, I’ve deployed a WordPress blog into a Kubernetes cluster that consisted of two deployments, one for the WordPress/Apache web server pod and one for the MySQL database pod. There are two yaml configuration files, one for the SQL part and one for the WordPress part, which contain the service, the deployment and the permanent storage requirements. These two config files are glued together by a kustomization.yaml file. In addition, I had to add an ingress rule to my common ingress configuration yaml file to direct requests for a certain domain name to this WordPress instance. so let’s expand on this setup with Helm:
Another alternative to using the kustomization.yaml file to glue the SQL and WordPress parts together is to use Helm. For that, Helm can create an ’empty’ Helm Chart directory. This directory contains a template directory with a few example files inside that can be deleted. This is where the MySQL and WordPress yaml files have to be copied into. As there is no longer a kustomization.yaml file that supplies the secret password to both deployments, the same password has to be put into both yaml files. That’s not how it is done for a production deployment, but makes the Helm Chart simple for the moment. And finally, I created an additional yaml file that describes the ingress configuration. Like the other two yaml files, it also goes into the template folder. And that’s it already, Helm is now ready to deploy the WordPress blog into the cluster.
What it can’t do at this point is to deploy the project several times into the cluster, as there are no Helm variables in the yaml files yet. To deploy several instances that shall be accessible with different domain names, a number of static names in the two yaml files and the ingress description yaml file have to become Helm variables. Sounds difficult, but it’s not. Here’s a ZIP file with my Helm chart for the WordPress deployment. Have a look, and a lot of things will become much clearer, the structure is very simple. Of course, a lot of ‘bells and whistles are missing’ and hence that’s not how to deploy a WordPress blog in production, but it shows the concept and it works.