Tektoncd usage and examples
Playing with the cat’s project 🐱
Let’s dig into some use case and examples of tektoncd/pipeline
. From secrets and
services accounts to real-life example, let’s document pipeline
usage, tips and tricks.
What is Tektoncd ?
The Tekton Pipelines project provides Kubernetes-style resources for declaring CI/CD-style pipelines.
- Started as an experiment from Knative to define more advance build use cases that
knative/build
was able to. - Is now it’s own project and GitHub organization.
Secrets
Most of the time, you’re gonna need to access private resources like git repositories, image registries, ssh server and clusters. We’ll dig into each of them but the gist is always the same :
- Create secrets that holds the credentials
- Create service accounts that uses those secrets
- Attach those service accounts to the
PipelineRun~/~TaskRun
Note
Those are working exactly the same as knative/build
. The docs are here.
Git credentials
Using ssh
apiVersion: v1 kind: Secret metadata: name: ssh-key annotations: tekton.dev/git-0: github.com tekton.dev/git-1: gitlab.com tekton.dev/git-2: sr.ht type: kubernetes.io/ssh-auth data: # cat ~/.id_rs | base64 -w 0 ssh-privatekey: <base64 encoded> # This is non-standard, but its use is encouraged to make this more secure. # ssh-keyscan github.com | base64 -w 0 known_hosts: <base64 encoded>
Using basic authentication
apiVersion: v1 kind: Secret metadata: name: basic-user-pass annotations: tekton.dev/git-0: https://github.com tekton.dev/git-1: https://gitlab.com tekton.dev/git-0: https://sr.ht type: kubernetes.io/basic-auth stringData: username: <username> password: <password>
Registry credentials
Using basic authentication
apiVersion: v1 kind: Secret metadata: name: basic-user-pass annotations: tekton.dev/docker-0: https://index.docker.io tekton.dev/docker-1: https://gcr.io type: kubernetes.io/basic-auth stringData: username: <username> password: <password>
Using kubernetes secret types
There is two secret specific secret types related to docker authentication, or more accurately to docker configuration files (that holds auth).
kubernetes.io/dockerconfigjson
($HOME/.docker/config.json
)kubernetes.io/dockercfg
($HOME/.dockercfg
)
kubectl create secret generic regcred \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjson # kubectl create secret generic regcred --from-file=.dockerconfigjson=$HOME/.docker/config.json --type=kubernetes.io/dockerconfigjson
apiVersion: v1 data: .dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0= kind: Secret metadata: ... name: regcred ... type: kubernetes.io/dockerconfigjson
Kubernetes documentation : Pull an Image from a Private Registry - Kubernetes
Service account
apiVersion: v1 kind: ServiceAccount metadata: name: build-bot secrets: - name: regcred - name: ssh-key
Using kaniko
Volume for kaniko
’s cache
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: kaniko-cache-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 8Gi
Resources
the
git
repositoryapiVersion: tekton.dev/v1alpha1 kind: PipelineResource metadata: name: private-go-hello spec: type: git params: - name: revision value: master - name: url value: git@github.com:vdemeester/go-hello.git
the
image
(s)apiVersion: tekton.dev/v1alpha1 kind: PipelineResource metadata: name: hello-image-res spec: type: image params: - name: url description: The target URL value: docker.io/vdemeester/go-hello --- apiVersion: tekton.dev/v1alpha1 kind: PipelineResource metadata: name: bye-image-res spec: type: image params: - name: url description: The target URL value: quay.io/rhdevelopers/vdemeest-go-bye
Task
apiVersion: tekton.dev/v1alpha1 kind: Task metadata: name: kaniko-build-push spec: inputs: resources: - name: src type: git params: - name: pathToDockerFile description: The path to the dockerfile to build (relative to the context) default: Dockerfile - name: pathToContext description: The path to the build context, used by Kaniko - within the workspace (https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts). The git clone directory is set by the GIT init container which setup the git input resource - see https://github.com/knative/build-pipeline/blob/master/pkg/reconciler/v1alpha1/taskrun/resources/pod.go#L107 default: . outputs: resources: - name: builtImage type: image steps: - name: build-and-push image: gcr.io/kaniko-project/executor:debug command: ["/kaniko/executor"] args: - --dockerfile=${inputs.params.pathToDockerFile} - --destination=${outputs.resources.builtImage.url} - --context=/workspace/src/${inputs.params.pathToContext} volumeMounts: - name: kaniko-cache mountPath: /cache volumes: - name: kaniko-cache persistentVolumeClaim: claimName: kaniko-cache-pvc
Pipeline
apiVersion: tekton.dev/v1alpha1 kind: Pipeline metadata: name: kaniko spec: resources: - name: src type: git - name: hello-image type: image - name: bye-image type: image tasks: - name: go-hello-image taskRef: name: kaniko-build-push params: - name: pathToContext value: hello resources: inputs: - name: src resource: src outputs: - name: builtImage resource: hello-image - name: go-bye-image taskRef: name: kaniko-build-push params: - name: pathToContext value: bye resources: inputs: - name: src resource: src outputs: - name: builtImage resource: bye-image
PipelineRun
apiVersion: tekton.dev/v1alpha1 kind: PipelineRun metadata: name: kaniko-run spec: pipelineRef: name: kaniko trigger: type: manual serviceAccount: build-bot resources: - name: src resourceRef: name: private-go-hello - name: hello-image resourceRef: name: hello-image-res - name: bye-image resourceRef: name: bye-image-res