--- title: "Tekton: Het Krachtige Open Source CI/CD-Framework" description: Tekton is an open-source framework designed for developing Continuous Integration and Continuous Deployment (CI/CD) systems. It enables developers to work seamlessly with both cloud providers and on-premise infrastructures. --- [ACA Group Blog | Inzichten over Softwareontwikkeling, UX/UI, Data & Innovatie ](https://acagroup.be/nl/blog) # [Tekton: Het Krachtige Open Source CI/CD-Framework](https://acagroup.be/nl/blog/tekton-the-powerful-open-source-ci-cd-framework) Geschreven door [Ugur Akkar](https://acagroup.be/nl/blog/author/ugur-akkar) | 18-jan-2024 3:30:00 Tekton, een krachtig en flexibel open-source framework, stelt ontwikkelaars in staat om CI/CD-systemen te bouwen, testen en implementeren, zowel in de cloud als op locatie. In dit artikel gaan we dieper in op wat Tekton is, de voordelen en hoe grote bedrijven zoals Google, Elastic en RedHat er gebruik van maken. ## Wat is Tekton? Tekton is een open-source framework ontworpen voor het ontwikkelen van Continuous Integration en Continuous Deployment (CI/CD) systemen. Het stelt ontwikkelaars in staat om naadloos samen te werken met zowel cloud providers als on-premise infrastructuren. Met Tekton kunnen ontwikkelaars pijplijnen bouwen, testen en implementeren en profiteren van een flexibele en uitbreidbare architectuur. ## Voordelen van Tekton #### Cloud-Native ecosysteem Tekton maakt gebruik van Kubernetes clusters om bronnen en componenten te beheren. Hierdoor kan Tekton op verschillende cloud providers draaien en lokaal worden ingezet. #### Kubernetes aangepaste bronnen Alle middelen die nodig zijn om een pijplijn te bouwen zijn beschikbaar als Kubernetes Custom Resources. Dit betekent dat pijplijnen volledig kunnen worden beschreven in YAML-bestanden, waardoor GitOps-principes kunnen worden toegepast voor een geautomatiseerd en versiegestuurd bouwproces. #### Uitbreidbaarheid De kern van Tekton is eenvoudig uit te breiden met extra componenten, zoals Tekton Triggers of Dashboards. Deze componenten bevinden zich niet direct in de kern, waardoor deze compact blijft en minimale resources gebruikt. #### Eenvoudig onderhoud Dankzij Tekton's modulaire ontwerp kan de kern onafhankelijk worden geüpgraded zonder dat dit invloed heeft op builds. De scheiding van de core en uitbreidingen maakt onderhoud veel eenvoudiger. #### Schaalbaarheid Als Cloud-Native oplossing kan Tekton eenvoudig worden geschaald voor hoge beschikbaarheid, waardoor het geschikt is voor een verscheidenheid aan projecten en omgevingen. ## Tekton Vrienden: Grote bedrijven omarmen Tekton Verschillende toonaangevende IT-bedrijven hebben Tekton geadopteerd en dragen actief bij aan de ontwikkeling ervan via een GitHub repository. Enkele opmerkelijke bedrijven zijn: - **Google**: De initiatiefnemer van het Tekton project en een actieve ontwikkelaar. - **Elastic**: De hele Elastic stack wordt gebouwd en uitgebracht met behulp van het Tekton ecosysteem. - **Red Hat**: Zorgt voor een naadloze werking van het Tekton ecosysteem op OpenShift en levert toegewijde bijdragen aan het Tekton project. ## Tekton ecosysteem: Componenten en functionaliteiten Het Tekton ecosysteem bestaat uit verschillende componenten die collectief of individueel kunnen worden ingezet. Hieronder volgt een uitleg van een aantal belangrijke componenten. ## 1. Tekton Pijplijnen Tekton Pipelines maakt gebruik van Kubernetes Custom Resources om bouwprocessen te definiëren. Volgens het 'pipeline-as-code' principe kunnen ontwikkelaars pipelines beschrijven in YAML-bestanden en versiebeheer toepassen met GitOps. Door elke resource op te slaan in Git kan worden gewerkt met versies van verschillende Pipeline-resources. Door het GitOps-principe toe te passen, wordt de bron bovendien automatisch ingezet op het cluster, waardoor je er zeker van bent dat je altijd de juiste en nieuwste versie hebt, zonder dat je handmatig met de Tekton-bronnen hoeft om te gaan. Een Pipeline is een subset van taken die in een specifieke volgorde worden uitgevoerd. Laten we een voorbeeld nemen van een Pipeline voor het bouwen van een Docker image: - Taak 1: Kloon Git repository - Taak 2: Scannen op kwetsbaarheden - Taak 3: Docker-bestand lezen en image bouwen - Taak 4: Docker container images naar een register pushen (https://acagroup.be/en/blog/navigating-the-cloud-native-landscape-with-harbor-registry/) Laten we dit nu visualiseren. - Elke uitvoering van een pijplijn wordt een PipelineRun genoemd. - Elke uitvoering van een taak wordt een TaskRun genoemd. In de pijplijn definiëren we de taken. Deze taken zijn ook individuele Tekton Custom Resources in Kubernetes. Wanneer de pijplijn wordt uitgevoerd, raadpleegt Tekton de gedefinieerde bron en gebruikt deze om de taken uit te voeren. Taken zijn heel flexibel. Je kunt een taak herhaaldelijk hergebruiken binnen een pijplijn en zelfs tussen verschillende pijplijnen. Taken kunnen worden aangepast of vanaf nul worden geschreven zonder dat het nodig is om afzonderlijk plugins of extra bronnen te installeren. Een taak kan een eenvoudige container image zijn die wordt uitgevoerd met specifieke parameters. Door versiebeheer toe te passen op taken is het eenvoudig om voor elk specifiek doel een andere versie van de taak te gebruiken. Dit elimineert de noodzaak om alle pijplijnen te upgraden wanneer een taak wordt bijgewerkt. #### Wat heeft een ontwikkelaar hieraan? - **Aanpasbaarheid**: Alle Tekton hulpmiddelen zijn aanpasbaar, waardoor ontwikkelaars zeer gedetailleerde pijplijnen en taken kunnen schrijven. - **Herbruikbaarheid**: Pijplijnen en/of taken kunnen herhaaldelijk worden ingezet, zowel binnen dezelfde pijplijn als tussen verschillende pijplijnen. - **Uitbreidbaarheid**: Tekton biedt een catalogus van vooraf geconfigureerde, veelgebruikte taken. De middelen in deze catalogus kunnen worden gedownload en aangepast aan de specifieke behoeften van uw project. #### Voorbeeld: Een Docker Container Image Pipeline Laten we als voorbeeld een pijplijn maken die een Docker container image bouwt en naar een Docker container register pusht. Eerst bereiden we onze Tekton-taken voor, zodat we ze in onze Tekton-pijplijn kunnen definiëren. Welke stappen zijn nodig om een Docker container image te bouwen? 1. Git kloon: Om onze broncode op te halen. 2. Git Versie: Om een versie voor onze container te definiëren. 3. Trivy Scanning: Om in eerste instantie te controleren of onze image CVE's bevat. 4. Kaniko Builder: Een tool om een Docker image te bouwen van een Dockerfile en het naar het register te pushen. 5. Pipeline starten: Met Tekton PipelineRun kunnen we onze parameters definiëren, zoals branch_name, repository_url en repository_name. 6. Uitrollen: De middelen achtereenvolgens inzetten om te testen: Taken, Pipeline en PipelineRun. U kunt de bijbehorende YAML-bestanden voor elk van deze taken vinden op de [Tekton Hub](https://hub.tekton.dev/). ### Taken #### Git kloon ``` apiVersion: tekton.dev/v1beta1kind: Taskmetadata: name: git-clone labels: app.kubernetes.io/version: "0.9" annotations: tekton.dev/pipelines.minVersion: "0.38.0" tekton.dev/categories: Git tekton.dev/tags: git tekton.dev/displayName: "git clone" tekton.dev/platforms: "linux/amd64,linux/s390x,linux/ppc64le,linux/arm64"spec: description: >- These Tasks are Git tasks to work with repositories used by other tasks in your Pipeline. The git-clone Task will clone a repo from the provided url into the output Workspace. By default the repo will be cloned into the root of your Workspace. You can clone into a subdirectory by setting this Task's subdirectory param. This Task also supports sparse checkouts. To perform a sparse checkout, pass a list of comma separated directory patterns to this Task's sparseCheckoutDirectories param. workspaces: - name: output description: The git repo will be cloned onto the volume backing this Workspace. - name: ssh-directory optional: true description: | A .ssh directory with private key, known_hosts, config, etc. Copied to the user's home before git commands are executed. Used to authenticate with the git remote when performing the clone. Binding a Secret to this Workspace is strongly recommended over other volume types. - name: basic-auth optional: true description: | A Workspace containing a .gitconfig and .git-credentials file. These will be copied to the user's home before any git commands are run. Any other files in this Workspace are ignored. It is strongly recommended to use ssh-directory over basic-auth whenever possible and to bind a Secret to this Workspace over other volume types. - name: ssl-ca-directory optional: true description: | A workspace containing CA certificates, this will be used by Git to verify the peer with when fetching or pushing over HTTPS. params: - name: url description: Repository URL to clone from. type: string - name: revision description: Revision to checkout. (branch, tag, sha, ref, etc...) type: string default: "" - name: refspec description: Refspec to fetch before checking out revision. default: "" - name: submodules description: Initialize and fetch git submodules. type: string default: "true" - name: depth description: Perform a shallow clone, fetching only the most recent N commits. type: string default: "1" - name: sslVerify description: Set the `http.sslVerify` global git config. Setting this to `false` is not advised unless you are sure that you trust your git remote. type: string default: "true" - name: crtFileName description: file name of mounted crt using ssl-ca-directory workspace. default value is ca-bundle.crt. type: string default: "ca-bundle.crt" - name: subdirectory description: Subdirectory inside the `output` Workspace to clone the repo into. type: string default: "" - name: sparseCheckoutDirectories description: Define the directory patterns to match or exclude when performing a sparse checkout. type: string default: "" - name: deleteExisting description: Clean out the contents of the destination directory if it already exists before cloning. type: string default: "true" - name: httpProxy description: HTTP proxy server for non-SSL requests. type: string default: "" - name: httpsProxy description: HTTPS proxy server for SSL requests. type: string default: "" - name: noProxy description: Opt out of proxying HTTP/HTTPS requests. type: string default: "" - name: verbose description: Log the commands that are executed during `git-clone`'s operation. type: string default: "true" - name: gitInitImage description: The image providing the git-init binary that this Task runs. type: string default: "gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/git-init:v0.40.2" - name: userHome description: | Absolute path to the user's home directory. type: string default: "/home/git" results: - name: commit description: The precise commit SHA that was fetched by this Task. - name: url description: The precise URL that was fetched by this Task. - name: committer-date description: The epoch timestamp of the commit that was fetched by this Task. steps: - name: clone image: "$(params.gitInitImage)" env: - name: HOME value: "$(params.userHome)" - name: PARAM_URL value: $(params.url) - name: PARAM_REVISION value: $(params.revision) - name: PARAM_REFSPEC value: $(params.refspec) - name: PARAM_SUBMODULES value: $(params.submodules) - name: PARAM_DEPTH value: $(params.depth) - name: PARAM_SSL_VERIFY value: $(params.sslVerify) - name: PARAM_CRT_FILENAME value: $(params.crtFileName) - name: PARAM_SUBDIRECTORY value: $(params.subdirectory) - name: PARAM_DELETE_EXISTING value: $(params.deleteExisting) - name: PARAM_HTTP_PROXY value: $(params.httpProxy) - name: PARAM_HTTPS_PROXY value: $(params.httpsProxy) - name: PARAM_NO_PROXY value: $(params.noProxy) - name: PARAM_VERBOSE value: $(params.verbose) - name: PARAM_SPARSE_CHECKOUT_DIRECTORIES value: $(params.sparseCheckoutDirectories) - name: PARAM_USER_HOME value: $(params.userHome) - name: WORKSPACE_OUTPUT_PATH value: $(workspaces.output.path) - name: WORKSPACE_SSH_DIRECTORY_BOUND value: $(workspaces.ssh-directory.bound) - name: WORKSPACE_SSH_DIRECTORY_PATH value: $(workspaces.ssh-directory.path) - name: WORKSPACE_BASIC_AUTH_DIRECTORY_BOUND value: $(workspaces.basic-auth.bound) - name: WORKSPACE_BASIC_AUTH_DIRECTORY_PATH value: $(workspaces.basic-auth.path) - name: WORKSPACE_SSL_CA_DIRECTORY_BOUND value: $(workspaces.ssl-ca-directory.bound) - name: WORKSPACE_SSL_CA_DIRECTORY_PATH value: $(workspaces.ssl-ca-directory.path) securityContext: runAsNonRoot: true runAsUser: 65532 script: | #!/usr/bin/env sh set -eu if [ "${PARAM_VERBOSE}" = "true" ] ; then set -x fi if [ "${WORKSPACE_BASIC_AUTH_DIRECTORY_BOUND}" = "true" ] ; then cp "${WORKSPACE_BASIC_AUTH_DIRECTORY_PATH}/.git-credentials" "${PARAM_USER_HOME}/.git-credentials" cp "${WORKSPACE_BASIC_AUTH_DIRECTORY_PATH}/.gitconfig" "${PARAM_USER_HOME}/.gitconfig" chmod 400 "${PARAM_USER_HOME}/.git-credentials" chmod 400 "${PARAM_USER_HOME}/.gitconfig" fi if [ "${WORKSPACE_SSH_DIRECTORY_BOUND}" = "true" ] ; then cp -R "${WORKSPACE_SSH_DIRECTORY_PATH}" "${PARAM_USER_HOME}"/.ssh chmod 700 "${PARAM_USER_HOME}"/.ssh chmod -R 400 "${PARAM_USER_HOME}"/.ssh/* fi if [ "${WORKSPACE_SSL_CA_DIRECTORY_BOUND}" = "true" ] ; then export GIT_SSL_CAPATH="${WORKSPACE_SSL_CA_DIRECTORY_PATH}" if [ "${PARAM_CRT_FILENAME}" != "" ] ; then export GIT_SSL_CAINFO="${WORKSPACE_SSL_CA_DIRECTORY_PATH}/${PARAM_CRT_FILENAME}" fi fi CHECKOUT_DIR="${WORKSPACE_OUTPUT_PATH}/${PARAM_SUBDIRECTORY}" cleandir() { # Delete any existing contents of the repo directory if it exists. # # We don't just "rm -rf ${CHECKOUT_DIR}" because ${CHECKOUT_DIR} might be "/" # or the root of a mounted volume. if [ -d "${CHECKOUT_DIR}" ] ; then # Delete non-hidden files and directories rm -rf "${CHECKOUT_DIR:?}"/* # Delete files and directories starting with . but excluding .. rm -rf "${CHECKOUT_DIR}"/.[!.]* # Delete files and directories starting with .. plus any other character rm -rf "${CHECKOUT_DIR}"/..?* fi } if [ "${PARAM_DELETE_EXISTING}" = "true" ] ; then cleandir || true fi test -z "${PARAM_HTTP_PROXY}" || export HTTP_PROXY="${PARAM_HTTP_PROXY}" test -z "${PARAM_HTTPS_PROXY}" || export HTTPS_PROXY="${PARAM_HTTPS_PROXY}" test -z "${PARAM_NO_PROXY}" || export NO_PROXY="${PARAM_NO_PROXY}" git config --global --add safe.directory "${WORKSPACE_OUTPUT_PATH}" /ko-app/git-init \ -url="${PARAM_URL}" \ -revision="${PARAM_REVISION}" \ -refspec="${PARAM_REFSPEC}" \ -path="${CHECKOUT_DIR}" \ -sslVerify="${PARAM_SSL_VERIFY}" \ -submodules="${PARAM_SUBMODULES}" \ -depth="${PARAM_DEPTH}" \ -sparseCheckoutDirectories="${PARAM_SPARSE_CHECKOUT_DIRECTORIES}" cd "${CHECKOUT_DIR}" RESULT_SHA="$(git rev-parse HEAD)" EXIT_CODE="$?" if [ "${EXIT_CODE}" != 0 ] ; then exit "${EXIT_CODE}" fi RESULT_COMMITTER_DATE="$(git log -1 --pretty=%ct)" printf "%s" "${RESULT_COMMITTER_DATE}" > "$(results.committer-date.path)" printf "%s" "${RESULT_SHA}" > "$(results.commit.path)" printf "%s" "${PARAM_URL}" > "$(results.url.path)" ``` #### Git versiebeheer ``` ---apiVersion: tekton.dev/v1beta1kind: Taskmetadata: name: git-version labels: app.kubernetes.io/version: "0.1" annotations: tekton.dev/pipelines.minVersion: "0.12.0" tekton.dev/displayName: "git version" tekton.dev/categories: Git tekton.dev/tags: git tekton.dev/platforms: "linux/amd64"spec: description: >- This task can be used to create a version from git history params: - description: branch to checkout to create a version for e.g. "develop" name: branch type: string results: - description: The calculated git version you could use for git tagging e.g. "0.1.0-tektonize.1-188" name: gitVersion - description: A normalized version for use in container images e.g. "0.1.0-tektonize.1-188" name: packageVersion steps: - image: mcr.microsoft.com/dotnet/sdk:3.1-focal@sha256:1d31e2582f69920c3a6ea9498bb7da285baffbca7ea84d90d9e5b545604cc92d name: set-git-version workingDir: $(workspaces.source.path) securityContext: runAsUser: 0 env: - name: PARAM_BRANCH value: $(params.branch) script: | #!/usr/bin/env bash export PATH="$PATH:/tekton/home/.dotnet/tools" dotnet tool install GitVersion.Tool --version 5.5.0 --tool-path "/tekton/home/.dotnet/tools" git checkout "${PARAM_BRANCH}" export GITVERSION=$(dotnet gitversion /showvariable FullSemVer) echo -n "${GITVERSION}" | tee $(results.gitVersion.path) # normalize a bit because # image tags can only contain `abcdefghijklmnopqrstuvwxyz0123456789_-.ABCDEFGHIJKLMNOPQRSTUVWXYZ` export PACKAGEVERSION=$(echo -n $GITVERSION | sed 's/[^-._0-9A-Za-z]/-/g') echo -n "${PACKAGEVERSION}" | tee $(results.packageVersion.path) workspaces: - name: source description: A workspace that contains the fetched git repository to create a version for. ``` #### Trivy Scanner ``` ---apiVersion: tekton.dev/v1beta1kind: Taskmetadata: name: trivy-scanner labels: app.kubernetes.io/version: "0.2" annotations: tekton.dev/pipelines.minVersion: "0.12.1" tekton.dev/categories: Security tekton.dev/tags: CLI, trivy tekton.dev/displayName: "trivy scanner" tekton.dev/platforms: "linux/amd64,linux/arm64,linux/ppc64le,linux/390x"spec: description: >- Trivy is a simple and comprehensive scanner for vulnerabilities in container images,file systems ,and Git repositories, as well as for configuration issues. This task can be used to scan for vulnenrabilities on the source code in stand alone mode. workspaces: - name: manifest-dir params: - name: ARGS description: The Arguments to be passed to Trivy command. type: array - name: TRIVY_IMAGE default: docker.io/aquasec/trivy@sha256:944a044451791617cc0ed2ee4d1942a4f66b790d527fcd0575a6b399ccbc05a1 # 0.43.1 description: Trivy scanner image to be used - name: IMAGE_PATH description: Image or Path to be scanned by trivy. type: string - name: AIR_GAPPED_ENABLED default: "false" description: a flag enabling Air-Gapped mode type: string steps: - name: trivy-scan image: $(params.TRIVY_IMAGE) workingDir: $(workspaces.manifest-dir.path) script: | #!/usr/bin/env sh cmd="trivy $* " if [ "$(params.AIR_GAPPED_ENABLED)" = "true" ]; then echo "Air-Gapped mode enabled" TRIVY_TEMP_DIR=$(mktemp -d) trivy --cache-dir "$TRIVY_TEMP_DIR" image --download-db-only tar -cf ./db.tar.gz -C "$TRIVY_TEMP_DIR/db" metadata.json trivy.db rm -rf "$TRIVY_TEMP_DIR" mkdir -p "$HOME"/.cache/trivy/db tar xvf ./db.tar.gz -C "$HOME"/.cache/trivy/db cmd="${cmd}--skip-update " fi cmd="${cmd}$(params.IMAGE_PATH)" echo "Running trivy task with command below" echo "$cmd" eval "$cmd" args: - "$(params.ARGS)" ``` #### Kaniko bouwer ``` ---apiVersion: tekton.dev/v1beta1kind: Taskmetadata: name: trivy-scanner labels: app.kubernetes.io/version: "0.2" annotations: tekton.dev/pipelines.minVersion: "0.12.1" tekton.dev/categories: Security tekton.dev/tags: CLI, trivy tekton.dev/displayName: "trivy scanner" tekton.dev/platforms: "linux/amd64,linux/arm64,linux/ppc64le,linux/390x"spec: description: >- Trivy is a simple and comprehensive scanner for vulnerabilities in container images,file systems ,and Git repositories, as well as for configuration issues. This task can be used to scan for vulnenrabilities on the source code in stand alone mode. workspaces: - name: manifest-dir params: - name: ARGS description: The Arguments to be passed to Trivy command. type: array - name: TRIVY_IMAGE default: docker.io/aquasec/trivy@sha256:944a044451791617cc0ed2ee4d1942a4f66b790d527fcd0575a6b399ccbc05a1 # 0.43.1 description: Trivy scanner image to be used - name: IMAGE_PATH description: Image or Path to be scanned by trivy. type: string - name: AIR_GAPPED_ENABLED default: "false" description: a flag enabling Air-Gapped mode type: string steps: - name: trivy-scan image: $(params.TRIVY_IMAGE) workingDir: $(workspaces.manifest-dir.path) script: | #!/usr/bin/env sh cmd="trivy $* " if [ "$(params.AIR_GAPPED_ENABLED)" = "true" ]; then echo "Air-Gapped mode enabled" TRIVY_TEMP_DIR=$(mktemp -d) trivy --cache-dir "$TRIVY_TEMP_DIR" image --download-db-only tar -cf ./db.tar.gz -C "$TRIVY_TEMP_DIR/db" metadata.json trivy.db rm -rf "$TRIVY_TEMP_DIR" mkdir -p "$HOME"/.cache/trivy/db tar xvf ./db.tar.gz -C "$HOME"/.cache/trivy/db cmd="${cmd}--skip-update " fi cmd="${cmd}$(params.IMAGE_PATH)" echo "Running trivy task with command below" echo "$cmd" eval "$cmd" args: - "$(params.ARGS)" ``` #### Kaniko Builder ``` apiVersion: tekton.dev/v1beta1kind: Taskmetadata: name: kaniko labels: app.kubernetes.io/version: "0.6" annotations: tekton.dev/pipelines.minVersion: "0.17.0" tekton.dev/categories: Image Build tekton.dev/tags: image-build tekton.dev/displayName: "Build and upload container image using Kaniko" tekton.dev/platforms: "linux/amd64,linux/arm64,linux/ppc64le"spec: description: >- This Task builds a simple Dockerfile with kaniko and pushes to a registry. This Task stores the image name and digest as results, allowing Tekton Chains to pick up that an image was built & sign it. params: - name: IMAGE description: Name (reference) of the image to build. - name: DOCKERFILE description: Path to the Dockerfile to build. default: ./Dockerfile - name: CONTEXT description: The build context used by Kaniko. default: ./ - name: EXTRA_ARGS type: array default: [] - name: BUILDER_IMAGE description: The image on which builds will run (default is v1.5.1) default: gcr.io/kaniko-project/executor:v1.5.1@sha256:c6166717f7fe0b7da44908c986137ecfeab21f31ec3992f6e128fff8a94be8a5 workspaces: - name: source description: Holds the context and Dockerfile - name: dockerconfig description: Includes a docker `config.json` optional: true mountPath: /kaniko/.docker results: - name: IMAGE_DIGEST description: Digest of the image just built. - name: IMAGE_URL description: URL of the image just built. steps: - name: build-and-push workingDir: $(workspaces.source.path) image: $(params.BUILDER_IMAGE) args: - $(params.EXTRA_ARGS) - --dockerfile=$(params.DOCKERFILE) - --context=$(workspaces.source.path)/$(params.CONTEXT) # The user does not need to care the workspace and the source. - --destination=$(params.IMAGE) - --digest-file=$(results.IMAGE_DIGEST.path) # kaniko assumes it is running as root, which means this example fails on platforms # that default to run containers as random uid (like OpenShift). Adding this securityContext # makes it explicit that it needs to run as root. securityContext: runAsUser: 0 - name: write-url image: docker.io/library/bash:5.1.4@sha256:c523c636b722339f41b6a431b44588ab2f762c5de5ec3bd7964420ff982fb1d9 script: | set -e image="$(params.IMAGE)" echo -n "${image}" | tee "$(results.IMAGE_URL.path)" ``` Nu we onze taken hebben voorbereid, kunnen we onze aangepaste Tekton Pipeline schrijven. Tekton Pipeline wordt van boven naar beneden opgebouwd. #### Tekton-pipeline ``` apiVersion: tekton.dev/v1beta1kind: Pipelinemetadata: name: custom-docker-image namespace: tekton-pipelinesspec: params: - name: branch_name description: The git branch - name: repository_url description: The git repository url - name: repository_name description: The git repository name tasks: - name: clonegit taskRef: name: git-clone params: - name: url value: $(params.repository_url) - name: revision value: $(params.branch_name) - name: deleteExisting value: true - name: depth value: "0" workspaces: - name: output workspace: source-workspace - name: gitversion taskRef: name: git-version runAfter: - clonegit params: - name: branch value: "$(params.branch_name)" workspaces: - name: source workspace: source-workspace - name: trivyscanner taskRef: name: trivy-scanner runAfter: - gitversion params: - name: IMAGE_PATH value: "." - name: ARGS value: [ ] workspaces: - name: source workspace: source-workspace - name: kanikobuilder taskRef: name: kaniko runAfter: - trivyscanner params: - name: IMAGE value: "/$(params.repository_name):$(tasks.gitversion.results.packageVersion)" - name: DOCKERFILE value: "Dockerfile" workspaces: - name: source workspace: source-workspace - name: dockerconfig workspace: docker-credentials workspaces: - name: source-workspace - name: docker-credentials ``` #### PipelineRun Nu we een complete Tekton Pipeline hebben, kunnen we onze pipeline starten. Hiervoor hebben we Tekton PipelineRun nodig. Hier gaan we onze parameters definiëren zoals: - tak_naam - archief_url - archiefnaam ``` apiVersion: tekton.dev/v1beta1kind: PipelineRunmetadata: name: custom-docker-image namespace: tekton-pipelinesspec: serviceAccountName: tekton-pipelines-build-bot pipelineRef: name: custom-docker-image params: - name: branch_name value: "develop" - name: repository_url value: "" - name: repository_name value: "" workspaces: - name: source-workspace subPath: source persistentVolumeClaim: claimName: custom-docker-image-source - name: docker-credentials subPath: source persistentVolumeClaim: claimName: custom-docker-image-docker-credentials pipelineSpec: tasks: - name: clonegit taskRef: name: git-clone] - name: gitversion taskRef: name: git-version - name: trivyscanner taskRef: name: gitversion - name: kanikobuilder taskRef: name: kaniko ``` Implementeer de middelen om te testen in volgorde: Taken, Pipeline en PipelineRun. ## 2. Tekton Triggers: Pipelines starten met gebeurtenissen Triggers zorgen ervoor dat Tekton Pipelines kunnen worden gestart door een gebeurtenis, zoals een commit naar een repository die vervolgens een webhook naar je Trigger Listener stuurt. Er zijn verschillende opties om je pipeline te activeren vanuit een gebeurtenis. Als we het bovenstaande diagram verder uitwerken en Tekton Triggers toevoegen, ziet het er als volgt uit: Stappen: 1. Git stuurt een payload via een webhook naar de EventListener. 2. De EventListener leest de inkomende webhook en payload, en controleert of het voor hem bedoeld is. 3. Als de EventListener vaststelt dat het voor hem bedoeld is, plaatst hij de geconfigureerde waarden uit de payload in een variabele. Dit gebeurt via TriggerBinding. 4. De EventListener maakt vervolgens een TriggerTemplate met de waarden uit TriggerBinding. 5. TriggerTemplate initieert vervolgens een PipelineRun en voert de gedefinieerde taken uit. ### Voorbeeld #### EventListener Eerst maken we onze EventListener aan op basis van een CEL-expressie.   ``` apiVersion: triggers.tekton.dev/v1alpha1kind: EventListenermetadata: name: custom-docker-build-listener namespace: tekton-pipelinesspec: serviceAccountName: tekton-triggers-build-bot triggers: - name: git-custom-docker-build-listener interceptors: - cel: filter: (body.repository.workspace.slug.matches('') && body.push.changes[0].new.name.matches('') && body.repository.name.matches('')) template: - ref: git-custom-docker-build-listener bindings: - ref: git-custom-docker-build-listener ``` In onze EventListener hebben we triggers geconfigureerd die: - zal kijken naar de WORKSPACE naam - naar de BRANCH naam zal kijken - zal kijken naar de REPOSITORY naam Als deze velden correct zijn, zal hij een sjabloon voorbereiden. We gaan ook een TriggerTemplate en TriggerBinding voorbereiden om parameters te gebruiken tijdens de trigger. #### TriggerBinding In de TriggerBinding extraheren we de Trigger Body en laden we de variabelen met de bodywaarden die zijn verzonden vanuit Webhook. ``` apiVersion: triggers.tekton.dev/v1alpha1kind: TriggerBindingmetadata: name: custom-docker-build-listener namespace: tekton-pipelinesspec: params: - name: branch_name value: $(body.pullrequest.destination.branch.name) - name: repository_url value: $(body.repository.links.html.href) - name: repository_name value: $(body.repository.name) ``` #### TriggerTemplate Nu we de variabelen in de TriggerBinding hebben, kunnen we onze Pipeline starten vanuit TriggerTemplate met onze variabelen die uit Trigger komen. We kunnen hiervoor de notatie ${tt.xx} gebruiken. ``` apiVersion: triggers.tekton.dev/v1alpha1kind: TriggerTemplatemetadata: name: custom-docker-build-listener namespace: tekton-pipelinesspec: params: - name: branch_name description: The git branch name - name: repository_url description: The git repository url - name: repository_name description: The git repository name resourcetemplates: - apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: generateName: $(tt.params.repository_name)- labels: tekton.dev/pipeline: tekton-pipeline spec: serviceAccountName: tekton-pipelines-build-bot pipelineRef: name: custom-docker-build-listener params: - name: branch_name value: $(tt.params.branch_name) - name: repository_url value: $(tt.params.repository_url) - name: repository_name value: $(tt.params.repository_name) workspaces: - name: source-workspace subPath: source persistentVolumeClaim: claimName: custom-docker-image-source - name: docker-credentials subPath: source persistentVolumeClaim: claimName: custom-docker-image-docker-credentials pipelineSpec: tasks: - name: clonegit taskRef: name: git-clone] - name: gitversion taskRef: name: git-version - name: trivyscanner taskRef: name: gitversion - name: kanikobuilder taskRef: name: kaniko ``` Implementeer de bronnen om te testen: TriggerTemplate, TriggerBinding, EventListener. ## 3. Tekton Dashboard: Gestroomlijnd beheer en monitoring Het observeren en beheren van Tekton middelen binnen een Kubernetes omgeving is niet altijd eenvoudig, zeker als je bedenkt dat ontwikkelaars vaak beperkte toegangsrechten hebben in de Kubernetes omgeving. Om deze reden wordt het gebruik van Tekton Dashboards aanbevolen. Tekton Dashboard dient als uitbreiding op het Tekton ecosysteem en biedt een gebruiksvriendelijke webinterface voor het beheren en monitoren van Tekton resources in Kubernetes omgevingen. Het faciliteert ontwikkelaars bij het volgen van pijplijnen, het monitoren van real-time logs en het verifiëren van taakstatussen. Hierdoor kunnen ontwikkelaars snel de redenen voor bouwfouten en hun specifieke locaties identificeren. ## 4. Tekton Hub: Uitgebreide bibliotheek van pijplijnen en taken Tekton biedt een uitgebreide reeks pijplijnen en taken die direct beschikbaar zijn. Hoewel ontwikkelaars pijplijnen of taken vanaf nul kunnen schrijven, hebben ze ook de optie om taken en pijplijnen van de Tekton Hub over te nemen. De middelen die van de Hub worden overgenomen, kunnen naar behoefte worden aangepast. Dit biedt ontwikkelaars flexibiliteit, zodat ze zich niet strikt hoeven te houden aan vooraf gedefinieerde middelen en in plaats daarvan hun middelen volledig kunnen herschrijven op basis van hun voorkeuren. Enkele belangrijke taken die beschikbaar zijn via de Hub zijn: - Git-Clone - Werkruimte schoner - Maven - Jib-Maven - BuildPacks - Kaniko/Docker Meer taken zijn beschikbaar op https://hub.tekton.dev/. ## Aan de slag met Tekton Voor ontwikkelaars die Tekton willen gaan gebruiken biedt de officiële [Tekton-documentatie](https://tekton.dev/docs/getting-started/) gedetailleerde informatie over installatie en configuratie. Samenvattend biedt Tekton een krachtige, flexibele en schaalbare oplossing voor CI/CD processen. Met zijn CloudNative kenmerken, uitbreidbaarheid en ondersteuning van grote bedrijven heeft Tekton zich gevestigd als een betrouwbaar framework voor ontwikkelaars. Wilt u de voordelen van Tekton in de praktijk ervaren en ontdekken hoe ACA Group innovatieve oplossingen kan bieden voor uw IT-uitdagingen? [Neem](https://acagroup.be/en/contact/?hsLang=nl)gerust [contact op met onze experts](https://acagroup.be/en/contact/?hsLang=nl) voor persoonlijk advies en een naadloze implementatie.   [Volledig bericht weergeven](https://acagroup.be/nl/blog/tekton-the-powerful-open-source-ci-cd-framework) ```json { "@context" : "http://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Ugur Akkar" }, "dateModified" : "2026-03-16T09:32:26.439Z", "datePublished" : "2024-01-18T03:30:00Z", "headline" : "Tekton: Het Krachtige Open Source CI/CD-Framework", "image" : { "@type" : "ImageObject", "height" : 1300, "url" : "https://25145356.fs1.hubspotusercontent-eu1.net/hubfs/25145356/tekton.png", "width" : 2000 }, "mainEntityOfPage" : "https://acagroup.be/nl/blog/tekton-the-powerful-open-source-ci-cd-framework", "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "height" : 60.0, "url" : "https://25145356.fs1.hubspotusercontent-eu1.net/hubfs/25145356/SVG%20Icons/aca-group%20(white).svg", "width" : 134.21053 }, "name" : "Blog" } } ```