5 ms·

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

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.

mstrzele 9y ago
I agree, but for me, Helm releases give the ability to track changes in configuration of my apps (you can see the history and roll back if something is wrong)
yebyen 9y ago
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.)
- jzelinskie 9y ago
  >I have always wondered about the decision to put all of the charts into a single "Kubernetes/charts" repo. There's discussion happening right now among the Charts maintainers about changing this. If you're interested you can join the conversation in #charts on the Kubernetes slack. Full Disclosure: I'm an author of App Registry which is a project that attempts to integrate projects like Helm with registries like Quay on a multiple-repository basis.
  - yebyen 9y ago
    Thanks! I will stop by and check it out, I'm already on this slack too.
- lobster_johnson 9y ago
  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?
ianburrell 9y ago
Helm has separation between charts and templates, and releases and values. The former should always be version controlled and deployed like code. The latter are local to cluster. They can be version controlled but then need tool to sync with the cluster. It looks like this is a tool for editing data on cluster. Which is something that helm currently makes hard cause need to dump current values, edit them locally, and update with changes.
guslees 9y ago
If you (and others on this sub-thread) like managing kubernetes through version control, I humbly suggest trying out the ksonnet/kubecfg toolchain (https://github.com/ksonnet/kubecfg https://github.com/ksonnet/kubecfg and the closely related ksonnet/ksonnet-lib repo - Disclaimer: I'm one of the contributors). Helm is nice, but (imo, and as some of the comments here are also pointing out) oriented more towards consuming 3rd-party pre-built charts from some sort of centralised marketplace/repo. (This is an important use case, and yes I know it is certainly possible to use helm to manage your own internal software too.)

mstrzele 9y ago

I agree, but for me, Helm releases give the ability to track changes in configuration of my apps (you can see the history and roll back if something is wrong)

yebyen 9y ago

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

jzelinskie 9y ago
>I have always wondered about the decision to put all of the charts into a single "Kubernetes/charts" repo. There's discussion happening right now among the Charts maintainers about changing this. If you're interested you can join the conversation in #charts on the Kubernetes slack. Full Disclosure: I'm an author of App Registry which is a project that attempts to integrate projects like Helm with registries like Quay on a multiple-repository basis.
- yebyen 9y ago
  Thanks! I will stop by and check it out, I'm already on this slack too.
lobster_johnson 9y ago
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?

ianburrell 9y ago

Helm has separation between charts and templates, and releases and values. The former should always be version controlled and deployed like code. The latter are local to cluster. They can be version controlled but then need tool to sync with the cluster. It looks like this is a tool for editing data on cluster. Which is something that helm currently makes hard cause need to dump current values, edit them locally, and update with changes.

guslees 9y ago

If you (and others on this sub-thread) like managing kubernetes through version control, I humbly suggest trying out the ksonnet/kubecfg toolchain (https://github.com/ksonnet/kubecfg https://github.com/ksonnet/kubecfg and the closely related ksonnet/ksonnet-lib repo - Disclaimer: I'm one of the contributors). Helm is nice, but (imo, and as some of the comments here are also pointing out) oriented more towards consuming 3rd-party pre-built charts from some sort of centralised marketplace/repo. (This is an important use case, and yes I know it is certainly possible to use helm to manage your own internal software too.)