2.9. 执行高级构建


以下小节提供了有关高级构建操作的说明,包括设置构建资源和最长持续时间、将构建分配给节点、串联构建、修剪构建,以及构建运行策略。

2.9.1. 设置构建资源

默认情况下,构建由 Pod 使用未绑定的资源(如内存和 CPU)来完成。这些资源可能会有限制。

流程

您可以以两种方式限制资源使用:

  • 通过在项目的默认容器限值中指定资源限值来限制资源使用。
  • 在构建配置中通过指定资源限值来限制资源使用。** 在以下示例中,每个 resourcescpumemory 参数都是可选的:

    apiVersion: "v1"
    kind: "BuildConfig"
    metadata:
      name: "sample-build"
    spec:
      resources:
        limits:
          cpu: "100m" 1
          memory: "256Mi" 2
    1
    cpu 以 CPU 单元数为单位:100m 表示 0.1 个 CPU 单元(100 * 1e-3)。
    2
    memory 以字节为单位:256Mi 表示 268435456 字节 (256 * 2 ^ 20)。

    不过,如果您的项目定义了配额,则需要以下两项之一:

    • 设定了显式 requestsresources 部分:

      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 状态。

流程

  • 通过在 BuildConfignodeSelector 字段中指定标签,将构建分配到特定的节点上运行,如下例所示:

    apiVersion: "v1"
    kind: "BuildConfig"
    metadata:
      name: "sample-build"
    spec:
      nodeSelector:1
        key1: value1
        key2: value2
    1
    与此构建配置关联的构建将仅在具有 key1=value2key2=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
1
from 指定 docker 构建应包含来自 artifact-image 镜像流的镜像输出,而这是上一个构建的目标。
2
paths 指定要在当前 docker 构建中包含目标镜像的哪些路径。
3
运行时镜像用作 docker 构建的源镜像。

此设置的结果是,第二个构建的输出镜像不需要包含创建 WAR 文件所需的任何构建工具。此外,由于第二个构建包含镜像更改触发器,因此每当运行第一个构建并生成含有二进制工件的新镜像时,将自动触发第二个构建,以生成包含该工件的运行时镜像。所以,两个构建表现为一个具有两个阶段的构建。

2.9.5. 修剪构建

默认情况下,生命周期已结束的构建将无限期保留。您可以限制要保留的旧构建数量。

流程

  1. 通过为 BuildConfig 中的 successfulBuildsHistoryLimitfailedBuildsHistoryLimit 提供正整数值,限制要保留的旧构建的数量,如下例中所示:

    apiVersion: "v1"
    kind: "BuildConfig"
    metadata:
      name: "sample-build"
    spec:
      successfulBuildsHistoryLimit: 2 1
      failedBuildsHistoryLimit: 2 2
    1
    successfulBuildsHistoryLimit 将保留最多两个状态为 completed 的构建。
    2
    failedBuildsHistoryLimit 将保留最多两个状态为 failedcancellederror 的构建。
  2. 通过以下操作之一来触发构建修剪:

    • 更新构建配置。
    • 等待构建结束其生命周期。

构建按其创建时间戳排序,首先修剪最旧的构建。

注意

管理员可以使用 oc adm 对象修剪命令来手动修剪构建。

2.9.6. 构建运行策略

构建运行策略描述从构建配置创建的构建应运行的顺序。这可以通过更改 Build 规格的 spec 部分中的 runPolicy 字段的值来完成。

还可以通过以下方法更改现有构建配置的 runPolicy 值:

  • 如果将 Parallel 改为 SerialSerialLatestOnly,并从此配置触发新构建,这会导致新构建需要等待所有并行构建完成,因为串行构建只能单独运行。
  • 如果将 Serial 更改为 SerialLatestOnly 并触发新构建,这会导致取消队列中的所有现有构建,但当前正在运行的构建和最近创建的构建除外。最新的构建接下来运行。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.