CODEWITHSUNDEEP
kuberneteskubernetes-helm
oooyaya
oooyaya

Reputation: 1803

Externalize / reuse Helm _helpers

I have several apps of different shapes and purposes, each with their own templates/ folder as generated by helm create chart. The templates within each App are sufficiently different to justify having them as one-offs. However, the _helpers.tpl is identical for all of them. I'd like to externalize/reuse this _helpers.tpl template so that I don't need a copy of it in every app.

What I have currently looks something like this:

App1
|--app (random source code crap, irrelevant)
|--chart
|---templates
|------_helpers.tpl
|------ deployment.yaml
|------ other unique templates

App2
|--app (random source code crap, irrelevant)
|--chart
|---templates
|------_helpers.tpl
|------ deployment.yaml
|------ other unique templates

I'd like to centralize this _helpers.tpl so that I don't need to maintain N versions of it. I'm imagining something like this, but I'm open to whatever:

Common
|--chart
|----templates
|------ _helpers.tpl (I live here now and was removed from the 2 Apps below)

App1
|-- app (random source code crap, irrelevant)
|-- chart
|--- templates
|------ deployment.yaml
|------ other unique templates

App2
|-- app (random source code crap, irrelevant)
|-- chart
|--- templates
|------ deployment.yaml
|------ other unique templates

I have tried doing this with a symlink pointing AppN/chart/templates/_helper.tpl to Common/chart/templates/_helper.tpl but that's clearly bad and I imagine there's a built-in way to do this that I'm just not finding.

Even if AppN/chart/templates/_helpers.tpl needs to exist only to read ../../_helpers.tpl, that's good enough but I'm not sure how to approach that given the YAML-y/Go-y syntax.

Upvotes: 2

Views: 1791

Answers (2)

David Maze
David Maze

Reputation: 159875

If one Helm chart includes another as a subchart, any {{ define }} templates anywhere in any of the parent or child charts are visible to all of the charts to be {{ include }}d or {{ template }}d. This means that you can create a library chart that only contains the helpers, with basically exactly the structure you show above

common
+-- Chart.yaml
\-- templates/
  +-- _a_helper.tpl
  \-- _another.tpl

This looks like a normal Helm chart in that it has a Chart.yaml file and a templates subdirectory, but inside templates are only _*.tpl files and not *.yaml files, and those files only contain {{ define }} top-level directives.

In your application charts, you can consume the library chart like any other chart dependency. If these are all checked into the same repository, you can use relative file: URLs to point at the common chart.

# app1/Chart.yaml
dependencies:
  - name: common
    repository: file://../common/

You do need to remember to run helm dep up before deploying the application chart; this makes a copy in the charts subdirectory.

(If you're using modern Helm 3, you can flag the library chart with type: library in the Chart.yaml file. If you're using obsolete Helm 2, the dependency needs to go in a separate requirements.yaml file. You can't usefully configure the library chart with values; if an application chart calls {{ include "common.some.template" . }} it will pass along the parent chart's view of .Values as part of the template parameter.)

Upvotes: 1

oooyaya
oooyaya

Reputation: 1803

I wound up solving this by inverting my file structure into something like:

Parent App
|--Chart.yaml // new
|--values.yaml // new
|--templates // new
|----_helpers.tpl // automagically gets referenced in charts/*/templates
|--apps (source code stuff, irrelevant)
|--charts
|----App1
|------Chart.yaml
|------values.yaml
|------templates
|--------deployment.yaml (and others)
|----App2
|------Chart.yaml
|------values.yaml
|------templates
|--------deployment.yaml (and others)

Which follows the "subchart" pattern outlined here more closely: https://helm.sh/docs/chart_template_guide/subcharts_and_globals/

Even though these are independent charts, not dependencies on some parent chart like this structure would indicate, this is good enough for me.

Upvotes: 2

Related Questions