第 7 章 触发和修改构建


以下小节概述了如何使用构建 hook 触发构建和修改构建。

7.1. 构建触发器

在定义 BuildConfig 时,您可以定义触发器来控制应该运行 BuildConfig 的环境。可用的构建触发器如下:

  • Webhook
  • 镜像更改
  • 配置更改

7.1.1. Webhook 触发器

Webhook 触发器允许您将请求发送到 Red Hat OpenShift Service on AWS API 端点来触发新构建。您可以使用 GitHub、GitLab、Bitbucket 或通用 Webhook 来定义这些触发器。

目前,Red Hat OpenShift Service on AWS Webhook 仅支持各种基于 Git 的源代码管理(SCM)系统的推送事件的类同版本。所有其他事件类型都会忽略。

处理推送事件时,Red Hat OpenShift Service on AWS control plane 主机上确认事件内的分支引用是否与对应 BuildConfig 中的分支引用匹配。如果是这样,它会检查 Red Hat OpenShift Service on AWS 构建上的 Webhook 事件中记录的确切提交引用。如果不匹配,则不触发构建。

注意

oc new-appoc new-build 会自动创建 GitHub 和通用 Webhook 触发器,但其他所需的 Webhook 触发器都必须手动添加。您可以通过设置触发器来手动添加触发器。

对于所有 Webhook,您必须使用名为 WebHookSecretKey 的键定义 secret,并且其值是调用 Webhook 时要提供的值。然后,Webhook 定义必须引用该 secret。secret可确保 URL 的唯一性,防止他人触发构建。键的值将与 Webhook 调用期间提供的 secret 进行比较。

例如,此处的 GitHub Webhook 具有对名为 mysecret 的 secret 的引用:

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

该 secret 的定义如下。注意 secret 的值采用 base64 编码,如 Secret 对象的 data 字段所要求。

- kind: Secret
  apiVersion: v1
  metadata:
    name: mysecret
    creationTimestamp:
  data:
    WebHookSecretKey: c2VjcmV0dmFsdWUx

7.1.1.1. 将未经身份验证的用户添加到 system:webhook 角色绑定

作为集群管理员,您可以为特定命名空间将未经身份验证的用户添加到 Red Hat OpenShift Service on AWS 中的 system:webhook 角色绑定中。system:webhook 角色绑定允许用户触发来自不使用 Red Hat OpenShift Service on AWS 身份验证机制的外部系统的构建。默认情况下,未经身份验证的用户无法访问非公共角色绑定。这是在 4.16 之前的 Red Hat OpenShift Service on AWS 版本的变化。

需要将未经身份验证的用户添加到 system:webhook 角色绑定,才能成功触发从 GitHub、GitLab 和 Bitbucket 的构建。

如果需要允许未经身份验证的用户访问集群,您可以通过将未经身份验证的用户添加到每个所需命名空间中的 system:webhook 角色绑定来完成此操作。这个方法比将未经身份验证的用户添加到 system:webhook 集群角色绑定更安全。但是,如果您有大量命名空间,可以将未经身份验证的用户添加到 system:webhook 集群角色绑定中,该绑定会将更改应用到所有命名空间。

重要

在修改未经身份验证的访问时,始终验证符合您机构的安全标准。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 创建名为 add-webhooks-unauth.yaml 的 YAML 文件,并添加以下内容:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      annotations:
        rbac.authorization.kubernetes.io/autoupdate: "true"
      name: webhook-access-unauthenticated
      namespace: <namespace> 1
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: "system:webhook"
    subjects:
      - apiGroup: rbac.authorization.k8s.io
        kind: Group
        name: "system:unauthenticated"
    1
    BuildConfig 的命名空间。
  2. 运行以下命令来应用配置:

    $ oc apply -f add-webhooks-unauth.yaml

7.1.1.2. 使用 GitHub Webhook

当存储库更新时,GitHub Webhook 处理 GitHub 发出的调用。在定义触发器时,您必须指定一个 secret,它将是您在配置 Webhook 时提供给 GitHub 的 URL 的一部分。

GitHub Webhook 定义示例:

