Helmfile at least does allow Helm-style templating, both in its Helmfile and in individual values files.
Let's say you have some chart, and it needs to know which cluster it's installed in for monitoring purposes. Ordinarily you'd pass this as a Helm value, but you'd like to have that written down (and scriptable, and be able to pass the same config into multiple charts at the same time). In Helmfile you can write:
environments:
production:
values:
- cluster: production.example.com
testing:
values:
- cluster: testing.example.com
releases:
- name: some-chart
namespace: some-chart
chart: ./charts/some-chart
values:
- ./charts/some-chart/values.yaml.gotmpl
- cluster: {{ .Values.cluster }}
The last block should resemble helm install
arguments, but there are two bits of magic there. The {{ .Values.cluster }}
is a Go text/template
block, almost like what you'd do in a Helm chart (the exact template functions are a little different). Or, if you reference a *.gotmpl
file, Helmfile runs the template engine over that file before supplying it as input to helm.
# values.yaml.gotmpl
{{-/* enable profiling but only in testing */}}
profiling: {{ eq .Environment.Name "testing" }}
Like with plain Helm, it's possible to go overboard with the templating. It can also be a little bit confusing in that accessing undefined properties is generally an error and not nil
, and that the helmfile.yaml
gets rendered multiple times (for the most part if you define a per-environment value it must be defined in every environment). But, this does give you a very generic way to provide per-chart settings, or to define a chart setup that's almost but not quite the same in different environments.