Tekton is a CI/CD process automation tool natively integrated with the Kubernetes cluster and tailored to the specificity of DevOps processes in the Cloud area (Cloud Native CI/CD).
The Tekton project was initiated by Google and is an open-source project. Due to its versatility and open architecture, it is becoming more and more popular and is used, among others, on the IBM Cloud, Open Shift and WMware Tanzu platforms.
Using Tekton, we can automate CI/CD processes in the area of building, testing and deploying microservices on a Kubernetes cluster. Processes configured in Tekton will be run on the K8S cluster, and the configuration of this process will be stored in Kubernetes objects. The source files for this configuration will be yaml files and can be versioned in the code repository.
Tekton has been divided into modules. Each functional area requires the installation of components from the appropriate module on the K8S cluster.
Tekton uses Kubernetes Custom Resource Definitions extending the available Kubernetes APIs with new objects after installing Tekton on the K8S cluster. The objects are described and parameterized in yaml files, and then with the kubectl command, we create their representation through the API on the Cluster in the context of the selected context (namespace).
The foundation of Tekton is the Pipelines module that defines the objects for building the CI/CD process. When defining processes, we have several types of structural objects at our disposal. Below, in the article, the basic ones will be described to present how the CI/CD process at Tekton is built.
Tekton has been divided into modules. Each functional area requires the installation of components from the appropriate module on the K8S cluster.
Tekton uses Kubernetes Custom Resource Definitions extending the available Kubernetes APIs with new objects after installing Tekton on the K8S cluster. The objects are described and parameterized in yaml files, and then with the kubectl command, we create their representation through the API on the Cluster in the context of the selected context (namespace).
An object of this type describes the definition of a single task in the process.
An example of such a task can be e.g. an image-building operation.
The basic attributes that describe this type of go object are:
The commands and tools that we will use in steps must be containerized. Thanks to this approach, all steps of the task can be executed as a sequence of dependent processes running on a Kubernetes cluster.
The basic attributes that describe this type of go object are:
The commands and tools that we will use in steps must be containerized. Thanks to this approach, all steps of the task can be executed as a sequence of dependent processes running on a Kubernetes cluster.
The steps may additionally have other resources defined, e.g. volume mount pointing to the volume to be mounted to the container when the task is started.
Another basic type of object describing the processes in Tekton necessary to understand the principle of its operation is Pipeline.
It defines the association of a task sequence into a complex multitasking process (e.g. tagging, versioning, saving an image to a repository, testing).
Tasks within one Pipeline can be made dependent on each other and performed sequentially or in parallel. We can use the output from one task as input to another. We can use the Conditions conditions under which the task is to be performed.
To create the Tasku or Pipeline execution process, we need to create one of the Runs type objects. Tekton offers the following facilities:
TaskRuns - containing the runtime configuration of a previously defined task of the Task type (the Task object can also be defined directly in TaskRun) with specific parameters such as input, output and definition of the full context and resulting in running the task in the context described above on the cluster.
PipelineRun - Similarly to TaskRun, containing a description of the parameters for launching the previously defined Pipleline in a specific context, including the context of a service account with a specific authorization context (Service Account parameter).
To create process definitions, objects supporting the definition of common task operating contexts, such as Workspace or PipelineResource, are additionally used. (we will not describe them in detail here)
When implementing the declarative process description, apart from Tekton's objects, we also have standard K8S objects useful for parameterization, such as ConfigMaps or Secrets. When defining processes, we can also define how it is to be run in the context of the configuration of K8S objects in our cluster, e.g. what type of feed should be used to perform a given Task or Pipeline.
Objects from the Triggers area are used to automatically (initiated by the occurrence of a specific event) start the processes defined in Tekton:
EventListener defines an object based on which Tekton will create a service that enables sending events to it (via HTTP protocol and JSON objects). The description of such a definition will include a reference to two previously defined objects. Object type TrigerBinding describing how the input message is to be processed into a set of Tekton parameters from the JSON object (TrigerBinding) so that Tekton can pass them further to TaskRuns and PipelineRuns. Defining mapping, we have a JSON Path at our disposal and we can map parameters from JSON objects.
The second reference is an indication of a previously created object of the TempateTrigger type, describing how Tekton is to react to the delivery of the event message. It allows to associate the received event with the appointment of an instance of the PiplineRun or TaskRun object that results in the launch of a specific process in Tekton.
The result of creating a EventListener in the object will be deployed by Tekoton on the cluster of a service that enables receiving Http JSON messages and initiating processes. Object parameterization Event Listener also enables securing service access and influencing the specifics of deployment on a cluster. Additionally, we have standard interceptors for WebHook communication and communication with message sources such as GitHub, GitLab, and BitBucket.
Services started after creating the Event Listener object are exposed as Kubernetes Service objects. To be able to access them from services outside the cluster (e.g. if we want to subscribe to commit events from GitHub), they must be previously made available via Ingress.
To manage objects from the level of the web console, Tekton provides the Tekton Dashboard component.
We can create Teknon objects by defining the process and run Task and Pipelines through Runs objects. The console shows logs from the process and the status of individual stages of execution. The console is an independent component that must also be installed on the cluster in advance.
Tekton is a very universal tool for automating Cloud Native CI/CD processes on Kubernetes clusters. We can build and implement services for many independent environments in Cloud and Multi-Cloud while maintaining security mechanisms and environment isolation. The process created in Tekton is composed. Tekton is a flexible platform and can be integrated with other CI/CD tools we already have, such as Jenkins.