I'm trying to keep my Helm charts clean and suitable for potential public release, avoiding any company-specific logic. Currently, I maintain separate environment-specific values files (like values-dev.yaml, values-prod.yaml) in a different GitOps repository. The downside is that it doesn't scale well; I need these files for every environment, and updates often require changing many strings, especially for hostnames and secret references that include the environment name. I could add an environment variable 'env' to the chart to simplify this, but that would tie my chart down to our setup. How do others manage this issue?
4 Answers
We use a common Helm chart with sensible defaults that most teams in the company follow. Then, each code repository has its own values files for dev, test, and prod to override those defaults.
I have a structure where I keep chart/values/ENV/{values.yaml, secrets.yaml} in my repo, with the main chart/values.yaml declaring all options, setting them to null when no defaults are applicable, like with some secrets. Check out my example here: https://github.com/denibertovic/hellok8s-django.
Consider using templating in values.yaml with 'tpl'. This keeps charts generic while maintaining flexible values.
In our platform engineering team, we maintain a common.yaml or default.yaml file for shared values and then override them with environment-specific files like dev.yaml, prod.yaml, and acc.yaml. All these environment files are kept in the same repository, making it easier to deploy and test across environments using a single pipeline.
But how do you handle the overrides? Are you using Kustomize? I found that it didn't work for me unless I modified the kustomization.yaml, which felt messy.
I was thinking of using templating for values.yaml too, but since we’re using ArgoCD for GitOps, I'm unsure if it supports templating without a custom plugin.