Builds

构建 (build) 是将输入参数转换为结果对象的过程。此过程最常用于将输入参数或源代码转换为可运行的镜像。BuildConfig 对象是整个构建过程的定义。

OpenShift Container Platform 使用 Kubernetes，从构建镜像创建容器并将它们推送到容器镜像 registry。

构建对象具有共同的特征，包括构建的输入，完成构建过程要满足的要求、构建过程日志记录、从成功构建中发布资源，以及发布构建的最终状态。构建会使用资源限制，具体是指定资源限值，如 CPU 使用量、内存使用量，以及构建或 Pod 执行时间。

OpenShift Container Platform 构建系统提供对构建策略的可扩展支持，它们基于构建 API 中指定的可选择类型。可用的构建策略主要有三种：

默认情况下，支持 docker 构建和 S2I 构建。

构建生成的对象取决于用于创建它的构建器（builder）。对于 docker 和 S2I 构建，生成的对象为可运行的镜像。对于自定义构建，生成的对象是构建器镜像作者指定的任何事物。

此外，也可利用管道构建策略来实现复杂的工作流：

构建配置描述单个构建定义，以及一组规定何时创建新构建的触发器（trigger）。构建配置通过 BuildConfig 定义，它是一种 REST 对象，可在对 API 服务器的 POST 中使用以创建新实例。

构建配置或 BuildConfig 的特征就是构建策略和一个或多个源。策略决定流程，而源则提供输入。

根据您选择使用 OpenShift Container Platform 创建应用程序的方式，如果使用 Web 控制台或 CLI，通常会自动生成 BuildConfig，并且可以随时对其进行编辑。如果选择稍后手动更改配置，则了解 BuildConfig 的组成部分及可用选项可能会有所帮助。

以下示例 BuildConfig 在每次容器镜像标签或源代码改变时产生新的构建：

kind: BuildConfig
apiVersion: build.openshift.io/v1
metadata:
  name: "ruby-sample-build" 1
spec:
  runPolicy: "Serial" 2
  triggers: 3
    -
      type: "GitHub"
      github:
        secret: "secret101"
    - type: "Generic"
      generic:
        secret: "secret101"
    -
      type: "ImageChange"
  source: 4
    git:
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy: 5
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "ruby-20-centos7:latest"
  output: 6
    to:
      kind: "ImageStreamTag"
      name: "origin-ruby-sample:latest"
  postCommit: 7
      script: "bundle exec rake test"

构建输入提供构建操作的源内容。您可以使用以下构建输入在 OpenShift Container Platform 中提供源，它们按优先顺序列出：

您可以在单个构建中组合多个输入。但是，由于内联 Dockerfile 具有优先权，它可能会覆盖任何由其他输入提供的名为 Dockerfile 的文件。二进制（本地）和 Git 存储库是互斥的输入。

如果不希望在构建生成的最终应用程序镜像中提供构建期间使用的某些资源或凭证，或者想要消耗在 secret 资源中定义的值，您可以使用输入 secret。外部工件可用于拉取不以其他任一构建输入类型提供的额外文件。

在运行构建时：

以下源定义示例包括多种输入类型，以及它们如何组合的说明。如需有关如何定义各种输入类型的更多详细信息，请参阅每种输入类型的具体小节。

source:
  git:
    uri: https://github.com/openshift/ruby-hello-world.git 1
    ref: "master"
  images:
  - from:
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths:
    - destinationDir: app/dir/injected/dir 2
      sourcePath: /usr/lib/somefile.jar
  contextDir: "app/dir" 3
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 4

提供 dockerfile 值时，此字段的内容将写到磁盘上，存为名为 Dockerfile 的文件。这是处理完其他输入源之后完成的；因此，如果输入源存储库的根目录中包含 Dockerfile，它会被此内容覆盖。

源定义是 BuildConfig 的 spec 部分的一部分：

source:
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 1

您可以使用镜像向构建过程添加其他文件。输入镜像的引用方式与定义 From 和 To 镜像目标的方式相同。这意味着可以引用容器镜像和镜像流标签。在使用镜像时，必须提供一个或多个路径对，以指示要复制镜像的文件或目录的路径以及构建上下文中要放置它们的目的地。

