【 云原生 | kubernetes 】- tekton构建CI/CD流水线(二)

简介: 上一节我们是通过创建Pipelinerun来触发流水线来进行构建,实际生产中完全自动化的实现需要借助tekton中的triggers。本文是上篇的拓展请先了解这篇文章

​ 上一节我们是通过创建Pipelinerun来触发流水线来进行构建,实际生产中完全自动化的实现需要借助tekton中的triggers。本文是上篇的拓展请先了解这篇文章

Tekton Triggers 是一个 Tekton 组件,它允许您从各种来源的事件中检测和提取信息,TaskRunsPipelineRuns 根据该信息确定性地实例化和执行。Tekton 触发器还可以将从事件中提取的信息直接传递给TaskRunsPipelineRuns
在这里插入图片描述

Triggers

Tekton Triggers包含下面几个CRD来对tekton进行拓展。

  • EventListener- 在 Kubernetes 集群上的指定端口监听事件。指定一个或多个Triggers
  • Trigger- 指定当EventListener检测到事件时会发生什么。ATrigger指定 a TriggerTemplate、 aTriggerBinding和可选的 an Interceptor
  • TriggerTemplate- 指定资源的蓝图,例如TaskRunPipelineRun,当您EventListener检测到事件时要实例化和/或执行该蓝图。它公开了您可以在资源模板中的任何位置使用的参数。
  • TriggerBinding- 指定要从中提取数据的事件有效负载中的字段以及对应的字段TriggerTemplate以填充提取的值。然后,您可以使用 中的填充字段TriggerTemplate来填充关联TaskRun或中的字段PipelineRun
  • ClusterTriggerBinding- 的集群范围版本,TriggerBinding对于在集群中重用特别有用。
  • Interceptor- 用于特定平台的“包罗万象”事件处理器,在TriggerBinding您执行有效负载过滤、验证(使用机密)、转换、定义和测试触发条件以及其他有用处理之前运行。一旦事件数据通过拦截器,它就会Trigger在您将有效负载数据传递给TriggerBinding.

git clone -->> make build -->> Kaniko

在这之后,我使用的tasks跟之前相比做了修改,为了方便大家,把它贴在下面。

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: git-clone
  labels:
    app.kubernetes.io/version: "0.6"
  annotations:
    tekton.dev/pipelines.minVersion: "0.29.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: branch
      description: Branch to use
      default: "master"
    - 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: 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: "hub.17usoft.com/tekton/tekton-pipeline-git-init:v0.38.2" 
    - name: userHome
      description: |
        Absolute path to the user's home directory. Set this explicitly if you are running the image as a non-root user or have overridden
        the gitInitImage param with an image containing custom user configuration.
      type: string
      default: "/tekton/home"
  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.
    - description: The repo name represented by 'service-name' format
      name: short-branch-name
      type: string
  steps:
    - name: clone
      image: "$(params.gitInitImage)"
      env:
      - name: HOME
        value: "$(params.userHome)"
      - name: PARAM_BRANCH
        value: $(params.branch)
      - 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_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)
      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}"
        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
        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}"

        /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
        printf "%s" "${RESULT_SHA}" > "$(results.commit.path)"
        printf "%s" "${PARAM_URL}" > "$(results.url.path)"
    - env:
        - name: PARAM_URL
          value: $(params.url)
        - name: PARAM_REVISION
          value: $(params.revision)
        - name: PARAM_BRANCH
          value: $(params.branch)
        - name: WORKSPACE_OUTPUT_PATH
          value: $(workspaces.output.path)
        - name: PARAM_SUBDIRECTORY
          value: $(params.subdirectory)
      image: $(params.gitInitImage)
      name: prepare-outputs
      resources: {}
      script: |
        set -eu
        git config --global --add safe.directory "*" 
        CHECKOUT_DIR="${WORKSPACE_OUTPUT_PATH}/${PARAM_SUBDIRECTORY}"
        cd "${CHECKOUT_DIR}"
        
        RESULT_SHORT_BRANCH_NAME="$(basename $PARAM_BRANCH)"
        RESULT_SHA="$(git rev-parse --short HEAD)"
 
        echo "###Results:"
        echo "branch: " $RESULT_SHORT_BRANCH_NAME
        echo "commit: " $RESULT_SHA

        echo -n $RESULT_SHORT_BRANCH_NAME | tee > "$(results.short-branch-name.path)"
        echo -n $RESULT_SHA | tee > "$(results.commit.path)"
        echo -n $PARAM_URL | tee > "$(results.url.path)"
