One thing I really like about Helm is that you can "tune" the level of complexity of your codebase. Or one could say, tune the "DRY-ness" of
your codebase.

Thus, you can have simple templates which are mostly plain YAML with only a few values that are set by a user. Or you can have complex configurations with logic, extensions, libraries, tests, and so on. Go templates are ass, but you can totally do that.

One of the common ways of making Helm codebase DRY-er is to move common specs into separate templates. Thus, in some charts you can see files like _pod-spec.tpl, _job-spec.tpl, and so on. Later on, you can include those templates into higher level objects (this is basically how library charts work).

But what if you want to pass an additional variable, not from
the values file, but from a high-level template itself? Think of a private
variable that controls if some parts are included in the manifests,
depending on from where they were called? Say, you want to enable profiling on a subset of pods, so you create two deployments: with
profiling off and on. This is the same app, so both deployments could share the same spec. You need to tell Helm somehow, that one of the deployments should have additional config to enable profiling.

You can actually do that! Helm template function accepts a single
argument that can be a dictionary of parameters, your usual {{ template "foo" . }}, where dot represents all the values in the current scope, which you could later access as {{ .Value.foo }} in your template. The scope here is a dictionary, so you can extend it with any private
variables you like.

For example:

 include "foo" (merge (dict "myVar" "bar") .) }}

Then, you'll be able to access myVar within the included template.

See:
- One
- Two.

#helm #kubernetes