Kubernetes API Event Driven Triggering of Tekton Pipelines
Posted: March 30th, 2021 | Author: sabre1041 | Filed under: Technology | Tags: knative, kubernetes, OpenShift, tekton | No Comments »Tekton
The Trusted Software Supply Chain emphasizes the procedural nature of incorporating security throughout the software delivery process without the notion of using specific tools. In Tekton, a Pipeline represents a set of Tasks containing the business logic. Given that this discussion primarily centers around the act of triggering workflows rather than the implementation itself, the pipeline and included steps foregos any of the logic that you would typically find when managing images and instead merely displays several pieces of metadata related to the image and the triggering process.
Create the Tekton pipeline and associated task by executing the following command:
kubectl create -f pipelines/print-image-task.yaml kubectl create -f pipelines/print-image-pipeline.yaml
Within the print-image
Tekton task previously, the name of the image, the image reference and the type of event that triggered the pipeline are printed to the screen. These are sourced from input parameters that are passed when the pipeline is triggered.
To simulate what will occur when the pipeline is triggered, execute the following command to start the pipeline:
tkn pipeline start print-image -p image-name=sha256:8ae3e6e3ef3722dcfec1a1c46a4caac20bcdbb14ded1e2b1501d2cbb187e2ebb -p image-reference=registry.redhat.io/rhel8/httpd-24@sha256:8ae3e6e3ef3722dcfec1a1c46a4caac20bcdbb14ded1e2b1501d2cbb187e2ebb -p event-type=update --showlog PipelineRun started: print-image-run-4ng4d Waiting for logs to be available... [print-image : print-image] Event Type: update [print-image : print-image] Image Name: sha256:8ae3e6e3ef3722dcfec1a1c46a4caac20bcdbb14ded1e2b1501d2cbb187e2ebb [print-image : print-image] Image Reference: registry.redhat.io/rhel8/httpd-24@sha256:8ae3e6e3ef3722dcfec1a1c46a4caac20bcdbb14ded1e2b1501d2cbb187e2ebb
The parameters used in the command above are representative of the types of values that the pipeline will expect during the actual runtime.
Triggers
With the pipeline in place and a basic validation of the print-image pipeline complete using manual invocation, the Tekton Triggers subproject can now be used in order to automatically start the pipeline whenever an event is received. The details of the eventing process will be described in a subsequent section, but for now let’s discuss the key components of the Triggers:
- TriggerTemplate – A blueprint for the Tekton resource (TaskRun or PipelineRun) that will be instantiated
- TriggerBinding – Specifies fields to extract from the event payload into the fields of the TriggerTemplate
- EventListener – Listens for events at a specific port
- Triggers – Specifies what should occur when an event is received. Will reference an existing TriggerTemplate and TrigerBiniding. An embedded trigger can be associated to an EventListener.
When an event is received by the service exposed by the EventListener, a mapping defined in the TriggerBinding will extract the necessary fields from the event and instantiate the pipeline defined in the TriggerTemplate.
More information related to the Tekton Triggers project can be found in the upstream documentation.
Now, created the TriggerTemplate, TriggerBinding and EventListener in the cluster by executing the following commands:
kubectl create -f pipelines/image-triggerbinding.yaml kubectl create -f pipelines/image-triggertemplate.yaml kubectl create -f pipelines/image-eventlistener.yaml
By creating an EventListener, a Kubernetes Service to receive incoming requests and backing pod(s) will also be created. This can be confirmed by listing pods within the namespace with the label eventlistener=image-eventlistener
.
oc get pods -l eventlistener=image-eventlistener NAME READY STATUS RESTARTS AGE el-image-eventlistener-5d969b7fdf-8xnbs 1/1 Running 0 172m el-image-eventlistener-5d969b7fdf-t6wrg 1/1 Running 0 153m
A common use case for Tekton Triggers is to start a pipeline whenever a change is made to a Git repository which necessitates the need to provide a method of ingress. In OpenShift, this would also involve the creation of a Route that references the EventListener service previously created. However, since all communication in our case will reside within the cluster, there is no need to create a Route for external access.
At this point, all of the resources related to Tekton have been completed. Focus can now shift towards determining when Image resources change in the cluster and how to invoke Tekton.
Leave a Reply