2.9. 执行高级构建
以下小节提供了有关高级构建操作的说明,包括设置构建资源和最长持续时间、将构建分配给节点、串联构建、修剪构建,以及构建运行策略。
2.9.1. 设置构建资源
默认情况下,构建由 Pod 使用未绑定的资源(如内存和 CPU)来完成。这些资源可能会有限制。
流程
您可以以两种方式限制资源使用:
- 通过在项目的默认容器限值中指定资源限值来限制资源使用。
在构建配置中通过指定资源限值来限制资源使用。** 在以下示例中,每个
resources
、cpu
和memory
参数都是可选的:apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: resources: limits: cpu: "100m" 1 memory: "256Mi" 2
不过,如果您的项目定义了配额,则需要以下两项之一:
设定了显式
requests
的resources
部分:resources: requests: 1 cpu: "100m" memory: "256Mi"
- 1
requests
对象包含与配额中资源列表对应的资源列表。
项目中定义的限值范围,其中
LimitRange
对象中的默认值应用到构建过程中创建的 Pod。否则,构建 Pod 创建将失败,说明无法满足配额要求。
2.9.2. 设置最长持续时间
定义 BuildConfig
对象时,您可以通过设置 completionDeadlineSeconds
字段来定义其最长持续时间。以秒为单位指定,默认情况下不设置。若未设置,则不强制执行最长持续时间。
最长持续时间从构建 Pod 调度到系统中的时间开始计算,并且定义它在多久时间内处于活跃状态,这包括拉取构建器镜像所需的时间。达到指定的超时后,OpenShift Container Platform 将终止构建。
流程
要设置最长持续时间,请在
BuildConfig
中指定completionDeadlineSeconds
。下例显示了BuildConfig
的部分内容,它指定了值为 30 分钟的completionDeadlineSeconds
字段:spec: completionDeadlineSeconds: 1800
Pipeline 策略选项不支持此设置。
2.9.3. 将构建分配给特定的节点
通过在构建配置的 nodeSelector
字段中指定标签,可以将构建定位到在特定节点上运行。nodeSelector
值是一组键值对,在调度构建 pod 时与 Node
标签匹配。
nodeSelector
值也可以由集群范围的默认值和覆盖值控制。只有构建配置没有为 nodeSelector 定义任何键值对,也没有为 nodeSelector
:{}
定义显式的空映射值,才会应用默认值。覆盖值将逐个键地替换构建配置中的值。
如果指定的 NodeSelector
无法与具有这些标签的节点匹配,则构建仍将无限期地保持在 Pending
状态。
流程
通过在
BuildConfig
的nodeSelector
字段中指定标签,将构建分配到特定的节点上运行,如下例所示:apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: nodeSelector:1 key1: value1 key2: value2
- 1
- 与此构建配置关联的构建将仅在具有
key1=value2
和key2=value2
标签的节点上运行。
2.9.4. 串联构建
对于编译语言(例如 Go、C、C ++ 和 Java),在应用程序镜像中包含编译所需的依赖项可能会增加镜像的大小,或者引入可被利用的漏洞。
为避免这些问题,可以将两个构建串联在一起。一个生成编译工件的构建,另一个构建将工件放置在运行工件的独立镜像中。
在以下示例中,Source-to-Image(S2I)构建与 Docker 构建相结合,以编译工件并将其置于单独的运行时镜像中。
虽然本例串联了 Source-to-Image(S2I) 构建和 Docker 构建,但第一个构建可以使用任何策略来生成包含所需工件的镜像,第二个构建则可以使用任何策略来消耗镜像中的输入内容。
第一个构建获取应用程序源,并生成含有 WAR
文件的镜像。镜像推送到 artifact-image
镜像流。输出工件的路径取决于使用的 S2I 构建器的 assemble
脚本。在这种情况下,它会输出到 /wildfly/standalone/deployments/ROOT.war
。
apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: name: artifact-build spec: output: to: kind: ImageStreamTag name: artifact-image:latest source: git: uri: https://github.com/openshift/openshift-jee-sample.git ref: "master" strategy: sourceStrategy: from: kind: ImageStreamTag name: wildfly:10.1 namespace: openshift
第二个构建使用路径指向第一个构建中输出镜像内的 WAR 文件的镜像源。内联 dockerfile
将该 WAR
文件复制到运行时镜像中。
apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: name: image-build spec: output: to: kind: ImageStreamTag name: image-build:latest source: dockerfile: |- FROM jee-runtime:latest COPY ROOT.war /deployments/ROOT.war images: - from: 1 kind: ImageStreamTag name: artifact-image:latest paths: 2 - sourcePath: /wildfly/standalone/deployments/ROOT.war destinationDir: "." strategy: dockerStrategy: from: 3 kind: ImageStreamTag name: jee-runtime:latest triggers: - imageChange: {} type: ImageChange
此设置的结果是,第二个构建的输出镜像不需要包含创建 WAR
文件所需的任何构建工具。此外,由于第二个构建包含镜像更改触发器,因此每当运行第一个构建并生成含有二进制工件的新镜像时,将自动触发第二个构建,以生成包含该工件的运行时镜像。所以,两个构建表现为一个具有两个阶段的构建。
2.9.5. 修剪构建
默认情况下,生命周期已结束的构建将无限期保留。您可以限制要保留的旧构建数量。
流程
通过为
BuildConfig
中的successfulBuildsHistoryLimit
或failedBuildsHistoryLimit
提供正整数值,限制要保留的旧构建的数量,如下例中所示:apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: successfulBuildsHistoryLimit: 2 1 failedBuildsHistoryLimit: 2 2
通过以下操作之一来触发构建修剪:
- 更新构建配置。
- 等待构建结束其生命周期。
构建按其创建时间戳排序,首先修剪最旧的构建。
管理员可以使用 oc adm 对象修剪命令来手动修剪构建。
2.9.6. 构建运行策略
构建运行策略描述从构建配置创建的构建应运行的顺序。这可以通过更改 Build
规格的 spec
部分中的 runPolicy
字段的值来完成。
还可以通过以下方法更改现有构建配置的 runPolicy
值:
-
如果将
Parallel
改为Serial
或SerialLatestOnly
,并从此配置触发新构建,这会导致新构建需要等待所有并行构建完成,因为串行构建只能单独运行。 -
如果将
Serial
更改为SerialLatestOnly
并触发新构建,这会导致取消队列中的所有现有构建,但当前正在运行的构建和最近创建的构建除外。最新的构建接下来运行。