I’m switching to a “Developer Relations” role at CloudBees. In doing so, my main focus will be to help promote Jenkins X and explore new areas of usage.

So, in the past few days, I’ve been experimenting with Jenkins X, creating various configurations (please remind me to submit an expense report with my Google Cloud bill). The primary goal for sure is for me to be able to run demos. However, this is not my way. I need to understand the internal plumbing, so I can understand why things have been done and what architectural idea is behind this code.

So, I’ll probably publish a few more articles on my thoughts, as I discover some stuff, playing with Jenkins X. Today let’s just focus on encapsulation.

Beer also gets encapsulated. This seems to demonstrate this is a must-have pattern, right?

Jenkins X's opinionated approach to CI/CD uses Helm to deploy Kubernetes applications. Not surprisingly, Helm is a highly popular “packaging system” for the Kubernetes ecosystem, hosted by the Cloud Native Computing Foundation (opinionated doesn’t necessarily mean exotic choices!).

So, the deployment pipeline at some point is expected to call the helm install command. Let’s now look at some interesting debates on the Helm architecture.

Helm was initially created as an equivalent for Homebrew (the missing package manager for macOS), targeting Kubernetes applications. It was intended to provide a simple way for an application developer to define the configuration to apply to a Kubernetes cluster, using file templates. The Helm 2 architecture (current release as I’m writing this article) is split into a Helm client (command line) and a cluster-side agent: Tiller. The latter exposes an API to the client, that applies the templates and updates cluster resources accordingly.

The primary issues with this architecture is that the Tiller component is both a single point of failure and a major security threat. In order to do its job, Tiller has to run with privileged API access to the cluster. In the meantime, Kubernetes has evolved to include RBAC and audit capabilities, so Tiller in this context becomes sort of a “kubernetes-sudo” that could act out of control. For this reason, Helm 3 architecture has been revisited to avoid this flaw: Helm 3 will be Tiller-less.

Right, So What?

Should we just wait for Helm 3? If not, how do we avoid being at risk in the meantime?

Jenkins X's answer is to offer a--no-tiller option. The actual implementation is to encapsulate all Helm operations within jx step helm. When run with no-tiller, this step executes Tiller locally so the template is applied client-side, as part of the jxcommand execution.

Back to my point: benefits of encapsulation.

Jenkins X already provides a Pipeline abstraction for application deployment. You don’t have to write a Jenkins pipeline script to use Jenkins X, as build-packs will provide a standard one for you, based on your selected application stack. Jenkins X pipeline mostly relies on jx step … commands. This encapsulation offers an opportunity to change implementation details, integrate with other components, all without the need to update existing Pipelines.

The Helm step for JX, using encapsulation and abstraction of the invocation of the Helm command line, allows Jenkins X to implement the templating client-side, and only run a standard kubectl apply on the resulting configuration files. From a user’s point of view this is fully transparent, but from the cluster point of view, RBAC security checks will apply.

Once Helm 3 is ready for production, Jenkins X will be able to adopt it and the Helm step implementation will be updated without requiring any change to your existing pipelines. Encapsulation also gives Jenkins X the opportunity to offer some to-be-defined options to experiment with the Helm 3 CLI once some release candidates are available, using the exact same pipelines. This will offer a very simple way to verify that Helm 3 does not break existing pipelines, and it gives us as a developer community the chance to report issues to the Helm developers before their final release.

Additionally, this encapsulation offers an option to plug other tools in the templating process. For example, Kustomize could offer some extra templating capabilities.

Generally speaking, Jenkins X is an integration project that assembles many Kubernetes-related projects together, in a pre-configured fashion to offer a full-featured continuous delivery solution. However, a major issue is the dependency on upstream projects to implement the required features. Encapsulation is a very powerful pattern that offers more flexibility, workarounds, and the ability to experiment with new solutions, without impacting the end-user.