Introduction
Tekton is a powerful tool for building continuous delivery pipelines using modern infrastructure. The project has been moving very quickly and has added a lot of awesome features recently, but due to the (necessary and wise) cancellation of conferences through the spring and summer of 2020 they have not gotten the attention they deserve. We’ve been working with Tekton as an upstream component of our devops automation service relay.sh, so I thought our new blog be a great chance to get the word out.
This 2-part blog series aims to give an overview of some core concepts for background and then dive into some more advanced technical topics and updates for Tekton. If you’re brand new to Tekton, check out Christie Wilson and Kim Lewandowski’s talk on “Next Generation CI/CD with GKE and Tekton” from Google Cloud Next 2019. If you want to skip ahead, you can go straight to Part 2.
Who’s Using Tekton?
It’s important to note that Tekton is more of a platform for building CD tools around, rather than a user facing product. The most advanced example of products built on Tekton is probably Jenkins X, a re-imagining of the ubiquitous Jenkins CI tool for cloud native applications. Jenkins X provides the user-facing GUI, a higher-level YAML dialect for describing pipelines, and a powerful GitOps workflow. To borrow git’s terminology, Jenkins X is the “porcelain”, while Tekton provides the “plumbing”: the pipeline execution engine that’s responsible for ordering the steps in a pipeline, launching pods that get the build/test/deploy work done, passing state and secrets around, etc. Ethan Jones at Cloudbees wrote a great blog post describing the history of the projects and the rationale behind the Jenkins X team’s decision to consolidate on Tekton as the one-and-only execution engine.
Similarly, here at Puppet, we’ve been using Tekton as the plumbing under the service formerly known as Project Nebula — now out of incubation and renamed Relay — for the last year. Relay lets you define workflows of operations tasks and trigger them by linking Relay to external services that you already use, like Github or PagerDuty. The goal is to fill in what we see as an emerging category of event-driven devops automation, now that desired-state and ad-hoc automation are well understood. When an event comes in to the service, Relay launches a container to figure out how to handle it (we’re calling this a trigger action). It can extract values from the incoming event and use them to fill in parameters in a workflow, which is launched as a Tekton pipeline on GCP. Similar to Jenkins X, workflows are written in simple YAML that the service translates into Tekton CRDs; Tekton then handles dependencies, ordering, and state management between workflow steps.
A Brief History of the (Tekton) Universe
Tekton is a project that evolved from an internal Google tool that used Knative to build and deploy software. In 2018, it was spun out as an independent project and donated to the Continuous Delivery Foundation, similar to Kubernetes’ donation to the CNCF.
The core component, Tekton Pipelines, runs as a controller in a Kubernetes cluster. It registers several custom resource definitions which represent the basic Tekton objects with the Kubernetes API server, so the cluster knows to delegate requests containing those objects to Tekton. These primitives are fundamental to the way Tekton works, and once you’ve got Tekton and the Tekton Dashboard up and running, you can view them like this:
> kubectl get crd | rg tekton | cut -f 1 -d ' '
clustertasks.tekton.dev
conditions.tekton.dev
extensions.dashboard.tekton.dev
pipelineresources.tekton.dev
pipelineruns.tekton.dev
pipelines.tekton.dev
taskruns.tekton.dev
tasks.tekton.dev
If the nomenclature here feels confusing, don’t feel bad — it is complicated! Each tool in the space uses slightly different terms; this is something we’re working on standardizing in the CDF Interoperability SIG. (We’d love your input!) Tekton’s usage of these terms — and the CRDs which implement the hierarchy of objects — maps closely to this list of CRDs (via the sig-interop Vocabulary definitions doc):
- Step : a specific function to perform.
- Task : is a collection of sequential steps you would want to run as part of your continuous integration flow. A task will run inside a pod on your cluster.
- ClusterTask : Similar to Task, but with a cluster scope.
- Pipeline : stateless, reusable, parameterized collection of tasks. Tasks are linked together in a Pipeline, which describes the end-to-end deployment for an application.
- PipelineRun : an instantiation of a Pipeline definition, filling in the Pipeline’s parameters with concrete values
- Pipeline Resource : objects that will be input to or output from tasks
- Trigger : Triggers is a Kubernetes Custom Resource Definition (CRD) controller that allows you to extract information from event payloads (a “trigger”) to create Kubernetes resources.
Notable omissions from this list are “Steps”, which don’t have their own CRD because they’re the smallest unit of execution which are always contained inside a Task; plus Conditions and Dashboard Extensions, which are still optional and experimental — but very exciting! We’ll talk about these more in part 2.
If you’re working on an in-house CD platform, and especially if you’re looking at ways to deliver cloud-native applications with a toolchain that looks and feels like the apps it’s managing, Tekton could be a good fit. Read on if these capabilities sound intriguing…
Top comments (0)