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

关于 OpenShift Pipelines

Red Hat OpenShift Pipelines 1.20

OpenShift Pipelines 简介

Red Hat OpenShift Documentation Team

摘要

本文档概述 OpenShift Pipelines 功能。

第 1 章 关于 Red Hat OpenShift Pipelines
复制链接

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

注意

因为 Red Hat OpenShift Pipelines 的发行节奏与 OpenShift Container Platform 不同，所以 Red Hat OpenShift Pipelines 文档现在为每个产品的次版本提供单独的文档。

Red Hat OpenShift Pipelines 文档包括在 https://docs.openshift.com/pipelines/。

特定版本的文档可以通过版本选择器下拉列表获得，或者直接将版本添加到 URL 中，例如 https://docs.openshift.com/pipelines/1.18。

另外，Red Hat OpenShift Pipelines 文档也包括在红帽客户门户网站 https://access.redhat.com/documentation/zh-cn/red_hat_openshift_pipelines/ 中。

如需有关 Red Hat OpenShift Pipelines 生命周期和支持的平台的更多信息，请参阅平台生命周期政策。

第 2 章 了解 OpenShift Pipelines
复制链接

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

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 命名空间中的管道。

2.2. OpenShift Pipelines 概念
复制链接

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

2.2.1. 任务
复制链接

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

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

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

apiVersion: tekton.dev/v1
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
任务 API 版本 v1。
2
Kubernetes 对象的类型，任务。
3
此任务的唯一名称。
4
列出任务中的参数和步骤，以及任务使用的工作区（workspace）。

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

注意

从 OpenShift Pipelines 1.6 开始，步骤 YAML 文件中的以下默认值会被删除：

  • HOME 环境变量不会被默认为 /tekton/home 目录
  • workingDir 字段不会默认为 /workspace 目录

相反，步骤的容器定义 HOME 环境变量和 workingDir 字段。但是，您可以通过在 YAML 文件中为步骤指定自定义值来覆盖默认值。

作为临时方法，为保持与旧 OpenShift Pipelines 版本向后兼容性，您可以在 TektonConfig 自定义资源定义中将以下字段设置为 false ： 

spec:
  pipeline:
    disable-working-directory-overwrite: false
    disable-home-env-overwrite: false
Copy to Clipboard Toggle word wrap

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/v1
kind: PipelineRun
1 

metadata:
  generateName: guarded-pr-
spec:
  taskRunTemplate:
    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
管道中使用的任务 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 表达式符号为红色。

2.2.3. 最后的任务
复制链接

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

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

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

apiVersion: tekton.dev/v1
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
管道的唯一名称。
2
克隆 git 存储库的共享工作区。
3
将应用存储库克隆到共享工作区的任务。
4
清理共享工作区的任务。
5
对任务运行中要执行的任务的引用。
6
管道中的任务在运行时需要的共享存储卷来接收输入或提供输出。
7
任务所需的参数列表。如果参数没有隐式默认值，您必须明确设置其值。
8
嵌入式任务定义.

2.2.4. TaskRun
复制链接

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

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

以下示例显示了使用相关输入参数运行 apply-manifests 任务的任务运行： 

apiVersion: tekton.dev/v1
1 

kind: TaskRun
2 

metadata:
  name: apply-manifests-taskrun
3 

spec:
4 

  taskRunTemplate:
    serviceAccountName: pipeline
  taskRef:
5 

    kind: Task
    name: apply-manifests
  workspaces:
6 

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

2.2.5. Pipelines
复制链接

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

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

以下示例显示了 build-and-deploy 管道，它使用 openshift-pipelines 命名空间中提供的 buildah 任务从 Git 存储库构建应用程序镜像： 

apiVersion: tekton.dev/v1
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.18"
  - name: IMAGE
    type: string
    description: image to be built from the code
  tasks:
7 

  - name: fetch-repository
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: git-clone
      - name: namespace
        value: openshift-pipelines
    workspaces:
    - name: output
      workspace: shared-workspace
    params:
    - name: URL
      value: $(params.git-url)
    - name: SUBDIRECTORY
      value: ""
    - name: DELETE_EXISTING
      value: "true"
    - name: REVISION
      value: $(params.git-revision)
  - name: build-image
