|
|
|
|
|
|
by ecnahc515
3110 days ago
|
|
|
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. |
|
|
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.