Can I have multiple values.yaml files in a Helm chart?
Something like mychart/templates/internalValues.yaml, mychart/templates/customSettings.yaml, etc?
Accessing properties in a values.yaml file can be done by {{ .Values.property1 }}.
How would I reference the properties in these custom values.yaml files?
Yes, it's possible to have multiple values files with Helm. Just use the --values flag (or -f).
Example:
helm install ./path --values ./internalValues.yaml --values ./customSettings.yaml
You can also pass in a single value using --set.
Example:
helm install ./path --set username=ADMIN --set password=${PASSWORD}
From the official documentation:
There are two ways to pass configuration data during install:
--values (or -f): Specify a YAML file with overrides. This can be specified multiple times and the rightmost file will take precedence
--set (and its variants --set-string and --set-file): Specify overrides on the command line.
If both are used, --set values are merged into --values with higher precedence. Overrides specified with --set are persisted in a configmap. Values that have been --set can be viewed for a given release with helm get values . Values that have been --set can be cleared by running helm upgrade with --reset-values specified.
Helm by default will only use the values.yaml file in the root directory of your chart.
You can ask it to load additional values files when you install. For instance, if you have any settings that point to different databases in different environments:
helm install . -f values.production.yaml
You could also get a similar effect by bundling additional settings as a file, and asking Helm to read the bundled file. Helm provides an undocumented fromYaml template function which can parse the file, so in principle you can do something like
{{- $v := $.Files.Get "more-values.yaml" | fromYaml }}
foo: {{ $v.bar }}
Just to update : As per the current official documentation --set & --values will not be merged
To override values in a chart, use either the '--values' flag and pass in a file or use the '--set' flag and pass configuration from the command line, to force a string value use '--set-string'. In case a value is large and therefore you want not to use neither '--values' nor '--set', use '--set-file' to read the single large value from file.
Also :
You can specify the '--values'/'-f' flag multiple times. The priority will be given to the last (right-most) file specified.
Related
I have multiple values file that Helm will merge together. I'd like to see the resulting values file but I'm not sure how I would do that.
I could run this command and this would result in the generated manifests, but I really just want to see the resulting values file instead.
helm template . -f values.yaml -f values-prod.yaml
I have a folder containing multiple values.yaml files and I would like to pass all the yaml files in that folder as an argument to helm install.
It is possible to use like helm install example . -f values/values1.yaml -f values/values2.yaml
But there are more than 10 files in values folder Is it possible to simply pass a folder as an argument
I already tried helm install example . -f values/* And this does not work.
This is not possible as -f expects a file or URL = specify values in a YAML file or a URL (can specify multiple) and helm does not know a command to use a directory.
Maybe you should reduce your values.yaml files to have a base value file and then one environment specific values file:
helm install example . -f values.yaml -f env/values_dev.yaml
I have the following chart:
deployment:
envVars:
- name: FIRST
value: first
- name: SECOND
value: second
I would like to append an extra name/value pair to the chart via the --set command in Helm.
The documentation at https://github.com/helm/helm/blob/master/docs/using_helm.md#the-format-and-limitations-of---set doesn't seem to help me.
I've tried to pass --set deployment.envVars[0].name=APPEND,deployment.envVars[0].value=yes but it says no matches found.
Using Helm 2.10.
Any suggestion?
Try escape square brackets [] with backslash \ in your command, like this --set deployment.envVars\[0\].name=APPEND,deployment.envVars\[0\].value=yes.
In ZSH, this should do it:
helm [...] --set 'ingress.annotations.nginx\.ingress\.kubernetes\.io\/proxy-body-size'=8m
Make sure to properly escape all slashes and dots which aren't object nesting level delimiters in the actual keys of the map, to avoid improper rendering.
I am new to helm chart. As part of the requirement I named my values.yaml to customize.yaml
To tell helm engine that I am using custom yaml file, I used the below command.
helm install mychart -f customize.yaml
but now the question is how should I not pass the name of the yaml (customize.yaml) file as part of the command, so the command should be like this
helm install mychart
and helm should know that it will get the values from customize.yaml
without explicitly mentioning it in the command. Is there a way to do this?
I tried to include it in _helpers.tpl but it didn't work
// ValuesfileName is the default values file name.
ValuesfileName = "values.yaml"
values.yaml have been defined as the default file in helm's source code. So, in your case, you may have to build helm from source with your changes.
Sometimes there are variables in the deployment yaml file which are not pre-specified and will be known only during deployment (For example name and tag for the image of a container).
Normally we put a marker text (e.g. {{IMAGE_NAME}}) in the yaml file and use a bash text manipulation tools to change it with actual value in the deployment file.
Is there a way to use environment variables or other methods (like using arguments when running kubectl create) instead of text-replace tools?
What I've done is use envvars in the deployment configuration, then run apply/create with the output from an envsubst command:
deployment.yaml file:
[...]
spec:
replicas: $REPLICA_COUNT
revisionHistoryLimit: $HISTORY_LIM
[...]
during deploy:
$ export REPLICA_COUNT=10 HISTORY_LIM=10
$ envsubst < deployment.yaml | kubectl apply -f -
Unfortunately there is no way to use environment variables directly with kubectl. The common solution is to use some kind of a templating language + processing as you suggested.