Technology is ever-evolving, and we have seen a major shift in application platforms from on-premise to cloud and containerization, application architecture from monolithic to micro-service, and many more. Organizations today are working towards making the operations an easy task and reducing the cost, as it is one of the painful areas where the project spends a lot of time and effort to streamline the entire process. Jenkins X is one of the platforms which has such kind of capability.
For an individual who is into technology, the familiarity of the name Jenkins is not uncommon. But “What is Jenkins X?” and once we will know about it, certainly, there will be more questions in our mind, and most of them will be answered in this essential document.
What is Jenkins X?
Unlike traditional Jenkins which is one of the most common CI tools and an integral part of DevOps that is usually used to integrate multiple DevOps Stages, Jenkins X (JX) is an apt solution for modern cloud applications on the Kubernetes. JX comes with continuous integration, automated testing, and continuous delivery capability for applications running on the Kubernetes platform. It provides an easy and simple way to work with Kubernetes. Using a single command, a Kubernetes cluster can be created along with all the tools which are needed to manage our application.
Initializing the application automatically creates a sample source code compatible with Kubernetes Platform, Dockerfile for image creation, Jenkinsfile for build and deployment pipeline along with other building blocks. Also, it creates few environments by default along with Preview to validate the pull request which can be used to deploy and test our application, which ultimately can be promoted to production. Looking at the above specifications, we can say that it reduces the overhead of developers to a great extent so that they can focus on application development.
Using Jenkins X, one does not need to know what all plugins are required to run CI/CD pipeline. It uses GitOps fundamentals for development and Code Promotion perspective where we have a single repository for each environment and helps to keep all the code, configuration into VCS providing advanced security and disaster recovery. Using Jenkins X, everything is saved in VCS as a code. It is the best suitable solution available in the market for applications running on Kubernetes. JX spins a lot of components automatically to support the whole platform and we will sneak into each one of them but first, we need to understand how JX is different from Jenkins 2.x.
Jenkins 2.x vs. Jenkins X
DevOps Principles and Best Practices
JX makes it straightforward to work on DevOps principles and best practices to address a couple of challenges like:
- Frequent Deployments.
- Configuration as a Code.
- Automated Release Management and Code Promotion.
Key Features of Jenkins X
- Uses GitOps Model — Each environment has its repository.
- Manages Kubernetes compatible application without knowing about it in detail.
- Automated Environment Management.
- Automated established CI/CD setup.
- Automated Preview Environments for smoke testing.
- Feedback on Pull requests.
Jenkins X Architecture
Now let us peek inside JX to understand JX architecture and platform components which automate entire CI/CD pipelines with application environments to make our life easy.
Let us look at each of the components of the JX platform.
1.1 JX Architecture
JX Building Blocks
Let’s look at each of the components of the JX platform.
JX Environment Management
JX by default creates a staging and Production environment but provides leverage to create a new one as per our requirement. Also, it creates a preview environment for smoke testing purposes where we can validate application functionality before promoting code to staging. Also, as it runs on GitOps fundamentals, every environment specification is saved as a code in VCS shown below.
1.3 JX Environment Management (Source: https://jenkins-x.io/docs/concepts/features/)
JX Source Code E2E Flow
1.4 JX Source Code E2E Flow (Source: https://jenkins-x.io/docs/concepts/features/)
People usually say that they have their application running on the Kubernetes platform but creating a decent CI/CD pipeline is very challenging. That is where Jenkins X simplifies all the complexities and sets up the tools and environment and removes the hassle of creating the CI/CD pipelines as well.
JX supports various cloud platforms like Google, AWS, Azure, etc. but for this demo purpose, I will use Minikube which is a single node cluster and perfect fit for us to understand how the JX ecosystem works. I will execute the whole demo on my machine with Windows 10 OS.
For production, we must opt for cloud providers like AWS, Google, Azure, or existing production Kubernetes Cluster.
For more details, please refer to JX official documentation:
As part of this demo, we will see what are all the pre-requisites before we start playing around with the JX utility, how we can install required components, how JX can be used for setting up different components explained above, and how to manage a sample application and promote the same from lower to higher environment using GitOps fundamentals.
Pre-Requisites and JX Setup
We need to have certain pre-requisites for the JX ecosystem to work which are as follows:
Once we are done with the above pre-requisites, let us setup Minikube to use the specified Kubernetes version and create a Minikube cluster using JX utility by running the below mentioned commands:
minikube config set kubernetes-version v<version you want to install>
jx create cluster Minikube
Once executed, it will prompt to install helm as it is one of the dependencies for the whole system to work properly.
Once helm is installed, we need to provide specifications for our cluster. I will keep the default one and select a virtual box as a driver. Please provide your specification as per workload as this configuration will be used to install all JX building blocks and set up the application environment as well.
1.6 Minikube Cluster Specification
1.7 Minikube Server
Once the Minikube cluster is set up, it will start setting up the Jenkins server for CI/CD, configure domain and prompt for GitHub username which is “mohitgargdevops” in my case and token. GitHub Token can be generated by visiting the below-specified URL which is needed for GitHub environment setup:
1.8 JX Building Blocks Setup
This will create two environment repositories in GitHub — staging, and production, install chartmuseum, nexus, docker-registry, and Jenkins (provide admin password), set up CI/CD pipeline jobs automatically for environment promotion, and create respective GitHub webbooks highlighted in the screenshot below:
1.9 Application Environment and Tools Setup
1.10 JX Components UI
As this infrastructure is running on top of Kubernetes, let us fire “
kubectl get pods” to see what all pods are created in the backend.
1.11 Kubernetes Pods Running in Backend
Application Management Using JX
Now, we are done with the tools needed for application management and DevOps setup. Let us see how application management can be done using Jenkins X without knowing in deep about Kubernetes and kubectl.
At the end of setup, JX provides an option to run the “
jx create spring -d web -d actuator” command to set up a sample spring boot application. Let us run it and name it “jxdemo”. Please refer to screenshot 1.9. Executing the same command, JX will set up the GitHub project, Jenkins pipeline, Webhooks and create dockerfile, jenkinsfile along with scaffold.yml into a repository. Developers can utilize this sample application and customize their application compatible with the Kubernetes platform. We need to provide a couple of inputs which are highlighted below along with GitHub and Jenkins project URL.
1.12 Spring Boot Application Setup
It creates a sample code in GitHub in the provided repository and by default creates a couple of files which helps to accelerate automate CI/CD using the GitOps model. This will automatically create a Jenkins pipeline which will be triggered to build branch source code from the master branch.
1.13 GitHub Application Repository
Code Promotion to Staging Environment
After a successful build, a pull request will be raised to promote the code to a staging environment. Once we approve the pull request, a new branch will be created, and the code will be promoted to staging automatically. Refer to the screenshots below which show the staging code promotion branch.
1.14 promote-jxdemo-0.0.1 Branch for Stage Deployment
Now staging application URL is accessible:
1.15 Staging App With Default Source Code
As of now, we have an automatic deployment setup for staging and a manual for production. We can validate the same by running “
jx get env“.
1.16 Deployment Mechanism for Stage and Prod Environment
Code Promotion to Production Environment
We can promote the same code to production by running the below-specified command and approving the pull request for an environment-production repository.
jx promote –app=jxdemo –version=0.0.1 –env=production
1.17 Code Promotion to Production
As the 1.17 screenshot mentions, all merge status checks are passed and promotion worked, it is time to access the production URL.
1.18 Application Production URL
Adding Change to Source Code and Code Promotion
Let us create a new branch with the name “
jxdemo” from the “
master” branch, make some code changes and raise a pull request to master.
Now for demo purposes, I will add an HTML file, and promote the same to staging and then to production, to see how our changes float.
1.19 Source Code Change to Add Static File
Raising a pull request from “
jxdemo” to the “
master” branch will trigger a PR-1 Build in Jenkins, and a new “
preview” environment will be created where the latest code from the “
jxdemo” branch will be deployed. We can do the smoke testing using a preview environment and once we are good with our changes, we need to merge the pull request. As soon as the merge completes, it automatically triggers the staging deployment job and provides a staging environment URL.
1.20 Jenkins PR-1 Pipeline
We can also look at the back-end flow happening in Jenkins using its blue ocean plugin.
1.21 Jenkins Flow
Once the preview environment is hosted and we are good with our changes, it is time to merge the pull request into the master branch, which in turn triggers environment promotion for source code deployment on the staging environment. Let us try accessing the staging environment URL and validate our changes.
1.22 jxdemo Branch Source Code Changes — STAGE Environment
Let us follow the same steps for production deployment as we used before. Refer to the below screenshots for command-line execution.
1.23 jxdemo Branch Source Code Promotion to Production
Let us try to access the production application URL.
1.24 jxdemo Branch Source Code Changes — PROD Environment
Also, using “
jx get activity” from the command-line, we can see what is happening in the back-end from the creation of application source code to code promotion to the staging environment and then to production.
jx get activity
We have seen that Jenkins X is the answer to most of our troubles and works well to simplify the setup and CI/CD of applications running on the Kubernetes platform. It creates the whole ecosystem consisting of a lot of tools integrated to make our life easy. JX is the utility that does all the magic and handles all of the tedious tasks by itself for us. I must say that it is a wonderful platform designed to solve the problem statements. JX also supports a lot of add-ons, which can be used to change the VCS in case we do not wish to use GitHub or want to opt for different deployment patterns like Canary. In case you wish to explore more, please refer to the JX official documentation.