Hey guys! One question related to Helm - we are cu...
# general
p
Hey guys! One question related to Helm - we are currently transitioning to K8s and we have decided to use Helm. We have around 30 microservices currently and I would really like to not have 30 (very similar) Helm charts for each of them. I read about subcharts, but they need to be standalone, so not sure if we will be getting many benefits for using them. Would be grateful if someone with experience in this topic could point me in the right direction 🙂
j
Hu Predrag, if those microservises are very similar, I would go with creation of one universal helmchart, with witch you are able to deploy each microsrvice, prividing specific values 🙂
p
hi Jaroslav! how do i do this exactly? how would I keep the versioning of services? I can provide values with -f … but didn’t find a way to provide the Chart.yaml to helm install command
j
Hi Predrag. It depends on your situation and requirements. If those microservices are internal ones and are part of one solution which is not OSS then you dont have to bother with helmchart versioning in chart.yaml because you version only microservices docker image. Helmchart can be generic. Lets imagine a situation you have 10 backend microservices - very similar in configuraiton and deplyment. Then you can have one helmchart called eg. <company_name_for_instance>_backend. and using this helmchart you do particular deployments/releases of individual microsevice where each release name reflect microservice name and consume its dedicated values-<microservice_name>.yaml from outside. (common default values could be integrated in generic values.yaml in the helm chart). In this situation you can omit Char.yaml versioning having dedicated for each microservice
s
@Predrag Despotovic https://timoni.sh/ You can also take a look at it as a potential helm replacement if your use case is complex, it's base on cue lang vs yaml, setting this up might be complex as this is a bit new, but using can extend it to advance use cases, also added a video here, describing when to consider over helm

https://www.youtube.com/watch?v=bbE1BFCs548

d
https://github.com/clouddrove/helmchart use this repo to deploy your application using helm chart.. these helm chart content all type of object deployment which doesn’t come up with default helm chart.
p
hey @Deepak Verma, not sure how this helps, this is a single chart if I understand it correctly
@Jaroslav Vojtekthanks for the advice, this sounds great! Could you give me an example when helmchart versioning is important?
j
Hi @Predrag Despotovic, Helm Chart version is required and important. you version your helm chart templates based on the changes in the helm chart following semantic versioning. But this
version
does not reflect any microservice/applications version, it has its own independent versioning cycle. Besides of this version you can have
appVersion
specified in the Chart.yaml. But this field is optional and you are free to use it whenever it makes sense to use it. For instance, when you develop some OSS application for which you provides helm chart for the deployments, then it is good practice to specify
version
and
appVersion
in the Chart.yaml. Or when you have dedicated helm chart per application/microservice. But on the other hand when you create a generic helm chart for backend microservices then it does not make sense to specify
appVersion
. Only
version
is required to reflect changes in the generic backend helm chart. Hopefully you will find this helpful.
p
thank you very much for the detailed explanation and taking the time! much clearer now :)