Jenkins X is a project which rethinks how developers should interact with CI/CD in the cloud with a focus on making development teams productive through automation, tooling and DevOps best practices.
The difference between Jenkins X and Jenkins
Jenkins is a tool which was developed long before cloud become the norm and it's definitely not a cloud-native tool, meaning it doesn't have out of the box capability to survive outages, seamless scaling, etc.
Basically, Jenkins X is not just a CI/CD tool to run builds and deployments, it automates the whole development process end to end for containerised applications based on Docker and Kubernetes.
With Jenkins X, you get not only Kubernetes pipelines for your apps but also a very scalable CI/CD solution.
Challenges while setting up CI/CD pipelines for container-based applications:
Setup the cloud environment
Setup kubernetes cluster and set up multiple environments like development, staging, testing
Migrate application to the container so that user can start building docker images
Figure out how to deploy the application on kubernetes and generate some yml and helm charts
Figure out how to do continuous delivery including promotion processes - eg Promote versions of the application from testing to staging to production.
Store all operational configurations like web application source code on the GitHub repository.
Then automate everything
So all this stuff which developers have to do is kind of unnecessary heavy lifting. Jenkins X is designed to get the above stuff done and focus on delivering actual value to customers.
How does Jenkins X help?
Automate the installation, configuration & upgrade of Jenkins + other s/w components (helm, nexus etc) on Kubernetes
Automate CI/CD for your applications on Kubernetes
Uses GitOps to manage promotions between environments
Test - Staging - Promotion
Lots of feedback. Eg. commenting on issues as they hit Staging + Production
What does Jenkins X do?
By using Jenkins X, the developer can type one command jx create or jx import and the following process : get the source code, the git repository and application created, automatically built and deployed to Kubernetes on each Pull Request or git push with full CI/CD complete with Environments and Promotion.
Developers and teams don’t have to spend time figuring out how to package software as docker images, create the Kubernetes YAML to run their application on kubernetes, create Preview environments or even learn how to implement CI/CD pipelines with declarative pipeline-as-code Jenkinsfiles. It’s all automated in Jenkins X.
If you want to see Dockerfile, Jenkinsfile or Helm charts for your apps or their environments then those are all available versioned in Git with the rest of your source code with full CI/CD on it all.
Jenkins X conceptual model
Automated CI/CD Pipelines
Create new projects or import existing source code quickly into Jenkins X via the jx command line tool and:
Get a Pipeline automatically set up for you that implements best practice CI/CD features:
Creates a Jenkinsfile for defining the CI/CD pipelines through declarative pipeline-as-code
Creates a Docker file for packaging the application up as an immutable container image (for applications which generate images)
Creates a Helm chart for deploying and running your application on Kubernetes
Ensures your code is in a git repository (e.g. GitHub) with the necessary webhooks to trigger the Jenkins CI/CD pipelines on push events
Triggers the first release pipeline to promote your application to your teams Staging Environment
On each Pull Request, a CI pipeline is triggered to build your application and run all the tests ensuring you keep the master branch in a ready to release state. When a Pull Request is merged to the master branch the Release pipeline is triggered to create a new release:
A new semantic version number is generated
The source code is modified for the new version and then tagged in Git
New versioned artifacts are published including docker image, helm chart, and any language-specific artifacts
Jenkins X functionality
JX is a command line tool for installing and using Jenkins X. Check out how to install jx. To create a new Kubernetes cluster with Jenkins X installed use the jx create cluster command. The command initialises Pods with the following applications in jx namespace of Kubernetes:
Chartmuseum (Open-source Helm Chart repository)
Docker registry (Docker image storage)
Jenkins (Automation server)
MongoDB (NoSQL Database)
Nexus repository (Artifact storage)
Let’s have a look at how the JX processes correlate to Git actions. For simplicity, let’s use only master and one feature branch. The table below details the steps of the flow.
Prerequisites for setting up Kubernetes + Jenkins X using GKE
Note: Following steps are for Ubuntu 16.04
Install Git and set your account’s default identity using Git config
Install gcloud - Google Cloud Platform's CLI tool
Install kubectl - Kubernetes CLI tool
Move to /usr/local/bin for path binding:
$ sudo cp /home/<user>/Downloads/kubectl /usr/local/bin/kubectl $ sudo chmod +x /usr/local/bin/kubectl
Install helm i.e. Kubernetes package manager
Move to /usr/local/bin for path binding:
$ sudo cp /home/<user>/Downloads/linux-amd64/helm /usr/local/bin/helm $ sudo chmod +x /usr/local/bin/helm
Install command line tool: jx
$ curl -L https://github.com/jenkins-x/jx/releases/download/v1.2.102/jx-linux-amd64.tar.gz | tar xzv
$ sudo mv jx /usr/local/bin
$ sudo chmod +x /usr/local/bin/jx
How to create a Kubernetes cluster on GKE and install Jenkins X
jx create cluster gke
After triggering this command, we are prompted to authenticate Google Cloud account. It also prompts for some questions on how to create our cluster. It generates a random admin password which is used to access all the applications that we’ve installed.
jx get build logs
We can now get logs for the build jobs which are actually provisioning the staging environment. Please find detailed logs of the above command displayed below.
Please find detailed logs of the above command from the Production environment displayed below.
Jenkins X has been successfully installed and default environments are created on our new GKE cluster.
How to create an application on Jenkins X
The following steps creates a sample Spring Boot application and import it into Jenkins X.
1. Command to create Spring Application
jx create spring
It will prompt for some questions like the type of project, mvn group ID, artefact name, spring boot dependencies etc. It initializes this project as a Git repository. It adds some extra files to the repo i.e. Dockerfile, Jenkinsfile, charts etc. This will create a repository in GitHub. Also creates a project in Jenkins and registers webhooks in the Git repository.
2. Command to get build logs
jx get build logs
The first build takes time because it downloads some dependencies from maven central.
We are using Nexus which was installed as a part of Jenkins X platform so that remaining builds will be faster because dependencies will be cached.
After that it tags our potential release & push tags to Github.It then builds application using maven.
It uploads artefacts to Nexus so that it can be shared between the teams.
Docker image is been built for this application & pushed to docker registry.
It then generates change log and publish it to chartmuseum registry.
Pipeline waits for pull request for staging environment to be merged and then waits for another pipeline to be triggered & perform deployment for our new application on staging environment using helm.
Now we can see staging environment with our application running in it.
3. Application deployment onto staging environment
Using CLI, we can see our application is now deployed to staging environment with version 0.0.1
$ jx get apps APPLICATION STAGING PODS URL PRODUCTION PODS URL demo08 0.0.1 1/1 http://demo08.jx-staging.126.96.36.199.nip.io
4. Application URL
We can get application URL with following command
$ jx open --env staging Name URL demo08 http://demo08.jx-staging.188.8.131.52.nip.io
5. Start working on the project
Now we can start working on our new project. Go to your project location and from there you can actually create a Github issue.
$ cd demo08/ $ jx create issue -t 'add a homepage'
6. Add HTML Page
Now switch to your working branch and add a simple HTML page.
$ git checkout -b wip $ vi src/main/resources/static/index.html
$ git add src $ git commit -a -m 'add a homepage fixes #1' $ git push origin wip
7. Create a pull request
Then create a pull request from working branch to master branch. After that our CI pipeline is automatically triggered.
After some time, our CI checks pass.
8. There we can see a comment has been added to the pull request saying our application is been built and deployed into the preview environment.
9. Now our application is deployed in preview environment.
$ jx get apps
10. Now, you can see the application running on the given URL.
So where is Jenkins?
As you have seen, there was no direct interaction with Jenkins, but it is there, running the pipelines for continuous integration and continuous delivery of the repository, and orchestrating things with Kubernetes.
If you run jx get pipelines you can see URLs to the various pipelines that have been setup for you are part of interacting with Jenkins X.
Additional JX Commands:
open apps, services or pipelines in your browser
explains how things got to where they are, a history
jx get environments
jx get apps
show the state of applications, what versions are in what environments.
So this is how Jenkins X automates installation, configuration of Jenkins and some other software components. It also automates CI/CD for your applications on Kubernetes alongwith promotions through GitHub.
Aditi is a Software Engineer at Velotio. While she began her career with Python and Django, she switched to automation later. Aditi has worked extensively on setting up DevOps processes and CI/CD pipeline for automation using Ansible, Kubernetes, Docker, Jenkins, and Chef on cloud providers like AWS, Microsoft, Google. Being an avid tv series buff, she loves catching up on her favorite series in her free time.