I have a Helm/Kubernetes deployment with the following structure:
mainchart
|- subchart1
| |- database
|- subchart2
...
So, database is a subchart of subchart1; no other subchart contains database.
In subchart1, Chart.yaml says:
dependencies:
- name: database
version: "*"
condition: global.owndb
and Values.yaml says:
global:
owndb: false
Also, in mainchart, Values.yaml says:
global:
owndb: false
When I run "helm install", I supposed the database chart was not deployed. It gets deployed all the times, instead.
Any idea of why it's behaving like this? I'm using helm v3.6.3
Related
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.
i'm triyng to do one Helm Chart for different environments. In many tutorials such scheme should works, but my structure does not read value from dependency repository. Helm just ignores it.
I have following folder structure
helm
- charts
- core-web
- Chart.yaml
- values.yaml
- templates
- frontend
- Chart.yaml
- values.yaml
- templates
- prod
- Chart.yaml
- values.yaml
- dev
- Chart.yaml
- values.yaml
prod/Chart.yaml
apiVersion: v1
name: test
version: 1.0.0
dependencies:
- name: core-web
version: "1.37.0"
repository: file://../charts/core-web/
- name: frontend
version: "1.6.0"
repository: "file://../charts/frontend"
From helm folder i execute following command
helm install ./prod --dry-run --generate-name -n sandbox -f prod/values.yaml
Error: INSTALLATION FAILED: found in Chart.yaml, but missing in charts/ directory: core-web, frontend
If i move charts forlder to prod folder, then everithing works.
Why helm does not accept file path from dependency repository?
It should: https://helm.sh/docs/helm/helm_dependency/
Thanks for the help.
Try to replicate the issue, seems like a cache issue
you can verify that helm dependency on which path it's looking for charts.
helm template test ./prod
#output Error: found in Chart.yaml, but missing in charts/ directory: backend, web-app
then I tried to verify the path on which the helm looking
helm dep ls ./prod
from the output its clear it's still looking into the wrong path with the status missing as its still looking for chart inside prod folder.
NAME VERSION REPOSITORY STATUS
backend 1.2.3 file://charts/backend/ missing
web-app 1.2.3 file://charts/web-app/ missing
so to fix this
helm dependency update ./prod
then I can see
helm dep ls ./prod
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
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.
I am new to this group. Glad to have connected.
I am wondering if someone has experience in using an umbrella helm chart in a CI/CD process?
In our project, we have 2 separate developer contractors. Each contractor is responsible for specific microservices.
We are using Harbor as our repository for charts and accompanying container images and GitLab for our code repo and CI/CD orchestrator...via GitLab runners.
The plan is to use an umbrella chart to deploy all approx 60 microservices as one system.
I am interested in hearing from any groups that have taken a similar approach and how they treated/handled the umbrella chart in their CI/CD process.
Thank you for any input/guidance.
VR,
We use similar kind of pattern where we have 30+ microservices.
We have got a Github repo for base-charts.
The base-microservice chart has all sorts of kubernetes templates (like HPA,ConfigMap,Secrets,Deployment,Service,Ingress etc) ,each having the option to be enabled or disabled.
Note- The base chart can even contain other charts too
eg. This base-chart has a dependency of nginx-ingress chart:
apiVersion: v2
name: base-microservice
description: A base helm chart for deploying a microservice in Kubernetes
type: application
version: 0.1.6
appVersion: 1
dependencies:
- name: nginx-ingress
version: "~1.39.1"
repository: "alias:stable"
condition: nginx-ingress.enabled
Below is an example template for secrets.yaml template:
{{- if .Values.secrets.enabled -}}
apiVersion: v1
kind: Secret
metadata:
name: {{ include "base-microservice.fullname" . }}
type: Opaque
data:
{{- toYaml .Values.secrets.data | nindent 2}}
{{- end}}
Now when commit happens in this base-charts repo, as part of CI process, (along with other things) we do
Check if Helm index already exists in charts repository
If exists, then download the existing index and merge currently generated index with existing one -> helm repo index --merge oldindex/index.yaml .
If it does not exist, then we create new Helm index ->( helm repo index . ) Then upload the archived charts and index yaml to our charts repository.
Now in each of our microservice, we have a charts directory , inside which we have 2 files only:
Chart.yaml
values.yaml
Directory structure of a sample microservice:
The Chart.yaml for this microservice A looks like:
apiVersion: v2
name: my-service-A
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: 1
dependencies:
- name: base-microservice
version: "0.1.6"
repository: "alias:azure"
And the values.yaml for this microservice A has those values which need to be overriden for the base-microservice values.
eg.
base-microservice:
nameOverride: my-service-A
image:
repository: myDockerRepo/my-service-A
resources:
limits:
cpu: 1000m
memory: 1024Mi
requests:
cpu: 300m
memory: 500Mi
probe:
initialDelaySeconds: 120
nginx-ingress:
enabled: true
ingress:
enabled: true
Now while doing Continuous Deployment of this microservice, we have these steps (among others):
Fetch helm dependencies (helm dependency update ./charts/my-service-A)
Deploy my release to kubernetes (helm upgrade --install my-service-a ./charts/my-service-A)