Have you ever wondered the differences between Jenkins and Tekton?
Hi, I’m Christine, and today I’m going to talk to you all about the differences between
the two CI/CD tools that have the same goal, just achieve them in different ways.
Let's start with the basics. To understand Jenkins and Tekton we first need to understand
Continuous Integration and Continuous Delivery, or CI/CD for short.
CI/CD is the process of automating software development through testing, building, and deploying
applications. Jenkins and Tekton are two CI/CD tools designed to create what is called CI/CD
pipelines. To learn more about continuous integration and delivery check out the videos linked below
in our description, but for today I’m going to talk to you guys just about the similarities
and the differences between the two. Let's start with Tekton. To understand Tekton we
first need to understand Kubernetes. Kubernetes is a container orchestration platform designed
for automating application deployment management and scaling. Tekton runs on Kubernetes allowing
you to work with your CI/CD processes on the same cluster as your applications. This allows
you to easily scale your workloads simply by adding nodes to your cluster. Tekton comes
with a set of Kubernetes custom resources giving you the building blocks to easily configure
and manage your pipelines. You can automate Tekton either through the command line or
through the Tekton UI in the browser. All right. Now let's get into the architecture. So I’m
going to start by giving a simple example to explain CI/CD pipelines, better let's say
you have an application that you want to deploy into production, and you want to automate this
process by using Tekton. To keep it even simpler you're going to run the following procedures
on it. You're going to want to test your application, build it,
and then deploy it.
Each one of these operations becomes a step which is the smallest building block of Tekton.
Steps are where you can specify your commands, your arguments, your images to execute your
processes.
Once you've created your steps you can organize them into what is called tasks. And a single
task, you can have one step, or multiple steps, depending on the order and sequence you put
them in your
files. So a task runs on basically a pod, and a pod is a single instance of a running process
on your Kubernetes cluster, but we're not going to get into pods or clusters today if you
want to take a deeper dive again check out the videos linked below in our description.
So the great thing about tasks is that once defined you can reuse them in any pipeline
you want. So say I have another pipeline that I’m working on that's dedicated solely to
testing applications, and I want to use this test task because it has exactly what I’m
trying to do. All I would have to do is reference the task name in my other pipeline, no need
to rewrite anything or duplicate it. All right. So that brings me to the next topic which
is pipelines, and pipelines are a way of further organizing your tasks by controlling the execution
of them. Pipelines allow you to organize tasks concurrently or sequentially depending on
the order they're placed. And pipelines and tasks are Tekton custom resources that allow
you to control what gets inputted and what gets outputted from the tasks. For example,
an input would be the source code of your application that you're running through the
pipeline and an example of an output would be the image produced from your build task.
Okay. So inputs and outputs these are called pipeline resources and you can define them
in your tasks or your pipelines or you can put them in their own file depending how organized
you want to get.
Okay. So pipelines organize the execution of tasks, tasks organize the execution of steps, and
steps execute what you're trying to do. How can we automate this process even further?
What fires off our pipeline? So a concept called a PipelineRun, run triggers our pipeline and
you can declare that in the TriggerTemplate. And Tekton triggers
allow you to detect and extract information from events from various sources that allow
you to execute your tasks and pipelines. So what exactly does that mean? An event, an example
of an event would be let's say we want to fire off this pipeline every time one of our
developers
commits changes to the code.
There's a concept called the EventListener
which listens to specific events in this case it will be listening to our developer committing
code. Once that happens it will pick it up and it'll fire off our pipeline.
All right.
So, as you can see, Tekton, its process is very structured. To put it even more visually each one of these
concepts is just a file. The EventListener, the TriggerTemplate, the pipeline in each
individual task is its own file, a YAML file to be exact. And that's one of the biggest
features of Tekton is that it's object oriented, it's modular, it makes it very easy to reuse
and customize and organize, and it's super flexible. Okay. So I’m going to touch on one
more thing before we get into Jenkins and that is storage. How or where does Tekton store
its CI/CD data? The answer to that is workspaces. All right. So workspaces, or let me back up,
when we think of storage for Tekton think of basically a very large file system. Okay.
And workspaces allow tasks to declare part of that file system to use for storage. What
are we storing? The inputs and the outputs throughout this whole process. To take it a
step further there's a concept called a Persistent Volume Claim, or PVC, which lets you specifically
define the location of that storage volume, and it lets tasks share them amongst the process.
And you can typically define these in the trigger template. One more thing that you can
also define in our trigger template is service accounts. And service accounts basically handle
secrets, or authentication with Tekton. So you've got passwords, you've got tokens, you've got
SSH keys, and you want to make sure everything is secure before you run your steps.
Tekton runs this credential initialization on each pod before it executes steps keeping your
whole process secure which is very important. All right. So let's get into Jenkins now that
we've got a good understanding of Tekton.
The biggest difference between the two is that while Tekton runs on Kubernetes, Jenkins
runs on its own servers or VMs,
virtual machines.
So,
a part of Tekton running on Kubernetes means that it's made up of many different languages
like Node, Python, Ruby, Java. Jenkins however, is based solely on Java. You might be wondering
how can Jenkins even stand up to Tekton if it only supports features written in Java?
The answer to that is plugins. Jenkins plugins extend the capability of projects written
in languages other than Java. So say for example, you want to use a version control system like
Github you would need to install the Github plugin on your Jenkins machine to work with
it. Super easy to install, there's over a thousand different Jenkins plugins and you manage them
and install them through what's called the Jenkins UI. Similar to Tekton you can work
with Jenkins through the UI or the command line, but mostly people use the UI.
And on the UI is where you can manage your pipelines.
Okay.
So, in that sense it's very similar, but when it comes to the file structure that's where they differ.
Jenkins stores its configurations in what's called a Jenkins file which is one
large file
like so.
So,
going off the same example I used over here, you've got an application that you want to
deploy to production and you want to automate this process, but this time using Jenkins. What
you would do is you'd create a Jenkins file and you'd come in here and uh,
I’m going to use this,
you'd come in here and you declare your Jenkins pipeline.
You want to test, make sure there's no errors or bugs. You'll want to build it.
And then you'll deploy it.
And over here in Jenkins they're referred to as stages,
whereas in Tekton they're tasks.
And within each of these stages you'll have your steps which is really the meat of what
you're trying to do. It's where you have your scripts, your commands, your arguments parameters,
it's held in the steps. So as you can see, looking at the structure it's already a little different.
We've got a three-part pipeline defined in one file while over here we've got about six
different files. So the Jenkins file lets you configure not only your pipelines but you
can do a lot more other things in here. For example, you can define functions like exporting
archives, or security functions that you want to run throughout your process. There is methods,
for example, for authentication there's a method called credentials where you would
define in here.
And this deals with secrets and authentication. For firing off the pipeline similar to the
event listener and Tekton there's a concept in here called webhooks, which is very similar
you would program it to listen to specific events. For example, your developer committing
code changes or creating a pull request, you'd you define it like so,
and once that event happens your webhook would fire off your pipeline.
Okay.
So storage, conceptually Jenkins and Tekton are pretty similar. Jenkins uses file
systems just like Tekton, but when we think of storage with Jenkins they organize their
directories a little different. So Jenkins has this home directory called the Jenkins home.
and inside this directory
you'd have a lot of other directories where you'd store your build logs, your configurations,
your artifacts. For example, there's a plugin directory where you'd store your plugins, or
you'd have a secrets directory where you'd store your secrets, but most importantly I
think the workspace directory is where
you'd work with the most. And the workspace directory is your working directory wherever
you run your pipelines. So every time you run a pipeline, it's build generates some artifacts,
which think of it as files or images. It's kind of like outputs in Tekton, and you have
these artifacts and you want to use them in your next run or your next stage, and so you've
got to save them in your workspace so that they're not wiped out completely with the
next build. You would do so by storing it in your workspace or archiving it elsewhere. Okay.
So now that we've got a good understanding of the two you can kind of see how conceptually
Jenkins and Tekton are very similar. At the end of the day they're just trying to automate
the software development life cycle. They're just trying to make a developer's life easier
by getting rid of all the manual steps as much as possible. Let's review a little bit
about what I just went through the biggest differences. So, the biggest difference is one
Tekton runs on Kubernetes allowing you to easily scale your workloads to enterprise
levels. While Jenkins runs on its own servers or VMs, it's Java based and it uses plugins
to extend its capability. Number two, Jenkins, or sorry Tekton, it organizes each component
of its pipeline into its own file making it very organized and easy to, easy to pinpoint.
While Jenkins uses one large Jenkins file to store its configurations and and configure
its pipeline. And then lastly, going off of this file structure the fact that Tekton divides
or organizes each file into its own entity it allows it it to be fully portable. So once
defined anybody in your organization can come in and reference your pipeline, resource
it, resource and use it in in their own pipeline making it very efficient for them and not
having them reinvent the wheel every time. Whereas Jenkins it's a little less organized
and it's not as easy to pinpoint exactly what you're trying to reuse.
So, I hope that helped.
Thank you so much.
If you have any questions, please drop us a line below.
If you want to see more videos like this in the future, please like and subscribe.
And don't forget, you can grow your skills and earn a badge with IBM CloudLabs,
which are free browser based interactive Kubernetes labs.