Depending on a subchart via requirements.yaml results in the template being rendered. I'm aware that I can use aliases to have more than one copy of a subchart, but is there a way to prevent the subchart to be rendered by default and instead included as a template, along the lines of:
{{- $root := . }}
{{- range $i, $service := .Values.services }}
---
{{ $k8sDeployment := (include "MY_SUBCHART_NAME" (dict "top" $root "deployment" $service)) | fromYaml }}
{{ include "deployment" (dict "top" $root "deployment" $k8sDeployment) }}
---
{{ $k8sService := (include "MY_SUBCHART_NAME2" $service) | fromYaml }}
{{ include "service" (dict "top" $root "service" $k8sService) }}
{{- end -}}
No, there's no way to do this. Helm dependencies (both in Helm 2 and Helm 3) work only as things that are installed in the cluster under the same Helm release name. Without using something like a post-renderer to manipulate the produced YAML, there's no way to include only part of a dependency chart or to re-include its Kubernetes objects with different parameters.
One could imagine the subchart being specifically designed to be used this way. The subchart would have to provide the templates you're trying to call, and its templates/*.yaml file would call those templates with standard values inside an if block, and then your parent chart could depend on the subchart with a value that disabled its normal output. Most charts aren't built this way, though.
Related
We have a helm chart that contains named templates to be used by other templates.
Originally, the helm chart containing the named templates has no "values.yaml" file, as all it has are "_function.tpl" files. But now, we would like to use a "values.yaml" file to define some values there instead of having to be passed by the caller like so after defining the dependency in the Chart.yaml.
{{ include "libchart.velero" (list . .Values.velero )}}
The named template then would have a definition, which converts those contexts passed as list to $root and "velero", so we can work comfortably with the caller passed context, like so:
{{- define "libchart.velero" -}}
{{- $root := index . 0 -}}
{{- $velero := index . 1 -}}
But question is, how could I define and consume the variables define in the "values.yaml" file present in the chart that contains the definition of the named template itself.
I've tried using things like {{ $.Values.local }} and {{ .Values.local }} to access "locally to the named template" defined variable, but no luck with those.
With that construction, the top-level Helm object (which contains Values, Release, Namespace, etc. fields) is in the $root variable inside the template.
{{-/*
Call with a list of two items, the top-level Helm object and the
.Values.velero chart configuration.
Outputs something only if the `local` top-level value is set.
*/-}}
{{- define "libchart.velero" -}}
{{- $root := index . 0 -}}
{{- $velero := index . 1 -}}
{{- if $root.Values.local -}} {{-/* <-- like this */-}}
... {{ $velero }} ...
{{- end -}}
{{- end -}}
This question already has an answer here:
Generic helm chart
(1 answer)
Closed 1 year ago.
Lets say I have a Helm chart "ManagementModule", and it has few env variables like as follows.
env1:[value1, value2, value3]
env2: "fixValue"
env3: "dynamic"
Now, my requirement is as follows:
if the target is Customer X environment, create just one deployment with 3 replica may be with name management-module. [this requirement is straightforward but it should work with below case as well]
If the target is Customer Y environment, create 3 different deployments with 2 replica each with below env variable.
-- deployment-name: management-module-1
env1:[value1]
env2: "fixValue"
env3: "dynamic1"
-- deployment-name: management-module-2
env1:[value2]
env2: "fixValue"
env3: "dynamic2"
-- deployment-name: management-module-3
env1:[value3]
env2: "fixValue"
env3: "dynamic2"
Second case just wants to have different deployments working on their set of environment values and independent of each other. The chart should support both ways deployments
Can I achieve it through templates/charts? Any suggestions, how we can achieve these 2 set of deployments with single chart?
Answer based on this. hence the CW.
You can use _*.tpl files to define generic templates, They are located in ./templates/_*.tpl (. being the directory with global Chart.yaml and values.yaml). Also by defaul in helm global values override local values. Solution to this can be found here.
By using these 2 techniques in conjunction you can make generic templates and only use values.yaml to render what you want to render.
For example:
# values.yaml
global:
defaults:
switches:
volumesEnabled: false
ingressEnabled: false
ingress:
host: "generic-host.com"
volumes:
volumeName: "generic-volume-name"
subchart1:
defaultOverrides:
switches:
volumesEnabled: true
volumes:
volumeName: "not-so-generic-name"
subchart2:
defaultOverrides:
switches:
volumesEnabled: true
ingressEnabled: true
Then templates (java is just for grouping templates in one category, you can try to guess in which language my backend microservices are written :) )
# ./templates/java/_deployment.tpl
{{- define "templates.java.deployment" }}
{{- $properties := merge .Values.defaultOverrides $.Values.global.defaults -}}
{{*/ generic deployment structure */}}
{{- if $properties.switches.volumesEnabled -}}
volume: {{ $properties.volumes.volumeName }}
{{- end }}
{{*/ generic deployment structure */}}
{{- end }}
# ./templates/java/_ingress.tpl
{{- define "templates.java.ingress" }}
{{- $properties := merge .Values.defaultOverrides $.Values.global.defaults -}}
{{- if $properties.switches.ingressEnabled -}}
host: {{ $properties.ingress.host }}
{{*/ generic ingress structure */}}
{{- end }}
{{- end }}
And then subchart templates
# ./charts/subchart1/templates/deployment.yaml
{{ include "templates.java.deployment" . }}
./charts/subchart1/templates/ingress.yaml:
{{ include "templates.java.ingress" . }}
subchart2 has exactly the same includes.
In the end we will have:
subchart1:
has deployment
volumeName is overriden from local values with "not-so-generic-name"
ingress is not rendered at all
subchart2:
has deployment
volumeName is default from global values
ingress host is default from global values
But I would say that it's a bad practice to generlize to much, because it will make your templates overly complex. In my case I found 2 distinct groups which have nearly identical manifests within them (basically frontend and backend) and made a set of _*.tpl files for each of them and settings default values for each group respectivelly in global values.yaml.
I have few dependencies like this
dependencies:
- name: some-chart
version: "1.2.3"
repository: "file://../some-chart"
And I install my chart like so
helm install my-chart .
However, it adds dependent charts my release name. so for example server-0 pod deploys like this
my-chart-some-chart-server-0
If I only install the dependent chart on its own, for example helm install some-chart ../some-chart it deploys 'server-0' like this
some-chart-server-0
Is there a way to deploy dependent charts without adding release name as its intended?
Some time has passed but this may be important information for other users -
As David has explained this can not be changed by helm and comes from the templates.
If you can find the following in the templates
{{- if .Values.fullnameOverride -}}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" -}}
then you can use the fullnameOverride for your needs.
You can override the values of the dependency by adding in the parent's (my-chart) values.yaml file the following:
some-chart:
fullnameOverride: some-chart
As a result, the parent's chart name (my-chart) will be dropped from the names of the resources and you will see your server-0 pod as some-chart-server-0 instead of as my-chart-some-chart-server-0.
This naming convention is part of the templates. Helm doesn't add it itself, and you can't change it without changing the templates (or doing complex post-processing).
If you run helm create, it creates a lot of infrastructure for you. Things like the Deployment are generally named
name: {{ include "<CHARTNAME>.fullname" . }}
That template, in turn, is also part of the generated _helpers.tpl file (trimmed slightly)
{{- define "<CHARTNAME>.fullname" -}}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- if contains $name .Release.Name }}
{{- .Release.Name | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}
So if you helm install some-chart ../some-chart, the release name (the first some-chart argument) matches the chart name, and you get the "short" form of just the release name; but if you helm install other-chart ../some-chart, you'll get the release-name-chart-name-suffix format.
This has nothing to do with it being a dependency, only the name you're using to install the release. Compare:
helm install some-chart ../some-chart # using its "normal" name
helm install foo ../some-chart # using some other name
helm install my-chart . # "normal" name of parent, not dependency
helm install some-chart . # "normal" name of dependency, not parent
This last case should be interesting: if your parent chart uses the same convention, you will actually see names like some-chart-my-chart-deployment, but the some-chart dependency will see the release and chart names match and so within that dependency you'll just see some-chart-foo.
I want to iterate over the Yaml list which is defined in the file, and use it in Job. For example i have
test.yaml
list:
- first element
- second element
In _helpers.tpl i can define
something like
{{- define "mychart.list" -}}
{{ .Files.Get "test.yaml"| toYaml }}
{{- end }}
And then in Job i want do something like
{{- $lists := include "mychart.list" . }}
{{- range $element := $lists.list}}
apiVersion: batch/v1
kind: Job
metadata:
and then use the $element.
But when i am trying to do the dry-run with --debug it complains about
at <$lists.list>: can't evaluate field list in type string.
Looks like whole value is coming as string rather than Yaml, does it needs explicit call to Yaml parser ? If yes, is there a way to do that ?
BTW i have also tried various combinations of
{{- $lists := include "mychart.list" . | toYaml }}
or loading the file inline, but none of them helps.
I can put the list in Values.yaml, but don't want to do that purposely.
Any help is really appreciated.
Just putting for future reference, if someone comes and have look.
There's fromYaml function, which is undocumented. I found it hard way, but that solved the isssue.
{{- $lists := include "mychart.list" . | fromYaml}}
I'm starting to write helm charts for our services.
There are two things I'm not sure how they are supposed to work or what to do with them.
First: the release name. When installing a chart, you specify a name which helm uses to create a release. This release name is often referenced within a chart to properly isolate chart installs from each other? For example the postgres chart contains:
{{- define "postgresql.fullname" -}}
{{- $name := default .Chart.Name .Values.nameOverride -}}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" -}}
{{- end -}}
Which is then used for the service:
metadata:
name: {{ template "postgresql.fullname" . }}
It does look like "myrelease-postgresql" in the end in kubernetes.
I wonder what a good release name is? What is typically used for this? A version? Or some code-name like the ubuntu releases?
Second: referencing values.
My chart uses postgresql as a sub-chart. I'd like to not duplicate the way the value for the name of the postgresql service is created (see snipped above).
Is there a way I can reference the service name of a sub-chart or that template define {{ template "postgresql.fullname" . }} in the parent chart? I need it to pass it into my service as database host (which works if I hardcode everything but that cannot be the meaning of this).
I tried:
env:
- name: DB_HOST
value: {{ template "mychart.postgresql.fullname" . }}
But that lead into an error message:
template "mychart.postgresql.fullname" not defined
I've seen examples of Charts doing similar things, like the odoo chart. But in here that logic how the postgresql host name is created is copied and an own define in the template is created.
So is there a way to access sub-chart names? Or values or template defines?
Thanks!
Update after some digging:
According to Subcharts and Globals the templates are shared between charts.
So what I can do is this:
In my chart in _helpers.tpl I add (overwrite) the postgres block:
{{- define "postgresql.fullname" -}}
{{- $name := .Values.global.name -}}
{{- printf "%s-%s" $name "postgresql" | trunc 63 | trimSuffix "-" -}}
{{- end -}}
So this value is used when the sub-chart is deployed. I cannot reference all values or the chart name in here as it will be different in the sub-chart - so I used a global value.
Like this I know the value of the service that is created in the sub-chart.
Not sure if this is the best way to do this :-/
Are you pulling in postgresql as a subchart of your chart (via your chart's requirements.yaml)? If so, both the postgresql (sub) chart and your chart will have the same .Release.Name - thus, you could specify your container's environment as
env:
- name: DB_HOST
value: {{ printf "%s-postgresql" .Release.Name }}
if you override postgresql's name by adding the following to your chart's values.yaml:
postgresql:
nameOverride: your-postgresql
then your container's env would be:
env:
- name: DB_HOST
value: {{ printf "%s-%s" .Release.Name .Values.postgresql.nameOverride }}
You can overwrite the values of the subchart with the values of the parent chart as described here:
https://helm.sh/docs/chart_template_guide/subcharts_and_globals/
I don't think it's possible (and it also doesn't make sense) to override the template name of the subchart.
What I would do is define the database service name in the .Values files both in the parent and sub charts and let helm override the one in the subchart - that way you will always have the database name in the parent chart. This would however mean that the service name of the database should not be {{ template "name" . }}, but something like {{ .Values.database.service.name }}
mychart/.Values
mysubchart:
service:
name: my-database
mychart/templates/deployment.yaml
env:
- name: DB_HOST
value: {{ .Values.mysubchart.service.name }}
mychart/charts/mysubchart/.Values
service:
name: my-database
mychart/charts/mysubchart/templates/service.yaml:
apiVersion: v1
kind: Service
metadata:
name: {{ .Values.service.name }}
Another way is to use global chart values, also described in https://helm.sh/docs/chart_template_guide/subcharts_and_globals/
For values in the helper.tpl instead of values.yaml
To access a value from a chart you do the following:
{{ template "keycloak.fullname" . }}
To access a value from a sub chart
{{ template "keycloak.fullname" .Subcharts.keycloak }}
You could import values from a sub chart as described here: https://helm.sh/docs/topics/charts/#importing-child-values-via-dependencies.
However there is a caveat. This works not for values defined at the root level in the values.yaml.
See this issue for more information: https://github.com/helm/helm/issues/9817