#helm (2020-05)

Archive: https://archive.sweetops.com/helm/

2020-05-20

Andrey Nazarov avatar
Andrey Nazarov

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:)

Zachary Loeber avatar
Zachary Loeber

This may be a good topic for todays office hours

Zachary Loeber avatar
Zachary Loeber

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)

Zachary Loeber avatar
Zachary Loeber

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.

Zachary Loeber avatar
Zachary Loeber

(though I may not be understanding your question entirely, if so sorry)

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

yea, @Andrey Nazarov hope you can join us for #office-hours today

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

would be a great topic

Andrey Nazarov avatar
Andrey Nazarov

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?

Zachary Loeber avatar
Zachary Loeber

I’m still writing on this one as it is a deeper subject than I initially thought it would be

2020-05-12

btai avatar

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

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

We use the single chart repo more or less out of convention by the Helm community.

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

IMO the helm community should have adopted the terraform module approach of one repo per chart, but alas, that’s not convention.

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

We use helmfile with the helm-git provider so we do not need to manage a helm chart repo

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

(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)

btai avatar

@Erik Osterman (Cloud Posse) how are you guys avoiding building an upstream helm charts even with helmfile?

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

upstream? we can point to github too

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)
cloudposse/helmfiles

Comprehensive Distribution of Helmfiles for Kubernetes - cloudposse/helmfiles

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)
aslafy-z/helm-git

Helm plugin to fetch charts from Git repositories. Contribute to aslafy-z/helm-git development by creating an account on GitHub.

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

@zadkiel.aharonian is the maintainer

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

helmfile + helm + helm-git is a great combo

btai avatar

@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)

stakater/Forecastle

Forecastle is a control panel which dynamically discovers and provides a launchpad to access applications deployed on Kubernetes – [✩Star] if you’re using it! - stakater/Forecastle

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

We use this for private charts too

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

And sometimes we import the charts to the repo and configure Helmfile with relative paths

btai avatar

do you have ci around those chart git repos? to push to a chart package repository or auto-increment the chart.yaml versions

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

You don’t need to have a chart package :-)

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

No artifacts required

btai avatar

oh

btai avatar

so you can avoid having like a hosted helm repo?

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Yup

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

None of our customers have a hosted repo

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Yet all of them use helm

btai avatar

hows the development cycle like when you are making modifcations to the private helm chart?

btai avatar
  1. make a change to the chart
  2. point helmfile to new chart version i.e 1.1.1-dev
Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Point Helmfile to git sha

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

The versions in the chart then become informational only

btai avatar

@Erik Osterman (Cloud Posse) whoa

btai avatar

o.o

    keyboard_arrow_up