3 ms·

Templating is a good start, here are a few other things of value that Helm provides in this context. Release management, upgrade/rollback. Dependency management

Templating is a good start, here are a few other things of value that Helm provides in this context. Release management, upgrade/rollback. Dependency management and the ability to create common charts and byo containers, the testing framework to test deployments on Kubernetes. I recently did a session at KubeCon about all these uses cases at KubeCon if you're interested in taking a look. https://youtu.be/cZ1S2Gp47ng https://youtu.be/cZ1S2Gp47ng Happy to chat more if you're interested.

lobster_johnson 9y ago
Release management is desirable, but Helm's version-number-oriented release management is a bad match for Kubernetes and git. We don't deal with versions; we use commit IDs, and we use Github. I also don't understand why Helm requires "packaging" and "publishing" anything into a repo. If I commit the chart files to a Github repo, why can't Helm just go there and get them? I shouldn't need to run an HTTP server to serve some kind of special index. Git is a file server. What I do like is the idea of Helm as a high-level deployment manager. Kubernetes deployments have nice rollback functionality, but you can't roll back multiple changes to things like configmaps and services, which I think Helm does? But Helm still wants those numbered versions... In my opinion, Helm ought to ditch the "package management for Kubernetes" approach, and instead focus on deployment. Right now it feels like it's straddling the line between the two, and coming up short because of that. Perhaps what I want should be a separate tool. Edit: Two more things: First, I don't like how Helm abuses the term "release". To me, and also the rest of the world, a release is a specific version of an app. You upgrade to a release, you don't upgrade a release. I think you should rename this to something like "deployment", "installation", "instance", "target" or similarly neutral. Also, I have to say that templating ends up being a bit boilerplatey. There are things you typically want parameterized across all apps — things like the image name/tag, image pull policy, resources, ports, volumes, etc. The fact that every single chart has to invent its own parameters for this — which means your org has to find a way to standardize them across all apps — isn't so cool. Edit: One more thing: Release names seem to be global across namespaces. That very much violates the point of namespaces. Name spaces. :-)
- Snappy 9y ago
  You don't have to publish the chart. Installing from a directory in a GitHub repo works fine.
  - lobster_johnson 9y ago
    But then you don't get dependency tracking, and you also have to clone the repo to install it, instead of something like "helm install github.com/foo/bar#e367f6d".
  - canes123456 9y ago
    Really? I started playing around with and it not clear how to do this with helm.
    - Snappy 9y ago
      `helm install path/to/chart/directory`
    - Snappy 9y ago
      Ah, I think I understand the confusion now. I guess you're wanting to do something like `helm install https://github.com/some/url` https://github.com/some/url` and that doesn't work. But I was assuming you were consuming the chart in the same repo, or including it via a submodule, such that the chart would be a local file reference. Sorry for the confusion! To use a URL, I think you'd either have to push up the packaged chart as a .gzip file in your repo (which is annoying), or you'd have to package up the chart and create a GitHub release with the resulting gzip file to be able to reference it that way. In GitLab you might be able to point to a pipeline artifact[0] after packaging the chart using GitLab CI. In one experimental project[1], I'm using GitLab Pages to package and publish the index. It works out surprisingly well, but has some shortcomings. [0]: https://docs.gitlab.com/ce/user/project/pipelines/job_artifacts.html#downloading-the-latest-job-artifacts https://docs.gitlab.com/ce/user/project/pipelines/job_artifa... [1]: https://gitlab.com/charts/charts.gitlab.io https://gitlab.com/charts/charts.gitlab.io

lobster_johnson 9y ago

Release management is desirable, but Helm's version-number-oriented release management is a bad match for Kubernetes and git. We don't deal with versions; we use commit IDs, and we use Github. I also don't understand why Helm requires "packaging" and "publishing" anything into a repo. If I commit the chart files to a Github repo, why can't Helm just go there and get them? I shouldn't need to run an HTTP server to serve some kind of special index. Git is a file server. What I do like is the idea of Helm as a high-level deployment manager. Kubernetes deployments have nice rollback functionality, but you can't roll back multiple changes to things like configmaps and services, which I think Helm does? But Helm still wants those numbered versions... In my opinion, Helm ought to ditch the "package management for Kubernetes" approach, and instead focus on deployment. Right now it feels like it's straddling the line between the two, and coming up short because of that. Perhaps what I want should be a separate tool. Edit: Two more things: First, I don't like how Helm abuses the term "release". To me, and also the rest of the world, a release is a specific version of an app. You upgrade to a release, you don't upgrade a release. I think you should rename this to something like "deployment", "installation", "instance", "target" or similarly neutral. Also, I have to say that templating ends up being a bit boilerplatey. There are things you typically want parameterized across all apps — things like the image name/tag, image pull policy, resources, ports, volumes, etc. The fact that every single chart has to invent its own parameters for this — which means your org has to find a way to standardize them across all apps — isn't so cool. Edit: One more thing: Release names seem to be global across namespaces. That very much violates the point of namespaces. Name spaces. :-)

Snappy 9y ago
You don't have to publish the chart. Installing from a directory in a GitHub repo works fine.
- lobster_johnson 9y ago
  But then you don't get dependency tracking, and you also have to clone the repo to install it, instead of something like "helm install github.com/foo/bar#e367f6d".
- canes123456 9y ago
  Really? I started playing around with and it not clear how to do this with helm.
  - Snappy 9y ago
    `helm install path/to/chart/directory`
  - Snappy 9y ago
    Ah, I think I understand the confusion now. I guess you're wanting to do something like `helm install https://github.com/some/url` https://github.com/some/url` and that doesn't work. But I was assuming you were consuming the chart in the same repo, or including it via a submodule, such that the chart would be a local file reference. Sorry for the confusion! To use a URL, I think you'd either have to push up the packaged chart as a .gzip file in your repo (which is annoying), or you'd have to package up the chart and create a GitHub release with the resulting gzip file to be able to reference it that way. In GitLab you might be able to point to a pipeline artifact[0] after packaging the chart using GitLab CI. In one experimental project[1], I'm using GitLab Pages to package and publish the index. It works out surprisingly well, but has some shortcomings. [0]: https://docs.gitlab.com/ce/user/project/pipelines/job_artifacts.html#downloading-the-latest-job-artifacts https://docs.gitlab.com/ce/user/project/pipelines/job_artifa... [1]: https://gitlab.com/charts/charts.gitlab.io https://gitlab.com/charts/charts.gitlab.io