Getting Started with Tekton Pipelines Part 2 — Triggers

Tekton is an open-source project for creating CI/CD systems,
allowing developers to build, test, and deploy across cloud providers and on-premise systems.

Riffel Trigger Mechanism Assembly

In Part 1, I addressed the Basic Pipeline with real everyday tasks.
In this Part 2, I will address the Pipeline Trigger with a real GitoOps (application CI/CD pattern) trigger example.
The Github reference to both parts is found at my GitHub repo.

Let’s review some use cases that Triggers involve and how we can use Triggers?

Triggers are endpoints, which would mean that conceptually anything that can initiate an HTTP request can trigger Tekton Triggers.

CI/CD are the main use cases we would be using Tekton Triggers.
Meaning, listening to events coming from the entities participating in these flows.

An example of Triggers that you would use in a CI/CD workflow:

• Git Commit — Trigger listens for a git commit request event.
  The trigger executes a unit test Pipeline on the committed code
• Git Push —Trigger listens for git push (usually, after the test finished successfully)
  The trigger validates the test’s outcome and executes a building code Pipeline and pushes the image to Container Registry
• Container registry sends an event that triggers a Pipeline which pushes the build artifacts to a staging environment.

Before we will get our hands dirty (actually this time lot less dirty) we need a bit of basic information/definitions

Why Tekton Triggers

Tekton Triggers allow you to easily create fully-fledged CI/CD systems in which you define all mechanics exclusively using Kubernetes resources.

What are Tekton Triggers

Tekton Triggers is a Tekton component that allows you to detect and extract information from events from a variety of sources and deterministically instantiate and execute TaskRuns and PipelineRuns based on that information.

In the schema below we can see the Tekton Trigger flow.
The EventListener is getting a Request, which instantiates the TriggerBinding and TriggerTemplate to create a Template of the defined resource (PipelineRun, TaskRun)

from: https://blog.andyserver.com/

How does Tekton Trigger work

Tekton Triggers consists of a controller service that runs on your Kubernetes cluster as well as Kubernetes Custom Resource Definitions (CRDs) that extend the functionality of Tekton Pipelines to support events

Let's Review the CRD’s that are used in the Trigger flow

EventListener - listens for events at a specified port on your Kubernetes cluster. Specifies one or more Triggers

TriggerTemplate - specifies a blueprint for the resource, such as a TaskRun or PipelineRun

TriggerBinding - specifies the fields in the event payload from which you want to extract data and the fields in your corresponding TriggerTemplate

ClusterTriggerBinding - a cluster-scoped version of the TriggerBinding, useful for reuse within your cluster

Interceptor - a "catch-all" event processor for a specific platform that runs before the TriggerBinding enabling you to perform payload filtering, verification (using a secret), transformation, define and test trigger conditions, and other useful processing

So stitching all this together:

• A Trigger specifies what happens when the EventListener detects an event.
• A Trigger specifies a TriggerTemplate, a TriggerBinding, and optionally an Interceptor

Tekton Event Trigger Schema from: developer.ibm.com

Let’s use our new Tekton Triggers knowledge and add to our Part 1 Pipeline a basic Trigger from Github

The plot is a simple pipeline that does the following:

• Pulls private Github repo — via PipelineResource
• Build & Push an image from source code — via Tekton Task using Kaniko
• The Credentials are given via secrets and mounted properly to the Tekton Pipeline and eventually to Kaniko Tekton Task

Now, we will add a Trigger from Github Push/PR Events to Run the Pipeline

Note, all the resources are found in the trigger folder in Part 2.

TriggerTemplate

The TriggerTemplate defines the template of the Tekton Resource we would like to create when the Trigger is activated.
That would mean a TaskRun or PipelineRun.

As one can see below, we have the definition of our PipelineRun Tekton Resource, which looks exactly like the Original PipelineRun from Part 1.
When the Trigger is activated the Template is created (using the special credentials we give it, look over the rbac.yaml).
The template would be filled with the values generated by the TriggerBinding Resource.

TriggerBinding

The TriggerBinding resource extracts the values received from the query call and then sets params with these values.
For the sake of simplicity in this example, we use hardcoded values

params:    
  - name: dockerfile-path
    value: "./Dockerfile"    
  - name: image-url
    value: "yossicohn/app"    
  - name: path-to-context
    value: "workspace/shared-data"

EventListener

This EventListener has the basic structure which mainly includes the bindings and the template.
The binding defines which TriggerBinding is used.
The template defines which TriggerTemplate is used.

In this example, we have additional usage of interceptor which is a trigger that is invoked before our own trigger.

There are some built-in interceptors like github interceptors that can be used.
The github interceptor helps in verifying the Github Secret Token.
If the interceptor fails then the trigger is blocked.

Note that we’ve added here the secret we are using to validate the Github Secret

Creation of Tekton Resources

In order for the Tekton Trigger flow to work, specific credentials are needed.
For example :

• Listening to Events
• Creation of Tekton Resources

This is fulfilled via the RBAC rules we create.

Note, that theServiceAccount service-tekton-triggers-sa is given all these credentials and that is being used by the EventListener Resource.

Running

First, we need to install Tekton Pipelines, Tekton Triggers and Interceptors on our Kubernetes cluster.
basically, this is done via the following kubernetes commands.

You can have more info here

Let’s apply all the new resources in the following manner:

We should have a new service:

Exposing The Trigger Endpoint

To expose the service to GitHub, you should use IngressController.
I’m using Kong for that.

To install kong, you can use Kong Helm Chart and the Helm values file kong-values.yaml found at the trigger folder.
Installing Kong as:

helm install kong kong/kong -f kong-values.yaml

The ingress would be exposed via the following Ingress Resource.

Testing

We can trigger our Repo via a simple git push and see how the PipelineRun is created.

As an advice, try to:

1. remove the GitHub interceptor
2. Use port-forwarding of the Service and call it easily from your machine

Security Aspects

You should note that exposing public endpoints into your cluster is asking for problems.

Two major things you can do as for Github Hooks:
1. IP Whitelisting
You can whitelist Github IP’s (Kong IP Restriction plugin can help with that)

You can see the example usage for Kong IP Restriction in the code example here
The Kong Helm Values files are also available in the code example here

2. Github SecretToken
you should use the Github SecretToken the same way I used with Interceptors.
More on Github SecretToken

Summary

We can see via the example above that we can leverage Triggers into Tekton Pipelines quite easily and fulfill basic use cases in a CI/CD flow.

Thanks again! to Regev Golan for the help