# values.yaml

config: rootDomain: rootdomain.com policyFile:

- from: example to: httpbin.org
- from: another-example to: httpbin.org

# ingress.yaml

... {{- $rootDomain := .Values.config.rootDomain }} hosts:
{{- range .Values.config.policyFile }}

- {{ .from }}.{{ $rootDomain }} {{- end }} ...

Which renders to this:

# rendered

hosts:
  - example.rootdomain.com
  - another-example.rootdomain.com

You may notice that we declared a variable $rootDomain before the range invocation. The reason behind this is that we can't reach outer scope within the range execution. However you can use these variables similar to any argument. This means that you can get child parameters like in the following example:

# variable example

{{ $config := .Values.config }} ... {{ $config.rootDomain }}

The with statement works similarly. Take a look at the following examples:

{{with "output"}}{{printf "%q" .}}{{end}} A with action
using dot.

{{with $x := "output" | printf "%q"}}{{$x}}{{end}} A with
action that creates and uses a variable.

{{with $x := "output"}}{{printf "%q" $x}}{{end}} A with
action that uses a variable in another action.

{{with $x := "output"}}{{$x | printf "%q"}}{{end}} The same,
but pipelined.

Controlling whitespace

In an application deployment there are lots of control statements like if and range. Again, because we're rendering yaml files, it's very important that indentations and newlines be put in exactly the right places. Some of you may know where I'm going with all this; let's take a look.

# deployment.yaml

... template: metadata: labels: app.kubernetes.io/name:
{{ include "test.name" . }} app.kubernetes.io/instance:
{{ .Release.Name }} annotations:
{{ if .Values.annotations }}
{{ toYaml .Values.annotations | indent 8 }} {{ end }} spec:

# rendered output

template: metadata: labels: app.kubernetes.io/name: test
app.kubernetes.io/instance: mouthy-zebra annotations:

    spec:

Note how there is a superfluous empty line after the annotations key. Wondering why? Because the rendering engine removes the contents inside brackets --- {{ }} --- but the preceding whitespace and the subsequent newline remain. In many cases it doesn't make a difference in the meaning --- yaml allows redundant and repeated white spaces at many places, but it is a common practice in the Helm community to generate a terse markup to make the output easier to read and to avoid cases where the difference causes invalid markup, or a valid one with a non-trivially different meaning. Fortunately, Helm helps remedy this with a special whitespace manipulator, the - or hyphen. Using it is simple. If you want to chomp the preceding whitespace you simply write {{-, and if you want to chomp the ensuing whitespace use -}}.

# deployment.yaml

template: metadata: labels: app.kubernetes.io/name:
{{ include "test.name" . }} app.kubernetes.io/instance:
{{ .Release.Name }} annotations:
{{- if .Values.annotations }}
{{ toYaml .Values.annotations | indent 8 }} {{- end }} spec:

# rendered output

template: metadata: labels: app.kubernetes.io/name: test
app.kubernetes.io/instance: flabby-badger annotations: spec:

Make sure there is a space between the - and the rest of your directive. {{- 3 }} translates to “remove a whitespace to the left and print '3'”, while {{-3}} means “print '-3'”. (from Helm documentation)

Define templates

Don't forget that you can define your own templates like the ones generated in _helpers.tpl.

{{- define "mychart.labels" }} labels: generator: helm date:
{{ now | htmlDate }} {{- end }}

When do I use include and when do I use template

There are several charts in which both include and template appear. They do the same job, which is to render a predefined template. However, the preferred way of using include is described in the Helm documentation, thusly:

"Because template is an action, and not a function, there is no way to pass the output of a template call to other functions; the data is simply inserted inline."

Templates in templates

You may think we've been through the tough stuff, but, fortunately (or unfortunately), that's not the case; let's take a look at templates embedded in templates.

{ { tpl TEMPLATE_STRING VALUES } }

The tpl function evaluates its first argument as a template in the context of its second argument, and returns the rendered result. Simple as that. Now let's look at an example from the Helm documentation.

# values

template: "{{ .Values.name }}" name: "Tom"

# template

{{ tpl .Values.template . }}

# output

Tom

Exercise

To summarise let's perform a small exercise:

Here, we have an application with a toml configuration. We want to generate this file based on the values in values.yaml. However, there are some credentials in this file, so we want to store it as a Kubernetes secret.

# Snippet from the app.conf

[github] clientId=XXXXX clientSecret=XXXXXXXXXXXXXXXXXXX

# values.yaml

clientId: AAAA clientSecret: BBBBBBBBBBBBBBB

Hint: you can read the contents of a file in the Chart with theFiles.Getfunction.

Here's a possible solution.

clientId={{ .Values.clientId }}
clientSecret={{ .Values.clientSecret }}

#chart/templates/secret.yaml apiVersion: v1 kind: Secret
metadata: name: mysecret type: Opaque data: config.cfg:
{{ tpl (.Files.Get "app.conf") . | b64enc }}

As you see, the trick is to get the TEMPLATE_STRING from a file with .Files.Get and pass all values with the . argument. After that we just need to encode its output with base64 as Kubernetes specification requires.

Note: File paths are relative to the chart root directory and you can NOT import files from the templates directory.

Thank you for reading the second part of our Helm blog. Stay tuned, because the next article of the series will cover Helm 3 and some of the exciting changes it will bring.

Learn more about Helm:

• Helm from basics to advanced
• Helm from basics to advanced - part II
• Decomposing a central Helm repository
• Manage Helm repositories and deploy charts via REST
• Helm 3, the Good, the Bad and the > Ugly
• Run your own free chart repository

About Banzai Cloud

Banzai Cloud is changing how private clouds are built, simplifying the development, deployment, and scaling of complex applications, and bringing the full power of Kubernetes and Cloud Native technologies to developers and enterprises everywhere. #multicloud #hybridcloud #BanzaiCloud