Helm Chart values.yaml: Difference between revisions
Line 18: | Line 18: | ||
All string values should be quoted, everything else should use implicit type conversion. Also see [[YAML#Data_Types|YAML Data Types]]. | All string values should be quoted, everything else should use implicit type conversion. Also see [[YAML#Data_Types|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: | Values specified in this file can be potentially overridden by values specified with [[Helm_install#--set|--set]], so it is a good idea to come up with variable names that can be easily overridden this way. For example: | ||
servers: | servers: |
Revision as of 22:45, 29 August 2019
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 inspect 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.
Values Best Practices
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"