ACCESS_TOKEN

Gain insights into building serverless applications on Kubernetes, using Knative, Tekton for CI/CD pipelines, and integrating GitHub for automated builds and deployments through GitHub events.

How to Build a Serverless App Platform on Kubernetes-01.png

knative.tar.gz

DigitalOcean Account

Install Knative

​​Businesses are modernizing and adopting multi-cloud approaches to deliver services. This shift in application deployment has given rise to containerization and Kubernetes for the deployment, management, and scaling of containerized applications. 

This course introduces you to serverless computing and shows you how to build serverless applications using Knative. It teaches CI/CD using Tekton and shows you how to build pipelines triggered by GitHub events. You will create a pipeline that builds container images using Build and, later, Cloud Native Buildpacks. 

In the last part of the course, you will build a web application that integrates with GitHub using a GitHub App, and triggers application build and deployment in response to GitHub events.

Building a Serverless App Platform on Kubernetes

Let's extend the Pipeline created in the last chapter with Tekton Triggers. We want an EventListener that listens for events from GitHub. When an event is detected, we want to execute a Pipeline. We'll start with creating a TriggerTemplate to specify which Pipeline to run when the event happens.





# TriggerTemplate

In the `trigger-template.yaml` file, we defined a `TriggerTemplate` and specified some parameters. It contains a resource template definition for a `PipelineRun`. The `PipelineRun` object is similar to the one we saw in the previous chapter. It references the `build-deploy` Pipeline and uses the values from the `TriggerTemplate` parameters as input values for the Pipeline. The value is read using `$(tt.params.name)`, where `name` is the name of the `TriggerTemplate` variable.

# TriggerBinding

To bind the event payload fields to the `TriggerTemplate` parameters, we need a TriggerBinding. The TriggerBinding for the TriggerTemplate `trigger-template.yaml` is provided in the `trigger-binding.yaml` file.

The TriggerBinding extracts values from the request body and maps them to the parameters identical to the parameters of the `TriggerTemplate`. The extra fields that will be added to the event payload by the CEL Interceptor are accessed via the top-level `extensions` field.

# TriggerListener

We need an EventListener that'll receive events and trigger the execution of our CI/CD pipeline. Let's define a Kubernetes manifest that specifies the EventListener and the necessary Triggers to do that.

In reference to the code provided in the `trigger-listener.yaml` file, we defined an EventListener with a single Trigger named `cicd-trig`. This Trigger references a TriggerTemplate using the `template` field and a TriggerBinding using the `bindings` field. A CEL Interceptor is applied to filter the events that don’t have an `X-GitHub-Event` header matching the `push` and that add extra keys to the JSON payload. The CEL expression is configured with functions like `truncate` and `split` that are used in `trigger-listener.yaml`.

# Apply the manifests

Now that we have the necessary manifests, run the command given below to apply them:
```shell
kubectl apply \
-f trigger-template.yaml \
-f trigger-binding.yaml \
-f trigger-listener.yaml
```


The EventListener will create a deployment and a service that receive incoming requests. We can confirm this by running the following command: 
```shell 
kubectl get deployments,eventlistener,svc -l eventlistener=cicd
```
We should get something similar to what we see below:

```
NAME                        READY    UP-TO-DATE     AVAILABLE     AGE
deployment.apps/el-cicd     0/1      1              0             2m58s

NAME                  TYPE          CLUSTER-IP       EXTERNAL-IP     PORTS(S)              AGE
service/el-cicd       ClusterIP     10.245.240.93    <none>          8080/TCP,9000/TCP     2m58s
```


> **Note:** We should replace the `<REGISTRY>/<REGISTRY_USERNAME>` with the `docker.io/username` in the `trigger-template.yaml` file first, and then click the “Run” button under the widget shown below. 







# TriggerTemplate

In the `trigger-template.yaml` file, we defined a `TriggerTemplate` and specified some parameters. It contains a resource template definition for a `PipelineRun`. The `PipelineRun` object is similar to the one we saw in the previous chapter. It references the `build-deploy` Pipeline and uses the values from the `TriggerTemplate` parameters as input values for the Pipeline. The value is read using `＄(tt.params.name)`, where `name` is the name of the `TriggerTemplate` variable.

# TriggerBinding

To bind the event payload fields to the `TriggerTemplate` parameters, we need a TriggerBinding. The TriggerBinding for the TriggerTemplate `trigger-template.yaml` is provided in the `trigger-binding.yaml` file.

The TriggerBinding extracts values from the request body and maps them to the parameters identical to the parameters of the `TriggerTemplate`. The extra fields that will be added to the event payload by the CEL Interceptor are accessed via the top-level `extensions` field.

# TriggerListener

We need an EventListener that'll receive events and trigger the execution of our CI/CD pipeline. Let's define a Kubernetes manifest that specifies the EventListener and the necessary Triggers to do that.

In reference to the code provided in the `trigger-listener.yaml` file, we defined an EventListener with a single Trigger named `cicd-trig`. This Trigger references a TriggerTemplate using the `template` field and a TriggerBinding using the `bindings` field. A CEL Interceptor is applied to filter the events that don’t have an `X-GitHub-Event` header matching the `push` and that add extra keys to the JSON payload. The CEL expression is configured with functions like `truncate` and `split` that are used in `trigger-listener.yaml`.

# Apply the manifests

Now that we have the necessary manifests, run the command given below to apply them:
```shell
kubectl apply \
-f trigger-template.yaml \
-f trigger-binding.yaml \
-f trigger-listener.yaml
```


The EventListener will create a deployment and a service that receive incoming requests. We can confirm this by running the following command: 
```shell 
kubectl get deployments,eventlistener,svc -l eventlistener=cicd
```
We should get something similar to what we see below:

```
NAME                        READY    UP-TO-DATE     AVAILABLE     AGE
deployment.apps/el-cicd     0/1      1              0             2m58s

NAME                  TYPE          CLUSTER-IP       EXTERNAL-IP     PORTS(S)              AGE
service/el-cicd       ClusterIP     10.245.240.93    <none>          8080/TCP,9000/TCP     2m58s
```


> **Note:** We should replace the `<REGISTRY>/<REGISTRY_USERNAME>` with the `docker.io/username` in the `trigger-template.yaml` file first, and then click the “Run” button under the widget shown below. 





Learn how to implement Tekton Triggers on an existing Pipeline.

Before We Begin

Introduction

Using Knative to Run Serverless Applications

CI/CD Using Tekton

Automate Tekton Pipeline Execution

Build Container Images without Dockerfile

Build the UI For the Platform

Implement Triggers