Unlike on CentOS or Ubuntu, where we feel that mv is faster than cp, when you build an image with a Dockerfile, using Run cp is faster than Run mv. This post presents the test and verification data behind that. 1. Test Setup Machine environment Ubuntu 20.04.1 LTS 32C

1. Purpose of the Test Tune the parameters of the build cluster Probe the upper limit on the number of concurrent Tekton pipelines Give the optimal concurrency limit for a single cluster 2. Related Components and Machine Configuration Kubernetes version v1.21.4 Tekton version v0.24.1, kept consistent with production OpenEBS version localpv version 3.

1. The Challenge of a Cross-Region Harbor If all you need is to store image data in a simple way, Registry is an excellent choice as an image repository. Registry not only supports multiple storage backends, but can also be configured with HTTPS certificates and access credentials. Worth noting: Harbor also uses Registry to store image data.

1. Scraping Tekton Metrics Add a ConfigMap configuration file 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 cat <<EOF | kubectl apply -f - apiVersion: v1 kind: ConfigMap metadata: name: config-observability namespace: tekton-pipelines labels: app.kubernetes.io/instance: default app.kubernetes.io/part-of: tekton-pipelines data: metrics.backend-destination: prometheus metrics.taskrun.level: "task" metrics.

In a non-staged build scenario, when we use a container to build, we can mount the cache directory inside the container onto the build host, run the build task, and then copy the artifacts into the runtime image to produce the application image. But with a staged build, the build image and the runtime image live in the same Dockerfile, which makes it harder to optimize the caching of third-party dependencies.