Templates

• Helm Chart templates are written in the Go template language
• All template files are stored in a chart’s templates/ folder.
• When Helm renders the charts, it will pass every file in that directory through the template engine.

Values for the templates are supplied two ways

• Chart developers may supply a file called values.yaml inside of a chart
• Chart users may supply a YAML file that contains values
• When a user supplies custom values, these values will override the values in the chart’s values.yaml file

Predefined Values

Values that are supplied via a values.yaml file (or via the --set flag) are accessible from the .Values object in a template.
$ helm install --values=myvals.yaml wordpress

Hooks

Helm provides a hook mechanism to allow chart developers to intervene at certain points in a release’s life cycle. For example, you can use hooks to:

• Load a ConfigMap or Secret during install before any other charts are loaded.
• Execute a Job to back up a database before installing a new chart, and then execute a second job after the upgrade in order to restore data.
• Run a Job before deleting a release to gracefully take a service out of rotation before removing it.

Hooks work like regular templates, but they have special annotations that cause Helm to utilize them differently

Hooks are declared as an annotation in the metadata section of a manifest:

apiVersion: ...
kind: ....
metadata:
  annotations:
    "helm.sh/hook": "pre-install"

THE AVAILABLE HOOKS

The following hooks are defined:

• pre-install: Executes after templates are rendered, but before any resources are created in Kubernetes.
• post-install: Executes after all resources are loaded into Kubernetes
• pre-delete: Executes on a deletion request before any resources are deleted from Kubernetes.
• post-delete: Executes on a deletion request after all of the release’s resources have been deleted.
• pre-upgrade: Executes on an upgrade request after templates are rendered, but before any resources are loaded into Kubernetes (e.g. before a Kubernetes apply operation).
• post-upgrade: Executes on an upgrade after all resources have been upgraded.
• pre-rollback: Executes on a rollback request after templates are rendered, but before any resources have been rolled back.
• post-rollback: Executes on a rollback request after all resources have been modified.
• crd-install: Adds CRD resources before any other checks are run. This is used only on CRD definitions that are used by other manifests in the chart.

Note

Hook resources are not managed with corresponding releases. The resources that a hook creates are not tracked or managed as part of the release. Once Tiller verifies that the hook has reached its ready state it will leave the hook resource alone. If you create resources in a hook, you cannot rely upon helm delete to remove the resources. To destroy such resources, you need to either write code to perform this operation in a pre-delete or post-delete hook or add "helm.sh/hook-delete-policy" annotation to the hook template file.

apiVersion: batch/v1
kind: Job
metadata:
  name: "{{.Release.Name}}"
  labels:
    app.kubernetes.io/managed-by: {{.Release.Service | quote }}
    app.kubernetes.io/instance: {{.Release.Name | quote }}
    helm.sh/chart: "{{.Chart.Name}}-{{.Chart.Version}}"
  annotations:
    # This is what defines this resource as a hook. Without this line, the
    # job is considered part of the release.
    "helm.sh/hook": post-install
    "helm.sh/hook-weight": "-5"
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    metadata:
      name: "{{.Release.Name}}"
      labels:
        app.kubernetes.io/managed-by: {{.Release.Service | quote }}
        app.kubernetes.io/instance: {{.Release.Name | quote }}
        helm.sh/chart: "{{.Chart.Name}}-{{.Chart.Version}}"
    spec:
      restartPolicy: Never
      containers:
      - name: post-install-job
        image: "alpine:3.3"
        command: ["/bin/sleep","{{default "10" .Values.sleepyTime}}"]

USING THE ‘REQUIRED’ FUNCTION

The required function gives developers the ability to declare a value entry as required for template rendering. If the entry is empty in values.yml, the template will not render and will return an error message supplied by the developer.

For example:

{{ required "A valid foo is required!" .Values.foo }}

USING THE ‘TPL’ FUNCTION

MODIFYING SCOPE USING WITH

Scopes can be changed. with can allow you to set the current scope (.) to a particular object.

data:
  myvalue: "Hello World"
  {{- with .Values.favorite }}
  drink: {{ .drink | default "tea" | quote }}
  food: {{ .food | upper | quote }}
  {{- end }}

In the above example, we can reference .drink and .food without qualifying them. That is because the with statement sets . to point to .Values.favorite. The . is reset to its previous scope after {{ end }}

LOOPING WITH THE RANGE ACTION

Sample values.yaml

favorite:
  drink: coffee
  food: pizza
pizzaToppings:
  - mushrooms
  - cheese
  - peppers
  - onions

To print a list using range:

data:
  myvalue: "Hello World"
  {{- with .Values.favorite }}
  drink: {{ .drink | default "tea" | quote }}
  food: {{ .food | upper | quote }}
  {{- end }}
  toppings: |-
    {{- range .Values.pizzaToppings }}
    - {{ . | title | quote }}
    {{- end }}

Each time through the loop, . is set to the current pizza topping. That is, the first time, . is set to mushrooms. The second iteration it is set to cheese, and so on.

Variables:

In Helm templates, a variable is a named reference to another object. It follows the form $name. Variables are assigned with a special assignment operator: :=