6 ms·

I think Helm is sold short when it's described as apt-get for kubernetes. I think it's probably substantially closer to chef/salt/puppet for k8s, with a little

I think Helm is sold short when it's described as apt-get for kubernetes. I think it's probably substantially closer to chef/salt/puppet for k8s, with a little bit of apt-get in the form of service dependency management. Pulling down the binaries is all handled by docker, but reusing and retooling config files is where Helm's real strength is, IMO. I use Helm on a couple different projects as an integral part of CI/CD for templating config files and Ingress resources. Coupled with a good CI/CD system (I'm using GitLab), Helm templating is pretty critical in my workflow for creating demo applications (one per PR) at some specific endpoint/dns but then after integration, moving the updated code out to multiple DNS endpoints, etc. Congrats to the team, and I look forward to seeing where Helm can go from here!

fredsir 10y ago
Have you written about your setup anywhere? I'm right now working on porting my manifests + kubectl manual k8s workflow to helm+gitlab-ci(to automatically build and push imagines and then deploy to cluster), but I'm only just at the stage of creating the helm charts, so any literature about how to set up a ci to build the Docker images, push them, bump the chart version, deploy to staging environment for every PR and so on is something I'm very interested in.
- andrewstuart2 10y ago
  I haven't, but I've thrown together a gist [1] of the most-relevant configuration. In this case it's a pretty simple static page hosted on an nginx container, but the approach should scale to multiple services if I ever started using proper Helm dependency management. If you have any questions let me know, and I can also comment the gist a bit more as I get time today. Admittedly, I'm probably only using 50% of Helm's capabilities, because I'm primarily interested in its templating abilities rather than managing a centralized repo of apps that can be installed. My current pattern (which I'm still iterating on) is that I have a `chart` directory which contains the Helm chart and templates, and TBH I don't really bother updating the version in `Chart.yaml` because I'm managing it in-repo with git tags, branches, etc. Then my gitlab CI scripts just `--set` a few variables so that the right docker image, DNS, and ingress path values are used for the branch. [1] https://gist.github.com/andrewstuart/8006a6f39ce5cb3fff7211e85c3aec0e https://gist.github.com/andrewstuart/8006a6f39ce5cb3fff7211e...
  - fredsir 10y ago
    Awesome! I will be reading through the gist later today when I get back to working on it. I'm not planning on using all of helm either, and specifically, the whole chart repo feature is something that I don't see myself using at the moment. The workflow I'm envisioning is one where I have a Project-A. Inside Project-A, there is a chart directory containing the project chart, so each project contains their own chart instead of having the charts in a centralised repo. The chart will be used for deployment, but something like versioning will not be bumped manually but instead be bumped by the CI after (if) tests succeeds, at which point a new docker image is built, tagged with a version-bump (or build number) and pushed, and then the chart is updated to use the new docker image and getting it's version bumped (or build number) and then at last deployed to staging environment. There should also be a next step for taking a chart deployed to staging and deploy it to production, but I'm not sure how that should be done yet. I'm also not sure how or what the correct solution is in the case of actually updating the chart in the repo in the CI, or just supplying runtime variables (or what it's called) to helm as you deploy the chart that then overwrites the values hardcoded in the chart, but in any case, I'm envisioning a workflow where you for each PR and version-tag you make to a repo, a new docker image is produced and pushed, and a new chart is produced and deployed, so that you have a complete history of images and chart for each pr and version.
    - bacongobbler 10y ago
      Skimming through the comments here so I apologize if you are already aware of this, but please feel free to drop by in #helm on the Kubernetes Slack channel with any questions there. :)
    - Snappy 10y ago
      Yeah, I'd think you'd want to take advantage of specifying the image tag as a variable rather than committing the image tag back to the repo. Kind of defeats the point of helm to hard code everything. :) Only bump the chart version when the configure itself (outside of the image tag) changes.
      - fredsir 10y ago
- rollulus 10y ago
  We use Helm together with Gitlab's CI as well. To make that process smoother, we built landscaper [1]. It receives a desired state, which is a bunch of yamls. Each yaml contains a chart-reference and values (settings). When landscaper is run during CI, it obtains the actual state (the releases) and either updates, creates or deletes to obtain the desired state. The desired state is under version control, so lately I rarely do any manual k8s work. Creating or updating a deployment is a matter of a pull request. [1]: https://github.com/Eneco/landscaper https://github.com/Eneco/landscaper
  - swozey 10y ago
    Well this is awesome. Thanks for posting.
  - sytse 10y ago
    This is great, we'll discuss integrating this with GitLab https://gitlab.com/gitlab-org/gitlab-ce/issues/30748 https://gitlab.com/gitlab-org/gitlab-ce/issues/30748
- swozey 10y ago
  I've been meaning to make a blog post about doing this on k8s.camp. I'll try to get to it this week/weekend and I'll let you know. I use helm to deploy several hundred services and microservices (stateless, stateful, etc). This gist of mine may help you get started with the CI portion (CI and k8s is interesting, there is a lot you need to account for as you're not given errors if a pod fails to deploy, etc). It could easily be converted to helm upgrade instead of raw kubectl - I've kept it kubectl so people know what's going on. https://gist.github.com/mikejk8s/0f805c3e7d0704cbea63db846a00357e https://gist.github.com/mikejk8s/0f805c3e7d0704cbea63db846a0...
