Container pipelines: Jenkins X and OpenShift Jenkins Pipeline

2018-12-21, 12:01 Posted by: Toni Ylenius

We have been working with OpenShift for quite long already. OpenShift has been my personal focus area, but we also work with Kubernetes, and probably even more in the future as OpenShift and Kubernetes are more and more alike.

The reasons to use container platforms are to standardize and accelerate software deployments. And because of that, usually our projects are not only about managing the platform, but also about software pipeline design and improvements.

Generally pipeline is a vague concept and it means different things in different contexts. In this context software pipeline means the technical steps starting from developers change to a repository and finally delivering the tested change to the production on an OpenShift or Kubernetes cluster. This definition is already quite broad and contains aspects highlighted in the following diagram and table.

Diagram of a container pipeilne

We are going to quickly compare the readiness of OpenShift development tools versus the new project Jenkins X. The following table lists wether the tool manages the aspects listed or not.

Aspect OpenShift Pipeline Jenkins X
Repository - X
Pipeline X X
Pipeline trigger X X
Build X X
Image promotion X X
Image storage X X
Secrets - -
Deployment - X
Namespace, roles - X

As you can quickly see from the table, Jenkins X is big project with a big vision. It tries to create an uniform solution for modern cloud application on Kubernetes. You can get good overview of both OpenShift pipelines and Jenkins X by following the links in the end.

An X mark in the table means that the aspect of the pipeline is managed. Managed in this context means that there is "as code" like automation for the aspect. For example Pipeline in OpenShift is managed using Jenkinsfile and OpenShift pipeline automation, where Jenkinsfile is automatically pulled from the repository and OpenShift manages Jenkins and pipeline there. Pipeline trigger is supported by triggering the Jenkinsfile build object. OpenShift has a good s2i Docker image build procedure and Image promotion in OpenShift is easy using imagestreams and internal Docker registry. Hyphen (-) in the table means that the current aspect is not automatically managed by the pipeline. However, the aspects like Secrets, Deployments, Namespaces and roles are still supported by creating the hooks

Jenkins X takes all this to an another level. When you run jx import it will automatically create a repository to the connected GIT repository, will automatically template Jenkinsfile for you and configure triggers for the build. For Docker builds Jenkins X uses skaffold tool and there is ready made system for promoting images to the connected registry. Jenkins X aims to be
complete solution, and it already fulfills the promise, there are only minor missing parts like secret management. However, Jenkins X project seems to have implemented too many features in short time and overall quality is not convincing. There are lot's of issues with minor details and documentation is lacking, but Jenkins X is in early development phase and all might change in near future.

However, the original motivator for the research and for this blog was the finding, that there is no best practice for managing container deployments and rolling changes to the deployment in the pipeline. Especially, in OpenShift you have new-app command to quickly initialize the application from template, but there isn't a documented fully managed way. I have searched by trial-and-error the best way for two years already. Nowadays we have openshift-applier, but that is only part of the solution and is comparable to helm chart and tiller concepts. In Kubernetes, helm seems to become the preferred way of controlling and versioning the deployments. This is also the way how Jenkins X does it, by using in-built Helm-registry. Probably helm charts, without tiller, is the best approach in OpenShift too.

The finding, to highlight here, is that there is no ready made solution that covers every aspect in software pipeline. There are excellent open source solution for each of them, but usually you need to work on your own solution to either integrate the many solution or cover the gaps. Jenkins X is an ambitious project that tries to cover most of the pipeline. We can't yet recommend Jenkins X as it it still maturing, but it is definitely something to try and take example from.

Join us to work with modern container platforms in clouds, data centers, or in hybrid environments. See our open positions here

comments powered by Disqus

Toni Ylenius

Senior Solutions Specialist

Call contact
Email contact