Helm Chart values.yaml: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 22: Line 22:
<syntaxhighlight lang='yaml'>
<syntaxhighlight lang='yaml'>
district:
district:
   sub-division: 1
   sub-division: north
</syntaxhighlight>
</syntaxhighlight>



Revision as of 21:45, 10 December 2020

Internal

Overview

A file that contains the default configuration values for a chart. The file is mandatory. The content of this file is displayed by helm show values. The values specified in this file can be accessed in templates as part of the Values template object. Note that the value applied to a template come from multiple sources: this values.yaml file and other sources. See Values and Chart Configuration.

Syntax

values.yaml contains YAML-structured configuration data, where YAML path are referred to as field names.

Field Names and Dashes

Field names, or in case of structured configuration, constituent elements of field names may not contain dashes, even if YAML format allows that.

A field name that contains dashes may not be read from a template in a straightforward way. For example, configuration expressed as:

district:
  sub-division: north

may not be rendered in a straightforward way in a template, as:

data:
  value: {{ .Values.district.sub-division }}

fails when rendered:

Error: parse error at (simplest/templates/configmap.yaml:6): bad character U+002D '-'

There is an inelegant workaround, though:

data:
  value: {{ index .Values "district" "sub-division" }}

Values Best Practices

https://helm.sh/docs/chart_best_practices/#values

Variable name should begin with a lowercase letter, and words should be separated with camelcase. All of Helm’s built-in variables begin with an uppercase letter to easily distinguish them from user-defined values.

All string values should be quoted, everything else should use implicit type conversion. Also see YAML Data Types.

Values specified in this file can be potentially overridden by values specified with --set, so it is a good idea to come up with variable names that can be easily overridden this way. For example:

servers:
  first:
   port: 80

if preferable to:

servers:
- name: first
   port: 80

because in the first case the override is:

--set servers.first.port=81

while in the second case is:

--set servers[0].port=81

which is sensitive to the potential change in order.

Every defined property should be documented. The documentation string should begin with the name of the property that it describes, and then give at least one sentence description. Beginning each comment with the name of the parameter it documents makes it easy to grep out documentation, and will enable documentation tools to reliably correlate doc strings with the parameters they describe:

# serverHost is the host name for the webserver
serverHost:  "example"

Example

imageRegistry: "quai.io/something"
dockerTag: "latest"
pullPolicy: "always"
storage: "s3"

TODO