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 在系统中被调度的时间开始计算，并定义它可以处于活动状态的时间长度，包括拉取构建器映像所需的时间。达到指定超时后，构建将被 Red Hat OpenShift Service on AWS 终止。

步骤

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

    spec:
  completionDeadlineSeconds: 1800

此设置不支持 Pipeline Strategy 选项。
编辑

将构建分配到特定节点

可以通过在构建配置的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 等编译型语言，在应用程序映像中包含编译所需的依赖项可能会增加映像的大小或引入可被利用的漏洞。

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

编辑

修剪构建

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

步骤

  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. 通过以下操作之一触发构建修剪

    • 更新构建配置。

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

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

编辑

构建运行策略

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

也可以更改现有构建配置的runPolicy值，方法是：

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

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