How to override values.yaml from parent chart in Helm - kubernetes

I am trying to install rabbitmq helm chart in dependencies section of my parent chart.
Here is my parent chart
apiVersion: v2
name: mychart
description: A Helm chart to install rabbitmq
type: application
version: 1.0.0
appVersion: "1.0.0"
dependencies:
- name: rabbitmq
repository: https://charts.bitnami.com/bitnami
version: 8.11.9
condition: rabbitmq.enabled
And here is the values.yml file of this chart
rabbitmq:
enabled: true
auth.username: test
auth.password: test
I am trying to override the values of auth.username and auth.password of rabbitmq dependency chart. But values are getting override. And default values are used when I deploy/test this chart.
What am I doing wrong here ?

While the helm install --set option takes options like --set rabbitmq.auth.username=..., and charts' documentation generally uses this syntax, in YAML files you need to put each part in a nested block:
rabbitmq:
enabled: true
auth:
# "username" under "auth", not a single key "auth.username"
username: test
password: test

Related

Multiple deployments using one helm chart and chart dependencies with alias

I have 10 Deployments that are currently managed by 10 unique helm releases.
But these deployments are so similar that I wish to group them together and manage it as one helm release.
All deployments use the same helm chart, the only difference is in the environment variables passed to the deployment pod which is set in values.yaml.
Can I do this using helm chart dependencies and the alias field?
dependencies:
- name: subchart
repository: http://localhost:10191
version: 0.1.0
alias: deploy-1
- name: subchart
repository: http://localhost:10191
version: 0.1.0
alias: deploy-2
- name: subchart
repository: http://localhost:10191
version: 0.1.0
alias: deploy-3
I can now set values for individual deploys in one parent Chart's values.yaml:
deploy-1:
environment:
key: value-1
deploy-2:
environment:
key: value-2
deploy-3:
environment:
key: value-3
But 99% of the values that I need to set for all the deployments are the same.
How do I avoid duplicating them across the deploy-n keys in the parent chart's values.yaml file?
If you have 10 deployments that are similar, but have only a few differences in environment variables, you can group them together and manage them as one helm release using a single values.yaml file. Here's how you can achieve this:
Define a single dependency in your parent chart's Chart.yaml file that points to the helm chart for your deployments:
dependencies:
- name: my-deployments
version: 1.0.0
repository: https://charts.example.com
Create a single values.yaml file in your parent chart's templates directory that defines the values for your deployments:
my-deployments:
environment:
key1: value1
key2: value2
key3: value3
In your deployment manifests, replace any environment variable values that vary between deployments with references to the values in the parent chart's values.yaml file:
env:
- name: ENV_VAR_1
value: {{ .Values.my-deployments.environment.key1 }}
- name: ENV_VAR_2
value: {{ .Values.my-deployments.environment.key2 }}
- name: ENV_VAR_3
value: {{ .Values.my-deployments.environment.key3 }}
This way, you only need to define the environment variable values that vary between deployments in the parent chart's values.yaml file, and Helm will automatically apply these values to all the deployments.
Note that this approach assumes that all of your deployments use the same Helm chart with the same structure for their deployment manifests. If this is not the case, you may need to adjust the approach accordingly to fit the specific needs of your deployments.

Airflow installation with helm on kubernetes cluster is failing with db migration pod

Error:
Steps:
I have downloaded the helm chart from here https://github.com/apache/airflow/releases/tag/helm-chart/1.8.0 (Under Assets, Source code zip).
Added following extra params to default values.yaml,
createUserJob:
useHelmHooks: false
migrateDatabaseJob:
useHelmHooks: false
dags:
gitSync:
enabled: true
#all data....
airflow:
extraEnv:
- name: AIRFLOW__API__AUTH_BACKEND
value: "airflow.api.auth.backend.basic_auth"
ingress:
web:
tls:
enabled: true
secretName: wildcard-tls-cert
host: "mydns.com"
path: "/airflow"
I also need KubernetesExecutor hence using https://github.com/airflow-helm/charts/blob/main/charts/airflow/sample-values-KubernetesExecutor.yaml as k8sExecutor.yaml
Installing using following command,
helm install my-airflow airflow-8.6.1/airflow/ --values values.yaml
--values k8sExecutor.yaml -n mynamespace
It worked when I tried the following way,
helm repo add airflow-repo https://airflow-helm.github.io/charts
helm install my-airflow airflow-repo/airflow --version 8.6.1 --values k8sExecutor.yaml --values values.yaml
values.yaml - has only overridden parameters

Helm overriding child chart values from parent chart

