实战 Tekton 流水线
作者: Ryan 发布于: 2024/4/17 更新于: 2025/7/21 字数: 0 字 阅读: 0 分钟
前面我们讲解了使用 Jenkins 流水线来实现 Kubernetes 应用的 CI/CD，现在我们来将这个流水线迁移到 Tekton 上面来，其实整体思路都是一样的，就是把要整个工作流划分成不同的任务来执行，前面工作流的阶段划分了以下几个阶段：Clone 代码 -> 单元测试 -> Golang 编译打包 -> Docker 镜像构建/推送 -> Kubectl/Helm 部署服务。
在 Tekton 中我们就可以将这些阶段直接转换成 Task 任务，Clone 代码在 Tekton 中不需要我们主动定义一个任务，只需要在执行的任务上面指定一个输入的代码资源即可。下面我们就来将上面的工作流一步一步来转换成 Tekton 流水线，代码仓库同样还是 http://git.k8s.local/course/devops-demo.git。
Clone 代码
虽然我们可以不用单独定义一个 Clone 代码的任务，直接使用 git 类型的输入资源即可，由于这里涉及到的任务较多，而且很多时候都需要先 Clone 代码然后再进行操作，所以最好的方式是将代码 Clone 下来过后通过 Workspace 共享给其他任务，这里我们可以直接使用 Catalog git-clone 来实现这个任务，我们可以根据自己的需求做一些定制，对应的 Task 如下所示：
yaml
# task-deploy.yaml
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: deploy-911
labels:
app.kubernetes.io/version: '0.3'
annotations:
tekton.dev/pipelines.minVersion: '0.12.1'
tekton.dev/categories: Deployment
tekton.dev/tags: helm
tekton.dev/platforms: 'linux/amd64,linux/s390x,linux/ppc64le,linux/arm64'
spec:
description: >-
These tasks will install / upgrade a helm chart into your Kubernetes /
OpenShift Cluster using Helm
params:
- name: charts_dir
description: The directory in source that contains the helm chart
- name: release_version
description: The helm release version in semantic versioning format
default: 'v1.0.0'
- name: release_name
description: The helm release name
default: 'helm-release'
- name: release_namespace
description: The helm release namespace
default: ''
- name: overwrite_values
description: 'Specify the values you want to overwrite, comma separated: autoscaling.enabled=true,replicas=1'
default: ''
- name: values_file
description: 'The values file to be used'
default: 'values.yaml'
- name: helm_image
description: 'helm image to be used'
default: 'registry.cn-beijing.aliyuncs.com/xxk8s/k8s-helm:v3.6.0'
- name: upgrade_extra_params
description: 'Extra parameters passed for the helm upgrade command'
default: ''
workspaces:
- name: source
results:
- name: helm-status
description: Helm deploy status
steps:
- name: upgrade
image: $(params.helm_image)
workingDir: /workspace/source
script: |
echo current installed helm releases
helm list --namespace "$(params.release_namespace)"
echo installing helm chart...
helm upgrade --install --wait --values "$(params.charts_dir)/$(params.values_file)" --namespace "$(params.release_namespace)" --version "$(params.release_version)" "$(params.release_name)" "$(params.charts_dir)" --debug --set "$(params.overwrite_values)" $(params.upgrade_extra_params)
status=`helm status $(params.release_name) --namespace "$(params.release_namespace)" | awk '/STATUS/ {print $2}'`
echo ${status} | tr -d "\n" | tee $(results.helm-status.path)一般来说我们只需要提供 output 这个个用于持久化代码的 workspace，然后还包括 url 和 revision 这两个参数，其他使用默认的即可。
单元测试
单元测试阶段比较简单，正常来说也是只是单纯执行一个测试命令即可，我们这里没有真正执行单元测试，所以简单测试下即可，编写一个如下所示的 Task：
yaml
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: test-911
spec:
steps:
- name: test
image: registry.cn-beijing.aliyuncs.com/xxk8s/golang:1.14.2-alpine3.11
command: ['echo']
args: ['this is a test task']编译打包
然后第二个阶段是编译打包阶段，因为我们这个项目的 Dockerfile 不是使用的多阶段构建，所以需要先用一个任务去将应用编译打包成二进制文件，然后将这个编译过后的文件传递到下一个任务进行镜像构建。
我们已经明确了这个阶段要做的事情，编写任务也就简单了，创建如下所的 Task 任务，首先需要通过定义一个 workspace 把 clone 任务里面的代码关联过来：
yaml
# task-build.yaml
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: build-911
spec:
workspaces:
- name: go-repo
mountPath: /workspace/repo
steps:
- name: build
image: registry.cn-beijing.aliyuncs.com/xxk8s/golang:1.14.2-alpine3.11
workingDir: /workspace/repo
script: |
go build -v -o demo-app
env:
- name: GOPROXY
value: https://goproxy.cn
- name: GOOS
value: linux
- name: GOARCH
value: amd64这个构建任务也很简单，只是我们将需要用到的环境变量直接通过 env 注入了，当然直接写入到 script 中也是可以的，或者直接使用 command 来执行任务都可以，然后构建生成的 demo-app 这个二进制文件保留在代码根目录，这样也就可以通过 workspace 进行共享了。
Docker 镜像
接下来就是构建并推送 Docker 镜像了，前面我们介绍过使用 Kaniko、DooD、DinD 3 种模式的镜像构建方式，这里我们直接使用 DinD 这种模式，我们这里要构建的镜像 Dockerfile 非常简单:
dockerfile
FROM alpine
WORKDIR /home
# 修改alpine源为阿里云
RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/g' /etc/apk/repositories && \
apk update && \
apk upgrade && \
apk add ca-certificates && update-ca-certificates && \
apk add --update tzdata && \
rm -rf /var/cache/apk/*
COPY demo-app /home/
ENV TZ=Asia/Shanghai
EXPOSE 8080
ENTRYPOINT ./demo-app直接将编译好的二进制文件拷贝到镜像中即可，所以我们这里同样需要通过 Workspace 去获取上一个构建任务的制品，这里我们使用 sidecar 的方式来实现 DinD 模式构建镜像，创建一个如下所示的任务：
yaml
# task-docker.yaml
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: docker
spec:
workspaces:
- name: go-repo
params:
- name: image
description: Reference of the image docker will produce.
- name: registry_mirror
description: Specific the docker registry mirror
default: ''
- name: registry_url
description: private docker images registry url
steps:
- name: docker-build # 构建步骤
image: registry.cn-beijing.aliyuncs.com/xxk8s/docker:l24910
env:
- name: DOCKER_HOST # 用 TLS 形式通过 TCP 链接 sidecar
value: tcp://localhost:2376
- name: DOCKER_TLS_VERIFY # 校验 TLS
value: '1'
- name: DOCKER_CERT_PATH # 使用 sidecar 守护进程生成的证书
value: /certs/client
- name: DOCKER_PASSWORD
valueFrom:
secretKeyRef:
name: harbor-auth
key: password
- name: DOCKER_USERNAME
valueFrom:
secretKeyRef:
name: harbor-auth
key: username
workingDir: $(workspaces.go-repo.path)
script: | # docker 构建命令
docker login $(params.registry_url) -u $DOCKER_USERNAME -p $DOCKER_PASSWORD
docker build --no-cache -f ./Dockerfile -t $(params.image) .
docker push $(params.image)
volumeMounts: # 声明挂载证书目录
- mountPath: /certs/client
name: dind-certs
sidecars: # sidecar 模式，提供 docker daemon服务，实现真正的 DinD 模式
- image: registry.cn-beijing.aliyuncs.com/xxk8s/docker:dind
name: server
args:
- --storage-driver=vfs
- --userland-proxy=false
- --debug
- --insecure-registry=$(params.registry_url)
- --registry-mirror=$(params.registry_mirror)
securityContext:
privileged: true
env:
- name: DOCKER_TLS_CERTDIR # 将生成的证书写入与客户端共享的路径
value: /certs
volumeMounts:
- mountPath: /certs/client
name: dind-certs
- mountPath: /var/lib/docker
name: docker-root
readinessProbe: # 等待 dind daemon 生成它与客户端共享的证书
periodSeconds: 1
exec:
command: ['ls', '/certs/client/ca.pem']
volumes: # 使用 emptyDir 的形式即可
- name: dind-certs
emptyDir: {}
- name: docker-root
persistentVolumeClaim:
claimName: docker-root-pvc这个任务的重点还是要去声明一个 Workspace，当执行任务的时候要使用和前面构建任务同一个 Workspace，这样就可以获得上面编译成的 demo-app 这个二进制文件了。
部署
接下来的部署阶段，我们同样可以参考之前 Jenkins 流水线里面的实现，由于项目中我们包含了 Helm Chart 包，所以直接使用 Helm 来部署即可，要实现 Helm 部署，当然我们首先需要一个包含 helm 命令的镜像，当然完全可以自己去编写一个这样的任务，此外我们还可以直接去 hub.tekton.dev 上面查找 Catalog，因为这上面就有很多比较通用的一些任务了，比如 helm-upgrade-from-source 这个 Task 任务就完全可以满足我们的需求了：
这个 Catalog 下面也包含完整的使用文档了，我们可以将该任务直接下载下来根据我们自己的需求做一些定制修改，如下所示：
yaml
# task-deploy.yaml
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: deploy-911
labels:
app.kubernetes.io/version: '0.3'
annotations:
tekton.dev/pipelines.minVersion: '0.12.1'
tekton.dev/categories: Deployment
tekton.dev/tags: helm
tekton.dev/platforms: 'linux/amd64,linux/s390x,linux/ppc64le,linux/arm64'
spec:
description: >-
These tasks will install / upgrade a helm chart into your Kubernetes /
OpenShift Cluster using Helm
params:
- name: charts_dir
description: The directory in source that contains the helm chart
- name: release_version
description: The helm release version in semantic versioning format
default: 'v1.0.0'
- name: release_name
description: The helm release name
default: 'helm-release'
- name: release_namespace
description: The helm release namespace
default: ''
- name: overwrite_values
description: 'Specify the values you want to overwrite, comma separated: autoscaling.enabled=true,replicas=1'
default: ''
- name: values_file
description: 'The values file to be used'
default: 'values.yaml'
- name: helm_image
description: 'helm image to be used'
default: 'registry.cn-beijing.aliyuncs.com/xxk8s/k8s-helm:v3.6.0'
- name: upgrade_extra_params
description: 'Extra parameters passed for the helm upgrade command'
default: ''
workspaces:
- name: source
results:
- name: helm-status
description: Helm deploy status
steps:
- name: upgrade
image: $(params.helm_image)
workingDir: /workspace/source
script: |
echo current installed helm releases
helm list --namespace "$(params.release_namespace)"
echo installing helm chart...
helm upgrade --install --wait --values "$(params.charts_dir)/$(params.values_file)" --namespace "$(params.release_namespace)" --version "$(params.release_version)" "$(params.release_name)" "$(params.charts_dir)" --debug --set "$(params.overwrite_values)" $(params.upgrade_extra_params)
status=`helm status $(params.release_name) --namespace "$(params.release_namespace)" | awk '/STATUS/ {print $2}'`
echo ${status} | tr -d "\n" | tee $(results.helm-status.path)因为我们的 Helm Chart 模板就在代码仓库中，所以不需要从 Chart Repo 仓库中获取，只需要指定 Chart 路径即可，其他可配置的参数都通过 params 参数暴露出去了，非常灵活，最后我们还获取了 Helm 部署的状态，写入到了 Results 中，方便后续任务处理。
回滚
最后应用部署完成后可能还需要回滚，因为可能部署的应用有错误，当然这个回滚动作最好是我们自己去触发，但是在某些场景下，比如 helm 部署已经明确失败了，那么我们当然可以自动回滚了，所以就需要判断当部署失败的时候再执行回滚，也就是这个任务并不是一定会发生的，只在某些场景下才会出现，我们可以在流水线中通过使用 WhenExpressions 来实现这个功能。要只在满足某些条件时运行任务，可以使用 when 字段来保护任务执行，when 字段允许你列出对 WhenExpressions 的一系列引用。
WhenExpressions 由 Input、Operator 和 Values 几部分组成：
Input是WhenExpressions的输入，它可以是一个静态的输入或变量（Params 或 Results），如果未提供输入，则默认为空字符串Operator是一个运算符，表示 Input 和 Values 之间的关系，有效的运算符包括in、notinValues是一个字符串数组，必须提供一个非空的 Values 数组，它同样可以包含静态值或者变量（Params、Results 或者 Workspaces 绑定）
当在一个 Task 任务中配置了 WhenExpressions，在执行 Task 之前会评估声明的 WhenExpressions，如果结果为 True，则执行任务，如果为 False，则不会执行该任务。
我们这里创建的回滚任务如下所示：
yaml
# task-rollback.yaml
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: rollback-911
spec:
params:
- name: release_name
description: The helm release name
- name: release_namespace
description: The helm release namespace
default: ''
- name: helm_image
description: 'helm image to be used'
default: 'registry.cn-beijing.aliyuncs.com/xxk8s/k8s-helm:v3.6.0' #tag: v3.6.0
steps:
- name: rollback
image: $(params.helm_image)
script: |
echo rollback current installed helm releases
helm rollback $(params.release_name) --namespace $(params.release_namespace)流水线
现在我们的整个工作流任务都已经创建完成了，接下来我们就可以将这些任务全部串联起来组成一个 Pipeline 流水线了，将上面定义的几个 Task 引用到 Pipeline 中来，当然还需要声明 Task 中用到的 resources 或者 workspaces 这些数据：
yaml
# pipeline.yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: pipeline-911
spec:
workspaces: # 声明 workspaces
- name: go-repo-pvc
- name: secret-gitee-auth
params:
# 定义代码仓库
- name: git_url
- name: revision
type: string
default: 'main'
# 定义镜像参数
- name: image
- name: registry_url
type: string
default: 'harbor.k8s.local'
- name: registry_mirror
type: string
default: 'https://mirror.baidubce.com'
# 定义 helm charts 参数
- name: charts_dir
- name: release_name
- name: release_namespace
default: 'default'
- name: overwrite_values
default: ''
- name: values_file
default: 'values.yaml'
tasks: # 添加task到流水线中
- name: 1-clone
taskRef:
name: git-clone-911
workspaces:
- name: output
workspace: go-repo-pvc
- name: ssh-directory
workspace: secret-gitee-auth
params:
- name: url
value: $(params.git_url)
- name: revision
value: $(params.revision)
- name: 2-test
taskRef:
name: test-911
runAfter:
- 1-clone
- name: 3-build # 编译二进制程序
taskRef:
name: build-911
runAfter: # 测试任务执行之后才执行 build task
- 2-test
- 1-clone
workspaces: # 传递 workspaces
- name: go-repo
workspace: go-repo-pvc
- name: 4-docker # 构建并推送 Docker 镜像
taskRef:
name: docker-911
runAfter:
- 3-build
workspaces: # 传递 workspaces
- name: go-repo
workspace: go-repo-pvc
params: # 传递参数
- name: image
value: $(params.image)
- name: registry_url
value: $(params.registry_url)
- name: registry_mirror
value: $(params.registry_mirror)
- name: 5-deploy # 部署应用
taskRef:
name: deploy-911
runAfter:
- 4-docker
workspaces:
- name: source
workspace: go-repo-pvc
params:
- name: charts_dir
value: $(params.charts_dir)
- name: release_name
value: $(params.release_name)
- name: release_namespace
value: $(params.release_namespace)
- name: overwrite_values
value: $(params.overwrite_values)
- name: values_file
value: $(params.values_file)
- name: 6-rollback # 回滚
taskRef:
name: rollback-911
when:
- input: '$(tasks.5-deploy.results.helm-status)'
operator: in
values: ['failed']
params:
- name: release_name
value: $(params.release_name)
- name: release_namespace
value: $(params.release_namespace)整体流程比较简单，就是在 Pipeline 需要先声明使用到的 Workspace、Resource、Params 这些资源，然后将声明的数据传递到 Task 任务中去，需要注意的是最后一个回滚任务，我们需要根据前面的 deploy 任务的结果来判断是否需要执行该任务，所以这里我们使用了 when 属性，通过 $(tasks.deploy.results.helm-status) 获取部署状态。
执行流水线
现在我们就可以来执行下我们的流水线，看是否符合我们自身的要求，首先我们需要先创建关联的其他资源对象，比如 Workspace 对应的 PVC、还有 GitLab、Harbor 的认证信息：
yaml
# other.yaml
apiVersion: v1
kind: Secret
metadata:
name: gitlab-auth
annotations:
tekton.dev/git-0: http://git.k8s.local
type: kubernetes.io/basic-auth
stringData:
username: root
password: admin321
---
apiVersion: v1
kind: Secret
metadata:
name: harbor-auth
annotations:
tekton.dev/docker-0: http://harbor.k8s.local
type: kubernetes.io/basic-auth
stringData:
username: admin
password: Harbor12345
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: tekton-build-sa
secrets:
- name: harbor-auth
- name: gitlab-auth
- name: gitlab-secret
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: tekton-triggers-gitlab-minimal
rules:
# EventListeners need to be able to fetch all namespaced resources
- apiGroups: ['triggers.tekton.dev']
resources:
['eventlisteners', 'triggerbindings', 'triggertemplates', 'triggers']
verbs: ['get', 'list', 'watch']
- apiGroups: ['']
# configmaps is needed for updating logging config
resources: ['configmaps']
verbs: ['get', 'list', 'watch']
# Permissions to create resources in associated TriggerTemplates
- apiGroups: ['tekton.dev']
resources: ['pipelineruns', 'pipelineresources', 'taskruns']
verbs: ['create']
- apiGroups: ['']
resources: ['serviceaccounts']
verbs: ['impersonate']
- apiGroups: ['policy']
resources: ['podsecuritypolicies']
resourceNames: ['tekton-triggers']
verbs: ['use']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: tekton-triggers-gitlab-binding
subjects:
- kind: ServiceAccount
name: tekton-build-sa
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: tekton-triggers-gitlab-minimal
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: tekton-triggers-gitlab-clusterrole
rules:
# EventListeners need to be able to fetch any clustertriggerbindings
- apiGroups: ['triggers.tekton.dev']
resources: ['clustertriggerbindings', 'clusterinterceptors']
verbs: ['get', 'list', 'watch']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: tekton-triggers-gitlab-clusterbinding
subjects:
- kind: ServiceAccount
name: tekton-build-sa
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: tekton-triggers-gitlab-clusterrole
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: go-repo-pvc
spec:
resources:
requests:
storage: 1Gi
volumeMode: Filesystem
storageClassName: rook-cephfs # 使用 StorageClass 自动生成 PV
accessModes:
- ReadWriteMany
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: docker-root-pvc
spec:
resources:
requests:
storage: 20Gi
volumeMode: Filesystem
storageClassName: rook-cephfs # 使用 StorageClass 自动生成 PV
accessModes:
- ReadWriteMany这些关联的资源对象创建完成后，还需要为上面的 ServiceAccount 绑定一个权限，因为在 Helm 容器中我们要去操作一些集群资源，必然需要先做权限声明，这里我们可以将 tekton-build-sa 绑定到 edit 这个 ClusterRole 上去。
我们接下来就可以创建一个 PipelineRun 资源对象来触发我们的流水线构建了：
yaml
# pipelinerun.yaml
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
name: pipelinerun-911
spec:
podTemplate:
securityContext:
fsGroup: 65532
serviceAccountName: github-bot
pipelineRef:
name: pipeline-911
workspaces:
- name: go-repo-pvc
persistentVolumeClaim:
claimName: go-repo-pvc
- name: secret-gitee-auth
secret:
secretName: git-ssh-secret-gee
params:
- name: git_url
value: git@gitee.com:ryanxin/devops-demo.git
- name: image
value: 'harbor.k8s.local/course/devops-demo:v0.1.0'
- name: charts_dir
value: './helm'
- name: release_name
value: devops-demo
- name: release_namespace
value: 'kube-ops'
- name: overwrite_values
value: 'image.repository=harbor.k8s.local/course/devops-demo,image.tag=v0.1.0'
- name: values_file
value: 'my-values.yaml'直接创建上面的资源对象就可以执行我们的 Pipeline 流水线了:
shell
$ kubectl apply -f pipelinerun.yaml
$ tkn pr describe pipelinerun
Name: pipelinerun
Namespace: default
Pipeline Ref: pipeline
Service Account: tekton-build-sa
Timeout: 1h0m0s
Labels:
tekton.dev/pipeline=pipeline
🌡️ Status
STARTED DURATION STATUS
4 minutes ago 2m30s Succeeded(Completed)
⚓ Params
NAME VALUE
∙ git_url http://git.k8s.local/course/devops-demo.git
∙ image harbor.k8s.local/course/devops-demo:v0.1.0
∙ charts_dir ./helm
∙ release_name devops-demo
∙ release_namespace kube-ops
∙ overwrite_values image.repository=harbor.k8s.local/course/devops-demo,image.tag=v0.1.0
∙ values_file my-values.yaml
📂 Workspaces
NAME SUB PATH WORKSPACE BINDING
∙ go-repo-pvc --- PersistentVolumeClaim (claimName=go-repo-pvc)
🗂 Taskruns
NAME TASK NAME STARTED DURATION STATUS
∙ pipelinerun-deploy deploy 3 minutes ago 1m14s Succeeded
∙ pipelinerun-docker docker 4 minutes ago 55s Succeeded
∙ pipelinerun-build build 4 minutes ago 11s Succeeded
∙ pipelinerun-test test 4 minutes ago 4s Succeeded
∙ pipelinerun-clone clone 4 minutes ago 6s Succeeded
⏭️ Skipped Tasks
NAME
∙ rollback
# 部署成功了
$ curl devops-demo.k8s.local
{"msg":"Hello DevOps On Kubernetes"}在 Dashboard 上也可以看到可以流水线可以正常执行，由于部署成功了，所以 rollback 回滚的任务也就被忽略了：
触发器
整个流水线已经成功执行了，接下来最后一步就是将 Gitlab 和 Tekton 进行对接，也就是通过 Tekton Trigger 来自动触发构建。
关于 Tekton Trigger 的使用前面我们已经详细讲解过了，细节就不过多讨论。
首先添加一个用于 Gitlab Webhook 访问的 Secret Token，同样要将这个 Secret 关联到上面使用的 ServiceAccount 上面去，然后继续添加对应的 RBAC 权限：
yaml
# other.yaml
# ......
apiVersion: v1
kind: Secret
metadata:
name: gitlab-secret
type: Opaque
stringData:
secretToken: '1234567'
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: tekton-build-sa
secrets:
- name: harbor-auth
- name: gitlab-auth
- name: gitlab-secret
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: tekton-triggers-gitlab-minimal
rules:
# EventListeners need to be able to fetch all namespaced resources
- apiGroups: ['triggers.tekton.dev']
resources:
['eventlisteners', 'triggerbindings', 'triggertemplates', 'triggers']
verbs: ['get', 'list', 'watch']
- apiGroups: ['']
# configmaps is needed for updating logging config
resources: ['configmaps']
verbs: ['get', 'list', 'watch']
# Permissions to create resources in associated TriggerTemplates
- apiGroups: ['tekton.dev']
resources: ['pipelineruns', 'pipelineresources', 'taskruns']
verbs: ['create']
- apiGroups: ['']
resources: ['serviceaccounts']
verbs: ['impersonate']
- apiGroups: ['policy']
resources: ['podsecuritypolicies']
resourceNames: ['tekton-triggers']
verbs: ['use']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: tekton-triggers-gitlab-binding
subjects:
- kind: ServiceAccount
name: tekton-build-sa
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: tekton-triggers-gitlab-minimal
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: tekton-triggers-gitlab-clusterrole
rules:
# EventListeners need to be able to fetch any clustertriggerbindings
- apiGroups: ['triggers.tekton.dev']
resources: ['clustertriggerbindings', 'clusterinterceptors']
verbs: ['get', 'list', 'watch']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: tekton-triggers-gitlab-clusterbinding
subjects:
- kind: ServiceAccount
name: tekton-build-sa
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: tekton-triggers-gitlab-clusterrole接着就可以来创建 EventListener 资源对象了，用来接收 Gitlab 的 Push Event 事件，如下所示：
yaml
# gitlab-listener.yaml
apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
name: gitlab-listener # 该事件监听器会创建一个名为el-gitlab-listener的Service对象
spec:
serviceAccountName: tekton-build-sa
triggers:
- name: gitlab-push-events-trigger
interceptors:
- ref:
name: gitlab
params:
- name: secretRef # 引用 gitlab-secret 的 Secret 对象中的 secretToken 的值
value:
secretName: gitlab-secret
secretKey: secretToken
- name: eventTypes
value:
- Push Hook # 只接收 GitLab Push 事件
bindings: # 定义TriggerBinding，配置参数
- name: gitrevision
value: $(body.checkout_sha)
- name: gitrepositoryurl
value: $(body.repository.git_http_url)
template:
ref: gitlab-template上面我们通过 TriggerBinding 定义了两个参数 gitrevision、gitrepositoryurl，这两个参数的值可以通过 Gitlab 发送过来的 POST 请求中获取到数据，然后我们就可以将这两个参数传递到 TriggerTemplate 对象中去，这里的模板其实也就是将上面我们定义的 PipelineRun 对象模板化而已，主要是替换 git_url 和镜像 TAG 这两个参数，如下所示：
yaml
# gitlab-template.yaml
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
name: gitlab-template
spec:
params: # 定义参数，和 TriggerBinding 中的保持一致
- name: gitrevision
- name: gitrepositoryurl
resourcetemplates: # 定义资源模板
- apiVersion: tekton.dev/v1beta1
kind: PipelineRun # 定义 pipeline 模板
metadata:
generateName: gitlab-run- # TaskRun 名称前缀
spec:
serviceAccountName: tekton-build-sa
pipelineRef:
name: pipeline
workspaces:
- name: go-repo-pvc
persistentVolumeClaim:
claimName: go-repo-pvc
params:
- name: git_url
value: $(tt.params.gitrepositoryurl)
- name: image
value: 'harbor.k8s.local/course/devops-demo:$(tt.params.gitrevision)'
- name: charts_dir
value: './helm'
- name: release_name
value: devops-demo
- name: release_namespace
value: 'kube-ops'
- name: overwrite_values
value: 'image.repository=harbor.k8s.local/course/devops-demo,image.tag=$(tt.params.gitrevision)'
- name: values_file
value: 'my-values.yaml'直接创建上面新建的几个资源对象即可，这会创建一个 eventlistern 服务用来接收 Webhook 请求：
shell
$ kubectl get eventlistener gitlab-listener
NAME ADDRESS AVAILABLE REASON READY REASON
gitlab-listener http://el-gitlab-listener.default.svc.cluster.local:8080 True MinimumReplicasAvailable True所以一定还要记得在 Gitlab 仓库中配置上 Webhook：
这样我们整个触发器和监听器就配置好了，接下来我们去修改下我们的项目代码，然后提交代码，正常提交过后就会在集群中创建一个 PipelinRun 对象用来执行我们的流水线了。
shell
$ kubectl get pipelinerun
NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME
gitlab-run-j77rx True Completed 4m46s 46s
$ curl devops-demo.k8s.local
{"msg":"Hello Tekton On Kubernetes"}可以看到流水线执行成功后，应用已经成功部署了我们新提交的代码，到这里我们就完成了使用 Tekton 来重构项目的流水线。