Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

4.2. 了解 OpenShift Pipelines

Red Hat OpenShift Pipelines 是一个基于 Kubernetes 资源的云原生的持续集成和持续交付（continuous integration and continuous delivery，简称 CI/CD）的解决方案。它通过提取底层实现的详情，使用 Tekton 构建块进行跨多个平台的自动部署。Tekton 引入了多个标准自定义资源定义 (CRD)，用于定义可跨 Kubernetes 分布的 CI/CD 管道。

4.2.1. 主要特性
复制链接

  • Red Hat OpenShift Pipelines 是一个无服务器的 CI/CD 系统，它在独立的容器中运行 Pipelines，以及所有需要的依赖组件。
  • Red Hat OpenShift Pipelines 是为开发基于微服务架构的非中心化团队设计的。
  • Red Hat OpenShift Pipelines 使用标准 CI/CD 管道（pipeline）定义，这些定义可轻松扩展并与现有 Kubernetes 工具集成，可让您按需扩展。
  • 您可以通过 Red Hat OpenShift Pipelines 使用 Kubernetes 工具（如 Source-to-Image (S2I)、Buildah、Buildpacks 和 Kaniko）构建镜像，这些工具可移植到任何 Kubernetes 平台。
  • 您可以使用 OpenShift Container Platform 开发控制台来创建 Tekton 资源，查看管道运行的日志，并管理 OpenShift Container Platform 命名空间中的管道。

4.2.2. OpenShift Pipeline 概念
复制链接

本指南提供了对管道（pipeline）概念的详细论述。

4.2.2.1. 任务
复制链接

Task（任务）是 Pipeline 的构建块，它由按顺序执行的步骤组成。它基本上是一个输入和输出的功能。一个任务可以单独运行，也可以作为管道的一部分运行。任务（Task）可以重复使用，并可用于多个 Pipelines。

Step（步骤）是由任务顺序执行并实现特定目标（如构建镜像）的一系列命令。每个任务都作为 pod 运行，每个步骤都作为该 pod 中的容器运行。由于步骤在同一个 pod 中运行，所以它们可以访问同一卷来缓存文件、配置映射和 secret。

以下示例显示了 apply-manifests 任务。 

apiVersion: tekton.dev/v1beta1
1 

kind: Task
2 

metadata:
  name: apply-manifests
3 

spec:
4 

  workspaces:
  - name: source
  params:
    - name: manifest_dir
      description: The directory in source that contains yaml manifests
      type: string
      default: "k8s"
  steps:
    - name: apply
      image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
      workingDir: /workspace/source
      command: ["/bin/bash", "-c"]
      args:
        - |-
          echo Applying manifests in $(params.manifest_dir) directory
          oc apply -f $(params.manifest_dir)
          echo -----------------------------------
Copy to Clipboard Toggle word wrap
1
Task API 版本 v1beta1。
2
Kubernetes 对象的类型，任务。
3
此任务的唯一名称。
4
列出任务中的参数和步骤，以及任务使用的工作区（workspace）。

此任务启动 pod，并在该 pod 中使用指定镜像运行一个容器，以运行指定的命令。

4.2.2.2. When 表达式
复制链接

When 表达式通过设置管道中执行任务的条件来执行任务。它们包含一个组件列表，允许仅在满足特定条件时执行任务。当使用管道 YAML 文件中的 finally 字段指定的最终任务集合中也支持表达式。

表达式的主要组件如下：

  • input：指定静态输入或变量，如参数、任务结果和执行状态。您必须输入有效的输入。如果没有输入有效输入，则其值默认为空字符串。
  • operator：指定一个输入与一组 values 的关系。输入 in 或 notin 作为 operator 的值。
  • values：指定字符串值的数组。输入由静态值或变量组成的非空数组，如参数、结果和工作空间的绑定状态。

在任务运行前评估表达式时声明的。如果 when 表达式的值为 True，则任务将运行。如果 when 表达式的值为 False，则跳过任务。

