Helm from Java, part 2

In the previous post, I outlined how microbean-helm produces the Java bindings for Helm, the Kubernetes package manager.  Specifically, it creates and packages up the gRPC Java code that describes the API surfaced by the Tiller server-side component of Helm (the thing that does the heavy lifting in the Helm ecosystem).

In the latest revision of the project, I’ve done some road grading to make it easier to work with the (cumbersome) gRPC API.  Here is how you connect to Tiller from Java and ask it for a particular release.  That is, we’re basically doing the Java equivalent of helm history someRelease:

import java.util.List;
import hapi.release.ReleaseOuterClass.Release;
import hapi.services.tiller.ReleaseServiceGrpc;
import hapi.services.tiller.ReleaseServiceGrpc.ReleaseServiceBlockingStub;
import hapi.services.tiller.Tiller.GetHistoryRequest;
import hapi.services.tiller.Tiller.GetHistoryResponse;
import io.fabric8.kubernetes.client.DefaultKubernetesClient;
import org.microbean.helm.Tiller;
// Use a DefaultKubernetesClient to set up a port forwarding situation
// with a Tiller pod running in your cluster, and make sure both are
// in a try-with-resources block so they're closed properly:
try (final DefaultKubernetesClient client = new DefaultKubernetesClient();
final Tiller tiller = new Tiller(client)) {
// Let's do the equivalent of helm history someRelease.
final GetHistoryRequest.Builder builder = GetHistoryRequest.newBuilder();
assertNotNull(builder);
builder.setMax(1);
builder.setName(releaseName);
final GetHistoryRequest request = builder.build();
final ReleaseServiceBlockingStub stub = tiller.getReleaseServiceBlockingStub();
final GetHistoryResponse response = stub.getHistory(request);
final List<? extends Release> releasesList = response.getReleasesList();
final Release release = releasesList.get(0);
}

view raw
ConnectToTiller.java
hosted with ❤ by GitHub

Under the covers, this sets up a port forwarding connection to the first Pod in the cluster that is running a healthy instance of Tiller (hopefully there is exactly one) and establishes all the gRPC plumbing for you (which is not very straightforward).  As long as you ensure that (in this example) both the DefaultKubernetesClient and the Tiller object are closed, as is done in this example, you won’t leak resources.

Happy Helming from Java!

Author: Laird Nelson

Devoted husband and father; working on Helidon at the intersection of Java, Jakarta EE, architecture, Kubernetes and microservices at Oracle; open source guy; Hammond B3 player and Bainbridge Islander.

One thought on “Helm from Java, part 2”

Comments are closed.