#helmfile (2022-05)

https://github.com/roboll/helmfile

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

Eric Luria avatar
Eric Luria

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?

bradym avatar

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.

bradym avatar

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

Helm Intellisense - Visual Studio Marketplace

Extension for Visual Studio Code - This extension provides intellisense for helm templates

1
Eric Luria avatar
Eric Luria

very cool, thanks for the insight! and for sharing that extension, that’s really cool

bradym avatar

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.

Eric Luria avatar
Eric Luria

yeah it seems like there is no right way so that’s helpful to hear

Eric Luria avatar
Eric Luria

I’m keeping a separate values file per application, just at the helmfile level rather than the chart level

bradym avatar

helmfile seems to be an interesting mix of “do what you want” and “no, that’s not how you do that thing.”

1
Eric Luria avatar
Eric Luria

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

Eric Luria avatar
Eric Luria

It would be really helpful to have a “common practices” guide for Helm rather than “here ya go, good luck”

1
tim.j.birkett avatar
tim.j.birkett

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

Getting Started

A quick guide on Chart templates.

1
tim.j.birkett avatar
tim.j.birkett

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”.

Eric Luria avatar
Eric Luria

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

tim.j.birkett avatar
tim.j.birkett

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.

FairwindsOps/polaris

Validation of best practices in your Kubernetes clusters

1

2022-05-05

2022-05-06

Jaivarsan B avatar
Jaivarsan B

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

sohaibahmed98 avatar
sohaibahmed98
appvia/tf2helm

Converts a Terraform module to a Helm Chart

    keyboard_arrow_up