kubernetes
and local-kubernetes
providers. 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, tasks and hot-reloading for your charts.kubernetes
module type instead. Check out the kubernetes-module example for more info.helm
module maps to a single Garden service (not to be confused with Kubernetes Service resources), with the same name as the module.container
module for your image, and then the helm
module that references it.redis
module from our example project, for example:redis
as a dependency of one of your other services, and this Helm chart is automatically deployed ahead of it, in dependency order.repo
field, to reference a specific chart repository. This may be useful if you run your own chart repository for your organization, or are referencing a module that isn't contained in the default Helm repo.garden.yml
in your chart directory (next to your Chart.yaml
) and start by giving it a name:vote-helm/postgres
module:serviceResource
field. This tells Garden which Kubernetes Deployment, DaemonSet or StatefulSet to regard as the primary resource of the chart. In this case, it is simply the postgres
application itself. When running the db-init
and db-clear
tasks, Garden will find the appropriate container spec in the chart based on the serviceResource
spec, and then execute that container with the task's args
and (optionally) the specified env
variables.vote
module:serviceResource
you can also add a resource
field with the same schema to any individual task or test specification. This can be useful if you have different containers in the chart that you want to use for different scenarios.values
field:garden.yml
file) and they will be supplied to Helm when rendering/deploying. For example:some.key
is set to "prod-value"
for the prod
environment, and other.key
maintains the default value set in values.default.yaml
.values
field in the Module configuration, the values there take precedence over both of the value files.container
modules that build the images used by a helm
module, you want to make sure the container
s are built ahead of deploying the Helm chart, and that the correct image tag is used when deploying. The vote-helm/worker
module and the corresponding worker-image
module provide a simple example:worker
module specifies the image as a build dependency, and additionally injects the worker-image
version into the Helm chart via the values
field. Note that the shape of the chart's values.yaml
file 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.values
.container
module referenced by a helm
module, you can even use Garden's hot-reloading feature for a Helm chart. Going back to the vote
module example:serviceResource.containerModule
, so that Garden knows which module contains the sources to use for hot-reloading. You can then optionally add serviceResource.hotReloadArgs
to, for example, start the container with automatic reloading or in development mode.garden deploy -w --hot-reload=vote
or garden dev --hot-reload=vote
to start the vote
service in hot-reloading mode. When you then change the sources in the vote-image module, Garden syncs the changes to the running container from the Helm chart.base
field on the helm
module type. Staying with our vote-helm
example project, let's look at the base-chart
and api
modules:base-chart
module contains the actual Helm chart and templates. Note the skipDeploy
flag, which we set because the module should only be used as a base chart in this case.api
module only contains the garden.yml
file, but configures the base chart using the values
field, and also sets its own dependencies (those are not inherited) and specifies its serviceResource.containerModule
.name
, image.repository
and image.tag
required (using the required helper function) in order to enforce correct usage. We recommend enforcing constraints like that, so that mistakes can be caught quickly.result
module also uses the same base chart, but sets different values and metadata:helm
module (not just "base" charts specifically made for that purpose), so you have a lot of flexibility in how you organize your charts.production
environment by setting the production flag to true
. This affects some default behavior when deploying helm
modules. See the Deploying to production section in the Remote Kubernetes guide for details.