6 ms·

Congrats to Gabe and the whole Deis team on the acquisition. For folks not familiar with Helm, it's basically apt-get for Kubernetes, but with the ability to d

Congrats to Gabe and the whole Deis team on the acquisition. For folks not familiar with Helm, it's basically apt-get for Kubernetes, but with the ability to deploy complex multi-tier systems. It has now graduated out of the Kubernetes incubator. And their Workflow product (also open source), is basically the smallest piece of software that lets you run Heroku buildpacks on top of Kubernetes. So, you can get a 12-factor PaaS workflow, and still have the full Kubernetes API underneath if and when you need it. Update: And I left out my all-time favorite piece of marketing collateral, their Children's Illustrated Guide to Kubernetes (available both as children's book and video): https://deis.com/blog/2016/kubernetes-illustrated-guide/ https://deis.com/blog/2016/kubernetes-illustrated-guide/ (Disclosure: I'm the executive director of CNCF and Gabe has been a super valuable member.)

mej10 10y ago
How does it compare to DC/OS on Mesos? Interested in hearing from people experienced in both.
andrewstuart2 10y ago
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.
biot 10y ago
The Children's Illustrated Guide to Kubernetes is pretty to look at, but it's terrible as a guide. I previously commented as to why: https://news.ycombinator.com/item?id=11927711 https://news.ycombinator.com/item?id=11927711
notamy 10y ago
Oh wow, the CIGtK is really awesome.
frik 10y ago
So Deis PaaS is dead. Is this now a AquireHire to get Kubernetes to Azure? https://deis.com/blog/2017/deis-paas-v1-takes-a-bow/ https://deis.com/blog/2017/deis-paas-v1-takes-a-bow/
- bacongobbler 10y ago
  Support for v1 was dropped earlier this year. v2 is still actively developed and worked on. It's even mentioned in the blog post. Obligatory disclaimer that I'm an engineer @ Deis working on Workflow daily.
- mns06 10y ago
  Brendan Burns (k8s co-founder) joined Microsoft last July, so this is certainly not their first move in the Kubernetes area.
- yebyen 10y ago
  Definitely not dead. Actively developed and worked on. The release schedule has continued with an unbroken chain of monthly stable releases, while v1 platform was sunset with loads of advance warning time. I'm hoping the monthly "Town-Hall" style Zoom meetings will continue, but if so I will also expect them to likely start getting much larger quickly, now with this news.

mej10 10y ago

How does it compare to DC/OS on Mesos? Interested in hearing from people experienced in both.

andrewstuart2 10y ago

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.

biot 10y ago

The Children's Illustrated Guide to Kubernetes is pretty to look at, but it's terrible as a guide. I previously commented as to why: https://news.ycombinator.com/item?id=11927711 https://news.ycombinator.com/item?id=11927711

notamy 10y ago

Oh wow, the CIGtK is really awesome.

frik 10y ago

So Deis PaaS is dead. Is this now a AquireHire to get Kubernetes to Azure? https://deis.com/blog/2017/deis-paas-v1-takes-a-bow/ https://deis.com/blog/2017/deis-paas-v1-takes-a-bow/

bacongobbler 10y ago
Support for v1 was dropped earlier this year. v2 is still actively developed and worked on. It's even mentioned in the blog post. Obligatory disclaimer that I'm an engineer @ Deis working on Workflow daily.
mns06 10y ago
Brendan Burns (k8s co-founder) joined Microsoft last July, so this is certainly not their first move in the Kubernetes area.
yebyen 10y ago
Definitely not dead. Actively developed and worked on. The release schedule has continued with an unbroken chain of monthly stable releases, while v1 platform was sunset with loads of advance warning time. I'm hoping the monthly "Town-Hall" style Zoom meetings will continue, but if so I will also expect them to likely start getting much larger quickly, now with this news.