In Brief: Helm Dependencies
I first ran into Helm sometime around the 2.x release while looking for ways
to manage the complexity of packaging software for Kubernetes. At the time
tiller
, an in-cluster service with broad permissions, made it a non-starter
for my use case. I didn't need it again until coworkers proposed Helm as a
way to package our latest product experiment at Armory.
Helm has matured dependency support since I last checked, making it an
attractive way to bundle extra software with a project. Charts may declare
a dependencies
block which contain a set of objects. These objects
contain the parent registry, version, and conditions under which you want
to include them. A sample dependency might look like the following config block:
# file: my-project/Chart.yaml
apiVersion: v2
version: v0.1.0
appVersion: v0.1.0
name: my-project
dependencies:
argo-rollouts:
repository: https://argoproj.github.io/argo-helm
name: argo-rollouts
version: ~2.1.0
condition: argo-rollouts.enabled
In this example, we bundle the Argo Rollouts Chart with our project. We also
conditionally omit it if the user disables it with a runtime value. They would
specify this condition either in their values.yaml
file, or at runtime
like so:
helm install my-project company/my-project \
--set argo-rollouts.enabled=false
Any Chart values defined by downstream dependencies can also be passed through
by prefixing values with the name of the dependency. In our example above we
are consuming the rollouts chart with this values file. If
we want to default to not installing Argo CRDs, for example, we can set this in
the values.yaml
file for our Chart:
# file: my-project/values.yaml
argo-rollouts:
enabled: true
installCRDs: false
If we decide later that we don't need argo-rollouts
for our package anymore,
we can remove it from our dependencies
block. The next time we package up
our Helm chart it will be removed from our charts
directory. This will also
remove it from any subsequent helm upgrade
commands that consumers of our
package run.
Neat!