#helmfile (2022-05)

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.

So you want pods to recreate when you do helm upgrade? Can you check UpgradeStrategy value in values.yaml. If it is OnDelete then change it to RollingUpdate. That should be able to recreate the pod with each helm upgrade

oh well let me check what’s going on… but my intention is that roboll/helmfile will ever have new releases anymore, and it’s never intended to go ahead of helmfile/helmfile

Ok, if I use curl I can download version 0.144.0 of helmfile/helmfile

But somehow it’s not presented in tags.

im a little confused but we have never replicated any releases in roboll/helmfile into helmfile/helmfile so if you’re trying to download any release assets from helmfile/helmfile, it won’t work(as they are inexistent

I don’t think that roboll/helmfile went ahead of helmfile/helmfile. It’s just some issue with a few later tags

and we’ve never released anything since our move to helmfile/helmfile. so once we cut a new release(it’s very likely to be 0.145.0), you’ll see it in helmfile/helmfile, but not in roboll/helmfiel

before that, you’ll see no releases in helmfile/helmfile.

And I’m curious what the release policy would be for helmfile/helmfile

haven’t decided yet. i tend to release very often but nowadays other maintainers are very active and adds many fixes in a short period so i missed the timing to cut a release..

re: releases in helmfile/helmfile- i have not planned to replicate historical releases to helmfile/helmfile. do you need it?

re: releases in helmfile/helmfile- i have not planned to replicate historical releases to helmfile/helmfile. do you need it? No, just curious:) We are switching repos in our build scripts. We can wait for the newer release of helmfile/helmile. It’s not a problem)

gotcha, thanks for clarification!

Jumping in, but isn’t it a good time to start with 1.0.0 ? I see a repeatable pattern when people deliberately avoid adopting/assessing helmfile because the version is zero something and the README says early stage of development.

Agree. We’ve been using helmfile for more that 3 years already. In production for almost 3 and consider it quite stable and reliable.

I thought we had a few issues that might result in breaking changes which will be super difficult to introduce after v1 but yeah… perhaps we can give up at mark it v1

https://github.com/roboll/helmfile/issues/1806

hm, maybe the only breaking change listed there would be https://github.com/roboll/helmfile/issues/688

Well, the version is a minor issue - but what about just removing from README

> Even though Helmfile is used in production environments across multiple organizations, it is still in its early stage of development, hence versioned 0.x.

that’s indeed a good idea! what if it looked like

“Even though Helmfile is versioned pre-1.0, it’s already used in production environments across multiple organizations for more than 3 years. We’ev made only a few breaking changes so far and there’s only 1 planned minor breaking change today..”

Much better IMO

If the FQDN is set as an environment variable you should be able to use that in your helm chart. Otherwise, you would have to set it as an env var before installing the chart

We have been making progress on that https://helmfile.readthedocs.io/en/latest/

We welcome suggestions and contributions

what kind of explanation do you need ? step by step installation guide ?

What it functionally does and why you might want helm and helmfile.

https://kubernetes.slack.com/archives/C0NH30761

You can do it with toYaml function

Thanks Andrew.

Hmm wrong channel, asking in #kubernetes

I use the raw chart for this, but its not super ideal.

this sounds like an Interview question

indeed

Actually I know few scenarios like 1. defining multiple helm file (each per environment) 2.defining environments in a single helm file (conditionally call values.yaml based on env) 3.define single helm file with all the releases required for different env(not a good practice ) . In all of this approaches we need to use 33 values.yaml file (based on each service). Looking for any better alternatives available

You can have only one values.yaml file per environment if you have all releases defined in one helmfile and utilise the environments: feature. It depends. Helmfile is not that opinionated, there are many ways to do things and a lot of flexibility even if you find it lacks some functionality.

you mean one values.yaml per microservice ?

or one values.yaml for all the microservices?

or one values.yaml for all the microservices? this

ture?

fix

Wouldn’t it just be:

helmfiles:
{{- if .Values.enable_test_secret }}
  - path: releases/-secrets/helmfile.yaml
{{- end }}

Yep. AFAIK.

{{- if (.Values | get "enable_test_secret" true) }}

get here might be useful when you don’t have a key defined in values and you can set the default value if it’s not defined.

@Andrew Nazarov Thanks very much.

you can template wih helmfile template but that won’t check the diff between local and installed… we use diff helm plugin to get the difference with helmfile diff. is that what you are looking for?

So i have migrations and test dataset

migration can apply on each release

but dataset could be used just on first install

so for example if migration release doesn’t exists values.args: dataset will be used, if it’s an update values.args: migration will be used

So i just write helmfile apply

and if release already installed it just skips\

Release.IsInstall

my solution

we do this with diff helm plugin… everytime if you run an apply then it will check and look for changes. if it change then deploy the modification if not changed, then skip that part.

@Balazs Varga can you share example?

<.Release.Revision>: can’t evaluate field Revision in type state.releaseTemplateDataRelease