触发器
触发器是 Tekton Triggers 中的一个关键组件,指定当事件监听器检测到事件时会发生什么。它通过定义如何处理、提取和使用传入数据,以将事件数据连接到管道执行,从而创建 Kubernetes 资源。
术语解释
术语 | 描述 |
---|
触发器 | 一种 Tekton 资源,定义检测到事件时发生的操作,将事件数据与管道执行联系起来。 |
触发器绑定 | 一种从事件负载中提取字段并将其绑定到命名参数的资源。 |
触发器模板 | 一种在收到事件时指定需要创建的资源(如 TaskRuns 或 PipelineRuns)的资源。 |
事件监听器 | 一种 Kubernetes 服务,监听事件并根据定义的触发器处理它们。 |
拦截器 | 一种可选组件,在传递到触发器绑定和触发器模板之前处理和过滤事件数据。 |
为什么需要触发器
事件驱动的 CI/CD 挑战
在传统的 CI/CD 系统中,将外部事件(如 Git 推送或 webhook 调用)连接到管道执行需要:
- 针对每个事件源编写自定义集成代码
- 手动配置以将事件数据映射到管道参数
- 复杂的逻辑来确定何时以及如何运行特定的管道
- 对不同环境和条件的单独处理
这种方法导致:
- 事件源与管道执行之间的紧密耦合
- 项目间集成代码的重复
- 维护和演化系统的困难
- 集成模式的有限重用性
触发器如何解决这些问题
Tekton Trigger 提供了一种声明性、Kubernetes 原生的方式来:
- 定义事件处理逻辑:精确指定事件应如何处理,无需自定义代码
- 提取相关数据:使用触发器绑定从事件负载中提取特定字段
- 创建适当的资源:使用触发器模板根据事件数据动态创建合适的资源
- 过滤和转换事件:应用拦截器,在处理之前验证、过滤和转换事件数据
- 关注点分离:将事件接收与资源创建解耦,以便更好的可维护性
这种方法实现了一个完全事件驱动的 CI/CD 系统,可以自动响应各种外部事件,同时保持灵活性和可重用性。
优势
- 声明性配置:使用 Kubernetes 资源定义事件到管道的连接
- 重用性:创建可重用的触发器,可以在多个项目中应用
- 灵活性:支持各种事件源(如 GitHub、GitLab、通用 webhooks 等)
- 可扩展性:可以为专业事件处理创建自定义拦截器
- 关注点分离:在事件接收、数据提取和资源创建之间有清晰的分离
- 安全性:内置支持事件验证和过滤
- Kubernetes 原生:与 Kubernetes 生态系统无缝集成
适用场景
触发器在以下场景中是必不可少的:
- 自动化 CI/CD 管道:在代码推送到存储库时自动启动构建和部署。
- 多环境部署:使用相同的事件数据,但针对不同环境触发不同管道。
- ChatOps:根据拉取请求或问题中的评论执行管道。
- 定期操作:与 cron 任务结合触发周期性维护或测试管道。
- 跨服务工作流:在其他系统(如问题追踪器、监控系统)发生事件时触发管道。
- GitOps:在 Git 存储库更新时自动应用配置更改。
约束和局限性
- 触发器需要一个事件监听器来接收和处理事件
- 每个事件监听器创建一个需要对事件源可访问的 Kubernetes 服务
- 复杂的事件处理可能需要自定义拦截器
- 事件源必须能够向事件监听器发送 HTTP 请求
- 必须处理 webhook 的安全性考虑(身份验证、授权)
原则
触发器结构
Tekton 中的触发器资源具有以下结构:
apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
name: trigger-name
spec:
# 可选:处理和过滤事件
interceptors:
- ref:
name: "interceptor-name"
params:
- name: "param-name"
value: "param-value"
# 从事件中提取数据
bindings:
- ref: binding-name # 引用现有的触发器绑定
# 或直接嵌入绑定
- name: param-name
value: $(body.field.path)
# 指定要创建的资源
template:
ref: template-name # 引用现有的触发器模板
# 或直接嵌入模板
# spec: ...
# 可选:用于资源创建的 ServiceAccount
serviceAccountName: service-account-name
关键组件及其关系
-
拦截器:在事件到达绑定和模板之前处理传入事件
- 基于特定条件过滤事件
- 转换事件数据
- 向事件负载添加额外数据
- 验证事件的真实性
-
绑定:从事件负载中提取数据
- 可以引用现有的触发器绑定或集群触发器绑定
- 可以直接嵌入到触发器中
- 可以在一个触发器中结合多个绑定
-
模板:定义要创建的资源
- 可以引用现有的触发器模板
- 可以直接嵌入到触发器中
- 使用绑定提取的参数
-
服务账户:为创建资源提供必要的权限
配置示例
GitHub 拉取请求触发器
apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
name: github-pull-request-trigger
spec:
interceptors:
- ref:
name: "github"
params:
- name: "eventTypes"
value: ["pull_request"]
- ref:
name: "cel"
params:
- name: "filter"
value: "body.action in ['opened', 'synchronize', 'reopened']"
- name: "overlays"
value:
- key: truncated_sha
expression: "body.pull_request.head.sha.truncate(7)"
bindings:
- name: git-revision
value: $(body.pull_request.head.sha)
- name: git-repository-url
value: $(body.repository.clone_url)
- name: pull-request-number
value: $(body.number)
template:
ref: pull-request-template
GitLab 推送事件触发器
基于提供的 GitLab 事件文档:
apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
name: gitlab-push-trigger
spec:
interceptors:
- ref:
name: "gitlab"
params:
- name: "eventTypes"
value: ["Push Hook"]
bindings:
- name: git-revision
value: $(body.checkout_sha)
- name: git-repository-url
value: $(body.project.git_http_url)
- name: git-repo-name
value: $(body.project.name)
- name: git-commit-message
value: $(body.commits[0].message)
template:
ref: gitlab-ci-template
与触发器相关的重要参数解释
拦截器
拦截器是强大的组件,它们在事件到达触发器绑定和触发器模板之前处理事件。
适用场景
- 验证 webhook 签名
- 基于特定条件过滤事件
- 转换事件数据
- 为事件添加额外上下文
约束和局限性
- 每个拦截器都会增加事件处理的时间
- 复杂的过滤逻辑可能需要 CEL 表达式
- 自定义拦截器需要额外的部署和管理
原则/参数说明
常见的拦截器包括:
- GitHub:验证 GitHub webhook 签名并按事件类型过滤
- GitLab:验证 GitLab webhook 签名并按事件类型过滤
- BitBucket:验证 BitBucket webhook 签名并按事件类型过滤
- CEL:使用公共表达式语言进行过滤和转换
- Webhook:使用密钥验证 webhook 签名
绑定
触发器中的绑定字段指定如何从事件中提取数据。
适用场景
- 提取 Git 提交信息
- 捕获关于拉取请求或合并请求的元数据
- 检索存储库信息
- 访问自定义头或负载字段
配置示例
bindings:
# 引用现有的触发器绑定
- ref: common-git-binding
# 直接嵌入绑定
- name: custom-field
value: $(body.custom.field)
# 引用集群触发器绑定
- ref: cluster-git-binding
kind: ClusterTriggerBinding
参考材料