Tekton is a Kubernetes native open source framework for creating continuous integration and continuous delivery (CI/CD) systems. It also facilitates end-to-end (build, test, deploy) application development across multiple cloud providers or internal enterprise systems by abstracting the underlying implementation details.

Tekton profile

Originally known as Knative Build, Tekton has since been reorganized as its own open source project, with its own management organization, and is now a project of the Linux Foundation. Tekton provides a container image build and deployment workflow within a cluster; in other words, it is a continuous integration (CI) and continuous delivery (CD) service. It consists of Tekton pipes and several supporting components, such as Tekton CLI, triggers, and directories.

Tekton is a Kubernetes native application. It is installed and runs as an extension on the Kubernetes cluster and includes a set of Kubernetes custom resources that define building blocks that you can create and reuse for your pipes. Since Tekton is a K-native technology, it is very easy to scale. When you need to increase your workload, you simply add nodes to your cluster. It is also easy to customize due to its extensible design and community contributed component library.

Tekton is ideal for developers who need CI/CD systems to get their work done and platform engineers who build CI/CD systems for developers in their organizations.

Tekton components

Building a CI/CD pipeline is a profound undertaking, so Tekton provides tools for each step. Here are the main components provided by Tekton.

  • Pipeline pipes define a set of Kubernetes custom resources as building blocks for assembling CI/CD pipes.
  • Trigger A trigger is a Kubernetes custom resource that allows you to create pipes based on information extracted from event payloads. For example, you can trigger the instantiation and execution of a pipe every time a merge request against a Git repository is opened.
  • CLIThe CLI provides thetknThe command line interface allows you to interact with Tekton from the terminal.
  • The Dashboard is a web-based graphical interface for Tekton pipelines that displays pipeline execution information.
  • The Catalog catalog is a high-quality, community-contributed library of Tekton artifacts (tasks, pipelines, and so on) that you can use for your own pipelines.
  • HubHub is a web-based graphical interface for accessing the Tekton directory.
  • Operator Operator is a Kubernetes Operator mode that allows you to install, update, upgrade, and delete Tekton projects on a Kubernetes cluster.
  • Chains is a Kubernetes Custom Resource Definition (CRD) controller that allows you to manage supply chain security in Tekton. It is currently a work in progress.
  • Results Results are intended to help users logically group CI/CD workload histories and separate long-term result storage from pipe controllers.

Tekton term

  • Steps Steps are the most basic entities in a CI/CD workflow, such as running some unit tests for a Python web application or compiling a Java program. Tekton performs each step using the supplied container image.

  • Tasks A task is a collection of steps that take place in a particular order. Tekton runs tasks as Kubernetes Pods, with each step becoming a run container within the POD.

  • Pipelines PIPELINES are collections of tasks arranged in a specific order. Tekton collects all the tasks, connects them into a directed acyclic graph (DAG), and executes the graph in sequence. In other words, it creates a few Kubernetes pods and ensures that each pod completes successfully as expected.

  • PipelineRun as its name suggests, PipelineRun is the concrete execution of pipelines.

  • TaskRun (TaskRun) a TaskRun is the specific execution of a task. Task run is also available when you choose to run a task outside of a pipe, allowing you to see how each step in the task executes.

Create your own CI/CD pipeline

The easiest way to get started with Tekton is to write a simple pipe of your own. If you use Kubernetes every day, you’re probably familiar with YAML, which is exactly how Tekton pipes are defined. Here is an example of a simple pipe that clones a code base.

First, create a file called task.yaml and open it in your favorite text editor. This file defines the steps you need to perform. In this case, that’s cloning a version library, so I’ll name this step clone. This file sets some environment variables and then provides a simple shell script to perform the clone.

Next comes the task. You can think of a step as a function called by a task that sets the parameters and workspace required by the step.

apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: git-clone spec: workspaces: - name: output description: The git repo will be cloned onto the volume backing this Workspace. params: - name: url description: Repository URL to clone from. type: string - name: revision description: Revision to checkout. (branch, tag, sha, ref, etc...) type: string default: "" steps: - name: clone image: "Gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/git-init:v0.21.0 env" : - name: PARAM_URL value: $(params.url) - name: PARAM_REVISION value: $(params.revision) - name: WORKSPACE_OUTPUT_PATH value: $(workspaces.output.path) script: | #! /usr/bin/env sh set -eu CHECKOUT_DIR="${WORKSPACE_OUTPUT_PATH}" /ko-app/git-init \ -url="${PARAM_URL}" \ -revision="${PARAM_REVISION}" \ -path="${CHECKOUT_DIR}" cd "${CHECKOUT_DIR}" EXIT_CODE="$?" if [ "${EXIT_CODE}" != 0 ] ; then exit "${EXIT_CODE}" fi # Verify clone is success by reading readme file. cat ${CHECKOUT_DIR}/README.mdCopy the code

Create a second file called pipeline.yaml and open it in your favorite text editor. This file defines the pipeline by setting important parameters, such as the workspace where tasks can be run and processed.

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
 name: cat-branch-readme
spec:
 params:
   - name: repo-url
     type: string
     description: The git repository URL to clone from.
   - name: branch-name
     type: string
     description: The git branch to clone.
 workspaces:
   - name: shared-data
     description: |
       This workspace will receive the cloned git repo and be passed
       to the next Task for the repo's README.md file to be read.
 tasks:
   - name: fetch-repo
     taskRef:
       name: git-clone
     workspaces:
       - name: output
         workspace: shared-data
     params:
       - name: url
         value: $(params.repo-url)
       - name: revision
         value: $(params.branch-name)
Copy the code

Finally, create a file called pipelinerun.yaml and open it in your favorite text editor. This file is actually running the pipe. It invokes the parameters defined in the pipe (which in turn invokes the tasks defined in the task file).

apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: name: git-clone-checking-out-a-branch spec: pipelineRef: name: cat-branch-readme workspaces: - name: shared-data volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi params: - name: repo-url value: https://github.com/tektoncd/pipeline.git - name: branch - the name value: release - v0.12. XCopy the code

The advantage of scheduling your work in separate files is that git-Clone tasks can be reused in multiple pipes.

For example, if you want to do end-to-end testing for a pipeline project, you can use the Git-Clone task to make sure you have a new copy of the code that needs to be tested.

conclusion

As long as you’re familiar with Kubernetes, getting started with Tekton is just as easy as adopting any other K-Native application. It has a lot of tools to help you create pipes and dock with your pipes. If you like automation, try Tekton!