Hello guys, how are you? I hope you’re all doing fine!
This will be a five part article, in which we’ll discuss:
- What is Continuous Delivery and why is that important?
- What are the available tools and how to choose one?
- Spinnaker: I want to sail in this one!
- Jenkins X: New way to look the good old Jenkins
- Concourse CI: New guy in town
I really hope you find this series useful, and if you do, please leave a comment or DM me on LinkedIn.
What is this new Jenkins?
Jenkins X is a tool specialized in continuous integration and continuous delivery around Kubernetes.
As we did using Jenkins, we could build our pipelines and use CloudBee's Kubernetes Plugin to spin up some pods, and make some deployments in a CI/CD environment. But, something was missing, we had to manage our multiple environments using Jenkinsfiles or shared libraries. Jenkins X comes to give us support in multiple environment deployment with multiple integrations with GitOps tools, Helm, Registries and others.
The main objective of Jenkins X is to accelerate the lead time for code committed to code in production, something that is crucial these days. Doing that we could also mitigate the recovery time from failures. You could read more about the concepts here.
Jenkins X has a great feature that is the import functionality. I have to say this is not 100% perfect, you may need to do some manual adjustments, but it saves a lot of time!
Another bright point to cover is the Serverless Jenkins X, we all know that serverless could be the new way to architect our environments, Jenkins X enables us to deploy serverless pipelines using Knative and Prow. Still in some kind of development so do not expect this to work right away.
How does it work?
Ok, let’s take a look at this architecture taken from the official website:
Now, let’s check each component involved in a Jenkins X pipeline.
Kubernetes and Container Runtime Interface
Basically, Jenkins X is supposed to run on top of Kubernetes. Hence its previous version being fully adopted by Helm, it was pretty straight forward that the new one would be around containers as well.
From the Jenkins X perspective a single Microservice is translated to a Pod, inside the Kubernetes world. Another object that changes a bit in perspective is the Namespace. In Jenkins X we have the concept of Environments, which we will see later in this article.
On top of everything, we have Helm that enables us to share manifest and Kubernetes' applications in an easy way.
Good Old Jenkins. Jenkins X is build upon Jenkins, using the Java JVM as an engine to build and run objects.
But, Jx is integrating a whole bunch of services making possible, in the near future, that others pipelines engines may be supported.
Environments are crucial to Jenkins X, they represent several forms to run your pipeline. They are the main component in Jenkins X, by default we have a development environment, which is translated to a Kubernetes Namespace.
Then, we could have many environments, like staging or production. We could even divide it by teams.
We can check all the environments running:
jx get environments
Draft is a tool which detects the language your app is written and then builds a Dockerized application around it. There are 8 current supported languages:
- JAVA (Maven, Gradle)
Is a tool made by Microsoft, and you could check the installation here.
Helm is a well known tool here for us, it has been recently released Helm v3, so you can expect great thing happening, make sure to stay tuned for more about it.
Helm is a tool which can wrap many Kubernetes manifest into a collection, called Chart. Charts can be stored in repositories to be used by anyone with access. The most common one is the Official Helm Chart Repository.
Git is fully supported on Jenkins X. Making possible to integrate with several Git Providers, like Gitlab, Github or Bitbucket.
There are many other, that you can check here.
How do we use it?
Well, first of all, we need to have git installed in our OS. If you are on Linux or MacOS, it is already there, just run the command below to check its version:
Now, we need to install the command line tool to use Jenkins X. Click here to read the official documentation.
To check if it is available run:
If everything is ok up to now, let’s run Jenkins X:
jx create cluster gke
Minikube is going to be deprecated, but you can still use it for test purposes. I’ll use GKE because it’s a little easier to integrate. After this, you must insert some option for our cluster, such as, regions, node count, master count, machine types, which version of Jenkins X we want to install and some GitHub connectivity.
At the end, it will prompt you with your admin password.
When it asks you the Github connection, you will have to create 2 tokens:
If you gave it the correct permissions, it will automatically create two repositories, one for staging and one of production.
Those repositories are the default ones. They do not serve any purpose for us.
After that, wait a couple minutes and run:
kubectl get ns
You will see a bunch of new Jenkins deployments. In order to access the web interface, run:
jx add app jx-app-ui
It will give you the URL for your web interface, even though we don’t necessarily need it.
If you want to create an app, we could follow the documentation, and use the SpringBoot(a Java app) to test our environment:
jx create spring
It will take a while, more or like to 5 or 7 minutes.
After that, you could check your application by running:
jx get apps
jx open --env staging
jx open --env production
You will receive your URL. Access it and you’ll see the default html page for Spring Boot.
I really hope you enjoyed this tutorial. If you have any questions, please leave a comment or send me a message on my In.