OpenShift 文档正在迁移，不久后将仅在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

执行高级构建

您可以设置构建资源和最大持续时间，将构建分配给节点，链接构建，修剪构建以及配置构建运行策略。

设置构建资源

默认情况下，构建由使用无绑定资源（例如内存和 CPU）的 Pod 完成。这些资源可以受到限制。

步骤

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

  • 通过在项目的默认容器限制中指定资源限制来限制资源使用。

  • 通过将资源限制指定为构建配置的一部分来限制资源使用。

    • 在以下示例中，每个 `resources`、`cpu` 和 `memory` 参数都是可选的

      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)。

      但是，如果已为您的项目定义了配额，则需要以下两项之一：

      • 设置了具有显式 `requests` 的 `resources` 部分

        resources:
  requests: (1)
    cpu: "100m"
    memory: "256Mi"
        1 `requests` 对象包含与配额中的资源列表相对应的资源列表。

      • 在您的项目中定义的限制范围，其中 `LimitRange` 对象中的默认值适用于构建过程中创建的 Pod。

        否则，构建 Pod 创建将失败，并引用无法满足配额的错误。

设置最大持续时间

在定义BuildConfig对象时，您可以通过设置completionDeadlineSeconds字段来定义其最大持续时间。该字段以秒为单位，默认为未设置。未设置时，不会强制执行最大持续时间。

最大持续时间从构建 pod 在系统中被调度的时间开始计算，并定义它可以处于活动状态的时间长度，包括拉取构建器镜像所需的时间。达到指定超时时间后，构建将由 OpenShift Container Platform 终止。

步骤

  • 要设置最大持续时间，请在您的BuildConfig中指定completionDeadlineSeconds。以下示例显示了BuildConfig的一部分，其中指定了 30 分钟的completionDeadlineSeconds字段

    spec:
  completionDeadlineSeconds: 1800

流水线策略选项不支持此设置。

将构建分配到特定节点

可以通过在构建配置的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标签的节点上运行。

链式构建

对于 Go、C、C++ 和 Java 等编译型语言，在应用程序镜像中包含编译所需的依赖项可能会增加镜像的大小或引入可被利用的漏洞。

为了避免这些问题，可以将两个构建链接在一起。一个构建生成编译后的工件，另一个构建将该工件放置在运行该工件的单独镜像中。

在以下示例中，源到镜像 (S2I) 构建与 Docker 构建相结合，编译然后放置在单独运行时镜像中的工件。

尽管此示例链接了 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文件所需的任何构建工具。此外，由于第二个构建包含镜像更改触发器，因此每当第一个构建运行并生成包含二进制工件的新镜像时，第二个构建都会自动触发以生成包含该工件的运行时镜像。因此，这两个构建的行为就像一个包含两个阶段的单一构建。

修剪构建

默认情况下，已完成生命周期的构建会无限期地保留。您可以限制保留先前构建的数量。

步骤

  1. 通过为BuildConfig中的successfulBuildsHistoryLimit或failedBuildsHistoryLimit提供一个正整数来限制保留先前构建的数量，例如

    apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  successfulBuildsHistoryLimit: 2 (1)
  failedBuildsHistoryLimit: 2 (2)
    1 successfulBuildsHistoryLimit将保留最多两个状态为completed的构建。
    2 failedBuildsHistoryLimit将保留最多两个状态为failed、canceled或error的构建。

  2. 通过以下操作之一触发构建修剪

    • 更新构建配置。

    • 等待构建完成其生命周期。

构建按其创建时间排序，最旧的构建将首先被修剪。

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

构建运行策略

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

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

  • 将Parallel更改为Serial或SerialLatestOnly并从该配置触发新的构建会导致新构建等待所有并行构建完成，因为串行构建只能单独运行。

  • 将Serial更改为SerialLatestOnly并触发新的构建会导致取消队列中所有现有构建，除了当前正在运行的构建和最近创建的构建。最新的构建接下来运行。