Jenkins X: A Cloud-native Approach to CI/CD
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 containerized 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
- Docker images
- Helm charts
- 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 initializes 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
b. Move to /usr/local/bin for path binding:
- Install Helm i.e. Kubernetes package manager
b. Move to /usr/local/bin for path binding:
- Install command line tool: jx
How to create a Kubernetes cluster on GKE and install Jenkins X
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.
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.
- Command to create Spring Application
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
- 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 a change log and publishes it to the 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
4. Application URL
We can get application URL with following command
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.
6. Add HTML Page
Now switch to your working branch and add a simple HTML page.
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.
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 set up 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
- list environments
jx get apps
- show the state of applications, what versions are in what environments.
So this is how Jenkins X automates the installation, configuration of Jenkins and some other software components. It also automates CI/CD for your applications on Kubernetes alongwith promotions through GitHub.
This post was originally published on Velotio Blog.
Velotio Technologies is an outsourced software product development partner for technology startups and enterprises. We specialize in enterprise B2B and SaaS product development with a focus on artificial intelligence and machine learning, DevOps, and test engineering.