源路径可以是指定镜像内的任何绝对路径。目的地必须是相对目录路径。构建时会加载镜像，并将指定的文件和目录复制到构建过程上下文目录中。这与源存储库内容要克隆到的目录相同。如果源路径以 /. 结尾，则复制目录的内容，但不在目的地上创建该目录本身。

镜像输入在 BuildConfig 的 source 定义中指定：

source:
  git:
    uri: https://github.com/openshift/ruby-hello-world.git
    ref: "master"
  images: 1
  - from: 2
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths: 3
    - destinationDir: injected/dir 4
      sourcePath: /usr/lib/somefile.jar 5
  - from:
      kind: ImageStreamTag
      name: myotherinputimage:latest
      namespace: myothernamespace
    pullSecret: mysecret 6
    paths:
    - destinationDir: injected/dir
      sourcePath: /usr/lib/somefile.jar

$ oc secrets link builder dockerhub

指定之后，从提供的位置获取源代码。

如果您提供内联 Dockerfile，它将覆盖 Git 存储库的 contextDir 中的 Dockerfile。

源定义是 BuildConfig 的 spec 部分的一部分：

source:
  git: 1
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
  contextDir: "app/dir" 2
  dockerfile: "FROM openshift/ruby-22-centos7\nUSER example" 3

如果 ref 字段注明拉取请求，则系统将使用 git fetch 操作，然后 checkout FETCH_HEAD。

如果未提供 ref 值，OpenShift Container Platform 将执行浅克隆 (--depth=1)。这时，仅下载与默认分支（通常为 master）上最近提交相关联的文件。这将使存储库下载速度加快，但不会有完整的提交历史记录。要执行指定存储库的默认分支的完整 git clone，请将 ref 设置为默认分支的名称（如 main）。

source:
  git:
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
    httpProxy: http://proxy.example.com
    httpsProxy: https://proxy.example.com
    noProxy: somedomain.com, otherdomain.com

$ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=ssh://bitbucket.atlassian.com:7999/*'

