It’s a sign you’re getting old in this industry when the flow of new projects/tech seems overwhelming. Hell, I still think JSF is new and no-one should mess about with JSP or STRUTS. So I find the deluge of new terminology and ways of thinking sometimes hard to deal with.
So I’m going to write some real introduction blogs; and these are based on my own efforts to understand and, cough, embrace new technologies (grumble, good old days etc etc).
The first of these is an easy one; I have a soft spot for Tekton because of the logo. Yeah, I know that’s a little mad but that logo is just the coolest I’ve seen.
So what is Tekton? Well, I spent a lot of time in the past dealing with Jenkins (and Hudson before that; again see ‘too many projects’). With OpenShift 3 we had integrated Jenkins directly into the project to provide the functionality of automated pipelines. And it was great; we extended the DSL for Jenkins so it could make direct calls into the OpenShift side.
The only downside was the fact that you (as OpenShift) had to pass off full control into the Jenkins engine. Jenkins would run the pipeline and then report, success or failure, back into OpenShift. Which was ok; the DSL was great and you could do some fun stuff with it but a lack of inner-pipeline visibility meant that OpenShift had to go off and have a coffee, or whatever it was doing, whilst the pipeline was in flight. You had to use the Jenkins UI to track the progress.
Back to absolute beginner time; the concept of a pipeline was originally produced to pull together the steps of a complex process, such as building, testing and deploying an app, into a single automated ‘hands-off’ process. In the old days we used to write scripts to do this which required maintenance and a good deal of contextual knowledge as to how to run it and also how to interpret the results.
Hudson, and then Jenkins when Oracle took Hudson, was created to address this need. Fast forward to now, on the verge of the Kubernetes revolution. Tekton’s goal is to produce a fully integrated atomic pipeline approach within Kubernetes itself; this is a superb thing because a: you have complete visibility from the framework into the progress of a pipeline and b: the way they have designed Tekton means that it takes advantage of the nature of containers themselves.
So let’s start with the absolute basics. Tekton provides the concept of what is called a Task. This is a singular atomic component which provides a template for executing a singular component of a pipeline, but it gets much better than that. A task is executed using another Kubernetes object, the TaskRun. This is an audited execution of the task; what that means in English is that the Task defines what makes up the operations to be executed, and the TaskRun is a runthrough of it.
It gets even better. The TaskRun is an executed Container; effectively anything you can containerise can be executed as a Task; this makes the concepts of the atomic components within Tekton extremely powerful.
Like most Kubernetes things the complexity comes from combination of simple atomic components, and this is where Pipelines come in. These are Kubernetes objects that define the combination of the Tasks to make a Pipeline. They are the cookie-cutters for the Pipeline processes themselves and like the Tasks are no actually executed.
The execution of a Pipeline is done using a PipelineRun object, which represents a single run-through of the combined tasks defined in a Pipeline object. In fact a PipelineRun consists of a number of TaskRuns that use the Tasks do define what they do.
With a Pipeline you can combine the Tasks to be executed in sequence and/or in parallel, leading to a massive amount of potential automated complexity.
I love the idea of being able to chain together executions of containers, but Tekton goes one step further by allowing persistent storage to be applied to multiple Tasks; what this means in simple terms is that you could have a task that, say, does a git clone into a shared Workspace (this is the terminology used within Tekton). It could then run another Task using the same Workspace that executes a Maven build. These Workspaces provide, sic, the workspaces for multiple Tasks which makes persisting content and resources simple.
The great thing for me is that because a: the Tasks use containers and b: the Tekton objects are fully integrated into the Kubernetes object model this makes Pipelines not just about dev/CICD. *Anything* you can do that requires automation or sequential steps can be expressed and executed as a Pipeline; a good example of this is that there is a Task (more on the sharing of these in a second) that provides a pre-built image with the command line ‘oc’ for interacting with OpenShift, along with a parameterised command. So anything you can do via the RESTful API into OpenShift you can do in an atomic Task.
You could create Users, apply network policies, enforce limit-ranges, whatever via a repeatable, parameterisable Pipeline. Using the system itself to automate changes to the system is just cool.
On Tasks – the fantastic Tekton website (that logo is great) has a hub where you can download prebuilt Tasks for a lot of atomic actions for Pipelines; in addition if you are using OpenShift it provides out-of-the-box ‘cluster’ tasks which have OCP-ish stuff in them, like the whole Source-2-Image builds, buildah etc.
The hub is at http://hub.tekton.dev and is a great resource (I found when Tekton started that the Tasks were few and far between and spent a lot of time, with the now deprecated PipelineResource object, building my own tasks; this hub is a massive timesaver).
So, enough of an overview, let’s look at some basic examples to show you how to do it.
Firstly, an example task:
apiVersion: tekton.dev/v1alpha1 kind: Task metadata: name: task1ubi spec: steps: - name: id image: registry.access.redhat.com/ubi8/ubi:latest command: - cat args: - /etc/redhat-release - name: echo image: registry.access.redhat.com/ubi8/ubi:latest command: - echo args: - "hello world"
Yeah, I know, ‘Hello World’. I reckon if you totted up the number of lines of code that were written world-wide for Hello World applications we’d all be a little ashamed of the time we’ve burnt, but that’s another discussion.
This task has two steps; note that a task, whilst atomic in terms of the pipeline, can have multiple individual steps (and those steps can be different images). There’s a great overview in depth on the Tekton git repo around steps at https://github.com/tektoncd/pipeline/blob/main/docs/tasks.md#defining-steps
Now for a very simple Taskrun; this definition will cause Tekton to execute a single atomic task (defined in the code above):
apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: runubi1 spec: taskRef: name: task1ubi
Obviously that’s a dead simple example; if you look at the docs for Taskrun on the Tekton site itself there’s a lot more you can do, including actually embedding the task definition into the Taskrun itself – have a peek at https://tekton.dev/docs/pipelines/taskruns/ for a full overview of the capabilities of Taskrun.
Now the good bit; an example of a Pipeline definition:
apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: filetest1 spec: tasks: - name: task4 taskRef: kind: Task name: task4 workspaces: - name: working workspace: working - name: task5 runAfter: - task4 taskRef: kind: Task name: task5 workspaces: - name: working workspace: working - name: task6 runAfter: - task5 taskRef: kind: Task name: task6 workspaces: - name: working workspace: working workspaces: - name: working
Tiny bit of a pitch here for OpenShift; the Ux in OpenShift has a great little ‘pipeline builder’ which allows you to visually stick the tasks together; I tend to use that to build the initial pipeline and then the yaml to shape it.
I chose this example to show some other features of the descriptive way of defining these pipelines; note that the tasks have an optional ‘runAfter’ attribute which allows for sequencing information. And all of these example tasks share a piece of persisted storage, exposed as a Tekton ‘workspace’, which is defined across the pipeline at the end, but referenced within the tasks by name for those that use it.
What I really like about the whole Tekton piece, other than the brilliant logo, is there’s very little restriction on what you can create, only your imagination; I see a situation where the whole of OpenShift day 2 is controlled by some very clever Tekton pipelines.
Anyway, enough for now; I’ll do some more of these ‘Absolute Beginner’ overviews on the other bits of tech as I gradually understand them.