I am new to Helm and using Helm 3. I am trying to build a simple helm chart which depends on the mongodb helm chart available from bitnami here.
This is the structure of my chart:
mychart
|- charts\
|- mongodb-8.1.1.tgz
|- Chart.yaml
|- values.yaml
I am trying to override the value of mongodb.rootPassword (and some other properties) through the values.yaml file of the parent chart. However, it does not override the value specified and reverts to the default values from the mongodb chart.
It would be a great help to understand what I am doing wrong and how can I override the value of the child chart from the parent chart.
Here are the contents of my files:
Chart.yaml
apiVersion: v2
name: mychart
appVersion: "1.0"
description: mychart has the best description
version: 0.1.0
type: application
dependencies:
- name: mongodb
version: 8.1.1
repository: https://charts.bitnami.com/bitnami
condition: mongodb.enabled
values.yaml
mongodb:
global:
namespaceOverride: production
fullnameOverride: mongo-mychart
useStatefulSet: true
auth:
rootPassword: example
persistence:
size: 100Mi
This is possible in case the format of the values.yaml file has an issue. In this case, the values.yaml file of the parent chart had a few extra encoded characters which were causing it to be ignored by helm and defaulting the child chart's values.

Basic Helm Dependency Clarification

To ease local development/testing, I have an umbrella chart that deploys all my sub-charts. Those applications make use of resources (e.g. MongoDB, Kafka, etc) and I want to make sure that if you are installing the umbrella chart to a cluster, it will also install those resources.
To do this, I have the following:
apiVersion: v2
name: my-cool-project
type: application
version: 0.1.0
appVersion: 0.1.0
dependencies:
- name: my-cool-app-1
repository: "file://my-cool-app-1"
- name: my-cool-app-2
repository: "file://my-cool-app-2"
- name: bitnami/kafka
version: 2.5.0
repository: "https://charts.bitnami.com/bitnami"
Unfortunately, installing this chart throws the following error:
Error: found in Chart.yaml, but missing in charts/ directory: bitnami/kafka
This seems so fundamental to the concept of Helm that the fact it's not working means I'm clearly missing something basic. Even the official docs are pretty clear this is the right approach.
Most documentation/guides instruct you to simply helm install it straight to the cluster. While this might solve my immediate problem of needing Kafka or MongoDB on the cluster, my desire is to code-ify the need for that resource so that I can achieve "single chart installs everything to an empty cluster and it just works" status.
What am I missing?
This worked for me 🔧:
apiVersion: v2
name: my-cool-project
type: application
version: 0.1.0
appVersion: 0.1.0
dependencies:
- name: my-cool-app-1
repository: "file://my-cool-app-1"
- name: my-cool-app-2
repository: "file://my-cool-app-2"
- name: kafka 👈
version: 11.6.0 👈
repository: "https://charts.bitnami.com/bitnami"
Then update on the dependencies on your local helm Chart:
○ → helm dependency update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "bitnami" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading kafka from repo https://charts.bitnami.com/bitnami
Deleting outdated charts
✌️☮️

Disabling subcharts in custom helm chart

I've created a custom helm chart with elastic-stack as a subchart with following configurations.
# requirements.yaml
dependencies:
- name: elastic-stack
version: 1.5.0
repository: '#stable'
# values.yaml
elastic-stack:
kibana:
# at this level enabled is not recognized (does not work)
# enabled: true
# configs like env, only work at this level
env:
ELASTICSEARCH_URL: http://foo-elasticsearch-client.default.svc.cluster.local:9200
service:
externalPort: 80
# enabled only works at root level
elasticsearch:
enabled: true
kibana:
enabled: true
logstash:
enabled: false
What i don't get is why i have to define the enabled tags outside the elasatic-stack: and all other configurations inside?
Is this a normal helm behavior or some misconfiguration in elastic-stack chart?
Helm conditions are evaluated in the top parent's values:
Condition - The condition field holds one or more YAML paths
(delimited by commas). If this path exists in the top parent’s values
and resolves to a boolean value, the chart will be enabled or disabled
based on that boolean value
Take a look at the conditions in requirements.yaml from stable/elastic-stack:
- name: elasticsearch
version: ^1.17.0
repository: https://kubernetes-charts.storage.googleapis.com/
condition: elasticsearch.enabled
- name: kibana
version: ^1.1.0
repository: https://kubernetes-charts.storage.googleapis.com/
condition: kibana.enabled
- name: logstash
version: ^1.2.1
repository: https://kubernetes-charts.storage.googleapis.com/
condition: logstash.enabled
The conditions paths are elasticsearch.enabled, kibana.enabled and logstash.enabled, so you need to use them in your parent chart values.
Those properties in parent values.yaml serve as switch for the subcharts.
You are suppose to use condition in your requirements.yaml to control the installation or execution of your dependent subcharts. If not provided then helm simply proceeds to deploy the subchart without and problem.
And also, those values are in parent's values.yaml because they are being used in the parent chart itself and moreover cannot be used inside the subchart unless provided as global or within the subchart's name property key (which is in your case elastic-stack).