The Helm package manager is one of the most commonly used tools for managing Kubernetes manifests. Garden supports using your own Helm charts, alongside your container builds, via the
local-kubernetesproviders. This guide shows you how to configure and use 3rd-party (or otherwise external) Helm charts, as well as your own charts in your Garden project. We also go through how to set up tests, runs and code synchronization for your charts.
In this guide we'll be using the vote-helm project. If you prefer to just check out a complete example, the project itself is also a good resource.
You may also want have a look at the reference documentation for the helm
kubernetes-execactions can be used for testing and task porposes.
Note: If you only need a way to deploy some Kubernetes manifests and don't need all the features of Helm, you can use the simpler
kubernetesaction type instead. Check out the kubernetes guide for more info.
Using external charts, where the chart sources are not located in your own project, can be quite straightforward. At a minimum, you just need to point to the chart, and perhaps provide some values as inputs. For example here is the
redisdeploy from our example project:
This may be all you need for a chart to be deployed with the rest of your stack. You can also list
deploy.redisas a dependency of one of your other actions. That will ensure redis being up and running before the other actions are executed.
A specific chart repository can be referenced via the
repofield. This may be useful if you run your own chart repository for your organization, or are referencing an action that isn't contained in the default Helm repo.
Instead of fetching the chart sources from another repository, you'll often want to include your chart sources in your Garden project. To do this, you can simply add a
garden.ymlin your chart directory (next to your
Chart.yaml) and start by giving it a name:
description: My helm deploy action
You can also use Garden's external repository support, to reference chart sources in another repo:
description: My helm deploy action
helm-podtest actions will create a fresh kubernetes workload and run your command in it. These actions are cached. This means that if garden will not rerun them if the version of the action hasn't changed. If a remote kubernetes cluster is used, test results are stored there which allows to share test results between the team or ci runs to decrease the number or re-runs.
helm-podactions don't have to depend on the deploy actions. The manifests are gathered from the rendered helm charts and deployed to the cluster.
command: [/bin/sh, -c, "npm run test:integ"]
In most cases you'll need to provide some parameters to the Helm chart you're using. The simplest way to do this is via the
This will effectively create a new YAML with the supplied values and pass it to Helm when rendering/deploying the chart. This is particularly handy when you want to template in the values (see the next section for a good example).
You can also provide you own value files, which will work much the same way. You just need to list the paths to them (relative to the action root, i.e. the directory containing the
garden.ymlfile) and they will be supplied to Helm when rendering/deploying. For example:
In this example,
some.keyis set to
other.keymaintains the default value set in
If you also set the
valuesfield in the Action configuration, the values there take precedence over both of the value files.
When your project also contains one or more
containerbuild actions that build the images used by a
helmdeploy, you want to make sure the containers are built ahead of deploying the Helm chart, and that the correct image tag is used when deploying. The
vote-helm/workerdeploy and the corresponding
worker-imagebuild provide a simple example:
description: Helm deploy for the worker container
worker-imageversion into the Helm chart via the
spec.valuesfield. Note that the shape of the chart's
values.yamlfile will dictate how exactly you provide the image version/tag to the chart (this example is based on the default template generated by
helm create), so be sure to consult the reference for the chart in question.
Notice that this can also work if you use multiple containers in a single chart. You just add them all as dependencies, and the appropriate reference under
Synchronization can be configured with helm deploys. In the example below code synchronization is set up from the
vote-imagebuild action's directory.
- containerPath: /app/src
Often you'll want to re-use the same Helm charts for multiple actions. For example, you might have a generic template for all your backend services that configures auto-scaling, secrets/keys, sidecars, routing and so forth, and you don't want to repeat those configurations all over the place.
TODO: allow non-relative paths for the chart and then write this
You can define a remote environment as a
productionenvironment by setting the production flag to
true. This affects some default behavior when working with
helmactions. See the Deploying to production guide for details.
Check out the full action reference for more details and the vote-helm example project for a full project that showcases Garden's Helm support.