Say you need to deploy a public helm chart (like jenkins/jenkins) with a lot of values. I want to write those values over multiple files and also use go templates inside those values files. I then want to compose them together and deploy them. Is there a way to write a meta - level helm chart that creates the values as a manifest then installs a sub chart based on those values?
I’m aware of kustomize, helmfile, and sub charts. I guess none of them just feel like the thing I want (or maybe I’m not using them properly). Kustomize doesn’t support go templates. Helmfile is good for composing and selecting values but not necessarily templating those values files (or maybe it does). Let me know if I’m asking a duplicate.
It looks like helm has already developed this feature using a values/ subdirectory http://www.github.com/helm/helm/pull/6876
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.