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, tasks and hot-reloading for your charts.
kubernetesmodule type instead. Check out the kubernetes-module example for more info.
helmmodule maps to a single Garden service (not to be confused with Kubernetes Service resources), with the same name as the module.
containermodule for your image, and then the
helmmodule that references it.
redismodule from our example project, for example:
redisas a dependency of one of your other services, and this Helm chart is automatically deployed ahead of it, in dependency order.
repofield, 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.ymlin your chart directory (next to your
Chart.yaml) and start by giving it a name:
serviceResourcefield. 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
postgresapplication itself. When running the
db-cleartasks, Garden will find the appropriate container spec in the chart based on the
serviceResourcespec, and then execute that container with the task's
argsand (optionally) the specified
serviceResourceyou can also add a
resourcefield 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.
garden.ymlfile) and they will be supplied to Helm when rendering/deploying. For example:
some.keyis set to
other.keymaintains the default value set in
valuesfield in the Module configuration, the values there take precedence over both of the value files.
containermodules that build the images used by a
helmmodule, 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/workermodule and the corresponding
worker-imagemodule provide a simple example:
workermodule specifies the image as a build dependency, and additionally injects the
worker-imageversion into the Helm chart via the
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.
serviceResource.containerModule, so that Garden knows which module contains the sources to use for hot-reloading. You can then optionally add
serviceResource.hotReloadArgsto, for example, start the container with automatic reloading or in development mode.
garden deploy -w --hot-reload=voteor
garden dev --hot-reload=voteto start the
voteservice 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.
basefield on the
helmmodule type. Staying with our
vote-helmexample project, let's look at the
base-chartmodule contains the actual Helm chart and templates. Note the
skipDeployflag, which we set because the module should only be used as a base chart in this case.
apimodule only contains the
garden.ymlfile, but configures the base chart using the
valuesfield, and also sets its own dependencies (those are not inherited) and specifies its
image.tagrequired (using the required helper function) in order to enforce correct usage. We recommend enforcing constraints like that, so that mistakes can be caught quickly.
resultmodule also uses the same base chart, but sets different values and metadata:
helmmodule (not just "base" charts specifically made for that purpose), so you have a lot of flexibility in how you organize your charts.