Code Engineered

Helm Charts: Higher Level Programming and Apps

When charts, the packages for the Helm package manager, first started they were fairly simple. Properties in Kubernetes YAML files could be turned into variables, with defaults, that could be easily changed. This meant that Charts were focused on simple infrastructure customization. For example, two different people could share configuration while changing the container image location. This was useful for those who maintainered their own internal copy of an image.

Over time, Charts have started to see a shift in complexity and focus. Variables and template function, which have been slowly expanded over time, provide a method for higher level programming in Charts.

An Example

A simple example can be seen in the community Wordpress chart. Below is a snippet for custom values that can be passed into the chart:

ingress:
  enabled: true

  hosts:
  - name: wordpress.local
    tls: true
    tlsSecret: wordpress.local-tls

  secrets:
  - name: wordpress.local-tls
    key: -----BEGIN RSA PRIVATE KEY----- ...
    certificate: -----BEGIN CERTIFICATE----- ...

In the custom configuration you can declare that ingress is enabled. This will cause an Ingress controller configuration to be created. If you don’t enable this you don’t get it. Consider this a way of enabling a feature.

If you enable Ingress you then list one or more hosts. This causes the correct Kubernetes Ingress objects to be created for each host. This is accomplished with if, range, and other statements in the templates. For users who have more than one domain routing to their application this makes configuring multiple hosts easy.

The tls configuration enables each host to specify if TLS should be setup. If TLS is enabled, which is a per host feature, the tlsSecret should be specified with the location of the key and certificate. When these are specified the Ingress controllers are setup with the configuration.

Optionally, secrets can be specified here with keys and certificates. This is another feature. When secrets are supplied the chart will create the right Kubernetes secrets. By this being optional the secrets can be managed by either Helm through this chart or outside the chart.

From Simple Templates To Application Features

From an end user perspective this is about application configuration rather than simple tweakable infrastructure configuration. Features are enabled or disabled, details about the feature are set, and when the chart is turned into Kubernetes configuration the configuration needed for the feature is created.

So Many Possibilities

The example above focused mostly on Kubernetes configuration objects. This is only one way configuration is being handled. Another part of this pattern is to collect application configuration and pass that to the application in for the form of a configmap or secret. For example, collecting an email address needed by the application and putting that into the right place in a configmap. Application configuration right through the chart.

How Did We Get Here?

It’s worth exploring how we got here. From the outside looking in a few things come to mind:

  • This change in style happened organically and came from real world users. When left to their own devices this is what people came up with.
  • The changes seem to focus on a simplified user experience for end users. That is, those installing and operating applications.
  • Instead of thinking about charts as a collection of Kubernetes configuration (an infrastructure perspective) this new view looks at charts as a way of descirbing an application (application centric perspective).

I always find it interesting to see how people use something, where that leads a project, and what we can learn from it. I look forward to seeing where these charts go.