8 

    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: buildah
      - name: namespace
        value: openshift-pipelines
    workspaces:
    - name: source
      workspace: shared-workspace
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    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 版本 v1。
2
指定 Kubernetes 对象的类型。在本例中, Pipeline。
3
此管道的唯一名称。
4
指定管道的定义和结构。
5
管道中的所有任务使用的工作区。
6
管道中的所有任务使用的参数。
7
指定管道中使用的任务列表。
8
任务 build-image 使用 openshift-pipelines 命名空间中提供的 buildah 任务从给定的 Git 存储库构建应用程序镜像。
9
任务 apply-manifests 使用相同名称的用户定义的任务。
10
指定在管道中运行任务的顺序。在本例中，apply-manifests 任务仅在 build-image 任务完成后运行。
注意

Red Hat OpenShift Pipelines Operator 在 openshift-pipelines 命名空间中安装 Buildah 任务，并创建具有足够权限来构建和推送镜像的 pipeline 服务帐户。当与权限不足的不同服务帐户关联时，Buildah 任务可能会失败。

2.2.6. PipelineRun
复制链接

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

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

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

以下示例使用相关的资源和参数运行 build-and-deploy 管道： 

apiVersion: tekton.dev/v1
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 版本 v1。
2
Kubernetes 对象的类型。在本例中，PipelineRun。
3
用于标识此管道运行的唯一名称。
4
要运行的管道的名称。在本例中，build-and-deploy。
5
运行管道所需的参数列表。
6
管道运行使用的工作区。

2.2.7. Pod 模板
复制链接

另外，您还可以在 PipelineRun 或 TaskRun 自定义资源(CR)中定义 pod 模板。您可以使用 pod 模板中的 Pod CR 的任何参数。在创建执行管道或任务的 pod 时，OpenShift Pipelines 会为每个 pod 设置这些参数。

例如，您可以使用 pod 模板，使 pod 以用户身份运行，而不是以 root 用户身份执行。

对于管道运行，您可以在 pipelineRunTemplate.podTemplate spec 中定义 pod 模板，如下例所示：

带有 pod 模板的 PipelineRun CR 示例

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: mypipelinerun
spec:
  pipelineRef:
    name: mypipeline
  taskRunTemplate:
    podTemplate:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1001
Copy to Clipboard Toggle word wrap

注意

在之前的 API 版本 v1beta1 中，PipelineRun CR 的 pod 模板直接在 spec: 部分中指定为 podTemplate。v1 API 不支持此格式。

对于任务运行，您可以在 podTemplate spec 中定义 pod 模板，如下例所示：

带有 pod 模板的 TaskRun CR 示例

apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: mytaskrun
  namespace: default
spec:
  taskRef:
    name: mytask
  podTemplate:
    schedulerName: volcano
    securityContext:
      runAsNonRoot: true
      runAsUser: 1001
Copy to Clipboard Toggle word wrap

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

注意

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

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

使用工作区，您可以：

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

您可以使用以下方法在 TaskRun 或 PipelineRun 中指定工作区：

  • 只读配置映射或 secret
  • 与其他任务共享的现有持久性卷声明
  • 来自提供的 VolumeClaim 模板的持久性卷声明
  • 任务运行完成后丢弃的 emptyDir

以下示例显示了 build-and-deploy 管道的代码片段，它为 build-image 和 apply-manifests 任务声明 shared-workspace 工作区。 

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

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

  - name: build-image
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: buildah
      - name: namespace
        value: openshift-pipelines
    workspaces:
3 

    - name: source
4 

      workspace: shared-workspace
5 

    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    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
管道中定义的任务共享的 Workspace 列表。管道可以根据需要定义工作区。在这个示例中，只声明了一个名为 shared-workspace 的工作区。
2
管道中使用的任务定义。此片段定义了两个任务： build-image 和 apply-manifests，它们共享一个通用工作区。
3
build-image 任务中使用的工作区列表。任务定义可以根据需要包含多个工作区。但是，建议任务最多使用一个可写工作区。
4
标识任务中使用的工作区的名称。此任务使用一个名为 source 的工作区。
5
任务使用的管道工作区的名称。请注意，工作区 source 依次使用名为 shared-workspace 的管道工作区。
6
apply-manifests 任务中使用的工作区列表。请注意，此任务与 build-image 任务共享 source 工作区。

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

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

apiVersion: tekton.dev/v1
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
指定管道 Workspaces 列表，用于在管道运行中提供卷绑定。
2
提供卷的管道中的工作区名称。
3
指定卷声明模板，该模板可创建一个持久性卷声明来为工作区定义存储卷。

