First Knative Attempt: A Quick Guide to Continuous Integration and Continuous Delivery

By Dongdao

Image for post
Image for post

After a prolonged discussion in the Knative community on how to replace the Build module with Tekton, the official Knative Build team has declared that Knative Build is no longer recommended.

Image for post
Image for post

Understanding Tekton is easy if you are familiar with the Knative Build. While Knative Build projects itself as a Kubernetes-native Build resource, Tekton describes itself as a Kubernetes-native pipeline resource. Though their positioning is very close, Tekton is designed with richer and more complete features. Hence, the community finally chose Tekton.

Let’s take a look at the core concepts of Tekton in the following section.

Quick Start to Tekton

Tekton consists of five core concepts and each of them provides services in the form of Custom Resource Definitions (CRDs). Let’s take a quick look at the five concepts in the following sections.

1) Task

It’s a task running template. It is referred to as a template because a task definition contains a variable, and for running the task, a particular value must be specified for the variable. A Tekton task is similar to a function in terms of definition. A task defines input parameters by using inputs.params, and a default value may be specified for each input parameter. The steps field of a task indicates the substeps of the current task. In detail, each step runs one image. Use the template syntax used by the input parameters of the task to set the startup parameters of the images.

TaskRun

A task never runs directly after definition. It is similar to a function that must be called before running. Therefore, define a TaskRun to ultimately run the task. TaskRun sets the parameters required by the task and refers to the to-be-run task by using the taskRef field.

Pipeline

One TaskRun is able to run only one task. There is a need for a pipeline for orchestrating multiple tasks. A pipeline is a template for orchestrating tasks. The params field of the pipeline declares the input parameters that are required during the run process. The spec.tasks field of the pipeline defines the tasks to be orchestrated. The value of the Tasks field is an array. Tasks in the array are not run in the order of declaration of the array, instead, they are run in the order declared by runAfter. When parsing a CRD, the Tekton controller parses the order of the tasks and then sequentially runs the tasks according to the specified order. When orchestrating tasks, the pipeline needs to pass a required parameter into each task. The values of these parameters may come from the params of the pipeline.

PipelineRun

Similar to a task, a pipeline also doesn’t run directly after the definition. To run a pipeline, PipelineRun is required. PipelineRun helps to set the required input parameters for a pipeline and run the pipeline.

PipelineResource

After defining the four core concepts of Tekton in the preceding sections, now it’s clear how to define a task, run a task, and orchestrate tasks. However, another critical component, PipelineResource helps to share resources between tasks. For example, storing information about a Git repository in PipelineResource helps to share the data across all pipelines.

Authorization Information

It is imperative to authenticate the Git repositories and image repositories before use. Hence, such scenarios require a mechanism for setting authentication information. Tekton is a native orchestration system of Kubernetes and thus, allows to directly use the ServiceAccount mechanism of Kubernetes to implement authentication.

Let’s consider an example to understand this better.

  • Define a Secret that saves the authentication information of the image repository.
  • Define ServiceAccount with the preceding Secret.
  • Execute the following commands to reference ServiceAccount in PipelineRun.

Hello World

Refer to the sample which is the Hello World for a complete Tekton. Let’s experience this Hello World together.

Kubernetes cluster, Knative, and Tekton are the prerequisites to go ahead with the demonstration. To complete the installation of Tekton, directly submit the release-v0.5.2.yaml file in tekton-knative to the Kubernetes cluster. Now, let's start to experience the automated process from source coding to building and eventually deployment based on Tekton.

Clone Code

Clone the code locally using the git clone https://github.com/knative-sample/tekton-knative command.

Create PipelineResource

For the main content, see resources/picalc-git.yaml.

The following figure shows how to save https://github.com/knative-sample/tekton-knative in the resource folder so that it is usable for other resources as well.

Create a Task

Next, create a task. For this example, let’s create the following two tasks:

  • 1) source-to-image

This task is to compile the source code into an image. Refer to the tasks/source-to-image.yaml file for the main content.

Use Kaniko compile Docker images in containers. The parameters of this task are used to set some compilation context information, such as Dockerfile, ContextPath, and target image tags.

  • 2) deploy-using-kubectl

Refer to the tasks/deploy-using-kubectl.yaml file for the main content.

As shown in the following code, this task mainly obtains information about the target image by using parameters and then runs a sed command to replace _IMAGE_ in the Knative Service yaml file with the target image. Then, use kubectl to publish the image to Kubernetes.

Define a Pipeline

Now, let’s orchestrate the two tasks created in the preceding section using a pipeline.

Authentication Information

As shown in the following code, define a Secret and ServiceAccount, and bind the ServiceAccount with the permission to run the Knative Service.

First, create a secret to save the authentication information of the image repository.

  • Replace tekton.dev/docker-0 with the address of the image repository that you want to push.
  • Replace username with the authentication username of the image repository.
  • Replace the password with the authentication password of the image repository.

Save the information to the file, and then submit the file to Kubernetes by running the kubectl apply-f command.

Define a PipelineRun

The authentication information corresponding to ServiceAccount is bound to PipelineRun for running.

For more details, refer to run/picalc-pipeline-run.yaml file.

Run Hello World

Prepare pipeline resources as shown below.

Run create to submit PipelineRun to the Kubernetes cluster. Use the create command instead of the apply command since a PipelineRun is created each time, and a PipelineRun resource is created based on generateName in the create command of kubectl.

Finally, the pod information displays as shown in the following snippet.

Original Source:

Written by

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store