Tekton is a powerful Kubernetes native open source tool for creating continuous integration and delivery systems.

By abstracting the underlying implementation details, users can build, test, and deploy across multi-cloud platforms and on-premise systems.

< span style = “box-sizing: border-box; word-break: inherit! Important; word-break: inherit! Important;

Custom resources are an extension of the Kubernetes API to create custom Kubernetes objects. Once a custom resource is installed, users can use Kubectl to create and access its objects, just as they can for pod, deployment, and other built-in resources. These resources run on clusters and are enforced by Kubernetes Custom Resource Definitions (CRD). There are five classes of objects in Tekton Pipeline, and the core idea is to define the build process by defining YAML. The status of the build task is stored in the Status field. The PipelineResouce objects are PipelineResouce, Task, TaskRun, Pipeline, and PipelineRun.

  • A Task is the construction process of a single Task, and you need to define TaskRun tasks to run the Task.
  • A Pipeline contains multiple tasks on which input and output are defined, which are delivered at PipelineResource.
  • PipelineResource is a collection of objects available for input and output.
  • Similarly, PipelineRun needs to be defined to run pipelines.

The arrow in the figure below illustrates the dependency from one resource to another.

About Tekton’s design concept:

  • Pipelines does not know what triggers them, they can be triggered by events or manually created PipelineRun.

  • Tasks can stand alone and can be invoked completely independently of Pipelines. They are characterized by high cohesion and low coupling.

  • Tasks can depend on artifacts and parameters created by other Tasks.

  • Tasks can be called by TaskRuns.

  • PipelineResources is the artifact used as the input and output of Tasks.

Let’s focus on Task here.

A Task (or ClusterTask) is a collection of sequential steps that you want to run in a continuous integration process. The task will run inside a POD on the cluster.

A Task declaration includes:

  • Inputs

  • Outputs

  • Steps

Task is scoped to a namespace, whereas ClusterTask is scoped to the entire Kubernetes cluster. grammar

To define a configuration file for a Task resource, you can specify the following fields: Mandatory:

  • Steps – Specifies one or more container images to run in Task.

  • ApiVersion – Specifies the API version, for example, tekton.dev/v1alpha1.

  • Kind – Specifies the Task resource object.

  • Metadata – Specifies data that uniquely identifies a Task resource object, such as name.

  • Spec – Specifies configuration information for the Task resource object. Task Steps must be defined by one of the following fields: Optional:

  • Inputs – Specifies the parameters and PipelineResources required by your Task

  • Outputs – Specifies the PipelineResources generated by your Task

  • Volumes – Specifies one or more mounted volumes to be used for steps in Task.

  • StepTemplate – Specifies the container step definition to be used as the basis for all steps in “Task”. .

  • Sidecars – Specifies that the Sidercar container runs with steps.

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: example-task-name
spec:
  inputs:
    resources:
      - name: workspace
        type: git
    params:
      - name: pathToDockerFile
        type: string
        description: The path to the dockerfile to build
        default: /workspace/workspace/Dockerfile
  outputs:
    resources:
      - name: builtImage
        type: image
  steps:
    - name: ubuntu-example
      image: ubuntu
      args: ["ubuntu-build-example"."SECRETS-example.md"]
    - image: gcr.io/example-builders/build-example
      command: ["echo"]
      args: ["$(inputs.params.pathToDockerFile)"]
    - name: dockerfile-pushexample
      image: gcr.io/example-builders/push-example
      args: ["push"."$(outputs.resources.builtImage.url)"]
      volumeMounts:
        - name: docker-socket-example
          mountPath: /var/run/docker.sock
  volumes:
    - name: example-volume
      emptyDir: {}
Copy the code

With reference to the above example, let’s take a look at the explanations of several parameters:

Steps

The Steps field is required. You define one or more Step fields to define the Task body. If multiple steps are defined, when tasks are called by TaskRun, they are executed in the order defined. Each Step in the Task must specify a container image that complies with the container specification. For each Step field or container image you define: Run and evaluate container images in turn, as per the configuration file. The container images run until the first failure is completed or detected. If the container image does not have a maximum resource request among all container images in Task, CPU, memory, and temporary storage resource requests are set to zero. This ensures that a Pod performing a task requests only the resources required to perform any individual container image in the task, rather than the sum of all container image resource requests.

Inputs

A Task can declare all of the inputs it requires:

  • parameter
  • Input resources

Parameters:

Tasks can declare input parameters that must be provided to the Task during TaskRun. Some example use cases for this include needing to know what compile flags to use when a Task builds an application. You need to know how to name tasks for built artifacts. Parameter names are limited to alphanumeric characters – and _, and can only start with alphanumeric characters and _. For example, foois-bar_ is a valid parameter name, barIsBa $or 0banana is not. Each declared parameter has a type field, which is assumed to be a string if not provided by the user. Another possible type is an array – useful, for example, when you need to provide a dynamic number of compile flags to the task of building your application. When the actual parameter value is provided, the type that it resolves is validated against the type field.

Usage:

The following example shows how Tasks can be parameterized and how these parameters can be passed from TaskRun to Task. An input parameter of the form $(elsions.params.foo) is replaced in the step (see also variable substitution). The following Task declares an input parameter named “Flags” and uses it in the steps.args list.


apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: task-with-parameters
spec:
  inputs:
    params:
      - name: flags
        type: array
      - name: someURL
        type: string
  steps:
    - name: build
      image: my-builder
      args: ["build"."$(inputs.params.flags)"."url=$(inputs.params.someURL)"]
Copy the code

Outputs

Task definitions can include input and output PipelineResource declarations. If only a specific resource set is declared in the output, the copy of the resource that is expected to be uploaded or shared by the next task is under the path/workspace/output/resource_name /.

resources:
  outputs:
    name: storage-gcs
    type: gcs
steps:
  - image: objectuser/run-java-jar #https://hub.docker.com/r/objectuser/run-java-jar/
    command: [jar]
    args:
      ["-cvf"."-o"."/workspace/output/storage-gcs/"."projectname.war"."*"]
    env:
      - name: "FOO"
        value: "world"

Copy the code

The normal operation of Pipeline also needs other resources, such as Git and Docker accounts or tokens mounted to the working container through Secrets; The serviceAccount used to access the K8S cluster in the container. These credential resources are mounted to special base image containers provided by Tekton, which are used to read accounts and credentials (usually initContainers).

conclusion

Task templates in Tekton Pipeline can be reused without having to re-define them, and redefining CI/CD through CRD is a big plus.

Official information on the latest technology exclusive interpretation