Best practices for managing multiple environments with Helm

6/14/2019

It is unclear to me what the best practices are for managing an application with multiple environments, that shares templated files but has different variables per environment. For example, we deploy a develop, staging and production environment. They use the same helm templates, but I have different variables for each environment.

Current File Structure:

helm/
  ├── templates/
  │   ├── _helpers.tpl
  │   ├── deploy.yaml
  │   └── ingress.yaml
  │   └── service.yaml
  │   └── managed-certs.yaml
  │   └── NOTES.txt
  ├── Chart.yaml
  ├── values-production.yaml
  ├── values-staging.yaml
  ├── values-develop.yaml

Right now I have two different value files for each environment, and I pass the following to helm helm install . --values=values-production.yaml

However we are unable to correctly manage versioning with the above.

I cannot find any solid documentation on what best practices are for managing multiple environments for an application. I came across helmfile which seems to tack this, but their documentation is unclear. The ecosystem for managing kubernetes is perplexing, any help appreciated.

-- theartofbeing
google-kubernetes-engine
helmfile
kubernetes-helm

1 Answer

6/14/2019

Weave Flux is a great way to handle versioning of both your image and charts. It uses a gitops based approach where everything is managed through updates to your code repository (for chart versioning) or image repository (for application versioning).

Weave Flux: https://github.com/weaveworks/flux

Gitops discussion on Weaveworks site: https://www.weave.works/technologies/gitops/

Example implementation using helm and multiple environments: https://github.com/stefanprodan/gitops-helm/blob/master/README.md

-- frankd
Source: StackOverflow