Tech Review: Jenkins X

- Updated March 27, 2018

What’s JenkinsX?  How is it different from regular Jenkins?  I did some investigating into this project and tested out the tool myself. What I found was a new compelling tool that could signal a possible future for Software Development and DevOps.  Keep reading and I’ll share my full assessment and takeaways.

 

Simply stated, JenkinsX is a platform that makes several key assumptions about how CI/CD systems should look. It codified these assumptions right into itself and left little room for other opinions. By doing this, the project developers free themselves to focus on automation and templates for best practices.  While building an opinionated platform like this may seem inflexible, most of the assumptions it takes are familiar to anyone who builds Continuous Delivery systems.

  • All web applications begin their life as code in a git repository
  • Applications run inside of an Environment where applications can interact with one another, but they can’t interact with other Environments.
  • Application code must be processed through a series of steps (called a Pipeline) before it can be turned into a runnable application (Build)
  • Each time code is changed, a new version of the application is built
  • To move an application to an environment it must be signed-off on (Promoted)
  • Development teams will want at least one environment for testing (Staging)
  • Application versions should be automatically promoted to Staging
  • After promotion to staging, an application version can be manually promoted to the “live” environment (Production) to be accessible by real users

This is a very common set of guidelines for anyone building a Continuous Delivery system. The promised novel of this system is to deliver these same Continuous Delivery concepts in an easy to deploy framework that sets itself up almost like a software package on an operating system. In many cases, JenkinsX does deliver on its promises.

However, there’s still a few glitches and missing pieces that will prevent this project from really taking off.

How Does it Work?

 

Before going into some of my concerns, let’s describe how JenkinsX solves its problems. JenkinsX is collects technologies that tie together with the jx CLI tool and the Jenkins-X Platform, a suite of pre-configured applications built for Kubernetes.

The major technologies at play are

  • Kubernetes: Container orchestration, operates as a cluster, and acts as “a platform for building platforms” essentially
    • kops: Tool for building and maintaining a Kubernetes cluster
    • kubectl: CLI tool for interacting with the Kubernetes API — useful for deploying applications, networking config, etc.
    • helm: Templated configurations called Charts used for applications that will run on Kubernetes
  • Chart Museum: repository for Chart templates
  • Docker: Container runtime and build tool
    • Docker Registry: repository for Docker Images
  • Jenkins: CI/CD pipelines and automation services
  • GitHub: Source code hosting and Pull-Request management
    • git: Source code management, version control, and branching
  • Nexus: artifact repository for application builds
  • Monocular: Web UI
  • jx: The JenkinsX CLI tool that glues everything together and acts as the main administrative tool.

 

There’s a lot going on here but, I must admit they all worked pretty well together. After getting past a few hiccups (the minikube version still needs a lot of work), I was able to run jx create cluster aws to build my cluster and all the AWS infrastructure required.  Notably, using jx , I was also able to destroy and then re-create everything multiple times.  That’s a huge signal of quality in my book.

The jx tool and Kubernetes Setup

The jx tool acts as your first abstraction point and is your main entry into the orchestrated system.  JenkinsX also requires an API token to your GitHub account. If you don’t want to use GitHub, please note that you’re out of luck for now and will have to wait until they add support for new platforms.

After setting up the Kubernetes cluster in your cloud provider of choice (I used AWS), it deploys the “Jenkins-X Platform” that includes a Jenkins Master pre-configured with many useful plugins like the Kubernetes plugin and Blue Ocean.  This Jenkins Master is where the automation and monitoring for any Pipelines will live. In addition to Jenkins Master, the Jenkins-X Platform has other sub-systems like Nexus, Chart Museum, and Monocular.

All these sub-systems install themselves in the newly created “jx” namespace on the Kubernetes cluster.  This acts like a “management” environment for your new CI/CD platform.  After this, it creates two more namespaces to represent Staging and Production environments.  These namespaces, called “jx-staging” and “jx-production”, will house your web applications and services complete with their own segregated, virtual networks.

The CI/CD Process

Once JenkinsX configures the Kubernetes environment and installs the platform, it prompts the user for their GitHub username. Assuming the user does this, it creates several code repositories with either a “-staging” or “-production” suffix. These repositories manage the state of each environment and details the installed applications and their versions.

During the CI/CD process, code commits to the repositories occur automatically and changes trigger Pull Requests. For manual Promotions, merging these Pull Requests will trigger the promotion process and launch the desired versions to the environment. By reading these repositories, the expectation is you can trace when and why deployments occurred to each of your environments.

New applications or services are quickly instantiated with commands like jx create spring -d web -d actuator . These use pre-made templates for setting up ready to go pipelines complete with the Jenkinsfile and Dockerfile files needed to define the CI/CD process. More templates are on the roadmap and with a little analysis there are ways that I didn’t explore to create your own templates.

I really, really want to love JenkinsX, but…

 

I recently wrote an article on simple systems vs. easy systems and I thought a lot about that article while I was using JenkinsX.  Especially my quick questionnaire for evaluating a system for “simplicity”:

  • Is this easy to understand?
  • Is this system easy to change?
  • Is this system easy to debug problems?
  • Is this system flexible?
  • Have the fact patterns changed for the original Problem Space?
  • Does the Problem Space still map well to this solution?

 

Is JenkinsX simple?

 

Right now, I can’t say that it is. I give the project huge points for mapping a good solution for setting up a CI/CD system quickly and easily. I also give it points for flexibility as it’s clear that it’s a very modular system. You can even tell from their roadmap that they are planning on treating the parts of their platform as “components” that swap in or out.

However, the problem I see now is an extreme lack of visibility.  When I look at JenkinsX, I see a very difficult system to debug and understand. Some of this blame is on Kubernetes and Docker. From what I can tell, they still don’t have monitoring and logging stories that satisfy me. #unpopularopinions

Luckily, I believe this is fixable with some extra baked in components like Grafana, Prometheus, and Elasticsearch. What I’d like to see is an equally opinionated deployment of monitoring tools that come packaged with the Jenkins X Platform. This would take the FUD I would expect to feel while running Jenkins X in Production.

 

I’m starting to really like the direction we’re heading in with these CI/CD tools. The future where we have a standard agreement on best practices is one where we can stop repeating ourselves and start automating it away. JenkinsX feels like a glimpse into that future and makes me optimistic for where we’re heading.

 

 

Acknowledgements