I have been implementing helm sub-chart by referring helm sub chart documentation. According to the documentation it worked for me. This works fine with default value files. But when I try to refer my own value file, the values are not there in the configmap.
My value file is values.staging.yaml.
eg :-
config.yaml in mysubchart
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
salad: {{ .Values.dessert }}
values.staging.yaml in mysubchart
dessert: banana
values.yaml in mysubchart
dessert: cake
Only 'cake' is referenced as the value. I need to reference banana as the value.
I have tried following commands.
helm install --dry-run --debug mychart --values mychart/charts/mysubchart/values.staging.yaml
helm install --dry-run --debug --name mychart mychart -f mychart/charts/mysubchart/values.staging.yaml
helm install --name mychart mychart -f mychart/charts/mysubchart/values.staging.yaml
In each instance the configmap does not refer the value in the values.staging.yaml.
Is there a way to do this?
Thank you .!
As described in Overriding Values of a Child Chart in your link, you need to wrap the subchart values in a key matching the name of the subchart.
Any values file you pass with helm install -f is always interpreted at the top level, even if it's physically located in a subchart's directory. A typical values file could look like
mysubchart:
dessert: banana
Related
The relevant docs: https://helm.sh/docs/chart_template_guide/functions_and_pipelines/#using-the-lookup-function
My helm version:
$ helm version
version.BuildInfo{Version:"v3.4.1",
GitCommit:"c4e74854886b2efe3321e185578e6db9be0a6e29",
GitTreeState:"dirty", GoVersion:"go1.15.4"}
Minimal example to reproduce:
Create a new helm chart and install it.
$ helm create my-chart
$ helm install my-chart ./my-chart
Create a simple ConfigMap.
# my-chart/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
data:
someKey: someValue
Upgrade the existing chart so that the ConfigMap is applied.
$ helm upgrade my-chart ./my-chart
Confirm that the ConfigMap exists.
$ kubectl -n default get configmap my-configmap
Which returns as expected:
NAME DATA AGE
my-configmap 1 12m
Try to use the lookup function to reference the existing ConfigMap.
# my-chart/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
data:
someKey: someValue
someOtherKey: {{ (lookup "v1" "ConfigMap" "default" "my-configmap").data.someValue }}
Then do a dry-run of the upgrade.
$ helm upgrade my-chart ./my-chart --dry-run
You will be met with a nil pointer error:
Error: UPGRADE FAILED: template: my-chart/templates/configmap.yaml:9:54: executing "my-
chart/templates/configmap.yaml" at <"my-configmap">: nil pointer evaluating interface
{}.someValue
What am I doing wrong?
This is an expected behavior if you are using --dry-run flag.
From documentation
Keep in mind that Helm is not supposed to contact the Kubernetes API
Server during a helm template or a helm install|update|delete|rollback --dry-run, so the lookup function will return an empty list (i.e. dict) in such a case.
it might be simple question but can't find anywhere if it's duable;
Is it possible to have values files for helm charts (stable/jenkins let's say) and have two different values files for it?
I would like in values_a.yaml have some values like these:
master:
componentName: "jenkins-master"
image: "jenkins/jenkins"
tag: "lts"
...
password: {{ .Values.secrets.masterPassword }}
and in the values_b.yaml - which will be encrypted with AWS KMS
secrets:
masterPassword: xxx
the above code doesn't work and wanted to know, as you can put those vars in kube manifests like it
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Values.config.name }}
namespace: {{ .Values.config.namespace }}
...
can they be somehow passed to other values files
EDIT:
If it was possible I would just put the
master:
password: xxx
in values_b.yaml but vars cannot be duplicated, and the official helm chart expects the master.password val from that file - so has to somehow pass it there but in encrypted way
I'm not quite sure but this feature of helm might help you.
Helm gives you the functionality to pass custom Values.yaml which have higher precedence over the fields of the main Values.yaml while performing helm install or helm upgrade.
For Helm 3
$ helm install <name> ./mychart -f myValues.yaml
For Helm 2
$ helm install --name <name> ./mychart --values myValues.yaml
The valid answer is from David Maze in the comments of the response of Kamol Hasan.
You can use multiple -f or --values options: helm install ... -f
values_a.yaml -f values_b.yaml. But you can't use templating in any
Helm values file unless the chart specifically supports it (using the
tpl function).
If you use multiple -f then latest value files override earlier ones.
I am creating a helm chart that uses multiple dependencies. For some of those dependencies I would like to use their values-production.yaml instead of the default values.yaml. I have tried adding a tag section to the dependencies to call the production values but that doesn't seem to work. For example the redis chart has production-values.yaml and values.yaml. Is there a way for me to use the production-values within my chart's dependencies?
Eg my helm Chart.yaml looks like:
apiVersion: v2
name: parentChart
...
dependencies:
- name: redis
version: 10.5.3
repository: "#stable"
tags:
- prd-values
There are two ways to provide your values file.
helm install -f myvals.yaml ./mychart
helm install --set foo=bar ./mychart
The order of specificity: values.yaml is the default, which can be overridden by a parent chart’s values.yaml, which can in turn be overridden by a user-supplied values file, which can in turn be overridden by --set parameters.
This means if you have same values in your values.yaml and values-production.yaml then only values-production.yaml will be used as it will overwrite the fields in values.yaml.
I'm installing the prometheus-redis-exporter Helm chart. Its Deployment object has a way to inject annotations:
# deployment.yaml
...
template:
metadata:
annotations:
{{ toYaml .Values.annotations | indent 8 }}
Typically if I was providing a values file, I could just do this:
# values.yaml
annotations:
foo: bar
bash: baz
And then install the chart with:
helm install --values values.yaml
However, in some cases it is more simple for me to specify these values on the command line with --set instead, I'm just not sure how I would specify a nested set like that.
How can I set the above annotations object when installing a helm chart on the commandline:
helm install --set <what_goes_here>
The helm docu has a section The Format and Limitations of --set, which contains what you are looking for.
--set outer.inner=value results in:
outer:
inner: value
Therefore your whole helm command looks like this:
helm install --set annotations.foo=bar,annotations.bash=baz stable/prometheus-redis-exporter
Just to add, if you are looking to override a key with a "." in the key name, add a back slash ("\") before the ".".
for example, with values (taken from grafana):
grafana.ini:
server:
root_url: https://my.example.com
To edit the root_url value we would pass
--set grafana\.ini.server.root_url=https://your.example.com
I have created basic helm template using helm create command. While checking the template for Ingress its adding the string RELEASE-NAME and appname like this RELEASE-NAME-microapp
How can I change .Release.Name value?
helm template --kube-version 1.11.1 microapp/
# Source: microapp/templates/ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: RELEASE-NAME-microapp
labels:
app: microapp
chart: microapp-0.1.0
release: RELEASE-NAME
heritage: Tiller
annotations:
kubernetes.io/ingress.class: nginx
This depends on what version of Helm you have; helm version can tell you this.
In Helm version 2, it's the value of the helm install --name parameter, or absent this, a name Helm chooses itself. If you're checking what might be generated via helm template that also takes a --name parameter.
In Helm version 3, it's the first parameter to the helm install command. Helm won't generate a name automatically unless you explicitly ask it to helm install --generate-name. helm template also takes the same options.
Also, in helm 3, if you want to specify a name explicitly, you should use the --name-template flag. e.g. helm template --name-template=dummy in order to use the name dummy instead of RELEASE-NAME
As of helm 3.9 the flag is --release-name, making the command: helm template --release-name <release name>