- lachie83 10y ago
  Here's something I've put together. Hopefully it helps. https://youtu.be/NVoln4HdZOY https://youtu.be/NVoln4HdZOY
  - fredsir 10y ago
    Ha, I just watched that. Someone posted it to me on the #helm channel on kubernetes slack just after I had watched your kubecon talk. Needless to say, I've been watching your croc-hunter pipeline doing it's thing a few times now

fredsir 10y ago

Have you written about your setup anywhere? I'm right now working on porting my manifests + kubectl manual k8s workflow to helm+gitlab-ci(to automatically build and push imagines and then deploy to cluster), but I'm only just at the stage of creating the helm charts, so any literature about how to set up a ci to build the Docker images, push them, bump the chart version, deploy to staging environment for every PR and so on is something I'm very interested in.

andrewstuart2 10y ago
I haven't, but I've thrown together a gist [1] of the most-relevant configuration. In this case it's a pretty simple static page hosted on an nginx container, but the approach should scale to multiple services if I ever started using proper Helm dependency management. If you have any questions let me know, and I can also comment the gist a bit more as I get time today. Admittedly, I'm probably only using 50% of Helm's capabilities, because I'm primarily interested in its templating abilities rather than managing a centralized repo of apps that can be installed. My current pattern (which I'm still iterating on) is that I have a `chart` directory which contains the Helm chart and templates, and TBH I don't really bother updating the version in `Chart.yaml` because I'm managing it in-repo with git tags, branches, etc. Then my gitlab CI scripts just `--set` a few variables so that the right docker image, DNS, and ingress path values are used for the branch. [1] https://gist.github.com/andrewstuart/8006a6f39ce5cb3fff7211e85c3aec0e https://gist.github.com/andrewstuart/8006a6f39ce5cb3fff7211e...
- fredsir 10y ago
  Awesome! I will be reading through the gist later today when I get back to working on it. I'm not planning on using all of helm either, and specifically, the whole chart repo feature is something that I don't see myself using at the moment. The workflow I'm envisioning is one where I have a Project-A. Inside Project-A, there is a chart directory containing the project chart, so each project contains their own chart instead of having the charts in a centralised repo. The chart will be used for deployment, but something like versioning will not be bumped manually but instead be bumped by the CI after (if) tests succeeds, at which point a new docker image is built, tagged with a version-bump (or build number) and pushed, and then the chart is updated to use the new docker image and getting it's version bumped (or build number) and then at last deployed to staging environment. There should also be a next step for taking a chart deployed to staging and deploy it to production, but I'm not sure how that should be done yet. I'm also not sure how or what the correct solution is in the case of actually updating the chart in the repo in the CI, or just supplying runtime variables (or what it's called) to helm as you deploy the chart that then overwrites the values hardcoded in the chart, but in any case, I'm envisioning a workflow where you for each PR and version-tag you make to a repo, a new docker image is produced and pushed, and a new chart is produced and deployed, so that you have a complete history of images and chart for each pr and version.
  - bacongobbler 10y ago
    Skimming through the comments here so I apologize if you are already aware of this, but please feel free to drop by in #helm on the Kubernetes Slack channel with any questions there. :)
  - Snappy 10y ago
    Yeah, I'd think you'd want to take advantage of specifying the image tag as a variable rather than committing the image tag back to the repo. Kind of defeats the point of helm to hard code everything. :) Only bump the chart version when the configure itself (outside of the image tag) changes.
    - fredsir 10y ago
rollulus 10y ago
We use Helm together with Gitlab's CI as well. To make that process smoother, we built landscaper [1]. It receives a desired state, which is a bunch of yamls. Each yaml contains a chart-reference and values (settings). When landscaper is run during CI, it obtains the actual state (the releases) and either updates, creates or deletes to obtain the desired state. The desired state is under version control, so lately I rarely do any manual k8s work. Creating or updating a deployment is a matter of a pull request. [1]: https://github.com/Eneco/landscaper https://github.com/Eneco/landscaper
- swozey 10y ago
  Well this is awesome. Thanks for posting.
- sytse 10y ago
  This is great, we'll discuss integrating this with GitLab https://gitlab.com/gitlab-org/gitlab-ce/issues/30748 https://gitlab.com/gitlab-org/gitlab-ce/issues/30748
swozey 10y ago
I've been meaning to make a blog post about doing this on k8s.camp. I'll try to get to it this week/weekend and I'll let you know. I use helm to deploy several hundred services and microservices (stateless, stateful, etc). This gist of mine may help you get started with the CI portion (CI and k8s is interesting, there is a lot you need to account for as you're not given errors if a pod fails to deploy, etc). It could easily be converted to helm upgrade instead of raw kubectl - I've kept it kubectl so people know what's going on. https://gist.github.com/mikejk8s/0f805c3e7d0704cbea63db846a00357e https://gist.github.com/mikejk8s/0f805c3e7d0704cbea63db846a0...
lachie83 10y ago
Here's something I've put together. Hopefully it helps. https://youtu.be/NVoln4HdZOY https://youtu.be/NVoln4HdZOY
- fredsir 10y ago
  Ha, I just watched that. Someone posted it to me on the #helm channel on kubernetes slack just after I had watched your kubecon talk. Needless to say, I've been watching your croc-hunter pipeline doing it's thing a few times now