The microBean Helm project lets you work with the server-side componentry of Helm from Java.

This means your Java applications can now manage applications in your Kubernetes cluster using the Helm notions of charts and releases.

Until now, Java developers had to use the helm command line client to do these operations.

Project announcements may be found in the wiki. You are encouraged to take a look!

The microBean Helm project's version number tracks the Helm and Tiller release it works with, together with its own version semantics. For example, a microBean Helm version of 2.12.3.0.0.1 means that the Helm version it tracks is 2.12.3 and the (SemVer-compatible) version of the non-generated code that is part of this project is 0.0.1.

To install microBean Helm, simply include it as a dependency in your project. If you're using Maven, the dependency stanza should look like this:

<dependency>
  <groupId>org.microbean</groupId>
  <artifactId>microbean-helm</artifactId>
  <!-- See http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.microbean%22%20AND%20a%3A%22microbean-helm%22 for available releases. -->
  <version>2.12.3.0.0.1</version>
  <type>jar</type>
</dependency>

Releases are available in Maven Central. Snapshots are available in Sonatype Snapshots.

The microBean Helm project documentation is online.

Helm is the package manager for Kubernetes. It consists of a command line program named helm and a server-side component named Tiller. helm serves as a Tiller client.

Tiller is the server-side component of Helm. Tiller accepts and works with Helm charts—packaged Kubernetes manifest templates together with their values. microBean Helm lets you build and work with those charts and the releases they produce from Java and send them back and forth to and from Tiller.

In a normal Helm usage scenario, Tiller is installed just-in-time by the helm command line client (via the helm init subcommand). It runs as a Pod in a Kubernetes cluster. microBean Helm features the TillerInstaller class that can do the same thing from Java.

Because Tiller normally runs as a Pod, communicating with it from outside the cluster is not straightforward. The helm command line client internally forwards a local port to a port on the Tiller Pod and, via this tunnel, establishes communication with the Tiller server. The microBean Helm project does the same thing but via a Java library.

Tiller is fundamentally a gRPC application. The microBean Helm project generates the Java bindings to its gRPC API, allowing applications to communicate with Tiller using Java classes.

Ideally, business logic for installing and updating releases would be entirely encapsulated within the Tiller server. Unfortunately, this is not the case. The helm command-line program investigates and processes a Helm chart's requirements.yaml file at installation time and uses it to alter what is actually dispatched to Tiller. For this reason, if you are using the microBean Helm project, you must use the non-generated ReleaseManager class to perform your Helm-related operations, since it contains a port of the business logic embedded in the helm program.