第 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-app
和 oc 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
)。
流程
创建名为
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
的命名空间。
运行以下命令来应用配置:
$ 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
集群角色。
流程
配置 GitHub Webhook。
从 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
- 从 GitHub Web 控制台将此 URL 剪切并粘贴到 GitHub 中。
-
在 GitHub 存储库中,从 Settings
Webhooks 中选择 Add Webhook。 - 将 URL 输出粘贴到 Payload URL 字段。
-
将 Content Type 从 GitHub 默认的
application/x-www-form-urlencoded
更改为application/json
。 点击 Add webhook。
您应该看到一条来自 GitHub 的消息,说明您的 Webhook 已配置成功。
现在,每当您将更改推送到 GitHub 存储库时,新构建会自动启动,成功构建后也会启动新部署。
注意Gogs 支持与 GitHub 相同的 Webhook 有效负载格式。因此,如果您使用的是 Gogs 服务器,也可以在
BuildConfig
中定义 GitHub Webhook 触发器,并由 Gogs 服务器触发它。
假设包含有效 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
集群角色。
流程
配置 GitLab Webhook。
输入以下命令来获取 Webhook URL:
$ oc describe bc <name>
-
复制 Webhook URL,将
<secret>
替换为您的 secret 值。 - 按照 GitLab 设置说明,将 Webhook URL 粘贴到 GitLab 存储库设置中。
假设包含有效 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
集群角色。
流程
配置 Bitbucket Webhook。
输入以下命令来获取 Webhook URL:
$ oc describe bc <name>
-
复制 Webhook URL,将
<secret>
替换为您的 secret 值。 - 按照 Bitbucket 设置说明,将 Webhook URL 粘贴到 Bitbucket 存储库设置中。
假设包含有效 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 传入环境变量。
流程
要设置调用者,请为调用系统提供构建的通用 webhook 端点的 URL。
通用 webhook 端点 URL 示例
https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic
调用者必须以
POST
操作的形式调用 Webhook。要手动调用 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
即可启用此行为。
要使用
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/yaml
或application/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 中缺少可唯一标识的镜像。
流程
定义指向您要用作触发器的上游镜像的
ImageStream
:kind: "ImageStream" apiVersion: "v1" metadata: name: "ruby-20-centos7"
这将定义绑定到位于
<system-registry>/<namespace>/ruby-20-centos7
的容器镜像存储库的镜像流。<system-registry
> 定义为一个服务,其名称为在 Red Hat OpenShift Service on AWS 上运行的docker-registry
。如果镜像流是构建的基础镜像,请将构建策略中的
from
字段设置为指向ImageStream
:strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "ruby-20-centos7:latest"
在这种情形中,
sourceStrategy
定义将消耗此命名空间中名为ruby-20-centos7
的镜像流的latest
标签。使用指向
ImageStreams
的一个或多个触发器定义构建:type: "ImageChange" 1 imageChange: {} type: "ImageChange" 2 imageChange: from: kind: "ImageStreamTag" name: "custom-image:latest"
将镜像更改触发器用于策略镜像流时,生成的构建会获得一个不可变 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
本例省略了与镜像更改触发器无关的元素。
先决条件
- 您已配置了多个镜像更改触发器。这些触发器已触发一个或多个构建。
流程
在
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`.
-
在
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.imageChangeTriggers
是 ImageChangeTriggerStatus
元素的数组。每个 ImageChangeTriggerStatus
元素都包含上例中所示的 from
、lastTriggeredImageID
和 lastTriggerTime
元素。
具有最新 lastTriggerTime
的 ImageChangeTriggerStatus
触发了最新的构建。您可以使用其 name
和 namespace
来识别触发构建的 buildConfig.spec.triggers
中的镜像更改触发器。
带有最新时间戳的 lastTriggerTime
表示最后一个构建的 ImageChangeTriggerStatus
。此 ImageChangeTriggerStatus
的name
和 namespace
与触发构建的 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