Perhaps, one of the most well-known CI/CD orchestration tools is Jenkins. In the early days, it was called “Hudson”. Development started at Sun Micro systems and the first official release was in 2005 on the java.net website. As of now Jenkins is still one of the most popular orchestrators in the world. Plenty of good arguments for its popularity can be found in this article on Dzone. The company that created Jenkins is called Cloudbees and they offer both the open source edition as well as the commercial edition that comes with professional support. A lot of companies already use Jenkins as their favorite CI/CD platform. With the rise of microservices and cloud(-native) technologies, the CI/CD landscape of tools is changing. In this post, we’ll talk about the impact on CI/CD and specifically Jenkins X – the new DevOps tool for your microservices.
Jenkins versus Jenkins X
Before jumping into the details of Jenkins X, let’s first take a look at what “classic” Jenkins is. Jenkins is a CI/CD automation tool written in Java. A lot of open source developers contribute to it. It is heavily dependent on plugins for various components. With Jenkins you can push applications of almost any technology stack from source code to production.
Roughly speaking, the Jenkins architecture consists of a Jenkins master server which stores all of its configuration and Jenkins slaves, which actually executes the pipeline jobs. Jenkins runs both on-premises as well as in the (public) cloud. Cloudbees offers professional support for Jenkins and they help companies with their DevOps journey using their products.
Jenkins X is one of the latest products being offered by Cloudbees. It was introduced in the early months of 2018 and the Jenkins community just celebrated the second birthday. This new tool is a completely new product and built from the ground up. So even with both products carrying a similar name, they are vastly different products. With the help of Jenkins X, you can spin up a Kubernetes cluster on the target provider of choice and ship your applications with simple (command-line) commands from source code to production. There are no master and slave servers (virtual machines or Docker containers) to maintain. It abstracts away a whole lot of infrastructure components.
Let’s view some of the core differences:
- Jenkins requires a lot of plugins to execute its tasks and to integrate with other services (e.g. web-hooks to Jira, build Go applications, etc). Plugins come either as “Cloudbees maintained” plugins or plugins maintained by third parties.
- With Jenkins X you can define the process of the software development life-cycle of your applications. Jenkins is more strict to follow an existing process.
- Jenkins uses a GUI to configure any jobs (freestyle jobs or pipelines) and the underlying configuration. Even when using the recently released “Infrastructure as Code”, not all can be automated in an easy fashion. This breaks the concept of “everything as code”. Jenkins X uses a command line interface (CLI) and APIs to trigger external tools. Everything can be done as code and thus can be automated. A big plus to apply GitOps in practice. More on that later.
What about the features? You need to know about them in order to decide for your organization if Jenkins X suits you well.
Promotion of microservices
Jenkins X allows you to create virtual environments for development, test, staging and production. This is all achieved using Kubernetes namespaces, thus the segregation-of-duties principle applies here. You can promote your application from one environment to the other.
It follows the GitOps way of work. If you have not heard of GitOps yet: the core idea is to have a streamlined pipeline that processes your declarative) source code (stored in a Git repository) up to production. Whatever you infrastructure looks like, it should always be traced back to your Git repository. The Git repository always remains the single source of truth. GitOps is a way of implementing Continuous Deployment for infrastructure and cloud-native applications and Jenkins X follows this principle.
Once a development team practices Git flow, they can create a so called “pull request” before they commit their code into the main stream of source code. Jenkins X creates a preview environment (either automatically or you can do this manually) to view the results of the code change in the pull request. Once you are satisfied with the outcome, the pull request is merged with the master branch, which holds the version of the code that is deployed in production.
It is possible to write extensions which run just before or just after your pipeline in Jenkins X. It can also run whenever the extension is installed or uninstalled. Using this feature, developers can use extra features on top of the default behavior of existing pipelines in Jenkins X.
Integration with Kubernetes
As said before, Jenkins X runs within a Kubernetes environment. In fact, it can only use Kubernetes, no Virtual Machines allowed :). With Jenkins X, it is possible to easily setup a new Kubernetes cluster yourself or to attach it to an existing cluster. It then uses the Kubernetes cluster (infrastructure) to run your Jenkins pipelines and create the preview environments. It’s a big plus for Jenkins to integrate with the most popular container orchestration tool in the world. Who-ever already operates Kubernetes, can use Jenkins X.
How it works
From a process point of view it’s good to understand how Jenkins X works. No need to cover all of the technical details here, but a global process overview will help.
- The first step is to commit a source code change to your Git source code repository.
- Jenkins X is triggered automatically and it kicks off the pipeline to run the CI/CD job. This pipeline runs as a container on Kubernetes which includes all of the details needed for your application. Remember to properly configure and secure your container images.
- The application is packaged as a so called Helm chart (Kubernetes deployment format) and it is being build and tested. Once it passes all of the tests, the Helm chart is pushed to the Helm chart museum (a repository) and the Docker image is pushed to a container registry.
- A pull request is created and the the pipeline creates a staging (preview) environment.
- In case you have automatic merging enabled, Jenkins X merges the pull request to the main source code.
- The staging pipeline runs and the preview environment lets you preview your changes “live in action”. This is achieved by the staging pipeline which creates the needed Kubernetes resources to be able to deploy and view your application.
These steps indicate a simplified view of the CI/CD workflow. It gives you a good indication about the power of Jenkins X since it takes care of a lot of steps you would have done manually yourself prior to the availability of Jenkins X.
In case you are interested to try it out, be sure to check the following steps to install it. You can either install it on Linux or on Windows or MacOs.
Jenkins X comes as part of a jx binary which is downloadable for free on github.
Simple execute the following script inside a terminal:
curl -L “https://github.com/jenkins-x/jx/releases/download/$(curl –silent https://api.github.com/repos/jenkins-x/jx/releases/latest | jq -r ‘.tag_name’)/jx-linux-amd64.tar.gz” | tar xzv “jx”
Jenkins X is installed in the directory of your choice. You only need the (also free) utility called “jq”.
On Windows you can install it using Chocolatey. This is a free package management system which enables you to install packaged on Windows using a Powershell terminal. You need to be an admin to use this. First open up a PowerShell window and then execute the following command:
@”%SystemRoot%System32WindowsPowerShellv1.0powershell.exe” -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command “iex ((New-Object System.Net.WebClient).DownloadString(‘https://chocolatey.org/install.ps1’))” && SET “PATH=%PATH%;%ALLUSERSPROFILE%chocolateybin”
Then install Jenkins X using chocolatey:
choco install jenkins-x
Use brew to install the jx binairy:
brew install jenkins-x/jx/jx
For all operating systems, test your Jenkins X installation using: jx -version. You should see the version of Jenkins X which you have just installed.
Managers constantly need to answer the “why-questions” for any new technology. The same is true for Jenkins X. From a business perspective, why should you move?
One of the main reasons is to limit the burden of having to maintain a complete CI/CD infrastructure for your various workloads. A famous quote I heard on one of the conferences I visited last year: “The best CI server is no CI server at all“. Simply said: why should you maintain a CI server yourself?
Jenkins X does not require an overwhelming number of plugins to define, install and maintain. Often, those plugins contain problems and should require regular updates. All needs to be aligned with the main product itself: the Jenkins core.
From a security perspective: it’s easy to hook Jenkins X onto an existing Kubernetes cluster. This cluster can and should have the default security controls. Jenkins X automatically adheres to these controls. No need to think about security too much compared to running your own Jenkins masters and slaves.
Companies can concentrate on their core business: develop applications and release business critical features instead of dedicate their time to maintain a CI/CD tool which should just support this way of working.
However, the most important benefit is to become ready for the cloud native world. It makes the transition to the public cloud easier since it picks the best of both worlds with regard to the DevOps way of working. Teams (might) know Jenkins already, now it’s being combined with Kubernetes and other cloud native technologies. It tends to be an easy way to fully adopt the possibilities which cloud providers offer as of today.
This article gave an introduction to Jenkins X. I hope it inspired you to give it a try. Organizations can benefit from it when processing and deploying microservices in a cloud native environment and in this way contribute to their Dev(Sec)Ops journey.