kind: Secret
apiVersion: v1
metadata:
  name: matches-all-corporate-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/*
data:
  ...
---
kind: Secret
apiVersion: v1
metadata:
  name: override-for-my-dev-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/*
    build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/*
data:
  ...

apiVersion: "build.openshift.io/v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"
  source:
    git:
      uri: "https://github.com/user/app.git"
    sourceSecret:
      name: "basicsecret"
  strategy:
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "python-33-centos7:latest"

$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>

[http]
        sslVerify=false

从本地文件系统流传输内容到构建器称为 Binary 类型构建。对于此类构建，BuildConfig.spec.source.type 的对应值为 Binary。

这种源类型的独特之处在于，它仅基于您对 oc start-build 的使用而加以利用。

要使用二进制构建，请使用以下选项之一调用 oc start-build：

在上方列出的每种情形中：

您可以将 HTTP 或 HTTPS 方案的 URL 传递给 --from-file 和 --from-archive，而不传递文件名。将 -from-file 与 URL 结合使用时，构建器镜像中文件的名称由 web 服务器发送的 Content-Disposition 标头决定，如果该标头不存在，则由 URL 路径的最后一个组件决定。不支持任何形式的身份验证，也无法使用自定义 TLS 证书或禁用证书验证。

使用 oc new-build --binary =true 时，该命令可确保强制执行与二进制构建关联的限制。生成的 BuildConfig 具有 Binary 源类型，这意味着为此 BuildConfig 运行构建的唯一有效方法是使用 oc start-build 和其中一个 --from 选项来提供必需的二进制数据。

Dockerfile 和 contextDir 源选项对二进制构建具有特殊含义。

Dockerfile 可以与任何二进制构建源一起使用。如果使用 Dockerfile 且二进制流是存档，则其内容将充当存档中任何 Dockerfile 的替代 Dockerfile。如果将 Dockerfile 与 --from-file 参数搭配 使用，且文件参数命名为 Dockerfile，则 Dockerfile 的值将替换二进制流中的值。

如果是二进制流封装提取的存档内容，contextDir 字段的值将解释为存档中的子目录，并且在有效时，构建器将在执行构建之前更改到该子目录。

有时候，构建操作需要凭证或其他配置数据才能访问依赖的资源，但又不希望将这些信息放在源代码控制中。您可以定义输入 secret 和输入配置映射。

例如，在使用 Maven 构建 Java 应用程序时，可以设置通过私钥访问的 Maven Central 或 JCenter 的私有镜像。要从该私有镜像下载库，您必须提供以下内容：

为安全起见，不应在应用程序镜像中公开您的凭证。

示例中描述的是 Java 应用程序，但您可以使用相同的方法将 SSL 证书添加到 /etc/ssl/certs 目录，以及添加 API 密钥或令牌、许可证文件等。

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque 1
data: 2
  username: <username> 3
  password: <password>
stringData: 4
  hostname: myapp.mydomain.com 5

$ oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn” \
    --build-config-map "settings-mvn"

source:
  git:
    uri: https://github.com/wildfly/quickstart.git
  contextDir: helloworld
  configMaps:
    - configMap:
        name: settings-mvn
      destinationDir: ".m2"
  secrets:
    - secret:
        name: secret-mvn
      destinationDir: ".ssh"

$ oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn:.ssh” \
    --build-config-map "settings-mvn:.m2"

FROM centos/ruby-22-centos7

USER root
COPY ./secret-dir /secrets
COPY ./config /

# Create a shell script that will output secrets and ConfigMaps when the image is run
RUN echo '#!/bin/sh' > /input_report.sh
RUN echo '(test -f /secrets/secret1 && echo -n "secret1=" && cat /secrets/secret1)' >> /input_report.sh
RUN echo '(test -f /config && echo -n "relative-configMap=" && cat /config)' >> /input_report.sh
RUN chmod 755 /input_report.sh

CMD ["/bin/sh", "-c", "/input_report.sh"]

建议不要将二进制文件存储在源存储库中。因此，您必须定义一个构建，在构建过程中拉取其他文件，如 Java .jar 依赖项。具体方法取决于使用的构建策略。

对于 Source 构建策略，必须在 assemble 脚本中放入适当的 shell 命令：

#!/bin/sh
APP_VERSION=1.0
wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar

#!/bin/sh
exec java -jar app.jar

对于 Docker 构建策略，您必须修改 Dockerfile 并通过 RUN 指令 调用 shell 命令：

FROM jboss/base-jdk:8

ENV APP_VERSION 1.0
RUN wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar

EXPOSE 8080
CMD [ "java", "-jar", "app.jar" ]

在实践中，您可能希望将环境变量用于文件位置，以便要下载的具体文件能够使用 BuildConfig 中定义的环境变量来自定义，而不必更新 Dockerfile 或 assemble 脚本。

您可以选择不同方法来定义环境变量：

您可以为构建提供 .docker/config.json 文件，在文件中包含私有容器 registry 的有效凭证。这样，您可以将输出镜像推送到私有容器镜像 registry 中，或从需要身份验证的私有容器镜像 registry 中拉取构建器镜像。

您可以为同一 registry 中的多个存储库提供凭证，每个软件仓库都有特定于该 registry 路径的凭证。

默认情况下，.docker/config.json 文件位于您的主目录中，并具有如下格式：

auths:
  index.docker.io/v1/: 1
    auth: "YWRfbGzhcGU6R2labnRib21ifTE=" 2
    email: "user@example.com" 3
  docker.io/my-namespace/my-user/my-image: 4
    auth: "GzhYWRGU6R2fbclabnRgbkSp=""
    email: "user@example.com"
  docker.io/my-namespace: 5
    auth: "GzhYWRGU6R2deesfrRgbkSp=""
    email: "user@example.com"

您可以定义多个容器镜像 registry，或在同一 registry 中定义多个存储库。或者，也可以通过运行 docker login 命令将身份验证条目添加到此文件中。如果文件不存在，则会创建此文件。

Kubernetes 提供Secret 对象，可用于存储配置和密码。

与 Pod 环境变量一样，可以定义构建环境变量，在使用 Downward API 时引用其他源或变量。需要注意一些例外情况。

您也可以使用 oc set env 命令管理 BuildConfig 中定义的环境变量。

服务用证书 secret 旨在支持需要开箱即用证书的复杂中间件应用程序。它的设置与管理员工具为节点和 master 生成的服务器证书相同。

其他 pod 可以信任由集群创建的证书，这些证书只为内部 DNS 名称签名，方法是使用 pod 中自动挂载的 /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt 文件中的证书颁发机构（CA）捆绑包。

此功能的签名算法是 x509.SHA256WithRSA。要手动轮转，请删除生成的 secret。这会创建新的证书。

若要使用一个 secret，Pod 需要引用该 secret。可以通过三种方式将 secret 用于 Pod：

卷类型 secret 使用卷机制将数据作为文件写入到容器中。imagePullSecrets 使用服务帐户将 secret 自动注入到命名空间中的所有 Pod。

当模板包含 secret 定义时，模板使用提供的 secret 的唯一方法是确保验证 secret 卷源通过验证，并且指定的对象引用实际指向 Secret 类型的对象。因此，secret 需要在依赖它的任何 Pod 之前创建。确保这一点的最有效方法是通过使用服务帐户自动注入。

Secret API 对象驻留在命名空间中。它们只能由同一命名空间中的 pod 引用。

每个 secret 的大小限制为 1MB。这是为了防止创建可能会耗尽 apiserver 和 kubelet 内存的大型 secret。不过，创建大量较小的 secret 也可能耗尽内存。

使用 docker 或 source-to-image（S2I）策略的构建会导致创建新的容器镜像。镜像而后被推送到由 Build 规格的 output 部分中指定的容器镜像 registry 中。

如果输出类型是 ImageStreamTag，则镜像将推送到集成的 OpenShift 镜像 registry 并在指定的镜像流中标记。如果输出类型为 DockerImage，则输出引用的名称将用作 docker push 规格。规格中可以包含 registry；如果没有指定 registry，则默认为 DockerHub。如果 Build 规格的 output 部分为空，则构建结束时不推送镜像。

spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"

spec:
  output:
    to:
      kind: "DockerImage"
      name: "my-registry.mycompany.com:5000/myimages/myimage:tag"

Docker 和 source-to-image（S2I）策略构建设置输出镜像的以下环境变量：

此外，任何用户定义的环境变量（例如，使用 S2I 或 docker 策略选项配置的环境变量）也将是输出镜像环境变量列表的一部分。

docker 和 Source-to-Image (S2I) 构建设置输出镜像的以下标签：

您还可以使用 BuildConfig.spec.output.imageLabels 字段指定将应用到构建配置构建的每个镜像的自定义标签列表。

spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "my-image:latest"
    imageLabels:
    - name: "vendor"
      value: "MyCompany"
    - name: "authoritative-source-url"
      value: "registry.mycompany.com"

OpenShift Container Platform 使用 Buildah 从 Dockerfile 构建容器镜像。有关使用 Dockerfile 构建容器镜像的更多信息，请参阅 Dockerfile 参考文档。

strategy:
  dockerStrategy:
    from:
      kind: "ImageStreamTag"
      name: "debian:latest"

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

dockerStrategy:
...
  env:
    - name: "HTTP_PROXY"
      value: "http://myproxy.net:5187/"

dockerStrategy:
...
  buildArgs:
    - name: "foo"
      value: "bar"

Source-to-Image (S2I) 是一种用于构建可重复生成的容器镜像的工具。它通过将应用程序源代码注入容器镜像并汇编新镜像来生成可随时运行的镜像。新镜像融合了基础镜像（构建器）和构建的源代码，并可搭配 buildah run 命令使用。S2I 支持递增构建，可重复利用以前下载的依赖项和过去构建的工件等。

#!/bin/bash

# restore build artifacts
if [ "$(ls /tmp/s2i/artifacts/ 2>/dev/null)" ]; then
    mv /tmp/s2i/artifacts/* $HOME/.
fi

# move the application source
mv /tmp/s2i/src $HOME/src

# build application artifacts
pushd ${HOME}
make all

# install the artifacts
make install
popd

#!/bin/bash

# run the application
/opt/application/run.sh

#!/bin/bash

pushd ${HOME}
if [ -d deps ]; then
    # all deps contents to tar stream
    tar cf - deps
fi
popd

#!/bin/bash

# inform the user how to use the image
cat <<EOF
This is a S2I sample builder image, to use it, install
https://github.com/openshift/source-to-image
EOF

采用自定义构建策略时，开发人员可以定义负责整个构建过程的特定构建器镜像。通过利用自己的构建器镜像，可以自定义构建流程。

自定义构建器镜像是嵌入了构建过程逻辑的普通容器镜像，例如用于构建 RPM 或基本镜像的逻辑。

自定义构建以级别很高的特权运行，默认情况下不可供用户使用。只有可赋予集群管理权限的用户才应被授予运行自定义构建的权限。

采用 Pipeline 构建策略时，开发人员可以定义 Jenkins 管道，供 Jenkins 管道插件使用。构建可以由 OpenShift Container Platform 启动、监控和管理，其方式与任何其他构建类型相同。

Pipeline 工作流在 jenkinsfile 中定义，或直接嵌入在构建配置中，或者在 Git 存储库中提供并由构建配置引用。

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "sample-pipeline"
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        node('agent') {
          stage 'build'
          openshiftBuild(buildConfig: 'ruby-sample-build', showBuildLogs: 'true')
          stage 'deploy'
          openshiftDeploy(deploymentConfig: 'frontend')
        }

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "sample-pipeline"
spec:
  source:
    git:
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfilePath: some/repo/dir/filename 1

您可以在构建配置中添加 secret，以便它可以访问私有存储库。

您可以通过在构建配置中设置 pull secret 来启用拉取到私有 registry，也可以通过设置 push secret 来启用推送。

启用推送：

您必须创建要用作自定义构建镜像的镜像。

您可以使用 OpenShift Container Platform 构建和推送要在 Custom 策略中使用的自定义构建器镜像。

您可以定义一个 BuildConfig 对象，它将结合使用 Custom 策略与自定义构建器镜像来执行您的自定义构建逻辑。

您可以从当前项目中的现有构建配置手动启动新构建。

$ oc start-build <buildconfig_name>

您可以使用 Web 控制台或通过以下 CLI 命令来取消构建。

要编辑构建配置，您可以使用 Developer 视角的 Builds 视图中的 Edit BuildConfig 选项。

您可以使用以下任一视图编辑 BuildConfig ：

您可以在 Form view 和 YAML 视图间切换，而不丢失任何数据。Form 视图中的数据传输到 YAML 视图，反之亦然。

您可以使用以下命令来删除 BuildConfig。

您可以使用 Web 控制台或 oc describe CLI 命令查看构建详情。

这会显示，包括：

如果构建采用 Docker 或 Source 策略，则 oc describe 输出还包括用于构建的源修订的相关信息，包括提交 ID、作者、提交者和消息等。

您可以使用 Web 控制台或 CLI 访问构建日志。

在定义 BuildConfig 时，您可以定义触发器来控制应该运行 BuildConfig 的环境。可用的构建触发器如下：

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

- kind: Secret
  apiVersion: v1
  metadata:
    name: mysecret
    creationTimestamp:
  data:
    WebHookSecretKey: c2VjcmV0dmFsdWUx

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

type: "GitLab"
gitlab:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

type: "Bitbucket"
bitbucket:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

type: "Generic"
generic:
  secretReference:
    name: "mysecret"
  allowEnv: true 1

$ oc describe bc <name>

strategy:
  sourceStrategy:
    from:
      kind: "DockerImage"
      name: "172.30.17.3:5001/mynamespace/ruby-20-centos7:<immutableid>"

type: "ImageChange"
imageChange:
  from:
    kind: "ImageStreamTag"
    name: "custom-image:latest"
  paused: true

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

  type: "ConfigChange"

$ oc set triggers --help

通过构建 hook，可以将行为注入到构建过程中。

BuildConfig 对象的 postCommit 字段在运行构建输出镜像的临时容器内执行命令。Hook 的执行时间是紧接在提交镜像的最后一层后，并且在镜像推送到 registry 之前。

当前工作目录设置为镜像的 WORKDIR，即容器镜像的默认工作目录。对于大多数镜像，这是源代码所处的位置。

如果脚本或命令返回非零退出代码，或者启动临时容器失败，则 hook 将失败。当 hook 失败时，它会将构建标记为失败，并且镜像也不会推送到 registry。可以通过查看构建日志来检查失败的原因。

构建 hook 可用于运行单元测试，以在构建标记为完成并在 registry 中提供镜像之前验证镜像。如果所有测试都通过并且测试运行器返回退出代码 0，则构建标记为成功。如果有任何测试失败，则构建标记为失败。在所有情况下，构建日志将包含测试运行器的输出，这可用于识别失败的测试。

postCommit hook 不仅限于运行测试，也可用于运行其他命令。由于它在临时容器内运行，因此 hook 所做的更改不会持久存在；也就是说，hook 执行无法对最终镜像造成影响。除了其他用途外，也可借助此行为来安装和使用会自动丢弃并且不出现在最终镜像中的测试依赖项。

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

定义 BuildConfig 对象时，您可以通过设置 completionDeadlineSeconds 字段来定义其最长持续时间。以秒为单位指定，默认情况下不设置。若未设置，则不强制执行最长持续时间。

最长持续时间从构建 Pod 调度到系统中的时间开始计算，并且定义它在多久时间内处于活跃状态，这包括拉取构建器镜像所需的时间。达到指定的超时后，OpenShift Container Platform 将终止构建。

通过在构建配置的 nodeSelector 字段中指定标签，可以将构建定位到在特定节点上运行。nodeSelector 值是一组键值对，在调度构建 pod 时与 Node 标签匹配。

nodeSelector 值也可以由集群范围的默认值和覆盖值控制。只有构建配置没有为 nodeSelector 定义任何键值对，也没有为 nodeSelector :{} 定义显式的空映射值，才会应用默认值。覆盖值将逐个键地替换构建配置中的值。

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

为避免这些问题，可以将两个构建串联在一起。一个生成编译工件的构建，另一个构建将工件放置在运行工件的独立镜像中。

在以下示例中，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 文件所需的任何构建工具。此外，由于第二个构建包含镜像更改触发器，因此每当运行第一个构建并生成含有二进制工件的新镜像时，将自动触发第二个构建，以生成包含该工件的运行时镜像。所以，两个构建表现为一个具有两个阶段的构建。

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

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

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

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

要在构建中使用红帽订阅，您可以创建一个镜像流标签来引用通用基础镜像（UBI）。

要让 UBI 在集群中的每个项目中都可用，您需要将镜像流标签添加到 openshift 命名空间中。否则，若要使其在一个特定项目中可用，您要将镜像流标签添加到该项目。

以这种方式使用镜像流标签的好处是，根据安装 pull secret 中的 registry.redhat.io 凭证授予对 UBI 的访问权限，而不会向其他用户公开 pull secret。这比要求每个开发人员使用项目中的 registry.redhat.io 凭证安装 pull secret 更为方便。

使用红帽订阅安装内容的构建需要包括做为一个构件 secret 的权利密钥。

RUN rm /etc/rhsm-host

您可以在一个可以安全地使用来自另外一个命名空间中的一个Secret 中的 RHEL 权利的命名空间中，配置和执行构建。

您仍可通过在与 Build 对象相同的命名空间中，创建包含订阅凭证的 Secret 对象来从 OpenShift 构建中访问 RHEL 权利。但是，在 OpenShift Container Platform 4.10 及之后的版本中，您可以从 OpenShift Container Platform 系统命名空间中的一个 Secret 对象来访问您的凭证和证书。您可以使用引用 Secret 对象的 SharedSecret 自定义资源(CR)实例的 CSI 卷挂载运行授权构建。

此流程依赖于新引入的 Shared Resources CSI Driver 功能，该功能可用于在 OpenShift Container Platform 构建中声明 CSI 卷挂载。它还依赖于 OpenShift Container Platform Insights Operator。

要在全局范围内阻止对特定构建策略的访问，请以具有集群管理源权限的用户身份登录，从 system:authenticated 组中移除对应的角色，再应用注解 rbac.authorization.kubernetes.io/autoupdate: "false" 以防止它们在 API 重启后更改。以下示例演示了如何禁用 Docker 构建策略。

您可以允许某一组用户使用特定策略来创建构建。

与在全局范围内向用户授予构建策略角色类似，您只能允许项目中的某一组特定用户使用特定策略来创建构建。

build.config.openshift.io/cluster 资源提供以下配置参数。

您可以通过编辑 build.config.openshift.io/cluster 资源来配置构建设置。

如果您的资源访问请求遭到拒绝：

requested access to the resource is denied

$ oc describe quota

如果您的资源访问请求遭到拒绝：

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

$ oc delete secret <secret_name>

$ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-

$ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-

您可以按照以下流程将证书颁发机构 (CA) 添加到集群，以便在推送和拉取镜像时使用。