您可以在各种用例中使用 when 表达式。例如，是否：

  • 上一任务的结果如预期所示。
  • 之前的提交中更改了 Git 存储库中的文件。
  • 镜像是否存在于 registry 中。
  • 有可选的工作区可用。

以下示例显示了管道运行的 when 表达式。只有在满足以下条件时，管道运行才会执行 create-file 任务：path 参数为README.md，只有来自 check-file 的任务的 exists 结果为 yes 时才执行 echo-file-exists 任务。 

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
1 

metadata:
  generateName: guarded-pr-
spec:
  serviceAccountName: 'pipeline'
  pipelineSpec:
    params:
      - name: path
        type: string
        description: The path of the file to be created
    workspaces:
      - name: source
        description: |
          This workspace is shared among all the pipeline tasks to read/write common resources
    tasks:
      - name: create-file
2 

        when:
          - input: "$(params.path)"
            operator: in
            values: ["README.md"]
        workspaces:
          - name: source
            workspace: source
        taskSpec:
          workspaces:
            - name: source
              description: The workspace to create the readme file in
          steps:
            - name: write-new-stuff
              image: ubuntu
              script: 'touch $(workspaces.source.path)/README.md'
      - name: check-file
        params:
          - name: path
            value: "$(params.path)"
        workspaces:
          - name: source
            workspace: source
        runAfter:
          - create-file
        taskSpec:
          params:
            - name: path
          workspaces:
            - name: source
              description: The workspace to check for the file
          results:
            - name: exists
              description: indicates whether the file exists or is missing
          steps:
            - name: check-file
              image: alpine
              script: |
                if test -f $(workspaces.source.path)/$(params.path); then
                  printf yes | tee /tekton/results/exists
                else
                  printf no | tee /tekton/results/exists
                fi
      - name: echo-file-exists
        when:
