CODEWITHSUNDEEP
kuberneteskubernetes-helm
Ryan
Ryan

Reputation: 490

Is there a way to use helm to template the values of another helm chart?

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.

Upvotes: 1

Views: 9190

Answers (3)

Nicolas Bousquet
Nicolas Bousquet

Reputation: 4000

I have the same issue as you have. And it bothered me for the time as there a real need, at least in my opinion.

I did it initially with mvn, copy resources and a mustache plugin and for most cases, this is fine. But now I have limitation as I need to use functions/code in my template. But wait. Isn't helm able to do all that already ???

So let's template helm with helm

This would give an organisation like that:

- meta-chart-folder
 |- Chart.yaml // Useless file to have helm template work
 |- values.yaml // Values to use for meta-templating
 |- template
   |- Chart.yaml // template for the real Chart.yaml
   |- values.yaml // template for the real values.yaml
- standard-chart-folder
  |- template
    |- The std templates of your chart.

So when calling your build system:

  • you copy your standard chart folder and everything inside to some target/helm folder
  • Call helm template on the meta-template folder with output template to be generated on target/helm folder..
    • helm template --output-dir target/helm meta-chart
    • You now have a standard helm chart structure in your target/helm folder with everything you need.
  • Call the standard helm commands on the target/helm folder

Pro/Cons

  • Add to complexity and confusion.
  • Powerful and flexible. You can do anything to your chart.yaml and values.yaml.
  • Still simple: use the existing tools you already use (helm and potentially a shell script or build system)
  • Templating is done as build time once for all. Packaged chart is a standard one.
    • So 100% compatible and working solution
    • But you can't change your mind once packaged/published... Or you need to rebuild.

Upvotes: 0

David Maze
David Maze

Reputation: 158714

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.

Upvotes: 3

Ryan
Ryan

Reputation: 490

It looks like helm has already developed this feature using a values/ subdirectory http://www.github.com/helm/helm/pull/6876

Upvotes: 0

Related Questions