I'm working on a project that involves 10 microservices and currently, I'm using a single values file in my Helm chart which has everything packed together. I'm looking to separate these into individual values files for each microservice. This would make it much easier for me to identify where to make changes without sifting through one big file. However, I want to install all of them under the same release name. I'm facing a challenge: when I try to upgrade using Helm, the old pods are being deleted and only the pods from the last value file are being installed. I found a way to use helmfile to manage installs and upgrades, but it requires me to merge all the values files into one, which is tedious, especially if I keep adding new microservices. Is there an automated way to handle this without having to manually merge files each time?
3 Answers
Helm allows you to specify multiple values files during installation. You can do this by using the `-f` flag multiple times. For upgrades, you might want to use the `--reuse-values` flag so that it keeps the values you've already applied, and just overrides the ones you want to change. Give that a try and see if it works for your case!
I tried that, but it still deleted the pods. Each value file contains different Docker images, so that might be the issue.
You might want to check out the `valueFiles` parameter in your Helm chart configuration. You can specify them in a list like this:
```yaml
helm:
valueFiles:
- values/service1.yaml
- values/service2.yaml
- ...
```
This could help you manage multiple files more effectively!
Can you clarify how to implement that? I'm not very familiar with the configuration.
A straightforward way is to create separate YAML files for each microservice, like `microservice1.yaml`, `microservice2.yaml`, etc. When you deploy, you can run a command like `helm install microservice1 microservice1 -f microservice1.yaml`. However, if you're updating multiple services in the same namespace, you might run into the problem of deleted pods again.
I tried that, but when I upgrade another microservice using the same release name, the previous ones get deleted.
Thanks for the tip! I'll test that out and let you know how it goes.