The More YAML You Have, The More Helm Can Help

Announcing improvements to Tilt <> Helm interop, plus a guide on how to use Helm in dev

There are two major ways we see teams use Helm charts in dev environments.

• You want to use an off-the-shelf server. You found an existing chart for it on Artifact Hub!

• You’re iterating on a server that has so much YAML that you need Helm to get your arms around it.

This week the Helm community is celebrating the release of Helm 3.8.0!

We’ve made some big improvements to our Helm support recently with the helm_resource extension.

Let’s dig into how you’d use Helm with Tilt and why.

Why Helm?

Helm is a packaging standard for Kubernetes apps.

In its simplest form, a Helm chart is simply a collection of Kubernetes objects described in YAML, with templating support to adapt those objects to different environments. Your objects might look slightly different in prod vs in dev.

But over the past few years, charts can do more and more at runtime, including:

• Installing different objects depending on which Kubernetes version you’re using.

• Controlling the order that objects are installed in.

• Running checks at different stages of the install process.

• Deleting the objects in the right order with helm uninstall.

That’s made it the tool-of-choice for installing a package of servers.

Installing off-the-shelf servers

Many off-the-shelf tools have Helm charts. The chart is an easy way to install a collection of objects into your Kubernetes cluster. You don’t have to worry about what objects are in there or what order to install them in.

Here’s an example that deploys the Bitnami mysql chart:

load('ext://helm_resource', 'helm_resource', 'helm_repo')
helm_repo('bitnami', 'https://charts.bitnami.com/bitnami')
helm_resource('mysql', 'bitnami/mysql')

Search on Artifact Hub to find Helm charts for many off-the-shelf tools. They each list the repo URL and chart name to use with helm_resource.

Iterating on the Image

Many Helm charts let you inject your own image. That’s why the helm_resource extension has a way to add a dependency on an image. Every time you rebuild the image, Tilt will redeploy the chart.

You need to add two arguments to your helm_resource declaration:

• An image_deps that lists the images you depend on.

• An image_keys that tells Tilt the names of the template keys for those images.

A widespread convention in the Helm ecosystem is to describe image with two different keys: an image.repository key (e.g., my-org/my-image-name and an image.tag key (e.g., v2). So helm_resource supports a special syntax for describing this as a (respository_key, tag_key) tuple.

Here’s an example from the helm_resource tests:

load('ext://helm_resource', 'helm_resource')

docker_build(
  'helloworld-image',
  './src',
  dockerfile='./Dockerfile')

# The ./helloworld helm chart is the default
# chart generated by 'helm create'
helm_resource(
  'helloworld',
  './helloworld',
  deps=['./helloworld'],
  image_deps=['helloworld-image'],
  image_keys=[('image.repository', 'image.tag')])

Iterating on the YAML

helm_resource is great when you want to treat the chart as a “black box” where you don’t care what objects are inside.

But if you’re developing your own chart, you may prefer Tilt’s helm built-in.

Calling helm() runs helm template on a chart directory and returns a blob of the Kubernetes YAML, which you can then deploy with k8s_yaml.

k8s_yaml(helm('./charts/my-chart'))

When you make edits to the files in the chart directory, Tilt will automatically re-deploy the chart.

Why Does Tilt Have helm() and helm_resource()?

helm() lets you break the chart into the individual Kubernetes objects, separate them out into resources, and deploy them independently. This gives you more insight into the chart details. But because Tilt is installing the objects, you lose a lot of Helm’s built-in tools for controlling the install process.

helm_resource() keeps the chart together as one resource, then uses helm install to deploy it. You get all the Helm features, but fewer of the Tilt features for grouping the objects.

The Future

We’re still adding new features to the helm_resource extension! Mark Ingram just submitted an awesome change this week. Also, shout-out to Bob Jackman, who has been instrumental in a lot of experiments with Tilt / Helm interop.

For more on how to package up Kubernetes objects in development, see our guides on:

• Modifying YAML for Dev

• Installing YAML with Helm

The helm_resource extension builds on the k8s_custom_deploy API that Milas wrote about last month.

The ecosystem of Kubernetes deploy tools has come a long way since we started Tilt. Now there are frameworks like Pulumi or NAML for install scripts without YAML.

This API should make it a lot easier to plug those kinds of scripts into your dev environment! Stay tuned!