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 demoNext, 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 demoNAME 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.yamlfile
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://savitaashture@gitlab.com':
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.