Categories
Uncategorized

A Complete Beginner’s Introduction to Tekton….

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.

Pictured – I liked the DSL a lot

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.

By utherp0

Amateur thinker, professional developer

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s