#helm (2020-05)
Archive: https://archive.sweetops.com/helm/
2020-05-12
those of you maintaining your own helm charts, do you use a single helm charts git repo or a git repo per helm chart? Also how are you testing/making changes your charts before they become stable? Do you have a dev helm package repo? And how are you integrating chart version upgrade automation
We use the single chart repo more or less out of convention by the Helm community.
IMO the helm community should have adopted the terraform module approach of one repo per chart, but alas, that’s not convention.
We use helmfile with the helm-git provider so we do not need to manage a helm chart repo
(although cloudposse does maintain a charts repo - that’s something we set up a long time ago. I would look for a managed solution today)
@Erik Osterman (Cloud Posse) how are you guys avoiding building an upstream helm charts even with helmfile?
upstream? we can point to github too
@zadkiel is the maintainer
helmfile + helm + helm-git is a great combo
@Erik Osterman (Cloud Posse) yeah i mean something like https://github.com/stakater/Forecastle/tree/master/deployments/kubernetes/chart/forecastle as an upstream helm chart. which would then be referenced by the helmfile. I was curious how people are managing their “upstream helm charts” that they write themselves (i.e. not an open sourced one)
We use this for private charts too
And sometimes we import the charts to the repo and configure Helmfile with relative paths
do you have ci around those chart git repos? to push to a chart package repository or auto-increment the chart.yaml versions
You don’t need to have a chart package :-)
No artifacts required
oh
so you can avoid having like a hosted helm repo?
Yup
None of our customers have a hosted repo
Yet all of them use helm
hows the development cycle like when you are making modifcations to the private helm chart?
- make a change to the chart
- point helmfile to new chart version i.e
1.1.1-dev
Point Helmfile to git sha
The versions in the chart then become informational only
@Erik Osterman (Cloud Posse) whoa
o.o
2020-05-20
I’ve just watched two weeks old open hours and I would give two thumbs up for monochart concept (never knew I has a name though:). We’ve been following a quite similar approach for about two years so far. Our approach is a bit different in a way that we do write helm charts. We have a common chart treated as an abstract class with all bells and whistles inside that covers 80-90% of use cases, but we still can’t satisfy everybody (since we are a very small team of ops, we just have a lot of other things to do). By writing charts per service (let’s call it a service chart) we allow chart developers to inherit all the components of the common chart plus add everything they need for a certain scenario. Sometimes these are objects that are not in the common chart. Sometimes these are dependencies which they want to make a bundle with. But it’s a matter of a couple of minutes to write a service chart. And yes we use helmfile to manage all of this, but also with helmfile we provide a very narrow interface to users who don’t want to deal with Helm at all and just want to deploy the app to his or her environment.
The question which bothers us sometimes though is what would be a better approach - to create a new object template inside a chart and populate it as a part of a chart or add additional functionality as a dependency to a chart. Say we want to add the possibility to do backups or monitoring. We can a)create a chart with all backup objects and add it to service charts as a dependency or b)add these objects as templates to the common chart and populate a new version of it. Although we really like the flexibility we have we sometimes encounter these questions about better approaches all the time:)
This may be a good topic for todays office hours
I’m working on an article to better articulate the usage of a monochart in an archtype pattern (a term I’m stealing from OOP design)
Generally, my thought process has been to add any and all base functionality to the monochart, then create charts that use it as a dependency to generate the patterns for deployment that may be required for specific projects/teams.
(though I may not be understanding your question entirely, if so sorry)
yea, @Andrew Nazarov hope you can join us for #office-hours today
would be a great topic
I’m afraid I cannot participate, but yes the topic is interesting indeed.
@Zachary Loeber I’d be happy to read your work. Could you please share the link afterwards?
I’m still writing on this one as it is a deeper subject than I initially thought it would be