Values Files

In the previous section we looked at the built-in objects that Helm templatesoffer. One of the four built-in objects is Values. This object provides accessto values passed into the chart. Its contents come from four sources:

  • The values.yaml file in the chart
  • If this is a subchart, the values.yaml file of a parent chart
  • A values file if passed into helm install or helm upgrade with the -fflag (helm install -f myvals.yaml ./mychart)
  • Individual parameters passed with —set (such as helm install —set foo=bar./mychart)The list above is in order of specificity: values.yaml is the default, whichcan be overridden by a parent chart’s values.yaml, which can in turn beoverridden by a user-supplied values file, which can in turn be overridden by—set parameters.

Values files are plain YAML files. Let’s edit mychart/values.yaml and thenedit our ConfigMap template.

Removing the defaults in values.yaml, we’ll set just one parameter:

  1. favoriteDrink: coffee

Now we can use this inside of a template:

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: {{ .Release.Name }}-configmap
  5. data:
  6.   myvalue: "Hello World"
  7.   drink: {{ .Values.favoriteDrink }}

Notice on the last line we access favoriteDrink as an attribute of Values:{{ .Values.favoriteDrink }}.

Let’s see how this renders.

  1. $ helm install --dry-run --debug ./mychart
  2. SERVER: "localhost:44134"
  3. CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart
  4. NAME:   geared-marsupi
  5. TARGET NAMESPACE:   default
  6. CHART:  mychart 0.1.0
  7. MANIFEST:
  8. ---
  9. # Source: mychart/templates/configmap.yaml
  10. apiVersion: v1
  11. kind: ConfigMap
  12. metadata:
  13.   name: geared-marsupi-configmap
  14. data:
  15.   myvalue: "Hello World"
  16.   drink: coffee

Because favoriteDrink is set in the default values.yaml file to coffee,that’s the value displayed in the template. We can easily override that byadding a —set flag in our call to helm install:

  1. helm install --dry-run --debug --set favoriteDrink=slurm ./mychart
  2. SERVER: "localhost:44134"
  3. CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart
  4. NAME:   solid-vulture
  5. TARGET NAMESPACE:   default
  6. CHART:  mychart 0.1.0
  7. MANIFEST:
  8. ---
  9. # Source: mychart/templates/configmap.yaml
  10. apiVersion: v1
  11. kind: ConfigMap
  12. metadata:
  13.   name: solid-vulture-configmap
  14. data:
  15.   myvalue: "Hello World"
  16.   drink: slurm

Since —set has a higher precedence than the default values.yaml file, ourtemplate generates drink: slurm.

Values files can contain more structured content, too. For example, we couldcreate a favorite section in our values.yaml file, and then add several keysthere:

  1. favorite:
  2.   drink: coffee
  3.   food: pizza

Now we would have to modify the template slightly:

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: {{ .Release.Name }}-configmap
  5. data:
  6.   myvalue: "Hello World"
  7.   drink: {{ .Values.favorite.drink }}
  8.   food: {{ .Values.favorite.food }}

While structuring data this way is possible, the recommendation is that you keepyour values trees shallow, favoring flatness. When we look at assigning valuesto subcharts, we’ll see how values are named using a tree structure.

Deleting a default key

If you need to delete a key from the default values, you may override the valueof the key to be null, in which case Helm will remove the key from theoverridden values merge.

For example, the stable Drupal chart allows configuring the liveness probe, incase you configure a custom image. Here are the default values:

  1. livenessProbe:
  2.   httpGet:
  3.     path: /user/login
  4.     port: http
  5.   initialDelaySeconds: 120

If you try to override the livenessProbe handler to exec instead of httpGetusing —set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt], Helm willcoalesce the default and overridden keys together, resulting in the followingYAML:

  1. livenessProbe:
  2.   httpGet:
  3.     path: /user/login
  4.     port: http
  5.   exec:
  6.     command:
  7.     - cat
  8.     - docroot/CHANGELOG.txt
  9.   initialDelaySeconds: 120

However, Kubernetes would then fail because you can not declare more than onelivenessProbe handler. To overcome this, you may instruct Helm to delete thelivenessProbe.httpGet by setting it to null:

  1. helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null

At this point, we’ve seen several built-in objects, and used them to injectinformation into a template. Now we will take a look at another aspect of thetemplate engine: functions and pipelines.