What is Tekton?
Tekton is a ‘Pipeline as Code’- Continuous Integration and Delivery Platform, which has been optimized for containers. Tekton was initially launched as a project by the CDF (Continuous Delivery Foundation). This is intended to provide manufacturer-independent and uniform specifications for CI / CD.
The project was originally launched by Google. In the meantime, however, other large companies have also been involved in it (IBM, CloudBees, Red Hat). There is also a community that is growing day by day and a exciting future of Tekton gives hope.
How does Tekton work?
Tekton works serverless. This has the big advantage that you don’t need a central build server.
However, this means that some logic has to be shifted into the pipelines.
The resources in Tekton are divided into Deskriptive Ressourcen and Runtime Ressourcen.
Deskriptive Ressourcen are used, as the name suggests, to describe the respective resource.
This means that a task can be defined in such a way that it can be reused, for example.
Runtime Ressourcen are used to provide the descriptive resources, information at runtime
to deliver.
Steps, Tasks and Pipelines
In Tekton, as in Jenkins, there are pipelines. These pipelines consist of at least one task. Every task
again has one or more steps.
A step is an operation in the pipeline. Here, for example, code is compiled or unit tests are carried out.
Each step is carried out in its own container. For this purpose, a separate image can be defined in each step.
For example, to build a Maven application, you need a container that Maven has already installed.
For example, Tekton already provides an image for this.
gcr.io/cloud-builders/mvn
Tekton Pipeline Entities
Tekton pipelines basically consist of 5 objects, some of which we have already got to know above to have.
-
Task: A task describes several steps that are executed in the container. The task specification is similar like a Kubernetes pod. Each task is carried out in its own Kubernetes pod. This will normally be no data exchanged between the tasks. However, you can exchange data by sending outputs to the next task passes on as input. -
TaskRun: A TaskRun is an object that triggers a task. Here are input and output parameters defines which are required for the task to run. -
Pipeline: A pipeline consists of several tasks that are executed. -
PipelineRun: Analog TaskRun is a PipelineRun, an object that triggers the execution of the pipeline. -
PipelineResource: A PipelineResource defines which inputs and outputs are used for a task. For example, you could define a Git repository as input and an image registry as output
There is another object Run, which is still in the alpha version as of today. We
but will give more information here as soon as the alpha status is exited.
Input and Output Resources
Every task and every pipeline can define inputs and outputs. So if you want to build software from a VCS and then deploy it in an artifact repository, so you can specify your Git repository as input and as output his Nexus.
Next steps
Next, we’ll look at Tekton in action. In particular, we want to look at how to create and setup a pipeline for a project and what obstacles there might be.
We will be learning Labels, WhenExpressions (Conditions in the past), Pod templates and Tekton Triggers and have a closer look and the Tekton Dashboard and the Tekton Catalog.
This text was automatically translated with our golang markdown translator.
