patternkubernetesMinor
How is it a good practice to version your helm charts for each deployment?
Viewed 0 times
yourhoweachpracticeversionchartshelmforgooddeployment
Problem
I'm trying to set up a process to release a web app with
Basically each for each push in a feature branch, I want to:
Step 1 is easy, we keep the Dockerfile in the sources, which makes sense because it allows developers to test the docker image and the CI can also build the image and push it automatically.
Step 2: I'm not sure. I was told it could be interesting to keep track of the deployment history and therefore to update the helm chart version for each deployment which seems do-able but I'm not sure I see the point because
Also it forces the CI to actually commit and push the new chart version itself!
My idea was to keep the helm chart in a separate repository with all our charts and to just use keep track of the changes of the chart but nothing to do with any deployments so: the CI could basically build the docker image, push it, clone the helm repository and do the following:
(with APP_VERSION being auto generated and matching the docker build tag)
I haven't seen this approach when reading about it, most people seems to keep their app version up to date in their helm charts and I'm wondering how is that supposed to work for continuous deployment?
helm in my company and I can't find a satisfying way.Basically each for each push in a feature branch, I want to:
- Build a docker image and push it to a registry
- Upgrade the app through
helm
Step 1 is easy, we keep the Dockerfile in the sources, which makes sense because it allows developers to test the docker image and the CI can also build the image and push it automatically.
Step 2: I'm not sure. I was told it could be interesting to keep track of the deployment history and therefore to update the helm chart version for each deployment which seems do-able but I'm not sure I see the point because
helm history already provides the info I guess?Also it forces the CI to actually commit and push the new chart version itself!
My idea was to keep the helm chart in a separate repository with all our charts and to just use keep track of the changes of the chart but nothing to do with any deployments so: the CI could basically build the docker image, push it, clone the helm repository and do the following:
helm upgrade $APP_NAME --set image.tag=$APP_VERSION ./path/to/chart(with APP_VERSION being auto generated and matching the docker build tag)
I haven't seen this approach when reading about it, most people seems to keep their app version up to date in their helm charts and I'm wondering how is that supposed to work for continuous deployment?
Solution
Approach you are describing - where app version is substituted at
Yet another approach that people use is doing
There is no universally accepted approach here among those 3 (1st being updating helm chart itself with new versions every time). So you should decide what works better for your use case.
One thing that is worth mentioning is versioning issue (disclaimer: I'm solving it with Reliza Hub, which I develop). Basically, you need some system which would tell you what version tag of each microservice to actually use on different environments. That problem may become quite complex, especially if you have many microservices and many environments.
helm upgrade command - is pretty popular as well. Maybe it's not well documented - I'm not sure about that.Yet another approach that people use is doing
helm template which would compile everything (including variable resolution) into fixed k8s definitions and then doing GitOps on that.There is no universally accepted approach here among those 3 (1st being updating helm chart itself with new versions every time). So you should decide what works better for your use case.
One thing that is worth mentioning is versioning issue (disclaimer: I'm solving it with Reliza Hub, which I develop). Basically, you need some system which would tell you what version tag of each microservice to actually use on different environments. That problem may become quite complex, especially if you have many microservices and many environments.
Context
StackExchange DevOps Q#11615, answer score: 4
Revisions (0)
No revisions yet.