Pipelines
Now it is time to gain a better understanding of tasks and pipelines. Before we create a pipeline, lets first create a Tekton namespace:
kubectl create ns tekton
In Tekton, a pipeline can consist of one or more tasks, which can be executed one after the other or in parallel with one another.
The pipeline includes the fetch-source, show-content and build-push tasks. Fetch-source clones the repo in which the Dockerfile is located and build-push builds the image and uploads it to a repo. The show-content task displays the artifacts obtained through Fetch-source.
One of biggest of advantages of Tekton is, that not all tasks and pipelines need to be rewritten because Tekton provides a Tekton Hub where users can share their tasks and pipelines with each other. Two tasks from the Tekton Hub were used in this example.
The first task, called Git-clone, clones a Git repository and saves the data to a workspace. Workspaces will be discussed in more detail later.
The second task, originating from the Tekton hub, builds an image and uploads it to any container registry. The task uses Kaniko to build an image. The task also saves the name and a digest of the image in a result so that Tekton Chains can sign the image and create an attestation. Tekton chains and results will be discussed in a later point.
The example of the “git-clone” task shows the name of the task has in the context of the pipeline. The “taskRef” field is used to reference the individual tasks, in this case git-clone. You can also define here which parameters and workspaces should be passed to the task.
The “url” parameter of the task is assigned the “repo-url” parameter. The names of the parameters can differ from pipeline to task. The notation $(params.repo-url) refers to the parameter that is in the “params” field. Parameters that come from a task or pipeline run are set in this field.
In order to use those tasks, we may not forget to install them. Here is the first task:
It can be applied either via tkn oder kubectl apply:
tkn hub install task git-clone
kubectl apply -f https://raw.githubusercontent.com/tektoncd/catalog/main/task/git-clone/0.6/git-clone.yaml
The second task can also be found on Tekton Hub and can be installed as follows:
tkn hub install task kaniko
kubectl apply -fhttps://raw.githubusercontent.com/tektoncd/catalog/main/task/kaniko/0.6/kaniko.yaml
If you have some troubles with the builder image, you might change the appropriate section as follows:
The last task is the show-readme.
To apply the pipeline, we just enter the following command:
kubectl apply -f pipeline.yaml
Installation of Tekton Chains
Since Chains is not installed via the operator, Chains must be installed separately.
kubectl apply –filename https://storage.googleapis.com/tekton-releases/chains/latest/release.yaml
If you prefer to install a special version, you can issue the following command:
kubectl apply -f https://storage.googleapis.com/tekton-releases/chains/previous/${VERSION}/release.yaml
After installation, the configmap can be configured.
Configuration in the manifest:
kubectl patch configmap chains-config -n tekton-chains -p=‘{“data”:{“artifacts.taskrun.format”:”in-toto”, “artifacts.pipelinerun.storage”: “tekton, oci”, “artifacts.taskrun.storage”: “tekton, oci”}}’
Furthermore, the keyless signing mode can be activated, which uses Fulcio from the Sigstore project.
kubectl patch configmap chains-config -n tekton-chains -p=‘{“data”:{“signers.x509.fulcio.enabled”: “true”}}’
Chains supports automatic binary uploads to a transparency log and uses Rekor by default. If activated, all signatures and attestations are logged.
kubectl patch configmap chains-config -n tekton-chains -p=‘{“data”:{“transparency.enabled”: “true”}}’
After the ConfigMap has been patched, it is recommended to delete the Chains Pod so that the changes are registered by the Pod
kubectl delete po -n tekton-chains -l app=tekton-chains-controller
Pipeline Runs
A run, whether TaskRun or PipelineRun, is instantiated and executes pipelines and tasks. When a PipelineRun is executed, TaskRuns are automatically created for the individual tasks. Among other things, the pipeline that is to be executed is referenced, the parameters that are to be used in a task are defined, or the pod templates. A blueprint for the executed pods is created using the templates. For example, environment variables can be provided for each pod and scheduling settings can be configured via nodeSelectors, tolerances and affinities.
After everything has been configured, the pipeline run can be executed.
Within the param section, you can specify the git repo for cloning and also choose where the image should be uploaded to.
So that’s it for today. In the next blog post, we will discuss authentication, workspaces, secrets and more. So there is still a lot of interesting stuff left.
