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.
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.8.2.1.1.0 means that the Helm
version it tracks is 2.8.2 and the (SemVer-compatible) version of
the non-generated code that is part of this project is 1.1.0.
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.8.2.1.1.0</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.