What is the best practice for overriding values in helm subcharts on a per-cluster basis?

user_221001 0
Viewed 5454

First, a little context: I have 4 Kubernetes clusters, one for each environment (develop, staging, testing, prod). Each cluster has its own values.yaml file with env-specific configuration of all helm charts that we've written.

So, when our CD pipeline deploys mychart to the develop cluster, it essentially does the following:

helm install -f base-values.yaml -f develop-values.yaml ./mychart.tgz

Now, let's presume mychart has a requirements.yaml file which specifies the mongodb chart as a subchart dependency. The mongodb chart references, for example, .Values.mongodbRootPassword. When included as a subchart by mychart, I can set .Values.mongodb.mongodbRootPassword in mychart's default values.yaml to change this value.

My problem is that given my current CD pipeline, if I set .Values.mongodb.mongodbRootPassword in develop-values.yaml, it will be taken for all mongodb instances that are deployed to the develop cluster - not just mychart's.

So, my questions:

  • using per-environment values.yaml files, how would I go about setting mychart's mongodb's root password in one of the cluster-specific values.yaml files?
  • is this even possible? Or is my current CD approach (per-environment values files) an anti-pattern?
  • if this is not possible or an anti-pattern, how would you go about setting the values of helm individual charts and subcharts on a per-environment basis?
continuous-deployment kubernetes-helm kubernetes configuration-management
2 Answers
  • using per-environment values.yaml files, how would I go about setting mychart's mongodb's root password in one of the cluster-specific values.yaml files?

You can override YAML files with --set option from install

Example:

helm install -f base-values.yaml -f develop-values.yaml --set someSection.someValue=1234 ./mychart.tgz

Then, you can set CI command call with environment settings and have just one YAML.

  • is this even possible? Or is my current CD approach (per-environment values files) an anti-pattern?

Nope, that's a feature :-)

  • if this is not possible or an anti-pattern, how would you go about setting the values of helm individual charts and subcharts on a per-environment basis?

It would be nice also. Perhaps, if your infrastructure grow fast and you have a lot of environments, apps or else, this could be better to manage.

user_8413390

I created a named template (within _helpers.tpl) that combined a set of default values defined in values.yaml with a set of env specific values defined in their own file. This allows me to set 20+ default values and then override them with the env file WITHOUT setting them as part of the cli command. I wanted to avoid using the cli to override values because that gets complicated and doesn't provide tracking (ie my env specific files are in git).

user_61581940
Related