2.2.9. 步骤操作
复制链接

一个步骤是任务的一部分。如果您在任务中定义步骤，则无法从另一个任务引用此步骤。

但是，您可以选择在 StepAction 自定义资源(CR)中定义步骤操作。此 CR 包含步骤执行的操作。您可以引用一个步骤中的 StepAction 对象，以创建执行操作的步骤。您还可以使用解析器引用外部源中提供的 StepAction 定义。

以下示例显示了名为 apply-manifests-action 的 StepAction CR。此步骤操作将源树中的清单应用到 OpenShift Container Platform 环境： 

apiVersion: tekton.dev/v1
kind: StepAction
metadata:
  name: apply-manifests-action
spec:
  params:
  - name: working_dir
    description: The working directory where the source is located
    type: string
1 

    default: "/workspace/source"
  - name: manifest_dir
    description: The directory in source that contains yaml manifests
    default: "k8s"
  results:
  - name: output
    description: The output of the oc apply command
  image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
  env:
  - name: MANIFEST_DIR
    value: $(params.manifest_dir)
  workingDir: $(params.working_dir)
  script: |
      #!/usr/bin/env bash
      oc apply -f "$MANIFEST_DIR" | tee $(results.output)
Copy to Clipboard Toggle word wrap
1
参数 的类型 规格是可选的。

StepAction CR 不包括工作区的定义。相反，step 操作需要包含操作的任务还提供挂载的源树，通常使用工作区。

StepAction 对象可以定义参数和结果。在引用此对象时，您必须在步骤定义中指定 StepAction 对象参数的值。StepAction 对象的结果会自动成为步骤的结果。

重要

为了避免使用 shell 的恶意攻击，StepAction CR 不支持在 脚本 值中使用参数值。反之，您必须使用 env: 部分来定义包含参数值的环境变量。

以下示例任务包括引用 apply-manifests-action step 操作的步骤，提供必要的参数，并使用结果： 

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: apply-manifests-with-action
spec:
  workspaces:
  - name: source
  params:
  - name: manifest_dir
    description: The directory in source that contains yaml manifests
    type: string
    default: "k8s"
  steps:
  - name: apply
    ref:
      name: apply-manifests-action
    params:
    - name: working_dir
      value: "/workspace/source"
    - name: manifest_dir
      value: $(params.manifest_dir)
  - name: display_result
    script: 'echo $(step.apply.results.output)'
Copy to Clipboard Toggle word wrap

2.2.10. 触发器
复制链接

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

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

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

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

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

    apiVersion: triggers.tekton.dev/v1beta1
    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 版本。在本例中，v1beta1。
    2
    指定 Kubernetes 对象的类型。在本例中，TriggerBinding。
    3
    用于标识 TriggerBinding 资源的唯一名称。
    4
    从接收的事件有效负载中提取并传递给 TriggerTemplate 的参数列表。在本例中，Git 仓库 URL、名称和修订版本是从事件有效负载主体中提取的。

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

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

    apiVersion: triggers.tekton.dev/v1beta1
    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.18
  - name: git-repo-name
    description: The name of the deployment to be created / patched

  resourcetemplates:
    5 
    
  - apiVersion: tekton.dev/v1
    kind: PipelineRun
    metadata:
      name: build-deploy-$(tt.params.git-repo-name)-$(uid)
    spec:
      taskRunTemplate:
        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 版本。在本例中，v1beta1。
    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/v1beta1
    1 
    
kind: Trigger
    2 
    
metadata:
  name: vote-trigger
    3 
    
spec:
  taskRunTemplate:
    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 版本。在本例中，v1beta1。
    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/v1beta1
    1 
    
kind: EventListener
    2 
    
metadata:
  name: vote-app
    3 
    
spec:
  taskRunTemplate:
    serviceAccountName: pipeline
    4 
    
  triggers:
    - triggerRef: vote-trigger
    5
    Copy to Clipboard Toggle word wrap
    1
    EventListener 资源的 API 版本。在本例中，v1beta1。
    2
    指定 Kubernetes 对象的类型。在本例中，EventListener。
    3
    用于标识 EventListener 资源的唯一名称。
    4
    要使用的服务帐户名称。
    5
    EventListener 资源引用的 Trigger 资源的名称。

法律通告
复制链接

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat