#helmfile (2022-05)
Questions and discussion around helmfile https://github.com/roboll/helmfile and https://github.com/cloudposse/helmfiles
Archive: https://archive.sweetops.com/helmfile/
2022-05-04
I’m using helmfile to install a chart that I’ve written myself. Currently, I keep all of my values files in the same directory as my helmfile.yaml, and the chart itself has no values files (just templates/ and a Chart.yaml ).
Should some of the values live in the helm chart, or does it make sense to keep them all alongside the helmfile like I’m currently doing?
I think it depends on how you’re using the chart. I have a chart we use for deploying a bunch of different apps, and the chart has a values file with default values.
Then I have a folder of values files with a file for each app. In those values files I only stuff that is different from what’s in the chart’s values.yaml file.
I like this approach as it makes it easy to see what things can be customized by looking at the chart’s values.yaml file.
The other thing I like about having a values file in the chart is with this vscode extension I can get autocomplete for stuff in values.yaml.
https://marketplace.visualstudio.com/items?itemName=Tim-Koehler.helm-intellisense
very cool, thanks for the insight! and for sharing that extension, that’s really cool
I don’t claim that the way I’m doing it is the “right way” by any means, just that it’s what we do and it’s working for us.
yeah it seems like there is no right way so that’s helpful to hear
I’m keeping a separate values file per application, just at the helmfile level rather than the chart level
helmfile seems to be an interesting mix of “do what you want” and “no, that’s not how you do that thing.”
yeah. I think the hardest part for me is that
1) helm documentation is so-so 2) a lot of helm’s functionality depends on understanding Go templating, as well as Sprig functions 3) helmfile has a ton of overlap with helm and it’s hard to see the differences and when to use what
It would be really helpful to have a “common practices” guide for Helm rather than “here ya go, good luck”
A chart should generally always have a default values.yaml within it that can be used with tools like helm-docs to document the chart’s interface (how people can use it and override things). All values are easily overridable by passing in your own customisations helm ... -f ... or helm ... --set ... (or values set or loaded in helmfile )- basically aim to be able to helm template your chart with no inputs and get something sensible out.
https://helm.sh/docs/chart_template_guide/getting_started/#charts
Also, if things are simple enough, the raw chart is a good option: https://github.com/helm/charts/tree/master/incubator/raw - although over-use of it, or trying to create an application deployment from it is probably a “smell”.
Thanks @tim.j.birkett! I hadn’t thought of the chart’s values.yaml documenting the interface, which is super important. I also didn’t know about helm-docs so thanks for sharing
No problem I’ve recently been neck deep in YAML and sprig/go templating and implementing lots of things like chart “auditing” with https://github.com/FairwindsOps/polaris and helm unit testing… all good fun… and YAML.
2022-05-05
2022-05-06
hello new here :wave:
so im here particularly seeking a special alternative to helm upgrade --recreate-pods which got removed in helm3. issue
but helmfile seems to be supporting in the helmfile.yaml , example code
recreatePods: true
does that work for helm3 , if yes how?
the source code in pkg/state/state.go is just passing on the flag, and not doing anything else. it won’t work with helm 3 right? it doesn’t when i do from helm3 ‘s cli.
the actual problem im trying to solve is, in case if you can help this directly:
• im creating helm-as-a-service (by wrapping helm3 binary behind a fastapi server), for deployments via API. similar to this and this project, where there’d be frequent need to refresh, soft-restart (graceful replace old with new) the pods by pulling fresh image and doing rollout and no values.yaml changes.
◦ if you thought kubectl rollout restart svc/blah-blah would work, im thinking same. but helm install release chart ‘s release and chart name exactly don’t match the kubectl pod name. also there might be lot of too many pod replicas and pod dependencies as well.
• the best thing i could have is: ◦ 1. helm command for soft-restarting a release (with chart dependencies) ◦ 2. helm command for soft-restarting a release (without chart dependencies). but they don’t exist.
thanks if you read this far!
2022-05-07
