Contributed by Vibhav Bobade, Red Hat (CDF Member)
The Good ol’ Days
Whenever someone says CI/CD, the first tool that comes to mind is Jenkins, even though it’s been around for more than 15 years (some of them in the form of Hudson). Today, there are a lot of alternatives available to users for various environments, but there is one that still reinvents itself again and again as time goes on, and that is Jenkins.
In the good old days of buying a server and renting out garage space to set up your website, Jenkins was one of the tools that was free and easy to set up on any server to act as a CI/CD system. Now, in a world where Kubernetes has swept the infrastructure space with containerization as a prerequisite to build and deploy microservices, Jenkins has had to keep up with the times and evolve.
Containerization and Life
Reintroducing Jenkins in a world of containers as businesses move from monoliths to microservices.
Jenkins as a Container Image
The first hurdle was to build Jenkins as a container image, which was necessary for running images as containers using Docker. Building a Java container brought other problems with it as Java itself doesn’t acknowledge the container jail and didn’t follow container resource limits properly. Java 10 brought along with it improved container support. Jenkins adoption in the container world was directly related to Java adoption in the container world.
Once this was accomplished, it was time to see how well this can scale and run Jenkins on Kubernetes.
Jenkins on Kubernetes
Jenkins is known for its modularity. The fact that the original design made it possible to extend Jenkins with plugins made the tool future-proof, to some extent. With extensions such as the Docker plugin, Jenkins had already started its journey to the cloud and with the creation and success of the Kubernetes plugin it was clear that Jenkins is not just accommodating to the cloud but helping existing users to be part of the journey as well.
But, the solutions provided by these plugins aren’t completely cloud native since they were created to have Jenkins jobs run on Kubernetes and not make Jenkins a cloud native CI/CD platform. For that to happen, Jenkins needs to leverage tools that are already resident in the cloud and delegate to these tools, acting as a central platform to curate and manage CI/CD pipelines.
Making Friends in the Cloud
Tekton Client Plugin
The first step to offloading pipelines to Kubernetes would be to leverage Tekton as the build engine to carry out all the Jenkins Kubernetes builds. The Tekton client plugin was created for this reason and was a starting point to understanding how this journey will unfold. The plugin was first showcased at cdCon 2020 and work is ongoing for the same with a GSOC 2021 project idea to extend the plugin to provide DSL for Tekton.
In the future, it should be possible for Jenkins to completely run all its jobs in Tekton and manage them directly through the Jenkins console.
Next: CloudEvents plugin
With microservices as the preferred architecture of the cloud and eventing as the primary way to let other microservices know when a particular change has taken place, the CloudEvents specification outlines the standardized way events should be structured in the cloud. This is being adopted by various tools including Tekton and will continue to be the standardized eventing substructure for the cloud. There’s a GSOC 2021 project idea for the same for Jenkins to allow emitting events and triggering jobs on certain events and hence, bringing Jenkins one step closer to operating with other technologies seamlessly in the cloud.
