
Helm plugin for editing release's values - mstrzele
https://github.com/mstrzele/helm-edit
======
numbsafari
For me, the value of helm is that the templates are something I can commit and
track through source control.

This essentially bypasses that.

I can see how it might be handy in a pinch, or during development, but I'd
rather invest in tooling to ensure I can foster a commit to release rather
than have operators one-offing my cluster.

~~~
yebyen
That's funny, because Helm is actually already keeping a revision history with
Kubernetes primitives (the pods belonging to the old release are scaled down
and Helm marks the ReplicaSet as "superseded", from the prior release, that's
how rollback works.) To begin with I have no doubt there are great reasons to
keep all of that in a formal source control.

I have always wondered about the decision to put all of the charts into a
single "Kubernetes/charts" repo. It seems like it would make a lot of sense to
have a repo for each chart, but then I guess you lose the capability of being
able to pull them all down at once, or quickly update your local copies of
everything in one shot. The charts are extremely small by design, maybe the
overhead of a single git repo per chart was judged to be too much, and the
value of having all the stable charts in one place was considered to be of
greater magnitude.

One common pattern I've seen is to put your charts directly into the
application's source tree (which is certainly under version control.) This is
how Draft sets up a chart. That seems OK to me, it seems very much like the
creators of Helm would like for you to be able to get to work and having
rollback capabilities without creating any (user-facing) dependency on a Git
repository, or necessarily knowing anything about how to use Git or other SCM
tools.

(Draft takes this a step further; if you're using it to the fullest extent,
then it generates a new release in Helm for every FS_NOTIFY as you save your
work.)

~~~
lobster_johnson
This is basically what we're doing: With each app, we put the chart in the
app's repo itself, and we built a wrapper around Helm that performs deploys
for us, using "helm upgrade --install ./k8s" from the file system. Keeping the
chart with the app means it's versioned along with the app.

(It's not a general-purpose wrapper; it's the CLI we use to manage anything
related to our clusters and apps, basically: DNS, secrets, ad-hoc shells etc.)

One of the things this wrapper does is ensure that every deploy is annotated
with metadata — git revision, git branch, git repo, and also who deployed it.
This allows a developer to run a status command to determine what versions of
each app are currently deployed, and also show a log of new commits that
haven't been deployed yet. It also means you can easily see that an app was
deployed from a specific branch, for example.

I think Helm's design is a bit flawed here. It's catering to two different
purposes: One is deploying packaged versions of third-party software (e.g.
PostgreSQL); the other is deploying your own software. There's an inherent
conflict there in that the release process is different. Why can't Helm pull
directly from git and use its revisions as version numbers? It doesn't make
any sense for us to "publish" an app to a "repository" when we _already_ have
git.

Right now, we're basically using Helm as a glorified templating system, and
it's a somewhat buggy one, so we may decide to ditch Helm and use a pure
templating solution instead. I haven't looked at Draft, but seeing as it's
based on Helm, I'm not sure that it can improve on the basic design?

~~~
yebyen
Draft is a very simple tool and it's not just based on Helm, it is using Helm
under the hood.

You will probably not find much use for Draft given the more advanced state of
your tooling. It's been described as "a gateway drug to k8s" because, for the
uninitiated, it simplifies the process of "OK, I want to put my app on K8s,
what now?" – it sets you up with a reasonable default chart, and a dummy
Dockerfile based on what kind of app the Draft logic decides your app is. (Eg.
it's going to recommend ruby:onbuild if you have a Ruby app.)

That might work out of the box, more likely you need to make some changes in
the Dockerfile, but that could very well be all.

It's really more like an advertisement for Deis. It's the "zeroconf" version
of Deis. If you've never heard of Deis, I'll be happy to tell you more about
that; Deis has a builder service/pod and acts as a git repository, so you set
it up as a git remote with the deis commandline tool and 'git push deis' to
prompt a release upgrade. It is more likely what you are probably expecting as
a piece of your CI/CD solution.

For people that aren't already fluent users of git, k8s, helm, charts... Draft
is easier to get started with, and it gives a chance to expose you to all of
those things, without making any of it prerequisite knowledge to spin up your
app on k8s at once.

For literally anyone else, you're going to get a much better experience from
Deis, which is not only out of Beta but long past the 2.0 milestone (when it
moved to K8s from the prior CoreOS/Fleet-based stack.) Deis is installed via
helm, but after that you do not need to use the Helm client. Your apps can use
Procfile-style or Dockerfile for deployments.

The builder is very modern and developed, and as it evolves, it picks up a lot
of efficiencies that you might have seen before on Heroku if you're familiar
with that platform, making it very convenient to work with. (That also means
it brings the baggage of 12-Factor, if you consider that as baggage...)

~~~
yebyen
To be clear, I think that Deis is using helm under the hood too, but you never
have to interact with helm or your chart.

Draft is written so you could probably avoid ever running the helm client, but
it is a much thinner layer of sugar on top. You are very near the helm charts,
but in Deis you might never even realize that there are helm releases
associated with your app. The Deis client interface is pretty fully featured,
almost drop-in as a comparison to heroku client. Using Draft, you are
encouraged to edit your charts, but with Deis it is well-hidden and there is
probably never any need to do that.

Service brokers (for supporting dynamic allocation of things like shared
instances of postgres and redis, like you get with heroku) are a thing, but
they are newer and I have not seen them being used in practice yet.

------
moocowtruck
came expecting something emacs related, saw something weird instead

~~~
secstate
Yes. Helm for a Kubernetes package manager makes things really confusing when
you spend much of your day in Emacs.

------
yebyen
Very nice contribution! I did not even know there was a plugin architecture
for Helm tbh

~~~
majewsky
It has only really become viable a few releases ago. One of my colleagues here
at SAP did a diff plugin for visualizing what's going to happen in the next
upgrade: [https://github.com/databus23/helm-
diff](https://github.com/databus23/helm-diff)

