Tekton on IBM Cloud — Level 1 Hello World Part: 1

Daniel Butler
5 min readJan 23, 2020

--

Please start at the introduction if you have not come from there: https://medium.com/@dannyeb/tekton-on-ibm-cloud-introduction-625d9af683e9

Now we have an idea of what Tekton is how do we actually implement it? To investigate this we will start at level 1 and create a hello world pipeline. It will simply echo hello world to the output console. This will be the base of our pipeline and as we advance I will iterate and add more functionality at each level. We will do the following:

  • Create a Tekton pipeline definition in Github
  • Create a Toolchain in IBM Cloud to run our pipeline
  • Execute the pipeline

Create a Tekton Pipeline Definition

Your pipeline will consist of YAML files which are native Kubernetes manifests describing the various custom resource(CRD’s) that make up Tekton. While an understanding of Kubernetes is not required to use Tekton it would be helpful.

Let’s start by creating a new GitHub repository or forking the example here https://github.com/danielbu-ibm/Tekton-Tutorial. I prefer starting fresh and learn more by typing my self but I’ll leave that up to you to decide. Typically you will have a .tekton folder in the root of your repository but this is not required. You can see in my example repository I have divided my pipelines by level and put the Tekton directory inside there. This is just to make it easier to find things during the tutorials.

If you look in level-1/.tekton directory you can see we are going to create 5 files.

Here is a visualization of what is going on.

The hello-listener(EventListener) is the front door. On the backend, it creates a Kubernetes service with a listener pod on the endpoint. It will wait for something to post to it and generates an event starts the whole process when it does. The hello-binding(TriggerBinding) lets you capture fields from the event and stores them as a parameter which can be used by the pipeline. It has access to the HTTP JSON body and the Headers and can map them to parameters. Next, the hello-trigger-template(TriggerTemplate) tells Tekton what to do when the event occurs. In our case, we want to trigger the hello-pipeline(Pipeline). In turn, the pipeline defines a list of tasks we wish to run. Tasks are where the actual work happens. In our case, we only have the hello-task(Task), which will echo hello world. I feel this is the minimum practical pipeline, but there are other ways of running tasks in Tekton which I will not cover now. Lets deep dive into each of these components.

Hello-listener

So let’s break this down. If you are familiar with Kubernetes manifests you’ll recognize a lot of this. If this is completely new to you I will go through it line by line. The first 5 lines will be quite similar across all the YAMLs but this is just the basics and a lot more could be added here. For more details see the full EventListener documentation

  • apiVersion Which version of the Kubernetes API you’re using to create this object
  • kind - What kind of object you want to create, an EventListener
  • metadata - Specifies data to uniquely identify the EventListener resource object, for example, a `name`
  • spec - What state you desire for the object
  • triggers - Is the object we want which contains a list of other properties
  • template - Is the name of the TriggerTempate we want to attach to this event. More on this next

Hello-trigger-binding

The binding is required so even though we don’t really need it for this example we just set it with some hardcoded values for now. For more details see the full TriggerBinding documentation

  • apiVersion Which version of the Kubernetes API you’re using to create this object
  • kind - What kind of object you want to create, a TriggerBinding
  • metadata - Specifies data to uniquely identify the TriggerBinding resource object, for example, a `name`
  • params - A list of parameters you wish to pass to your pipeline

Hello-trigger-template

We can see the same required fields for Kubernetes. Then you can see the resourceTemplate where we define what we want to do once the event is triggered. In this case, we want to run a new instance of our hello pipeline. Here we have defined a PipelineRun object, which you can read more on here. At this stage just note the name needs to be unique each run, so we use the $(uid) variable. It is implicitly available throughout a TriggerTemplate's resource templates. A random string value is assigned to $(uid). The other point of interest is the pipelineRef which is the name of the pipeline to run. For more details see the full TriggerTemplate documentation

  • apiVersion Which version of the Kubernetes API you’re using to create this object
  • kind - What kind of object you want to create, a TriggerTemplate
  • metadata - Specifies data to uniquely identify theTriggerTemplate resource object, for example, a `name`
  • spec - What state you desire for the object

Hello-pipeline

Hopefully we are used to the pattern by now and we can skip straight to the tasks section. A Pipeline consists of one or more tasks. The task has a name and a reference to aTask object which we will define next. For more details see the full Pipeline documentation

  • apiVersion Which version of the Kubernetes API you’re using to create this object
  • kind - What kind of object you want to create, a Pipeline
  • metadata - Specifies data to uniquely identify thePipeline resource object, for example, a `name`
  • spec - Specifies the configuration information for your Pipeline resource object. In order for a Pipeline to do anything, the spec must include tasks
  • tasks - Specifies which Tasks to run and how to run them
  • name - Specify the name of the task from a pipeline point of view does not need to match an actual task name. This is just a label
  • taskRef - Specify the actual task you want to run

Hello-task

Finally we come to the Task, this is where the actual work happens. A task is made of a list of Steps which each run in their own pod on Kubernetes. The steps will be executed in the order in which they are defined. For more details see the full Task documentation

  • apiVersion Which version of the Kubernetes API you’re using to create this object
  • kind - What kind of object you want to create, a Task
  • metadata - Specifies data to uniquely identify theTask resource object, for example, a `name`
  • spec - Specifies the configuration information for your Task resource object
  • steps - Specifies one or more container images that you want
    to run in your Task
  • name - Name for the container
  • image - Image to use
  • command - Command to run inside the container
  • args - Arguments to pass to the command

Conclusion

Now you have the definition for your first pipeline ready to go. In the next part, we will create an IBM Cloud Toolchain with a Tekton pipeline in it. Once created we will take it for a spin and execute our first pipeline!

Tekton on IBM Cloud — Level 1 Hello World Part: 2

--

--

Daniel Butler

Software Engineer for IBM. Over 10 years experience building automation solutions. “Automate All The Things!”