type: "GitHub"
github:
  secretReference:
    name: "mysecret"
注意

Webhook 触发器配置中使用的 secret 与您在 GitHub UI 中配置 Webhook 时遇到的 secret 字段不同。Webhook 触发器配置中的 secret 使 Webhook URL 是唯一的且难以预测。GitHub UI 中配置的 secret 是一个可选字符串字段,用于创建正文的 HMAC 十六进制摘要,该摘要作为 X-Hub-Signature 标头发送。

oc describe 命令将有效负载 URL 返回为 GitHub Webhook URL(请参阅“显示 Webhook URL”),其结构如下:

输出示例

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

先决条件

  • 从 GitHub 存储库创建 BuildConfig
  • system:unauthenticated 在所需命名空间中可以访问 system:webhook 角色。或者,system:unauthenticated 能够访问 system:webhook 集群角色。

流程

  1. 配置 GitHub Webhook。

    1. 从 GitHub 存储库创建 BuildConfig 对象后,运行以下命令:

      $ oc describe bc/<name_of_your_BuildConfig>

      此命令生成 webhook GitHub URL。

      输出示例

      https://api.starter-us-east-1.openshift.com:443/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

    2. 从 GitHub Web 控制台将此 URL 剪切并粘贴到 GitHub 中。
    3. 在 GitHub 存储库中,从 Settings Webhooks 中选择 Add Webhook
    4. 将 URL 输出粘贴到 Payload URL 字段。
    5. Content Type 从 GitHub 默认的 application/x-www-form-urlencoded 更改为 application/json
    6. 点击 Add webhook

      您应该看到一条来自 GitHub 的消息,说明您的 Webhook 已配置成功。

      现在,每当您将更改推送到 GitHub 存储库时,新构建会自动启动,成功构建后也会启动新部署。

      注意

      Gogs 支持与 GitHub 相同的 Webhook 有效负载格式。因此,如果您使用的是 Gogs 服务器,也可以在 BuildConfig 中定义 GitHub Webhook 触发器,并由 Gogs 服务器触发它。

  2. 假设包含有效 JSON 有效负载的文件,如 payload.json,您可以使用以下 curl 命令手动触发 Webhook:

    $ curl -H "X-GitHub-Event: push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

    只有在 API 服务器没有适当签名的证书时,才需要 -k 参数。

注意

只有 GitHub Webhook 事件的 ref 值与 BuildConfig 资源中的 source.git 字段中指定的 ref 值匹配时,才会触发构建。

其他资源

7.1.1.3. 使用 GitLab Webhook

当存储库更新时,GitLab Webhook 处理 GitLab 发出的调用。与 GitHub 触发器一样,您必须指定一个 secret。以下示例是 BuildConfig 中的触发器定义 YAML:

type: "GitLab"
gitlab:
  secretReference:
    name: "mysecret"

oc describe 命令将有效负载 URL 返回为 GitLab Webhook URL,其结构如下:

输出示例

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

先决条件

  • system:unauthenticated 在所需命名空间中可以访问 system:webhook 角色。或者,system:unauthenticated 能够访问 system:webhook 集群角色。

流程

  1. 配置 GitLab Webhook。

    1. 输入以下命令来获取 Webhook URL:

      $ oc describe bc <name>
    2. 复制 Webhook URL,将 <secret> 替换为您的 secret 值。
    3. 按照 GitLab 设置说明,将 Webhook URL 粘贴到 GitLab 存储库设置中。
  2. 假设包含有效 JSON 有效负载的文件,如 payload.json,您可以使用以下 curl 命令手动触发 Webhook:

    $ curl -H "X-GitLab-Event: Push Hook" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

    只有在 API 服务器没有适当签名的证书时,才需要 -k 参数。

7.1.1.4. 使用 Bitbucket Webhook

当存储库更新时,Bitbucket Webhook 处理 Bitbucket 发出的调用。与 GitHub 和 GitLab 触发器类似,您必须指定一个 secret。以下示例是 BuildConfig 中的触发器定义 YAML:

type: "Bitbucket"
bitbucket:
  secretReference:
    name: "mysecret"

oc describe 命令将有效负载 URL 返回为 Bitbucket Webhook URL,其结构如下:

输出示例

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

先决条件

  • system:unauthenticated 在所需命名空间中可以访问 system:webhook 角色。或者,system:unauthenticated 能够访问 system:webhook 集群角色。

流程

  1. 配置 Bitbucket Webhook。

    1. 输入以下命令来获取 Webhook URL:

      $ oc describe bc <name>
    2. 复制 Webhook URL,将 <secret> 替换为您的 secret 值。
    3. 按照 Bitbucket 设置说明,将 Webhook URL 粘贴到 Bitbucket 存储库设置中。
  2. 假设包含有效 JSON 有效负载的文件,如 payload.json,您可以输入以下 curl 命令手动触发 Webhook:

    $ curl -H "X-Event-Key: repo:push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

    只有在 API 服务器没有适当签名的证书时,才需要 -k 参数。

7.1.1.5. 使用通用 Webhook

通用 Webhook 从能够发出 Web 请求的任何系统调用。与其他 Webhook一样,您必须指定一个 secret,该 secret 将成为调用者必须用于触发构建的 URL 的一部分。secret可确保 URL 的唯一性,防止他人触发构建。如下是 BuildConfig 中的示例触发器定义 YAML:

type: "Generic"
generic:
  secretReference:
    name: "mysecret"
  allowEnv: true 1
1
设置为 true,以允许通用 Webhook 传入环境变量。

流程

  1. 要设置调用者,请为调用系统提供构建的通用 webhook 端点的 URL。

    通用 webhook 端点 URL 示例

    https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

    调用者必须以 POST 操作的形式调用 Webhook。

  2. 要手动调用 webhook,请输入以下 curl 命令:

    $ curl -X POST -k https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

    HTTP 操作动词必须设置为 POST。指定了不安全 -k 标志以忽略证书验证。如果集群拥有正确签名的证书,则不需要此第二个标志。

    端点可以接受具有以下格式的可选有效负载:

    git:
      uri: "<url to git repository>"
      ref: "<optional git reference>"
      commit: "<commit hash identifying a specific git commit>"
      author:
        name: "<author name>"
        email: "<author e-mail>"
      committer:
        name: "<committer name>"
        email: "<committer e-mail>"
      message: "<commit message>"
    env: 1
       - name: "<variable name>"
         value: "<variable value>"
    1
    BuildConfig 环境变量类似,此处定义的环境变量也可供您的构建使用。如果这些变量与 BuildConfig 环境变量发生冲突,则以这些变量为准。默认情况下,Webhook 传递的环境变量将被忽略。在 Webhook 定义上将 allowEnv 字段设为 true 即可启用此行为。
  3. 要使用 curl 传递此有效负载,请在名为 payload_file.yaml 的文件中进行定义,并运行以下命令:

    $ curl -H "Content-Type: application/yaml" --data-binary @payload_file.yaml -X POST -k https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

    参数与前一个示例相同,但添加了标头和 payload。-H 参数将 Content-Type 标头设置为 application/yamlapplication/json,具体取决于您的 payload 格式。--data-binary 参数用于通过 POST 请求发送带有换行符的二进制 payload。

注意

Red Hat OpenShift Service on AWS 允许通用 Webhook 触发构建,即使出无效的请求有效负载,如无效的内容类型、无法解析或无效的内容等。保留此行为是为了向后兼容。如果出示无效的请求有效负载,Red Hat OpenShift Service on AWS 会返回 JSON 格式的警告,作为其 HTTP 200 OK 响应的一部分。

7.1.1.6. 显示 Webhook URL

您可以使用 oc describe 命令显示与构建配置关联的 Webhook URL。如果命令没有显示任何 Webhook URL,则目前不会为该构建配置定义任何 Webhook 触发器。

流程

  • 要显示与 BuildConfig 关联的任何 Webhook URL,请运行以下命令:
$ oc describe bc <name>

7.1.2. 使用镜像更改触发器

作为开发人员,您可以将构建配置为在每次基础镜像更改时自动运行。

当上游镜像有新版本可用时,您可以使用镜像更改触发器自动调用构建。例如,如果构建基于 RHEL 镜像,您可以触发该构建在 RHEL 镜像更改时运行。因此,应用程序镜像始终在最新的 RHEL 基础镜像上运行。

注意

指向 v1 容器 registry 中的容器镜像的镜像流仅在镜像流标签可用时触发一次构建,后续镜像更新时则不会触发。这是因为 v1 容器 registry 中缺少可唯一标识的镜像。

流程

  1. 定义指向您要用作触发器的上游镜像的 ImageStream

    kind: "ImageStream"
    apiVersion: "v1"
    metadata:
      name: "ruby-20-centos7"

    这将定义绑定到位于 <system-registry>/<namespace>/ruby-20-centos7 的容器镜像存储库的镜像流。& lt;system-registry > 定义为一个服务,其名称为在 Red Hat OpenShift Service on AWS 上运行的 docker-registry

  2. 如果镜像流是构建的基础镜像,请将构建策略中的 from 字段设置为指向 ImageStream

    strategy:
      sourceStrategy:
        from:
          kind: "ImageStreamTag"
          name: "ruby-20-centos7:latest"

    在这种情形中,sourceStrategy 定义将消耗此命名空间中名为 ruby-20-centos7 的镜像流的 latest 标签。

  3. 使用指向 ImageStreams 的一个或多个触发器定义构建:

    type: "ImageChange" 1
    imageChange: {}
    type: "ImageChange" 2
    imageChange:
      from:
        kind: "ImageStreamTag"
        name: "custom-image:latest"
    1
    监控构建策略的 from 字段中定义的 ImageStreamTag 的镜像更改触发器。此处的 imageChange 对象必须留空。
    2
    监控任意镜像流的镜像更改触发器。此时 imageChange 部分必须包含一个 from 字段,以引用要监控的 ImageStreamTag

将镜像更改触发器用于策略镜像流时,生成的构建会获得一个不可变 docker 标签,指向与该标签对应的最新镜像。在执行构建时,策略会使用此新镜像引用。

对于不引用策略镜像流的其他镜像更改触发器,系统会启动新构建,但不会使用唯一镜像引用来更新构建策略。

由于此示例具有策略的镜像更改触发器,因此生成的构建将是:

strategy:
  sourceStrategy:
    from:
      kind: "DockerImage"
      name: "172.30.17.3:5001/mynamespace/ruby-20-centos7:<immutableid>"

这将确保触发的构建使用刚才推送到存储库的新镜像,并且可以使用相同的输入随时重新运行构建。

您可以暂停镜像更改触发器,以便在构建开始之前对引用的镜像流进行多次更改。在将 ImageChangeTrigger 添加到 BuildConfig 时,您也可以将 paused 属性设为 true,以避免立即触发构建。

type: "ImageChange"
imageChange:
  from:
    kind: "ImageStreamTag"
    name: "custom-image:latest"
  paused: true

如果因为 Webhook 触发器或手动请求而触发构建,则创建的构建将使用从 Strategy 引用的 ImageStream 解析而来的 <immutableid>。这将确保使用一致的镜像标签来执行构建,以方便再生。

其他资源

7.1.3. 识别构建的镜像更改触发器

作为开发人员,如果您有镜像更改触发器,您可以识别启动了上一次构建的镜像更改。这对于调试或故障排除构建非常有用。

BuildConfig示例

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: bc-ict-example
  namespace: bc-ict-example-namespace
spec:

# ...

  triggers:
  - imageChange:
      from:
        kind: ImageStreamTag
        name: input:latest
        namespace: bc-ict-example-namespace
  - imageChange:
      from:
        kind: ImageStreamTag
        name: input2:latest
        namespace: bc-ict-example-namespace
    type: ImageChange
status:
  imageChangeTriggers:
  - from:
      name: input:latest
      namespace: bc-ict-example-namespace
    lastTriggerTime: "2021-06-30T13:47:53Z"
    lastTriggeredImageID: image-registry.openshift-image-registry.svc:5000/bc-ict-example-namespace/input@sha256:0f88ffbeb9d25525720bfa3524cb1bf0908b7f791057cf1acfae917b11266a69
  - from:
      name: input2:latest
      namespace: bc-ict-example-namespace
    lastTriggeredImageID:  image-registry.openshift-image-registry.svc:5000/bc-ict-example-namespace/input2@sha256:0f88ffbeb9d25525720bfa3524cb2ce0908b7f791057cf1acfae917b11266a69

  lastVersion: 1

注意

本例省略了与镜像更改触发器无关的元素。

先决条件

  • 您已配置了多个镜像更改触发器。这些触发器已触发一个或多个构建。

流程

  1. BuildConfig CR 中,在 status.imageChangeTriggers 中,标识具有最新时间戳的 lastTriggerTime

    这个 ImageChangeTriggerStatus

    Then you use the `name` and `namespace` from that build to find the corresponding image change trigger in `buildConfig.spec.triggers`.
  2. UnderimageChangeTriggers 下,比较时间戳以标识最新的

镜像更改触发器

在构建配置中,buildConfig.spec.triggers 是构建触发器策略 BuildTriggerPolicy 的数组。

每个 BuildTriggerPolicy 都有 type 字段和指针字段。每个指针字段对应于 type 字段允许的值之一。因此,您只能将 BuildTriggerPolicy 设置为一个指针字段。

对于镜像更改触发器,type 的值为 ImageChange。然后,imageChange 字段是指向 ImageChangeTrigger 对象的指针,其具有以下字段:

  • lastTriggeredImageID :此字段在 Red Hat OpenShift Service on AWS 4.8 中已弃用,并将在以后的发行版本中被忽略。它包含从此 BuildConfig 触发最后一次构建时的 ImageStreamTag 的已解析镜像引用。
  • paused:您可以使用此字段(示例中未显示)暂时禁用此特定镜像更改触发器。
  • from :使用此字段引用驱动此镜像更改触发器的 ImageStreamTag。其类型是核心 Kubernetes 类型 OwnerReference

from 字段有以下字段:

  • kind :对于镜像更改触发器,唯一支持的值是 ImageStreamTag
  • 命名空间 :使用此字段指定 ImageStreamTag 的命名空间。
  • 名称 :使用此字段指定 ImageStreamTag

镜像更改触发器状态

在构建配置中,buildConfig.status.imageChangeTriggersImageChangeTriggerStatus 元素的数组。每个 ImageChangeTriggerStatus 元素都包含上例中所示的 fromlastTriggeredImageIDlastTriggerTime 元素。

具有最新 lastTriggerTimeImageChangeTriggerStatus 触发了最新的构建。您可以使用其 namenamespace 来识别触发构建的 buildConfig.spec.triggers 中的镜像更改触发器。

带有最新时间戳的 lastTriggerTime 表示最后一个构建的 ImageChangeTriggerStatus。此 ImageChangeTriggerStatusnamenamespace 与触发构建的 buildConfig.spec.triggers 中的镜像更改触发器相同。

其他资源

7.1.4. 配置更改触发器

通过配置更改触发器,您可以在创建新 BuildConfig 时立即自动调用构建。

如下是 BuildConfig 中的示例触发器定义 YAML:

  type: "ConfigChange"
注意

配置更改触发器目前仅在创建新 BuildConfig 时运作。在未来的版本中,配置更改触发器也可以在每当 BuildConfig 更新时启动构建。

7.1.4.1. 手动设置触发器

您可以使用 oc set triggers 在构建配置中添加和移除触发器。

流程

  • 要在构建配置上设置 GitHub Webhook 触发器,请输入以下命令:

    $ oc set triggers bc <name> --from-github
  • 要设置镜像更改触发器,请输入以下命令:

    $ oc set triggers bc <name> --from-image='<image>'
  • 要删除触发器,请输入以下命令:

    $ oc set triggers bc <name> --from-bitbucket --remove
注意

如果 Webhook 触发器已存在,再次添加它会重新生成 Webhook secret。

如需更多信息,请输入以下命令查阅帮助文档:

$ oc set triggers --help
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.