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
Let’s dig into how you’d use Helm with Tilt and why.
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
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
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
Iterating on the Image
Many Helm charts let you inject your own image. That’s why the
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
image_depsthat lists the images you depend on.
image_keysthat 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.,
helm_resource supports a special syntax for
describing this as a
(respository_key, tag_key) tuple.
Here’s an example from the
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 template on a chart directory and returns a blob of
the Kubernetes YAML, which you can then deploy with
When you make edits to the files in the chart directory, Tilt will automatically re-deploy the chart.
Why Does Tilt Have
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
install to deploy it. You get all the Helm features, but fewer of the Tilt
features for grouping the objects.
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:
helm_resource extension builds on the
API that Milas wrote
about last month.
This API should make it a lot easier to plug those kinds of scripts into your dev environment! Stay tuned!