InfoQ recently interviewed Jason Hansen, chief architect at Deis, about a recent major release of the Deis Helm product. Deis builds open source tools that make using Kubernetes easier. The banner feature for the release is first-class support to upgrade Kubernetes releases in place. Helm now also provides the ability to define pre and post hooks that are called during install, upgrade, and deletion.
Deis the company helps other companies make the transition to the world of Kubernetes and cloud-native computing. While Deis is a big believer in Kubernetes, they think it has a way to go in terms of usability. Deis Helm is the package manager (analogous to yum and apt) and Charts are packages (analogous to debs and rpms). The home for these Charts is the Kubernetes Charts repository which provides continuous integration for pull requests, as well as automated releases of Charts in the master branch. There is also a Kubernetes blog which provides further explanation and detailed examples of Helm Charts.
Deis is building a community around Helm. There is a GitHub open source community project. As the community grows additional Kubernetes operators make new Helm charts available. Those interested in creating new Helm Charts can join the Kubernetes #helm channel. Companies like Bitnami are developing quality charts and helping shape the Helm Chart development process so that the community can contribute their own charts.
InfoQ asked Hansen about the key features of the recent Helm release:
The Helm community was able to pack a lot into the Alpha.3 release. The banner feature for Helm Alpha.3 is first-class support to upgrade Kubernetes releases in place. For Chart authors, Helm now provides the ability to define pre and post hooks that are called during install, upgrade, and deletion. With these hooks, you can attach custom functionality to release events. Quick and easy upgrades are a very important part of the “day two” story for running applications on Kubernetes.
Beyond in-place upgrades, a lot of work has been invested in the templating engine, how Helm is deployed into Kubernetes clusters, and the overall operator UX.
InfoQ asked Hansen about the advantages of using Helm with Kubernetes over using Kubernetes alone. In response Hansen gave an example:
When building Deis Workflow, we quickly found that wrangling more than a handful of Kubernetes manifests became a hassle. The lack of package management led to a lot of problems born out of “what does your manifest look like.” Helm provided a common templating language, approach to versioning, and generic development process that really helped the team stay on the same page.
Deis also offers a workflow product. InfoQ asked Hansen about how the product works with Helm. Hansen noted that the role of Helm (distributing cloud-native applications) is complementary to the role of Deis Workflow. Helm is used to bring Deis Workflow and components to operators.
Deis Workflow is very tightly focused on running 12-factor applications and facilitating developer self-service. It would be great for everyone if all applications, especially backing services, fit that model. Today, that just isn’t true. Helm’s goal is to make packaging and managing any application as simple as possible.
InfoQ asked Hansen if they plan to keep Deis Helm as an open source product. Hansen stated that the primary goal is to keep all of the Deis projects open source and free:
Which is why we granted Helm to the Cloud Native Compute Foundation (CNCF). We are particularly excited about helping teams make the jump to the cloud-native way of building and running applications.
Deis also recently released Deis Helm v2.0.0-Alpha.4 after the InfoQ Q&A for this news piece. Coverage of the Alpha.4 release is available on the Kubernetes #helm channel.