3 

          - input: "$(tasks.check-file.results.exists)"
            operator: in
            values: ["yes"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: 'echo file exists'
...
      - name: task-should-be-skipped-1
        when:
4 

          - input: "$(params.path)"
            operator: notin
            values: ["README.md"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: exit 1
...
    finally:
      - name: finally-task-should-be-executed
        when:
5 

          - input: "$(tasks.echo-file-exists.status)"
            operator: in
            values: ["Succeeded"]
          - input: "$(tasks.status)"
            operator: in
            values: ["Succeeded"]
          - input: "$(tasks.check-file.results.exists)"
            operator: in
            values: ["yes"]
          - input: "$(params.path)"
            operator: in
            values: ["README.md"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: 'echo finally done'
  params:
    - name: path
      value: README.md
  workspaces:
    - name: source
      volumeClaimTemplate:
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 16Mi
Copy to Clipboard Toggle word wrap
1
指定 Kubernetes 对象的类型。在本例中，PipelineRun。
2
Pipeline 中使用的任务 create-file。
3
when 表达式指定，只有来自 check-file 的 exists 结果为 yes 时才执行 echo-file-exists 任务。
4
when 表达式指定，只有 path 参数是 README.md 时跳过 task-should-be-skipped-1 任务。
5
when 表达式指定，只有 echo-file-exists 任务的执行状态以及任务状态为 Succeeded，来自 check-file 任务的 exists 结果为 yes，path 参数是 README.md 时，才执行 finally-task-should-be-executed 任务。

OpenShift Container Platform Web 控制台的 Pipeline Run details 页面显示任务和 when 表达式的状态，如下所示：

  • 所有条件都满足：任务和 when 表达式符号（以钻石形表示）为绿色。
  • 有任何一个条件不符合：任务被跳过。跳过的任务和 when 表达式符号为灰色。
  • 未满足任何条件：任务被跳过。跳过的任务和 when 表达式符号为灰色。
  • 任务运行失败：失败的任务和 when 表达式符号为红色。

4.2.2.3. 最后的任务
复制链接

finally 任务是使用管道 YAML 文件中的 finally 字段指定的最终任务集合。finally 任务始终执行管道中的任务，无论管道运行是否成功执行。finally 任务以并行方式执行，在所有管道任务运行后，相应的频道存在前。

您可以配置一个 finally 任务，以使用同一管道中任何任务的结果。这个方法不会更改运行此最终任务的顺序。它在所有非最终任务执行后与其他最终任务并行执行。

以下示例显示了 clone-cleanup-workspace 管道的代码片段。此代码将存储库克隆到共享的工作区，并清理工作区。执行管道任务后，管道 YAML 文件的 finally 中指定的 cleanup 任务会清理工作区。 

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: clone-cleanup-workspace
1 

spec:
  workspaces:
    - name: git-source
2 

  tasks:
    - name: clone-app-repo
3 

      taskRef:
        name: git-clone-from-catalog
      params:
        - name: url
          value: https://github.com/tektoncd/community.git
        - name: subdirectory
          value: application
      workspaces:
        - name: output
          workspace: git-source
  finally:
    - name: cleanup
4 

      taskRef:
5 

        name: cleanup-workspace
      workspaces:
6 

        - name: source
          workspace: git-source
    - name: check-git-commit
      params:
7 

        - name: commit
          value: $(tasks.clone-app-repo.results.commit)
      taskSpec:
8 

        params:
          - name: commit
        steps:
          - name: check-commit-initialized
            image: alpine
            script: |
              if [[ ! $(params.commit) ]]; then
                exit 1
              fi
Copy to Clipboard Toggle word wrap
1
Pipeline 的唯一名称。
2
克隆 git 存储库的共享工作区。
3
将应用存储库克隆到共享工作区的任务。
4
清理共享工作区的任务。
5
对 TaskRun 中要执行的任务的引用。
6
Pipeline 中的任务在运行时需要的共享存储卷来接收输入或提供输出。
7
任务所需的参数列表。如果参数没有隐式默认值，您必须明确设置其值。
8
嵌入式任务定义.

4.2.2.4. TaskRun
复制链接

TaskRun 使用集群上的特定输入、输出和执行参数来实例化一个任务用来执行它。它可自行调用，或作为管道中每个任务的 PipelineRun 的一部分。

任务由执行容器镜像的一个或多个步骤组成，每个容器镜像执行特定的构建工作。TaskRun 以指定顺序在任务中执行步骤，直到所有步骤都成功执行或发生失败为止。PipelineRun 由 Pipeline 中每个任务的 PipelineRun 自动创建。

以下示例显示了一个带有相关输入参数运行 apply-manifests 任务的 TaskRun: 

apiVersion: tekton.dev/v1beta1
1 

kind: TaskRun
2 

metadata:
  name: apply-manifests-taskrun
3 

spec:
4 

  serviceAccountName: pipeline
  taskRef:
5 

    kind: Task
    name: apply-manifests
  workspaces:
6 

  - name: source
    persistentVolumeClaim:
      claimName: source-pvc
Copy to Clipboard Toggle word wrap
1
TaskRun API 版本 v1beta1。
2
指定 Kubernetes 对象的类型。在本例中，TaskRun。
3
用于标识此 TaskRun 的唯一名称。
4
TaskRun 的定义。对于这个 TaskRun，指定了任务和所需的工作区。
5
用于此 TaskRun 的任务引用的名称。此 TaskRun 会执行 apply-manifests 任务。
6
TaskRun 使用的工作空间。

4.2.2.5. Pipelines
复制链接

Pipeline 一组 Task（任务）资源，它们按特定顺序执行。执行它们是为了构建复杂的工作流，以自动化应用程序的构建、部署和交付。您可以使用包含一个或多个任务的管道为应用程序定义 CI/CD 工作流。

Pipeline 资源的定义由多个字段或属性组成，它们一起可让管道实现一个特定目标。每个 Pipeline 资源定义必须至少包含一个Task（任务）资源，用于控制特定输入并生成特定的输出。Pipeline 定义也可以根据应用程序要求包括 Conditions、Workspaces、Parameters 或 Resources。

以下示例显示了 build-and-deploy pipeline，它使用 buildah ClusterTask 资源从 Git 存储库构建应用程序镜像： 

apiVersion: tekton.dev/v1beta1
1 

kind: Pipeline
2 

metadata:
  name: build-and-deploy
3 

spec:
4 

  workspaces:
5 

  - name: shared-workspace
  params:
6 

  - name: deployment-name
    type: string
    description: name of the deployment to be patched
  - name: git-url
    type: string
    description: url of the git repo for the code of deployment
  - name: git-revision
    type: string
    description: revision to be used from repo of the code for deployment
    default: "pipelines-1.5"
  - name: IMAGE
    type: string
    description: image to be built from the code
  tasks:
7 

  - name: fetch-repository
    taskRef:
      name: git-clone
      kind: ClusterTask
    workspaces:
    - name: output
      workspace: shared-workspace
    params:
    - name: url
      value: $(params.git-url)
    - name: subdirectory
      value: ""
    - name: deleteExisting
      value: "true"
    - name: revision
      value: $(params.git-revision)
  - name: build-image
8 

    taskRef:
      name: buildah
      kind: ClusterTask
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter:
    - fetch-repository
  - name: apply-manifests
9 

    taskRef:
      name: apply-manifests
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter:
10 

    - build-image
  - name: update-deployment
    taskRef:
      name: update-deployment
    workspaces:
    - name: source
      workspace: shared-workspace
    params:
    - name: deployment
      value: $(params.deployment-name)
    - name: IMAGE
      value: $(params.IMAGE)
    runAfter:
    - apply-manifests
Copy to Clipboard Toggle word wrap
1
Pipeline API 版本 v1beta1。
2
指定 Kubernetes 对象的类型。在本例中, Pipeline。
3
此 Pipeline 的唯一名称。
4
指定 Pipeline 的定义和结构。
5
Pipeline 中所有任务使用的工作区。
6
Pipeline 中所有任务使用的参数。
7
指定 Pipeline 中使用的任务列表。
8
任务 build-image 使用 buildah ClusterTask 从给定的 Git 仓库构建应用程序镜像。
9
任务 apply-manifests 使用相同名称的用户定义的任务。
10
指定在 Pipeline 中运行任务的顺序。在本例中，apply-manifests 任务仅在 build-image 任务完成后运行。
注意

Red Hat OpenShift Pipelines Operator 安装 Buildah 集群任务，并创建具有足够权限来构建和推送镜像的管道服务帐户。当与没有权限不足的不同服务帐户关联时，Buildah 集群任务可能会失败。

4.2.2.6. PipelineRun
复制链接

PipelineRun 是一种资源类型，它绑定了管道、工作区、凭证和一组特定于运行 CI/CD 工作流的情况的参数值。

管道运行（pipeline run）是管道的运行实例。它使用集群上的特定输入、输出和执行参数来实例化 Pipeline 执行。它还为管道运行中的每个任务创建一个任务运行。

管道按顺序运行任务，直到任务完成或任务失败为止。status 字段跟踪和每个任务运行的进度，并存储它以用于监控和审计目的。

以下示例显示了一个 PipelineRun，用于运行带有相关资源和参数的 build-and-deploy Pipeline: 

apiVersion: tekton.dev/v1beta1
1 

kind: PipelineRun
2 

metadata:
  name: build-deploy-api-pipelinerun
3 

spec:
  pipelineRef:
    name: build-and-deploy
4 

  params:
5 

  - name: deployment-name
    value: vote-api
  - name: git-url
    value: https://github.com/openshift-pipelines/vote-api.git
  - name: IMAGE
    value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/vote-api
  workspaces:
6 

  - name: shared-workspace
    volumeClaimTemplate:
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi
Copy to Clipboard Toggle word wrap
1
Pipeline 运行 API 版本 v1beta1。
2
Kubernetes 对象的类型。在本例中，PipelineRun。
3
用于标识此管道运行的唯一名称。
4
要运行的管道的名称。在本例中，build-and-deploy。
5
运行管道所需的参数列表。
6
管道运行使用的工作区。

4.2.2.7. Workspaces（工作区）
复制链接

注意

建议您在 OpenShift Pipelines 中使用 Workspaces 而不是 PipelineResources，因为 PipelineResources 很难调试，范围有限，且不容易重复使用。

Workspace 声明 Pipeline 中的任务在运行时需要的共享存储卷来接收输入或提供输出。Workspaces 不指定卷的实际位置，它允许您定义运行时所需的文件系统或部分文件系统。Task 或 Pipeline 会声明 Workspace，您必须提供卷的特定位置详情。然后，它会挂载到 TaskRun 或 PipelineRun 中的 Workspace 中。这种将卷声明与运行时存储卷分开来使得任务可以被重复使用、灵活且独立于用户环境。

使用 Workspaces，您可以：

  • 存储任务输入和输出
  • 任务间共享数据
  • 使用它作为 Secret 中持有的凭证的挂载点
  • 使用它作为 ConfigMap 中保存的配置的挂载点
  • 使用它作为机构共享的通用工具的挂载点
  • 创建可加快作业的构建工件缓存

您可以使用以下方法在 TaskRun 或 PipelineRun 中指定 Workspaces:

  • 只读 ConfigMap 或 Secret
  • 与其他任务共享的现有 PersistentVolumeClaim
  • 来自提供的 VolumeClaimTemplate 的 PersistentVolumeClaim
  • TaskRun 完成后丢弃的 emptyDir

以下显示了 build-and-deploy Pipeline 的代码片段，它为任务 build-image 和 apply-manifests 声明了一个 shared-workspace Workspace。 

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
  workspaces:
1 

  - name: shared-workspace
  params:
...
  tasks:
2 

  - name: build-image
    taskRef:
      name: buildah
      kind: ClusterTask
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces:
3 

    - name: source
4 

      workspace: shared-workspace
5 

    runAfter:
    - fetch-repository
  - name: apply-manifests
    taskRef:
      name: apply-manifests
    workspaces:
6 

    - name: source
      workspace: shared-workspace
    runAfter:
      - build-image
...
Copy to Clipboard Toggle word wrap
1
Pipeline 中定义的任务共享的 Workspace 列表。Pipeline 可以根据需要定义 Workspace。在这个示例中，只声明了一个名为 shared-workspace 的 Workspace。
2
Pipeline 中使用的任务定义。此片段定义了两个任务，build-image 和 apply-manifests。这两个任务共享一个 Workspace。
3
build-image 任务中使用的 Workspaces 列表。任务定义可以根据需要包含多个 Workspace。但建议任务最多使用一个可写 Workspace。
4
唯一标识任务中使用的 Workspace 的名称。此任务使用一个名为 source 的 Workspace。
5
任务使用的 Pipeline Workspace 的名称。请注意,，Workspace source 使用 Pipeline Workspace shared-workspace。
6
apply-manifests 任务中使用的 Workspace 列表。请注意，此任务与 build-image 任务共享 source Workspace。

工作区可帮助任务共享数据，并允许您指定 Pipeline 中每个任务在执行过程中所需的一个或多个卷。您可以创建持久性卷声明，或者提供一个卷声明模板，用于为您创建持久性卷声明。

以下 build-deploy-api-pipelinerun PipelineRun 的代码片段使用卷声明模板创建持久性卷声明来为 build-and-deploy Pipeline 中使用的 shared-workspace Workspace 定义存储卷。 

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: build-deploy-api-pipelinerun
spec:
  pipelineRef:
    name: build-and-deploy
  params:
...

  workspaces:
1 

  - name: shared-workspace
2 

    volumeClaimTemplate:
3 

      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi
Copy to Clipboard Toggle word wrap
1
指定 Pipeline Workspaces 列表，用于在 PipelineRun 中提供卷绑定。
2
提供卷的 Pipeline 中的 Workspace 的名称。
3
指定卷声明模板，该模板可创建一个持久性卷声明来为工作区定义存储卷。

4.2.2.8. 触发器
复制链接

使用触发器（Trigger）和 Pipelines 一起创建一个完整的 CI/CD 系统，其中 Kubernetes 资源定义整个 CI/CD 执行。触发器捕获外部事件，如 Git 拉取请求，并处理它们以获取关键信息。将这个事件数据映射到一组预定义的参数会触发一系列任务，然后创建和部署 Kubernetes 资源并实例化管道。

例如，您可以使用 Red Hat OpenShift Pipelines 为应用程序定义 CI/CD 工作流。管道必须启动，才能在应用程序存储库中使任何新的更改生效。通过捕获和处理任何更改事件，并通过触发器部署新镜像的管道运行来自动触发这个过程。

触发器由以下主要资源组成，它们可一起组成可重复使用、分离和自力更生的 CI/CD 系统：

  • TriggerBinding 资源从事件有效负载中提取字段，并将它们保存为参数。

    以下示例显示了 TriggerBinding 资源的代码片段,它从接收的事件有效负载中提取 Git 存储库信息： 

    apiVersion: triggers.tekton.dev/v1alpha1
    1 
    
kind: TriggerBinding
    2 
    
metadata:
  name: vote-app
    3 
    
spec:
  params:
    4 
    
  - name: git-repo-url
    value: $(body.repository.url)
  - name: git-repo-name
    value: $(body.repository.name)
  - name: git-revision
    value: $(body.head_commit.id)
    Copy to Clipboard Toggle word wrap
    1
    TriggerBinding 资源的 API 版本。在本例中，v1alpha1。
    2
    指定 Kubernetes 对象的类型。在本例中，TriggerBinding。
    3
    用于标识 TriggerBinding 资源的唯一名称。
    4
    从接收的事件有效负载中提取并传递给 TriggerTemplate 的参数列表。在本例中，Git 仓库 URL、名称和修订版本是从事件有效负载主体中提取的。

  • TriggerTemplate 资源充当创建资源的方式标准。它指定了 TriggerBinding 资源中参数化数据的方式。触发器模板从触发器绑定接收输入，然后执行一系列操作来创建新管道资源，并启动新管道运行。

    以下示例显示了 TriggerTemplate 资源的代码片段，它使用您刚创建的 TriggerBinding 资源提供的 Git 存储库信息创建一个管道运行： 

    apiVersion: triggers.tekton.dev/v1alpha1
    1 
    
kind: TriggerTemplate
    2 
    
metadata:
  name: vote-app
    3 
    
spec:
  params:
    4 
    
  - name: git-repo-url
    description: The git repository url
  - name: git-revision
    description: The git revision
    default: pipelines-1.5
  - name: git-repo-name
    description: The name of the deployment to be created / patched

  resourcetemplates:
    5 
    
  - apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      name: build-deploy-$(tt.params.git-repo-name)-$(uid)
    spec:
      serviceAccountName: pipeline
      pipelineRef:
        name: build-and-deploy
      params:
      - name: deployment-name
        value: $(tt.params.git-repo-name)
      - name: git-url
        value: $(tt.params.git-repo-url)
      - name: git-revision
        value: $(tt.params.git-revision)
      - name: IMAGE
        value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/$(tt.params.git-repo-name)
      workspaces:
      - name: shared-workspace
        volumeClaimTemplate:
         spec:
          accessModes:
           - ReadWriteOnce
          resources:
            requests:
              storage: 500Mi
    Copy to Clipboard Toggle word wrap
    1
    TriggerTemplate 资源的 API 版本。在本例中，v1alpha1。
    2
    指定 Kubernetes 对象的类型。在本例中，TriggerTemplate。
    3
    用于标识 TriggerTemplate 资源的唯一名称。
    4
    TriggerBinding 资源提供的参数。
    5
    指定使用 TriggerBinding 或 EventListener 资源接收的参数创建资源方法的模板列表。

  • Trigger 资源组合了 TriggerBinding 和 TriggerTemplate 资源，以及可选的 interceptors 事件处理器。

    拦截器会处理在 TriggerBinding 资源之前运行的特定平台的所有事件。您可以使用拦截器过滤载荷，验证事件，定义和测试触发器条件，以及实施其他有用的处理。拦截器使用 secret 进行事件验证。在事件数据穿过拦截器后，在将有效负载数据传递给触发器之前，它会被发送到触发器。您还可以使用拦截器修改 EventListener 规格中引用的关联触发器的行为。

    以下示例显示了一个 Trigger 资源的代码片段，名为 vote-trigger，它连接 TriggerBinding 和 TriggerTemplate 资源，以及 interceptors 事件处理器。 

    apiVersion: triggers.tekton.dev/v1alpha1
    1 
    
kind: Trigger
    2 
    
metadata:
  name: vote-trigger
    3 
    
spec:
  serviceAccountName: pipeline
    4 
    
  interceptors:
    - ref:
        name: "github"
    5 
    
      params:
    6 
    
        - name: "secretRef"
          value:
            secretName: github-secret
            secretKey: secretToken
        - name: "eventTypes"
          value: ["push"]
  bindings:
    - ref: vote-app
    7 
    
  template:
    8 
    
     ref: vote-app
---
apiVersion: v1
kind: Secret
    9 
    
metadata:
  name: github-secret
type: Opaque
stringData:
  secretToken: "1234567"
    Copy to Clipboard Toggle word wrap
    1
    Trigger 资源的 API 版本。在本例中，v1alpha1。
    2
    指定 Kubernetes 对象的类型。在本例中, Trigger。
    3
    用于标识 Trigger 资源的唯一名称。
    4
    要使用的服务帐户名称。
    5
    要被引用的拦截器名称。在本例中，是 github。
    6
    要指定的参数.
    7
    连接到 TriggerTemplate 资源的 TriggerBinding 资源的名称。
    8
    连接到 TriggerBinding 资源的 TriggerTemplate 资源的名称。
    9
    用于验证事件的 Secret。

  • EventListener 资源提供一个端点或事件接收器（sink），用于使用 JSON 有效负载侦听传入的基于 HTTP 的事件。它从每个 TriggerBinding 资源提取事件参数，然后处理此数据以按照对应的 TriggerTemplate 资源指定的 Kubernetes 资源创建 Kubernetes 资源。EventListener 资源还使用事件 interceptors（拦截器） 在有效负载上执行轻量级事件处理或基本过滤，这可识别有效负载类型并进行自选修改。目前，管道触发器支持五种拦截器：Webhook Interceptors, GitHub 拦截器、GitLab 拦截器、Bitbucket 拦截器 和 Common Expression Language (CEL) 拦截器。

    以下示例显示了一个 EventListener 资源，它引用名为 vote-trigger 的 Trigger 资源。 

    apiVersion: triggers.tekton.dev/v1alpha1
    1 
    
kind: EventListener
    2 
    
metadata:
  name: vote-app
    3 
    
spec:
  serviceAccountName: pipeline
    4 
    
  triggers:
    - triggerRef: vote-trigger
    5
    Copy to Clipboard Toggle word wrap
    1
    EventListener 资源的 API 版本。在本例中，v1alpha1。
    2
    指定 Kubernetes 对象的类型。在本例中，EventListener。
    3
    用于标识 EventListener 资源的唯一名称。
    4
    要使用的服务帐户名称。
    5
    EventListener 资源引用的 Trigger 资源的名称。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat