Dynamic scheduling of Tekton workloads utilizing Triggers

Tekton is a Kubernetes-native steady integration and supply (CI/CD) framework. It permits you to create containerized, composable, and configurable workloads declaratively by Kubernetes Custom Resource Definitions (CRD).

Tekton Triggers is a Tekton part that permits you to detect and extract info from occasions from varied sources and execute TaskRuns and PipelineRuns primarily based on that info. It additionally allows passing extracted info to TaskRuns and PipelineRuns from occasions.

This article demonstrates how Tekton Triggers integrates with exterior companies, resembling a Git repository, utilizing GitLab for example.

Prerequisites

If you need to observe the steps on this article, you need to have a Kubernetes cluster operating Kubernetes 1.18 or above with an ingress controller put in that can provide you an exterior IP. You should even have Tekton Pipelines and Tekton Triggers put in.

Triggers circulate

A Trigger works as a result of Tekton, utilizing a particular pod referred to as an EventListener, is ready to monitor your cluster for a particular occasion. To decide up on related occasions, you need to use a ClusterInterceptor. When an occasion happens that you’ve recognized as important, the Tekton Trigger begins an motion or workflow you have got outlined.

Tekton Trigger permits you to create a particular useful resource referred to as an EventListener, which is a Kubernetes service that listens for incoming HTTP requests from completely different sources, normally a Git repository, together with these hosted on GitLab, GitHub, and others. Based on these occasions, the EventListener pod performs actions and creates Tekton assets, resembling TaskRun or PipelineRun.

All Triggers useful resource definitions are created in YAML, the configuration format mostly utilized in Kubernetes. However, earlier than writing YAML recordsdata to outline a Trigger, it is necessary to know Tekton Triggers terminology.

EventListener

An EventListener is a Kubernetes service that listens for incoming HTTP requests and executes a Trigger. For instance, after receiving a particular incoming request, this definition executes the gitlab-listener-trigger Trigger:

apiVersion: triggers.tekton.dev/v1beta1
variety: EventListener
metadata:
 title: gitlab-event-listener
spec:
 serviceAccountName: gitlab-listener-sa
 triggers:
   - triggerRef: gitlab-listener-trigger
 assets:
   kubernetesResource:
     serviceType: NodePort

Trigger

A Trigger decides what to do with a obtained occasion. It additionally units a TriggerBinding, TriggerTemplate, and elective interceptors to run. Triggers make use of interceptors to validate or modify incoming requests earlier than continuing.

apiVersion: triggers.tekton.dev/v1beta1
variety: Trigger
metadata:
 title: gitlab-listener-trigger
spec:
 interceptors:
   - title: "verify-gitlab-payload"
     ref:
       title: "gitlab"
       variety: ClusterInterceptor
     params:
       - title: secretRef
         worth:
           secretName: "gitlab-secret"
           secretKey: "secretToken"
       - title: eventTypes
         worth:
           - "Push Hook"
 bindings:
   - ref: binding
 template:
   ref: template

Interceptor

An interceptor is an occasion processor that runs earlier than the TriggerBinding. It additionally performs payload filtering, verification (utilizing a secret), and transformation; defines and exams set off circumstances; and implements different helpful processing.

By default, 4 core interceptors are put in when putting in Triggers: GitHub, GitLab, Bitbucket, and CEL. The set up additionally contains one Webhook interceptor for implementing customized enterprise logic.

GitLab interceptors

GitLab interceptors assist to validate and filter GitLab webhooks and filter incoming occasions by occasion sort. The GitLab interceptor requires a secret token. This token is about when creating the webhook in GitLab and is validated by the GitLab interceptor when the request arrives.

apiVersion: v1
variety: Secret
metadata:
 title: gitlab-secret
sort: Opaque
stringData:
 secretToken: "1234567"

TriggerBinding

After validating and modifying the incoming request, it is advisable extract values from the request and bind them to variables which you could later use in a TriggerTemplate to go our Pipeline.

For our instance, you simply want a URL and a revision.

apiVersion: triggers.tekton.dev/v1beta1
variety: TriggerBinding
metadata:
 title: binding
spec:
 params:
   - title: gitrevision
     worth: $(physique.checkout_sha)
   - title: gitrepositoryurl
     worth: $(physique.repository.git_http_url)

TriggerTemplate

The TriggerTemplate is a blueprint that instantiates TaskRun or PipelineRun when EventListener detects an occasion.

apiVersion: triggers.tekton.dev/v1beta1
variety: TriggerTemplate
metadata:
 title: template
spec:
 params:
   - title: gitrevision
   - title: gitrepositoryurl
 resourcetemplates:
   - apiVersion: tekton.dev/v1alpha1
     variety: TaskRun
     metadata:
       generateName: gitlab-run-
     spec:
       taskSpec:
         inputs:
           assets:
             - title: supply
               sort: git
         steps:
           - picture: ubuntu
             script: |
               #! /bin/bash
               ls -al $(inputs.assets.supply.path)
       inputs:
         assets:
           - title: supply
             resourceSpec:
               sort: git
               params:
                 - title: revision
                   worth: $(tt.params.gitrevision)
                 - title: url
                   worth: $(tt.params.gitrepositoryurl)

Note that the pipeline assets module is, on the time of writing, being deprecated and will probably be changed by git-clone duties, from tektoncd/catalog.

Dynamically schedule workloads by configuring a webhook

First, create a brand new namespace, demo:

$ kubectl create ns demo

Next, earlier than making use of the Triggers useful resource, configure the required role-based entry management (RBAC):

$ kubectl -n demo apply -f 
"https://gist.githubusercontent.com/savitaashture/596bc4d93ff6b7606fe52aa20ba1ba14/raw/158a5ed0dc30fd1ebdac461147a4079cd6187eac/triggers-rbac.yaml"

Note: RBAC configurations fluctuate relying on the permissions.

Apply Triggers assets:

$ kubectl -n demo apply -f 
"https://gist.githubusercontent.com/savitaashture/8aa013db1cb87f5dd1f2f96b0e121363/raw/f4f592d8c1332938878c5ab9641e350c6411e2b0/triggers-resource.yaml"

After making use of, confirm the profitable creation of the EventListener object and pod:

EL object READY standing ought to be True. 

$ kubectl get el -n demo
NAME                    ADDRESS                                                     AVAILABLE REASON              READY             REASON                                                                                                             
gitlab-event-listener   http://el-gitlab-event-listener.demo.svc.cluster.local:8080   True                 MinimumReplicasAvailable   True

EL Pod standing ought to be Running.

$ kubectl get pods -n demo
NAME                                       READY          STATUS    RESTARTS              AGE
el-gitlab-event-listener-fb77ff8f7-p5wnv   1/1            Running   0                     4m22s

Create ingress to get the exterior IP to configure within the GitLab webhook:

$ kubectl -n demo apply -f 
"https://gist.githubusercontent.com/savitaashture/3b3554810e391477feae21bb8a9af93a/raw/56665b0a31c7a537f9acbb731b68a519be260808/triggers-ingress.yaml"

Get the ingress IP:

$ kubectl get ingress triggers-ingress-resource -n demo
NAME               CLASS    HOSTS     ADDRESS                             PORTS   AGE
ingress-resource   <none>   *         <deal with>                            80      6s

Configure a webhook in GitLab. In your GitLab repository, go to Settings -> Webhooks.

Then set the under fields:

• URL: exterior IP Address from the Ingress with / path
• Secret token: 1234567, which ought to match the key worth created above from triggers-resource.yaml file

Choose occasion sort from the Trigger part, then simply choose Push occasions, uncheck Enable SSL verification, and click on on Add webhook.

Testing GitLab occasions by pushing PR

Clone your individual GitLab repository, make adjustments, and push. For instance:

$ git clone https://gitlab.com/savitaashture1/gitlabtest-triggers
$ cd gitlabtest-triggers
               $ git commit -m "empty-commit" --allow-empty && git push origin primary
[main 934ecba] empty-commit
Username for 'https://gitlab.com': savitaashture
Password for 'https://[email protected]': 
warning: redirecting to https://gitlab.com/savitaashture1/gitlabtest-triggers.git/
Enumerating objects: 1, achieved.
Counting objects: 100% (1/1), achieved.
Writing objects: 100% (1/1), 183 bytes | 183.00 KiB/s, achieved.
Total 1 (delta 0), reused 0 (delta 0)
To https://gitlab.com/savitaashture1/gitlabtest-triggers
   ff1d11e..934ecba  primary -> primary

Events will probably be generated and despatched to the EventListener pod. You can confirm this by doing:

kubectl get pods -n demo
kubectl logs -f <pod_name> -n demo

Verify profitable supply of occasions by doing a get operation for TaskRun.

$ kubectl  -n demo get taskruns | grep gitlab-run-
gitlab-run-hvtll   True        Succeeded   95s         87s

Clean all assets created by Triggers by eradicating namespace demo:

$ kubectl delete ns demo

Conclusion

Tekton Triggers is without doubt one of the most helpful modules that assist schedule workloads dynamically in response to a user-defined set of occasions. Because of this module, my group was in a position to obtain end-to-end CI/CD.