In another post I talked about CI/CD in a nutshell and its fundamentals, before going further on Tekton. In case you need, I suggest you reading that post before.
Now that we understand CI/CD practices, the importance of Cloud Delivery Foundation (CDF) as community and that Tekton is a graduated CDF project, we can deep dive into Tekton.
Let's see its internals and a brief yet complete tutorial on Tekton, integrating with Github, by building and delivering an application from development to production.
Tekton is an open-source framework for creating CI/CD systems.
Instead of using a proprietary CI/CD tool such as Github Actions, Gitlab, BitBucket or CircleCI, Tekton allows developers to easily create components that will build, test and deploy applications, using their own infrastructure.
Is this post for me ❓
- You deploy applications using Docker, Kubernetes or similar
- You use cloud-native design to guide you building standardized yet scalable applications in the cloud
- Also, you build and deliver applications using proprietary CI/CD tooling in the cloud
Other than that, you want to give a try running CI/CD in your own infrastructure, maybe having some cost reduction, why not?
Then this post is for you.
Why Tekton ❓
Advantages of using Tekton as a CI/CD tool:
- We can build reusable components and deploy them into our own infrastructure, similar to what Gitlab Runners do
- Tekton components are simply Kubernetes Operators that extend Kubernetes functionalities, so Tekton is very friendly to those who work on Kubernetes clusters
- The general idea is not that far from Gitlab CI, Github Actions or similar: we declare our pipeline usually using a YAML file
- It's open-source
- It's a graduated CDF project, which means a lot of companies are behind its maintenance, Google, Red Hat, SAP, Oracle, to name a few...
After an introduction, time to explore the building blocks of Tekton.
Installation
In the Kubernetes cluster, we can import all CRD's using kubectl. For now, let's install them using the Tekton pipeline release:
kubectl apply \ --filename \ https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml Tekton components
The main components of Tektons are:
- Steps
- Tasks
- Pipelines
There are more components to explore, but as for this article we'll focus on these three ones.
Steps
Steps are literally containers that run from images, and in essence we can give a name and provide an arbitrary script in the step.
Nice, but how do we create a Step in Tekton?
Simply we can't. Steps are pretty much like containers in Kubernetes, and as such we should group them into a higher abstraction similar to Pods, which in Tekton is called Task.
Tasks
Tasks are collections of steps, that you define and arrange in a specific order. A Task executes as a Pod in the Kubernetes cluster.
Let's create our first Task hello-task.yml that should have only one step and prints the message Hello in the STDOUT:
apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: hello-task spec: steps: - name: hello image: ubuntu script: > echo "Hello" Apply the yaml as usual in Kubernetes and check that the task was created in the cluster:
$ kubectl get tasks NAME AGE hello-task 19s However, we have only the task definition. We should be able to run the task, which would run a Task pod.
Tekton provides the TaskRun, which is an abstraction that runs an underlying Task (hello-task-run.yml).
apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: generateName: hello-task- spec: taskRef: name: hello-task In this example, we refer the underlying Task using the taskRef field.
Now, for TaskRun we have to use the kubectl create instead of apply, because the generateName does not work with the apply command.
kubectl create -f hello-task-run.yml Checking the taskruns:
$ kubectl get taskruns NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME hello-task-xvtgb True Succeeded 42s 28s And the pods:
$ kubectl get pods NAME READY STATUS RESTARTS AGE hello-task-xvtgb-pod 1/1 Running 0 13s Getting the pod logs in order to see if the message Hello is echoed:
$ kubectl logs hello-task-xvtgb-pod Hello Tasks are great, but if we want to build more robust CI/CD pipelines, we should group tasks into a higher abstraction, which in Tekton is called Pipelines.
Pipelines
Pipelines are collections of tasks, that you define and arrange in a specific order.
Let's create our first Pipeline. In the following example, we'll have a pipeline containing 2 tasks:
- 1 taskRef referencing to the Task previously created
- 1 taskSpec containing the Step for the new Task
apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: hello-pipeline spec: tasks: - name: hello-task taskRef: name: hello-task - name: bye-task taskSpec: steps: - name: bye image: ubuntu script: > echo "Bye" After kubectl apply, we should see the pipeline successfully created:
$ kubectl get pipelines NAME AGE hello-pipeline 5s As in Tasks, Pipelines are only definitions. We need another abstraction in order to run the pipeline, which is called PipelineRun.
apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: generateName: hello-pipeline- spec: pipelineRef: name: hello-pipeline Then:
$ kubectl create -f hello-pipeline-run.yml Check the pipelineruns:
$ kubectl get pipelineruns NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME hello-pipeline-zbbcr True Succeeded 10s 1s And the pods:
$ kubectl get pods NAME READY STATUS RESTARTS AGE hello-task-xvtgb-pod 0/1 Completed 0 25m hello-pipeline-zbbcr-hello-task-pod 0/1 Completed 0 82s hello-pipeline-zbbcr-bye-task-pod 0/1 Completed 0 82s Note that we have 2 pods for the hello-pipeline, because each Task runs as a Pod.
The hello task pod:
$ kubectl logs hello-pipeline-zbbcr-hello-task-pod Hello And the bye task pod:
$ kubectl logs hello-pipeline-zbbcr-bye-task-pod Bye Yay! 🚀
In this post we've seen an introduction to Tekton and an overview on its main components.
In the upcoming posts, we'll see the Tekton UI Dashboard and how to trigger Pipelines listening to external events such as Push/PullRequests in Github.
Stay tuned!
Top comments (0)