---
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: golang-build
  labels:
    app.kubernetes.io/version: "0.3"
  annotations:
    tekton.dev/pipelines.minVersion: "0.12.1"
    tekton.dev/categories: Build Tools
    tekton.dev/tags: build-tool
    tekton.dev/displayName: "golang build"
    tekton.dev/platforms: "linux/amd64,linux/s390x,linux/ppc64le"
spec:
  description: >-
    This Task is Golang task to build Go projects.

  params:
#  - name: package
#    description: base package to build in
  - name: packages
    description: "packages to build (default: ./cmd/...)"
    default: "./cmd/..."
  - name: subdirectory
    description: subdirectory inside the "source"
    default: "./"
  - name: version
    description: golang version to use for builds
    default: "latest"
  - name: flags
    description: flags to use for the test command
    default: -v
  - name: GOOS
    description: "running program's operating system target"
    default: linux
  - name: GOARCH
    description: "running program's architecture target"
    default: amd64
  - name: GO111MODULE
    description: "value of module support"
    default: auto
  - name: GOCACHE
    description: "Go caching directory path"
    default: ""
  - name: GOMODCACHE
    description: "Go mod caching directory path"
    default: ""
  - name: CGO_ENABLED
    description: "Toggle cgo tool during Go build. Use value '0' to disable cgo (for static builds)."
    default: ""
  - name: GOSUMDB
    description: "Go checksum database url. Use value 'off' to disable checksum validation."
    default: ""
  workspaces:
  - name: source
  steps:
  - name: build
    image: hub.17usoft.com/gstrain/golang:v1.18.3
    workingDir: $(workspaces.source.path)
    script: |
      if [ ! -e $GOPATH/src/$(params.subdirectory)/go.mod ];then
        SRC_PATH="$GOPATH/src/$(params.subdirectory)"
        mkdir -p $SRC_PATH
        cp -R "$(workspaces.source.path)"/$(params.subdirectory)/* $SRC_PATH
        cd $SRC_PATH
      fi
      go build -tags netgo  $(params.flags) $(params.packages)
      pwd && ls -l
      
    env:
    - name: GOOS
      value: "$(params.GOOS)"
    - name: GOARCH
      value: "$(params.GOARCH)"
    - name: GO111MODULE
      value: "$(params.GO111MODULE)"
    - name: GOCACHE
      value: "$(params.GOCACHE)"
    - name: GOMODCACHE
      value: "$(params.GOMODCACHE)"
    - name: CGO_ENABLED
      value: "$(params.CGO_ENABLED)"
    - name: GOSUMDB
      value: "$(params.GOSUMDB)"
---
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  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"
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: hub.17usoft.com/tekton/kaniko-executor:v1.5.1
  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:
    - image: 'docker.io/library/bash:5.1.4@sha256:b208215a4655538be652b2769d82e576bc4d0a2bb132144c060efc5be8c3f5d6'
      name: check-dockerconfig
      resources: {}
      script: |
        ls -al /kaniko/.docker
        cat /kaniko/.docker/config.json
    - 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)
      securityContext:
        runAsUser: 0
    - name: write-url
      image: docker.io/library/bash:5.1.4@sha256:b208215a4655538be652b2769d82e576bc4d0a2bb132144c060efc5be8c3f5d6
      script: |
        set -e
        image="$(params.IMAGE)"
        echo -n "${image}" | tee "$(results.IMAGE_URL.path)"

Modify listing

​ 我们上节结尾处跟大家讲了,我们会添加一个新的任务。当我们完成镜像推送后自动修改配置仓库中yaml信息。

---
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: modify-listing
  labels:
    app.kubernetes.io/version: "0.4"
  annotations:
    tekton.dev/pipelines.minVersion: "0.21.0"
    tekton.dev/categories: Git
    tekton.dev/tags: git
    tekton.dev/displayName: "git cli"
    tekton.dev/platforms: "linux/amd64,linux/s390x,linux/ppc64le"
spec:
  description: >-
    This task can be used to perform git operations.

    Git command that needs to be run can be passed as a script to
    the task. This task needs authentication to git in order to push
    after the git operation.

  workspaces:
    - name: source
      description: A workspace that contains the fetched git repository.

    - name: input
      optional: true
      description: |
        An optional workspace that contains the files that need to be added to git. You can
        access the workspace from your script using `$(workspaces.input.path)`, for instance:

          cp $(workspaces.input.path)/file_that_i_want .
          git add file_that_i_want
          # etc

    - 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.
  params:
    - name: BASE_IMAGE
      description: |
        The base image for the task.
      type: string
      default:  "cnych/helm-kubectl-curl-git-jq-yq "

    - name: GIT_USER_NAME
      type: string
      description: |
        Git user name for performing git operation.
      default: "Administrator"

    - name: GIT_USER_EMAIL
      type: string
      description: |
        Git user email for performing git operation.
      default: "1376252133@qq.com"
    
    - name: subdirectory
      type: string
      default: ""

    - name: IMAGE_URL
      type: string
      description: |
        The latest build image
      default: "$(tasks.kaniko.results.IMAGE_URL)"

    - name: GIT_SCRIPT
      description: The git script to run.
      type: string
      default: |
        cd web-service 
        git clone --branch master --depth 1  http://tekton-pipelines:z7FavbPhfEGrghsdCU5h@10.177.9.244:31002/tekton/project.git repo
        cd "repo/web-service"
        ls -l
        echo old value:
        cat 02-deployment.yaml | yq r - 'spec.template.spec.containers[0].image'
        echo replacing with new value:
        yq w -i 02-deployment.yaml 'spec.template.spec.containers[0].image' "${IMAGE_URL}"
        echo verifying new value :
        yq r 02-deployment.yaml spec.template.spec.containers[0].image
        if ! git diff-index --quiet HEAD --; then
          git status
          git add .
          git commit -m "auto updated yaml by tekton pipeline"
          git push
        else
            echo "no changes, git repository is up to date"
        fi

    - name: USER_HOME
      description: |
        Absolute path to the user's home directory. Set this explicitly if you are running the image as a non-root user or have overridden
        the gitInitImage param with an image containing custom user configuration.
      type: string
      default: "/root"

    - name: VERBOSE
      description: Log the commands that are executed during `git-clone`'s operation.
      type: string
      default: "true"

  results:
    - name: commit
      description: The precise commit SHA after the git operation.

  steps:
    - name: git
      image: $(params.BASE_IMAGE)
      workingDir: $(workspaces.source.path)
      env:
      - name: HOME
        value: $(params.USER_HOME)
      - name: PARAM_VERBOSE
        value: $(params.VERBOSE)
      - name: PARAM_USER_HOME
        value: $(params.USER_HOME)
      - 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: IMAGE_URL
        value: $(params.IMAGE_URL)
      script: |
        #!/usr/bin/env sh
        set -eu

        # Setting up the config for the git.
        git config --global user.email "$(params.GIT_USER_EMAIL)"
        git config --global user.name "$(params.GIT_USER_NAME)"

        eval '$(params.GIT_SCRIPT)'

​ 聪明的朋友已经看到了,我们这个任务主要的信息定义在$ GIT_SCRIPT ,其实很简单,就是把我们的清单从git上拉去下来通过yq工具来修改image信息,修改成功之后在推送到我们的代码库中。

Triggers创建

我们通过 EventListener 指定触发器,文件如下:

EventListener

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: gitlab-listener
spec:
  serviceAccountName: tekton-triggers-gstrain-sa
  resources:
    kubernetesResource:
      serviceType: NodePort 
  triggers:
    - name: gitlab-push-events-trigger
      bindings:                        #TriggerBinding 对象
        - name: gitrevision
          value: $(body.checkout_sha)
        - name: gitrepositoryurl
          value: $(body.repository.git_http_url)  
        - name: service-name
          value: $(body.repository.name)
        - name: gitref
          value: $(body.ref)
      interceptors:
        - name: "verify-gitlab-payload"
          ref:
            name: "gitlab"
            kind: ClusterInterceptor
          params:
            - name: secretRef
              value:
                secretName: "gitlab-secret"
                secretKey: "secretToken"
            - name: eventTypes
              value:
                - "Push Hook" #接收gitlab push 事件
      template:
        ref: triggertemplate   #TriggerTemplate 对象

因为EventListener 创建完成后会生成一个Listener服务,用来接收事件的响应。我是直接选择的NodePort来对外提供服务,使用路由的可忽略。

[root@master pipeline]# kubectl get svc 
NAME                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                              AGE
el-gitlab-listener                  NodePort    10.253.177.9     <none>        8080:39949/TCP,9000:47734/TCP        3d7h

Secret

通过secrets来配置gitlab发送webhook时请求的校验

apiVersion: v1
kind: Secret
metadata:
  name: github-secret
type: Opaque
stringData:
  secretToken: "tekton-pipeline-123"

gitlabToken添加流程

-->> project -->> settings -->> webhooks -->> url(Listener服务URL) -->> secret token(github-secret资源)

RBAC

triggers中各个资源的访问,需要声名RBAC

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tekton-triggers-gstrain-sa
secrets:
  - name: gitlab-secret
  - name: gitlab-auth
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: triggers-gstrain-eventlistener-binding
subjects:
- kind: ServiceAccount
  name: tekton-triggers-gstrain-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tekton-triggers-eventlistener-roles
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: triggers-gstrain-eventlistener-clusterbinding
subjects:
- kind: ServiceAccount
  name: tekton-triggers-gstrain-sa
  namespace: gstrain-pipeline
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tekton-triggers-eventlistener-clusterroles

TriggerBinding

指定要从中提取数据的事件有效负载中的字段以及对应的字段,具体指的是哪些字段呢。其实这里所说的是gitlab webhook中发送来的请求,这些字段都可以被我们拿来利用。

bindings:                        #TriggerBinding 对象
  - name: gitrevision
    value: $(body.checkout_sha)
  - name: gitrepositoryurl
    value: $(body.repository.git_http_url)  
  - name: service-name
    value: $(body.repository.name)
  - name: gitref
    value: $(body.ref)
{
  "object_kind": "push",
  "event_name": "push",
  "before": "68e0d3b62814596f5988d1db668df6da787f6b00",
  "after": "6e4977fb359fdde13d3f21ed7ac739102841e4ce",
  "ref": "refs/heads/master",
  "checkout_sha": "6e4977fb359fdde13d3f21ed7ac739102841e4ce",
  "message": null,
  "user_id": 1,
  "user_name": "gstrain",
  "user_username": "gstrain",
  "user_email": "",
  "user_avatar": "https://www.gravatar.com/avatar/5ccc082a1092ca51760a7b3956c04abc?s=80&d=identicon",
  "project_id": 4,
  "project": {
    "id": 4,
    "name": "web-service",
    "description": "",
    "web_url": "http://gitlab-6859ff885-96p66/gstrain/web-service",
    "avatar_url": null,
    "git_ssh_url": "git@gitlab-6859ff885-96p66:gstrain/web-service.git",
    "git_http_url": "http://10.177.9.244:31002/gstrain/web-service.git",
    "namespace": "gstrain",
    "visibility_level": 20,
    "path_with_namespace": "gstrain/web-service",
    "default_branch": "main",
    "ci_config_path": null,
    "homepage": "http://gitlab-6859ff885-96p66/gstrain/web-service",
    "url": "git@gitlab-6859ff885-96p66:gstrain/web-service.git",
    "ssh_url": "git@gitlab-6859ff885-96p66:gstrain/web-service.git",
    "http_url": "http://10.177.9.244:31002/gstrain/web-service.git"
  },
  "commits": [
    {
      "id": "6e4977fb359fdde13d3f21ed7ac739102841e4ce",
      "message": "z\n",
      "title": "z",
      "timestamp": "2022-08-22T17:46:04+08:00",
      "url": "http://gitlab-6859ff885-96p66/gstrain/web-service/-/commit/6e4977fb359fdde13d3f21ed7ac739102841e4ce",
      "author": {
        "name": "Administrator",
        "email": "1376252133@qq.com"
      },
      "added": [

      ],
      "modified": [
        "Jenkinsfile"
      ],
      "removed": [

      ]
    }
  ],
  "total_commits_count": 1,
  "push_options": {
  },
  "repository": {
    "name": "web-service",
    "url": "git@gitlab-6859ff885-96p66:gstrain/web-service.git",
    "description": "",
    "homepage": "http://gitlab-6859ff885-96p66/gstrain/web-service",
    "git_http_url": "http://10.177.9.244:31002/gstrain/web-service.git",
    "git_ssh_url": "git@gitlab-6859ff885-96p66:gstrain/web-service.git",
    "visibility_level": 20
  }
}

TriggerTemplate

接下来到了我们最重要的环节,我们可以通过读取 TriggerBinding 定义的参数,定义如下TriggerTemplate ,我们这里定义的是一个 PipelineRun 的模板,需要选定一个定义好的pipeline

---
apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
  name: triggertemplate
spec:
  params:
    - name: gitrevision
      description: The git revision
      default: master
    - name: gitrepositoryurl
      description: The git repository url
    - name: service-name
      description: The service name
    - name: gitref
      description: The branch to checkout
  resourcetemplates:
    - apiVersion: tekton.dev/v1beta1
      kind: PipelineRun
      metadata:
        generateName: $(tt.params.service-name)-pipeline-
        labels:
          service: $(tt.params.service-name)
        namespace: gstrain-pipeline
      spec:
        params:
          - name: git-http-url
            value: $(tt.params.gitrepositoryurl)
          - name: git-revision
            value: $(tt.params.gitrevision)
          - name: service-name
            value: $(tt.params.service-name)        
          - name: git-ref
            value: $(tt.params.gitref)
          - name: subdirectory
            value: $(tt.params.service-name)
#          - name: package
#            value: $(tt.params.service-name)
        serviceAccountName: tekton-triggers-gstrain-sa
        pipelineRef:
          name: gstrain-pipeline
        workspaces:
        - name: shared-data
          persistentVolumeClaim:
            claimName: my-app
        - name: dockerconfig
          secret:
            secretName: dockerconfig
#        - name: git-basic-auth
#          secret:
#            secretName: git-basic-auth

结果

​ 最后让我们git push来触发我们的triggers,测试下我们的流程是否正常,在kubernetes集群中可查看相应的pod任务。

[root@master ~]# kubectl get pod -l triggers.tekton.dev/eventlistener=gitlab-listener
NAME                                              READY   STATUS      RESTARTS   AGE
web-service-pipeline-pcpsl-change-manifests-pod   0/1     Completed   0          4h37m
web-service-pipeline-pcpsl-fetch-repo-pod         0/2     Completed   0          4h38m
web-service-pipeline-pcpsl-golang-build-pod       0/1     Completed   0          4h38m
web-service-pipeline-pcpsl-kaniko-pod             0/3     Completed   0          4h37m

到这我们的tekton构建CI/CD就已经全部完成,

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
27天前
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
130 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
2月前
|
Kubernetes Cloud Native 微服务
云原生入门与实践:Kubernetes的简易部署
云原生技术正改变着现代应用的开发和部署方式。本文将引导你了解云原生的基础概念,并重点介绍如何使用Kubernetes进行容器编排。我们将通过一个简易的示例来展示如何快速启动一个Kubernetes集群,并在其上运行一个简单的应用。无论你是云原生新手还是希望扩展现有知识,本文都将为你提供实用的信息和启发性的见解。
|
2月前
|
Kubernetes Cloud Native 开发者
云原生入门:Kubernetes的简易指南
【10月更文挑战第41天】本文将带你进入云原生的世界,特别是Kubernetes——一个强大的容器编排平台。我们将一起探索它的基本概念和操作,让你能够轻松管理和部署应用。无论你是新手还是有经验的开发者,这篇文章都能让你对Kubernetes有更深入的理解。
|
2月前
|
运维 Kubernetes Cloud Native
云原生技术入门:Kubernetes和Docker的协同工作
【10月更文挑战第43天】在云计算时代,云原生技术成为推动现代软件部署和运行的关键力量。本篇文章将带你了解云原生的基本概念,重点探讨Kubernetes和Docker如何协同工作以支持容器化应用的生命周期管理。通过实际代码示例,我们将展示如何在Kubernetes集群中部署和管理Docker容器,从而为初学者提供一条清晰的学习路径。
|
2月前
|
Kubernetes Cloud Native 云计算
云原生入门:Kubernetes 和容器化基础
在这篇文章中,我们将一起揭开云原生技术的神秘面纱。通过简单易懂的语言,我们将探索如何利用Kubernetes和容器化技术简化应用的部署和管理。无论你是初学者还是有一定经验的开发者,本文都将为你提供一条清晰的道路,帮助你理解和运用这些强大的工具。让我们从基础开始,逐步深入了解,最终能够自信地使用这些技术来优化我们的工作流程。
|
1月前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
|
1月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
2月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
64 3
|
2月前
|
Cloud Native 持续交付 云计算
云原生架构的演进与挑战
随着云计算技术的不断发展,云原生架构已成为企业数字化转型的重要支撑。本文深入探讨了云原生架构的概念、发展历程、核心技术以及面临的挑战,旨在为读者提供一个全面了解云原生架构的视角。通过分析Kubernetes、Docker等关键技术的应用,以及微服务、持续集成/持续部署(CI/CD)等实践案例,本文揭示了云原生架构在提高应用开发效率、降低运维成本、增强系统可扩展性等方面的显著优势。同时,也指出了云原生架构在安全性、复杂性管理等方面所面临的挑战,并提出了相应的解决策略。
|
2天前
|
人工智能 编解码 自然语言处理
AI运用爆发时代, 视频服务云原生底座“视频云”架构的全智能再进化
本文介绍了AI运用爆发时代下,视频服务云原生底座“视频云”架构的全智能再进化。随着AI技术的发展,视频内容和交互方式正经历深刻变革。文章从背景、视频AI应用挑战、视频云网端底座、AIGC时代的全智能化及未来展望五个方面展开讨论。重点阐述了云、网、端三者如何深度融合,通过AI赋能视频采集、生产、分发和消费全流程,实现视频处理的智能化和高效化。同时,展望了未来AI在视频领域的创新应用和潜在的杀手级应用。