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
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.
Extension for Visual Studio Code - This extension provides intellisense for helm templates
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.
A quick guide on Chart templates.
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.
Validation of best practices in your Kubernetes clusters
hello new here :wave:
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!