[linkmotif]

Yeah it’s not the best docs. But the tool is great.

Helm just renders a bunch of templates of kubernetes manifests against a values file. It then takes the resulting manifests, compares them to what’s running on your cluster and makes sure nothing less or more is running. That’s it. What’s nice about it is that you can then change the manifest templates or values files, and when you install the updated result, you have a single concrete new state that your entire application is in. Which makes it easy to version your entire application, whether you changed just one env var in one manifest or made many changes thoughout.

There’s a package manager component but you can skip that completely and imo it’s just confusing that they lead front and center with that component.

The essential commands are helm ls and helm upgrade. And helm rollback is nice too.

[bogomipz]

Thank you for this. This is helpful.

So its kind of like configuration management for your manifests then? Would that also be an accurate analogy?

[linkmotif]

Great to hear.

> So its kind of like configuration management for your manifests then?

Basically, yep.

Which is why, for example, it makes it easy to deploy staging environments. Instead of writing your manifests are the final finished product, you set up your manifests to be interpolatable templates. Then you can deploy your application one way to your production environment, but then staging another way (different env vars, different replicas, different anything, but still the same app).

The whole package management/sharing of charts thing falls out as a result of this, but I've yet to find this useful. I don't pay attention to my chart's version number (it's always 1.0), but instead aggregate all the tags for each image I need throughout my manifest templates in the values file. Then when I upgrade my helm release to deploy those latest tags, helm provides me with a monotonically increasing integer for the resultant release. I can always point to this integer and ask, "what manifests were running at this release?"

[ecnahc515]

Similar. The reason they say "package manager" rather than "configuration management" for your manifests is because it's actually much more about packaging than it is config management.

The chart packaging format and template language don't allow you to easily encapsulate or abstract away your dependent charts, it's really just a simple package which you can use as-is, but not really possible "tweak" or "extend" charts without forking them. Contrasted this to a CM system which typically make it possible to build new modules/cookbooks/recipes/whatever on top of others, with the possibility to hide away the details of the underlying module/recipe/etc.

It's really just tarballs with yaml templates and a way to specify values for the templates.

[linkmotif]

I have yet to appreciate with the whole tarball/package thing.

My application is 5-6 deployments, a 3 statefulset and a cron job. I have it all in one chart that I keep unpackaged on in a directory. The workflow is (i) update the templates/values, (ii) ensure necessary containers live on GCR, `helm upgrade` my application. And that's it.

I've yet to find a need for breaking this single chart into multiple charts with dependencies. Maybe once it gets much, much bigger? I also don't like the idea of pulling in third party charts as dependencies, even if they're public from github. This last point is probably irrational and me-specific, but something about it is less appealing than just copy/pasting the manifests I want into my project. So much more direct.

[bogomipz]

Thanks, this really helps to intuit the project's documentation for me. Cheers.