4 ms·

This is exactly the pattern that we are experimenting with. Glad to see that we're not alone in thinking that this is much better than the centralized chart rep

This is exactly the pattern that we are experimenting with. Glad to see that we're not alone in thinking that this is much better than the centralized chart repo way. This does mean that we're only using a small portion of Helm, and I wonder if a simpler tool wouldn't work just as well. All you need is templating, really.

Snappy 10y ago
You're not alone and it's great to see others thinking this way. We're looking at making it easier for people to bring-your-own-helm-chart[1] and have GitLab deploy it. There's value in keeping the chart in the project repo, and there's value in decoupling the chart and putting in a different repo. I'm fascinated to see which becomes best practice. [1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/29969 https://gitlab.com/gitlab-org/gitlab-ce/issues/29969
- lobster_johnson 10y ago
  We considered keeping all the charts together in one repo. But it's just simpler for developers. I can't say I'm thrilled to put deployment-specific values in the repo. Maybe the solution is to keep the chart itself, with its defaults, in the repo, and then have a configmap or third-party resource in Kubernetes that contains the values. To deploy anything, you use the Kubernetes API to find the app's values and merge them into the template. I wouldn't be surprised if one day Kubernetes might support that kind of templating. I also wonder what kind of system Google uses internally. They have been rather silent about offering good advice here.
  - Snappy 10y ago
    I hope eventually you can use environment-specific variables[1] in GitLab to manage your deploy variables. [1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20367 https://gitlab.com/gitlab-org/gitlab-ce/issues/20367
- deleted 10y ago
  [deleted]
lachie83 10y ago
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 10y 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 10y ago

Snappy 10y ago

You're not alone and it's great to see others thinking this way. We're looking at making it easier for people to bring-your-own-helm-chart[1] and have GitLab deploy it. There's value in keeping the chart in the project repo, and there's value in decoupling the chart and putting in a different repo. I'm fascinated to see which becomes best practice. [1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/29969 https://gitlab.com/gitlab-org/gitlab-ce/issues/29969

lobster_johnson 10y ago
We considered keeping all the charts together in one repo. But it's just simpler for developers. I can't say I'm thrilled to put deployment-specific values in the repo. Maybe the solution is to keep the chart itself, with its defaults, in the repo, and then have a configmap or third-party resource in Kubernetes that contains the values. To deploy anything, you use the Kubernetes API to find the app's values and merge them into the template. I wouldn't be surprised if one day Kubernetes might support that kind of templating. I also wonder what kind of system Google uses internally. They have been rather silent about offering good advice here.
- Snappy 10y ago
  I hope eventually you can use environment-specific variables[1] in GitLab to manage your deploy variables. [1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20367 https://gitlab.com/gitlab-org/gitlab-ce/issues/20367
deleted 10y ago
[deleted]

lachie83 10y ago

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 10y 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 10y ago