关于 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 任务。
此任务启动 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
spec:
pipeline:
disable-working-directory-overwrite: false
disable-home-env-overwrite: false
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 任务。
- 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 任务会清理工作区。
2.2.4. TaskRun 复制链接链接已复制到粘贴板!
TaskRun 使用集群上的特定输入、输出和执行参数来实例化一个任务用来执行它。它可自行调用,或作为管道中每个任务的管道运行的一部分。
任务由执行容器镜像的一个或多个步骤组成,每个容器镜像执行特定的构建工作。任务运行以指定顺序在任务中执行步骤,直到所有步骤都成功执行或发生失败为止。PipelineRun 由 PipelineRun 为管道中的每个任务自动创建。
以下示例显示了使用相关输入参数运行 apply-manifests 任务的任务运行:
2.2.5. Pipelines 复制链接链接已复制到粘贴板!
Pipeline 一组 Task(任务)资源,它们按特定顺序执行。执行它们是为了构建复杂的工作流,以自动化应用程序的构建、部署和交付。您可以使用包含一个或多个任务的管道为应用程序定义 CI/CD 工作流。
Pipeline 资源的定义由多个字段或属性组成,它们一起可让管道实现一个特定目标。每个 Pipeline 资源定义必须至少包含一个Task(任务)资源,用于控制特定输入并生成特定的输出。Pipeline 定义也可以根据应用程序要求包括 Conditions、Workspaces、Parameters 或 Resources。
以下示例显示了 build-and-deploy 管道,它使用 openshift-pipelines 命名空间中提供的 buildah 任务从 Git 存储库构建应用程序镜像:
- 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 管道:
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 示例
在之前的 API 版本 v1beta1 中,PipelineRun CR 的 pod 模板直接在 spec: 部分中指定为 podTemplate。v1 API 不支持此格式。
对于任务运行,您可以在 podTemplate spec 中定义 pod 模板,如下例所示:
带有 pod 模板的 TaskRun CR 示例
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 工作区。
- 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 定义存储卷。
2.2.9. 步骤操作 复制链接链接已复制到粘贴板!
一个步骤是任务的一部分。如果您在任务中定义步骤,则无法从另一个任务引用此步骤。
但是,您可以选择在 StepAction 自定义资源(CR)中定义步骤操作。此 CR 包含步骤执行的操作。您可以引用一个步骤中的 StepAction 对象,以创建执行操作的步骤。您还可以使用解析器引用外部源中提供的 StepAction 定义。
以下示例显示了名为 apply-manifests-action 的 StepAction CR。此步骤操作将源树中的清单应用到 OpenShift Container Platform 环境:
- 1
- 参数
的类型规格是可选的。
StepAction CR 不包括工作区的定义。相反,step 操作需要包含操作的任务还提供挂载的源树,通常使用工作区。
StepAction 对象可以定义参数和结果。在引用此对象时,您必须在步骤定义中指定 StepAction 对象参数的值。StepAction 对象的结果会自动成为步骤的结果。
为了避免使用 shell 的恶意攻击,StepAction CR 不支持在 脚本 值中使用参数值。反之,您必须使用 env: 部分来定义包含参数值的环境变量。
以下示例任务包括引用 apply-manifests-action step 操作的步骤,提供必要的参数,并使用结果:
2.2.10. 触发器 复制链接链接已复制到粘贴板!
使用触发器(Trigger)和 Pipelines 一起创建一个完整的 CI/CD 系统,其中 Kubernetes 资源定义整个 CI/CD 执行。触发器捕获外部事件,如 Git 拉取请求,并处理它们以获取关键信息。将这个事件数据映射到一组预定义的参数会触发一系列任务,然后创建和部署 Kubernetes 资源并实例化管道。
例如,您可以使用 Red Hat OpenShift Pipelines 为应用程序定义 CI/CD 工作流。管道必须启动,才能在应用程序存储库中使任何新的更改生效。通过捕获和处理任何更改事件,并通过触发器部署新镜像的管道运行来自动触发这个过程。
触发器由以下主要资源组成,它们可一起组成可重复使用、分离和自力更生的 CI/CD 系统:
TriggerBinding资源从事件有效负载中提取字段,并将它们保存为参数。以下示例显示了
TriggerBinding资源的代码片段,它从接收的事件有效负载中提取 Git 存储库信息:Copy to Clipboard Copied! Toggle word wrap Toggle overflow TriggerTemplate资源充当创建资源的方式标准。它指定了TriggerBinding资源中参数化数据的方式。触发器模板从触发器绑定接收输入,然后执行一系列操作来创建新管道资源,并启动新管道运行。以下示例显示了
TriggerTemplate资源的代码片段,它使用您刚创建的TriggerBinding资源提供的 Git 存储库信息创建一个管道运行:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Trigger资源组合了TriggerBinding和TriggerTemplate资源,以及可选的interceptors事件处理器。拦截器会处理在
TriggerBinding资源之前运行的特定平台的所有事件。您可以使用拦截器过滤载荷,验证事件,定义和测试触发器条件,以及实施其他有用的处理。拦截器使用 secret 进行事件验证。在事件数据穿过拦截器后,在将有效负载数据传递给触发器之前,它会被发送到触发器。您还可以使用拦截器修改EventListener规格中引用的关联触发器的行为。以下示例显示了一个
Trigger资源的代码片段,名为vote-trigger,它连接TriggerBinding和TriggerTemplate资源,以及interceptors事件处理器。Copy to Clipboard Copied! Toggle word wrap Toggle overflow EventListener资源提供一个端点或事件接收器(sink),用于使用 JSON 有效负载侦听传入的基于 HTTP 的事件。它从每个TriggerBinding资源提取事件参数,然后处理此数据以按照对应的TriggerTemplate资源指定的 Kubernetes 资源创建 Kubernetes 资源。EventListener资源还使用事件interceptors(拦截器)在有效负载上执行轻量级事件处理或基本过滤,这可识别有效负载类型并进行自选修改。目前,管道触发器支持五种拦截器:Webhook Interceptors, GitHub 拦截器、GitLab 拦截器、Bitbucket 拦截器 和 Common Expression Language (CEL) 拦截器。以下示例显示了一个
EventListener资源,它引用名为vote-trigger的Trigger资源。Copy to Clipboard Copied! Toggle word wrap Toggle overflow