Write your first CI/CD pipeline in Kubernetes with Tekton | Opensource.com

Write your first CI/CD pipeline in Kubernetes with Tekton

Tekton is a Kubernetes-native open source framework for creating continuous integration and continuous delivery (CI/CD) systems.

Plumbing tubes in many directions
x

Subscribe now

Get the highlights in your inbox every week.

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

Introduction to Tekton

Tekton, known initially as Knative Build, later got restructured as its own open source project with its own governance organization and is now a Linux Foundation project. Tekton provides an in-cluster container image build and deployment workflow—in other words, it is a continuous integration (CI) and continuous delivery (CD) service. It consists of Tekton Pipelines and several supporting components, such as Tekton CLI, Triggers, and Catalog.

Tekton is a Kubernetes native application. It installs and runs as an extension on a Kubernetes cluster and comprises a set of Kubernetes Custom Resources that define the building blocks you can create and reuse for your pipelines. Because it's a K-native technology, Tekton is remarkably easy to scale. When you need to increase your workload, you can just add nodes to your cluster. It's also easy to customize because of its extensible design and thanks to a community repository of contributed components.

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

Tekton components

Building CI/CD pipelines is a far-reaching endeavor, so Tekton provides tools for every step of the way. Here are the major components you get with Tekton:

  • Pipeline: Pipeline defines a set of Kubernetes Custom Resources that act as building blocks you use to assemble your CI/CD pipelines.
  • Triggers: Triggers is a Kubernetes Custom Resource that allows you to create pipelines based on information extracted from event payloads. For example, you can trigger the instantiation and execution of a pipeline every time a merge request gets opened against a Git repository.
  • CLI: CLI provides a command-line interface called tkn that allows you to interact with Tekton from your terminal.
  • Dashboard: Dashboard is a web-based graphical interface for Tekton pipelines that displays information about the execution of your pipelines.
  • Catalog: Catalog is a repository of high-quality, community-contributed Tekton building blocks (tasks, pipelines, and so on) ready for use in your own pipelines.
  • Hub: Hub is a web-based graphical interface for accessing the Tekton catalog.
  • Operator: Operator is a Kubernetes Operator pattern that allows you to install, update, upgrade, and remove Tekton projects on a Kubernetes cluster.
  • Chains: Chains is a Kubernetes Custom Resource Definition (CRD) controller that allows you to manage your supply chain security in Tekton. It is currently a work-in-progress.
  • Results: Results aims to help users logically group CI/CD workload history and separate out long-term result storage away from the pipeline controller.

Tekton terminology

  • Step: A step is the most basic entity in a CI/CD workflow, such as running some unit tests for a Python web app or compiling a Java program. Tekton performs each step with a provided container image.
  • Task: A task is a collection of steps in a specific order. Tekton runs a task in the form of a Kubernetes pod, where each step becomes a running container in the pod.
  • Pipelines: A pipeline is a collection of tasks in a specific order. Tekton collects all tasks, connects them in a directed acyclic graph (DAG), and executes the graph in sequence. In other words, it creates a number of Kubernetes pods and ensures that each pod completes running successfully as desired.
  • PipelineRun: A PipelineRun, as its name implies, is a specific execution of a pipeline.
  • TaskRun: A TaskRun is a specific execution of a task. TaskRuns are also available when you choose to run a task outside a pipeline, with which you may view the specifics of each step execution in a task.

Create your own CI/CD pipeline

The easiest way to get started with Tekton is to write a simple pipeline of your own. If you use Kubernetes every day, you're probably comfortable with YAML, which is precisely how Tekton pipelines are defined. Here's an example of a simple pipeline that clones a code repository.

First, create a file called task.yaml and open it in your favorite text editor. This file defines the steps you want to perform. In this example, that's cloning a repository, so I've named the step clone. The 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 that gets called by the task, and the task sets parameters and workspaces required for steps.

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.md

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 a workspace where the task 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)

Finally, create a file called pipelinerun.yaml and open it in your favorite text editor. This file actually runs the pipeline. It invokes parameters defined in the pipeline (which, in turn, invokes the task defined by 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-name
     value
: release-v0.12.x

The advantage of structuring your work in separate files is that the git-clone task is reusable for multiple pipelines.

For example, suppose you want to do end-to-end testing for a pipeline project. You can use the git-clone task to ensure that you have a fresh copy of the code you need to test.

Wrap up

As long as you're familiar with Kubernetes, getting started with Tekton is as easy as adopting any other K-native application. It has plenty of tools to help you create pipelines and to interface with your pipelines. If you love automation, try Tekton!

Person using a laptop

YAML looks simple so why is it so hard to write? Learn the two secrets to YAML success.
Working from home at a laptop

Knative is a great way to get started quickly on serverless development with Kubernetes.
Tips and gears turning

Build your continuous integration/continuous delivery adoption plan by looking back at the top articles of 2020.

About the author

Open Enthusiast, Open Source Evangelist
Savita Ashture - Bangalore, India I am a Senior Software Engineer at Red Hat India, Bangalore. I am an Open-Source enthusiast who contributes to Open Source in every possible way. I have working experience on Public, Private Cloud, Kubernetes, Knative, Service Mesh etc... around Cloud native projects.Currently full time contributor to Tekton Project. I have presented my work at different conferences and Basically I am more passionate about speaking at conferences.