构建（build）

Docker 构建策略调用 docker build 命令，它需要一个含有 Dockerfile 的存储库并且其中包含所有必要的工件，从而能生成可运行的镜像。

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

S2I 的优点包括：

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

自定义构建器（Custom builder）镜像是嵌入了构建过程逻辑的普通 Docker 格式容器镜像，例如用于构建 RPM 或基础镜像。

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

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

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

如果 Git 存储库需要使用代理才能访问，您可以在 BuildConfig 的 source 部分中定义要使用的代理。您可以同时配置要使用的 HTTP 和 HTTPS 代理。两个字段都是可选的。也可以在 NoProxy 字段中指定不应执行代理的域。

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

构建器 Pod 需要访问定义为构建源的任何 Git 存储库。源克隆 secret 为构建器 Pod 提供了通常无权访问的资源的访问权限，例如私有存储库或具有自签名或不可信 SSL 证书的存储库。

$ oc secrets link builder mysecret

$ 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:
  ...

$ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'

apiVersion: "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 set build-secret --source bc/sample-build basicsecret

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

[http]
        sslVerify=false

$ oc create secret generic <secret_name> \
    --from-file=ssh-privatekey=<path/to/ssh/private/key> \
    --from-file=<path/to/.gitconfig> \
    --type=kubernetes.io/ssh-auth

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

$ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=ca-cert=</path/to/file> \
    --type=kubernetes.io/basic-auth

$ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=</path/to/.gitconfig> \
    --type=kubernetes.io/basic-auth

$ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=</path/to/.gitconfig> \
    --from-file=ca-cert=</path/to/file> \
    --type=kubernetes.io/basic-auth

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

要在新 BuildConfig 中包含 secret 和 ConfigMap，请运行以下命令：

$ 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"

在构建期间，settings.xml 和 id_rsa 文件将复制到源代码所在的目录中。在 OpenShift Container Platform S2I 构建器镜像中，这是镜像的工作目录，使用 Dockerfile 中的 WORKDIR 指令设置。如果要指定其他目录，请在定义中添加 destinationDir：

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"

您还可以指定创建新 BuildConfig 时的目标目录：

$ 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"

在这两种情况下，settings.xml 文件都添加到构建环境的 ./.m2 目录中，而 id_rsa 密钥则添加到 ./.ssh目录中。

采用 Source 策略时，所有定义的输入 secret 都复制到对应的 destinationDir 中。如果 destinationDir 留空，则 secret 会放置到构建器镜像的工作目录中。

destinationDir 是相对路径时采用相同的规则；secret 将放置到相对于镜像工作目录的路径中。如果构建器镜像中不存在 destinationDir 路径中的最终目录，则会创建该目录。destinationDir 中的所有上述目录都必须存在，否则会发生错误。

采用 Docker 策略时，您可以使用 Dockerfile 中的 ADD 和 COPY 指令，将所有定义的输入 secret 添加到容器镜像中。

如果没有为 secret 指定 destinationDir，则文件将复制到 Dockerfile 所在的同一目录中。如果将一个相对路径指定为 destinationDir，则 secret 将复制到相对于 Dockerfile 所在位置的这个目录中。这样，secret 文件可供 Docker 构建操作使用，作为构建期间使用的上下文目录的一部分。

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"]

使用 Custom 策略时，所有定义的输入 secret 和 ConfigMap 都位于 /var/run/secrets/openshift.io/build 目录下的构建器容器内。自定义构建镜像负责适当地使用这些 secret 和 ConfigMap。Custom 策略也允许按照 Custom 策略选项中所述定义 secret。

现有策略 secret 与输入 secret 之间没有技术差异。但是，构建器镜像可以区分它们并以不同的方式加以使用，具体取决于您的构建用例。

输入 secret 始终挂载到 /var/run/secrets/openshift.io/build 目录中，或您的构建器可以解析 $BUILD 环境变量（包含完整构建对象）。

您可以注入构建对象的信息，使用 fieldPath 环境变量源指定要获取值的字段的 JsonPath。

您可以使用 valueFrom 语法，将 secret 的键值作为环境变量提供。

主要属性包括：

type 字段中的值指明 secret 的键名称和值的结构。此类型可用于强制使 secret 对象中存在用户名和密钥。如果您不想进行验证，请使用 opaque 类型，这也是默认类型。

指定以下一种类型来触发最小服务器端验证，确保 secret 数据中存在特定的键名称：

如果不想进行验证，设置 type= Opaque。这意味着，secret 不声明符合键名称或值的任何约定。opaque secret 允许使用无结构 key:value 对，可以包含任意值。

当修改 secret 的值时，已在被运行的 Pod 使用的 secret 值不会被动态更新。若要更改 secret，需要删除原始 Pod 并创建一个新 Pod（可能具有相同的 PodSpec）。

更新 secret 遵循与部署新容器镜像相同的工作流。您可以使用 kubectl rolling-update 命令。

secret 中的 resourceVersion 值不在引用时指定。因此，如果在 pod 启动的同时更新 secret，则将不能定义用于 pod 的 secret 版本。

您必须先创建 secret，然后创建依赖于此 secret 的 Pod。

在创建 secret 时：

您可以将 Dockerfile 中的 FROM 指令替换为 BuildConfig 中的 from。如果 Dockerfile 使用多阶段构建，最后一个 FROM 指令中的镜像将被替换。

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

默认情况下，Docker 构建使用位于 BuildConfig.spec.source.contextDir 字段中指定的上下文的根目录的 Dockerfile（名为 Dockerfile）。

dockerfilePath 字段允许构建使用不同的路径来定位 Dockerfile，该路径相对于 BuildConfig.spec.source.contextDir 字段。它可以是不同于默认 Dockerfile 的其他文件名（如 MyDockerfile），或子目录中 Dockerfile 的路径（如 dockerfiles/app1/Dockerfile）。

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

要将环境变量提供给 Docker 构建过程和生成的镜像使用，您可以在 BuildConfig 的 dockerStrategy 定义中添加环境变量。

这里定义的环境变量作为单个 ENV Dockerfile 指令直接插入到 FROM 指令后，以便稍后可在 Dockerfile 内引用该变量。

例如，定义要在构建和运行时使用的自定义 HTTP 代理：

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

集群管理员还可以使用 Ansible 配置全局构建设置。

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

您可以使用 BuildArgs 数组来设置 Docker 构建参数。构建参数将在构建启动时传递给 Docker。

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

S2I 可以执行增量构建，也就是能够重复利用过去构建的镜像中的工件。

strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "incremental-image:latest" 1
    incremental: true 2

您可以覆盖构建器镜像提供的 assemble、run 和 save-artifacts S2I 脚本。

strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "builder-image:latest"
    scripts: "http://somehost.com/scripts_directory" 1

可以通过两种方式将环境变量提供给源构建过程和生成的镜像：环境文件和 BuildConfig 环境值。提供的变量将存在于构建过程和输出镜像中。

sourceStrategy:
...
  env:
    - name: "DISABLE_ASSET_COMPILATION"
      value: "true"

Source-to-Image 支持 .s2iignore 文件，该文件包含了需要被忽略的文件列表。构建工作目录中的文件（由各种输入源提供）若与 .s2iignore 文件中指定的文件匹配，将不会提供给 assemble 脚本使用。

如需有关 .s2iignore 文件格式的更多详细信息，请参阅 Source-to-Image 文档。

Source-to-Image (S2I) 是一种框架，它可以轻松地将应用程序源代码作为输入，生成可运行编译的应用程序的新镜像。

使用 S2I 构建可重复生成的容器镜像的主要优点是便于开发人员使用。作为构建器镜像作者，您必须理解两个基本概念，才能让您的镜像提供最佳的 S2I 性能：构建过程和 S2I 脚本。

5.2.5.1. 了解 S2I 构建过程

构建过程包含以下三个基本元素，这些元素组合成最终的容器镜像：

• 源代码
• S2I 脚本
• 构建器镜像

在构建过程中，S2I 必须将源代码和脚本放在构建器镜像中。为此，S2I 创建一个包含源和脚本的 tar 文件，然后将该文件流传输到构建器镜像中。在执行 assemble 脚本前，S2I 解压缩该文件并将其内容放到构建器镜像的 io.openshift.s2i.destination 标签中指定的位置，默认位置为 /tmp 目录。

为了使这个过程能够发生，您必须提供 tar 存档实用程序（可在 $PATH 中使用的 tar 命令）和命令行解释器（/bin/sh 命令）；这样，您的镜像能够使用最快捷的构建路径。如果 tar 或 /bin/sh 命令不可用，则强制 s2i build 过程自动执行额外容器构建，将源和脚本放进镜像中，然后才运行常规构建。

参见下图中的基本 S2I 构建工作流：

图 5.1. 构建工作流

运行构建的过程包括解压源代码、脚本和工件（若存在），并且调用 assemble 脚本。如果这是二次运行（在捕获了“未找到 tar 或 /bin/sh”错误后），它将仅负责调用 assemble 脚本，因为脚本和源代码都已就位。

#!/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

您可以使用 customStrategy.from 部分来指示要用于自定义构建的镜像。

strategy:
  customStrategy:
    from:
      kind: "DockerImage"
      name: "openshift/sti-image-builder"

除了可以添加到所有构建类型的源和镜像的 secret 之外，自定义策略还允许向构建器 Pod 添加任意 secret 列表。

strategy:
  customStrategy:
    secrets:
      - secretSource: 1
          name: "secret1"
        mountPath: "/tmp/secret1" 2
      - secretSource:
          name: "secret2"
        mountPath: "/tmp/secret2"

要将环境变量提供给 Custom 构建过程使用，可在 BuildConfig 的 customStrategy 定义中添加环境变量。

这里定义的环境变量将传递给运行自定义构建的 Pod。

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

集群管理员还可以使用 Ansible 配置全局构建设置。

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

OpenShift Container Platform 的 Custom 构建策略允许您定义负责整个构建过程的特定构建器镜像，旨在填补因创建容器镜像日益普及而造成的空缺。如果构建仍然需要生成各种工件（例如，软件包、JAR、WAR、可安装 ZIP 和基础镜像），采用 Custom 构建策略的自定义构建器镜像是填补这一空缺的理想选择。

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

此外，自定义构建器还允许实施任何扩展构建过程，例如运行单元或集成测试的 CI/CD 流。

要充分利用 Custom 构建策略的优势，您必须了解如何创建能够构建所需对象的自定义构建器镜像。

通过管道（pipeline），您可以控制在 OpenShift Container Platform 上构建、部署和推进您的应用程序。通过结合使用 Jenkins Pipeline 构建策略、Jenkinsfile 和 OpenShift Container Platform 域特定语言 (DSL)（由 Jenkins 客户端插件提供），您可以为任何场景创建高级构建、测试、部署和推进管道。

OpenShift Container Platform Jenkins 同步插件

OpenShift Container Platform Jenkins 同步插件使 BuildConfig 和 Build 对象与 Jenkins 任务和构建保持同步，并提供以下功能：

OpenShift Container Platform Jenkins 客户端插件

OpenShift Container Platform Jenkins 客户端插件是一种 Jenkins 插件，旨在提供易读、简洁、全面且流畅的 Jenkins Pipeline 语法，以便与 OpenShift Container Platform API 服务器进行丰富的交互。该插件利用了 OpenShift 命令行工具 (oc)，此工具必须在执行脚本的节点上可用。

Jenkins 客户端插件必须安装到 Jenkins master上，这样才能在您的应用程序的 JenkinsFile 中使用 OpenShift Container Platform DSL。使用 OpenShift Container Platform Jenkins 镜像时，默认安装并启用此插件。

对于项目中的 OpenShift Container Platform 管道，必须使用 Jenkins Pipeline 构建策略。此策略默认使用源存储库根目录下的 jenkinsfile，但也提供以下配置选项：

jenkinsfile 使用标准的 Groovy 语言语法，允许对应用程序的配置、构建和部署进行精细控制。

您可以通过以下一种方式提供 jenkinsfile：

使用第一个选项时，jenkinsfile 必须包含在以下位置之一的应用程序源代码存储库中：

jenkinsfile 在 Jenkins slave Pod 上执行，如果您打算使用 OpenShift DSL，它必须具有 OpenShift Client 二进制文件。

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

要将环境变量提供给 Pipeline 构建过程使用，您可以在 BuildConfig 的 jenkinsPipelineStrategy 定义中添加环境变量。

定义之后，环境变量将设置为与 BuildConfig 关联的任何 Jenkins 任务的参数。

jenkinsPipelineStrategy:
...
  env:
    - name: "FOO"
      value: "BAR"

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

本例演示如何创建 OpenShift Pipeline，以使用 nodejs-mongodb.json 模板构建、部署和验证 Node.js/MongoDB 应用程序。

您可以使用 --from-build 标志，手动重新运行构建。

$ oc start-build --from-build=<build_name>

您可以指定 --follow 标志，在标准输出中流传输构建日志。

$ oc start-build <buildconfig_name> --follow

您可以指定 --env 标志，为构建设置任何所需的环境变量。

$ oc start-build <buildconfig_name> --env=<key>=<value>

您可以通过直接推送源来启动构建，而不依赖于 Git 源拉取或构建的 Dockerfile；源可以是 Git 或 SVN 工作目录的内容、您想要部署的一组预构建二进制工件，或者单个文件。这可以通过为 start-build 命令指定以下选项之一来完成：

将任何这些选项直接传递给构建时，内容将流传输到构建中并覆盖当前的构建源设置。

$ oc start-build hello-world --from-repo=../hello-world --commit=v2

您可以使用以下 CLI 命令取消多个构建。

$ oc cancel-build <build1_name> <build2_name> <build3_name>

您可以使用以下 CLI 命令取消构建配置中的所有构建。

$ oc cancel-build bc/<buildconfig_name>

您可以取消给定状态下的所有构建（例如 new 或 pending 状态），并忽略其他状态下的构建。

$ oc cancel-build bc/<buildconfig_name>

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

$ oc logs -f bc/<buildconfig_name>

您可以使用 Web 控制台或 CLI 访问 BuildConfig 的给定版本构建的日志。

$ oc logs --version=<number> bc/<buildconfig_name>

您可以传递 BUILD_LOGLEVEL 环境变量作为 BuildConfig 中 sourceStrategy 或 dockerStrategy 的一部分，来实现更为详细的输出。

Source 构建的可用日志级别如下：

sourceStrategy:
...
  env:
    - name: "BUILD_LOGLEVEL"
      value: "2" 1

Webhook 触发器通过发送请求到 OpenShift Container Platform API 端点来触发新构建。您可以使用 GitHub、GitLab、Bitbucket 或通用 Webhook 来定义这些触发器。

目前，OpenShift Container Platform Webhook 仅支持各种基于 Git 的源代码管理系统 (SCM) 的推送事件的类同版本。所有其他事件类型都会忽略。

处理推送事件时，OpenShift Container Platform master 主机确认事件内的分支引用是否与相应 BuildConfig 中的分支引用匹配。如果匹配，它会检查 OpenShift Container Platform 构建的 Webhook 事件中记录的确切提交引用。如果不匹配，则不触发构建。

对于所有 Webhook，您必须使用名为 WebHookSecretKey 的键定义 Secret，并且其值是调用 Webhook 时要提供的值。然后，Webhook 定义必须引用该 secret。secret可确保 URL 的唯一性，防止他人触发构建。键的值将与 Webhook 调用期间提供的 secret 进行比较。

例如，此处的 GitHub Webhook 具有对名为 mysecret 的 secret 的引用：

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

该 secret 的定义如下。注意 secret 的值采用 base64 编码，如 Secret 对象的 data 字段所要求。

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

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

https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

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

https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

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

https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

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

$ oc describe bc <name>

通过镜像更改触发器，您可以在上游镜像有新版本可用时自动调用构建。例如，如果构建以 RHEL 镜像为基础，那么您可以触发该构建在 RHEL 镜像更改时运行。因此，应用程序镜像始终在最新的 RHEL 基础镜像上运行。

将镜像更改触发器用于策略镜像流时，生成的构建会获得一个不可变 Docker 标签，指向与该标签对应的最新镜像。在执行构建时，策略将使用此新镜像引用。

对于不引用策略镜像流的其他镜像更改触发器，系统会启动新构建，但不会使用唯一镜像引用来更新构建策略。

由于此示例具有策略的镜像更改触发器，因此生成的构建将是：

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

这将确保触发的构建使用刚才推送到存储库的新镜像，并且可以使用相同的输入随时重新运行构建。

您可以暂停镜像更改触发器，以便在构建开始之前对引用的镜像流进行多次更改。在将 ImageChangeTrigger 添加到 BuildConfig 时，您也可以将 paused 属性设为 true，以避免立即触发构建。

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

除了设置适用于所有 Strategy 类型的镜像字段外，自定义构建还需要检查 OPENSHIFT_CUSTOM_BUILD_BASE_IMAGE 环境变量。如果不存在，则使用不可变镜像引用来创建它。如果存在，则使用不可变镜像引用进行更新。

如果因为 Webhook 触发器或手动请求而触发构建，则创建的构建将使用从 Strategy 引用的 ImageStream 解析而来的 <immutableid>。这将确保使用一致的镜像标签来执行构建，以方便再生。

通过配置更改触发器，您可以在创建新 BuildConfig 时立即自动调用构建。

如下是 BuildConfig 中的示例触发器定义 YAML：

  type: "ConfigChange"

配置提交后构建 hook 的方法有多种。以下示例中所有形式具有同等作用，也都执行 bundle exec rake test --verbose。

oc set build-hook 命令可用于为构建配置设置构建 hook。

使用 Subscription Manager 安装内容的构建必须为订阅的存储库提供适当的配置文件和证书颁发机构。

Docker 策略构建可以使用 Subscription Manager 来安装订阅内容。

FROM registry.redhat.io/rhel7:latest
USER root
# Copy entitlements
COPY ./etc-pki-entitlement /etc/pki/entitlement
# Copy subscription manager configurations
COPY ./rhsm-conf /etc/rhsm
COPY ./rhsm-ca /etc/rhsm/ca
# Delete /etc/rhsm-host to use entitlements from the build container
RUN rm /etc/rhsm-host && \
    # Initialize /etc/yum.repos.d/redhat.repo
    # See https://access.redhat.com/solutions/1443553
    yum repolist --disablerepo=* && \
    subscription-manager repos --enable <enabled-repo> && \
    yum -y update && \
    yum -y install <rpms> && \
    # Remove entitlements and Subscription Manager configs
    rm -rf /etc/pki/entitlement && \
    rm -rf /etc/rhsm
# OpenShift requires images to run as non-root by default
USER 1001
ENTRYPOINT ["/bin/bash"]

使用 Satellite 安装内容的构建必须提供适当的配置，以从 Satellite 存储库获取内容。

Docker 策略构建可以使用 Satellite 存储库来安装订阅内容。

FROM registry.redhat.io/rhel7:latest
USER root
# Copy entitlements
COPY ./etc-pki-entitlement /etc/pki/entitlement
# Copy repository configuration
COPY ./yum.repos.d /etc/yum.repos.d
# Delete /etc/rhsm-host to use entitlements from the build container
RUN rm /etc/rhsm-host && \
    # yum repository info provided by Satellite
    yum -y update && \
    yum -y install <rpms> && \
    # Remove entitlements
    rm -rf /etc/pki/entitlement
# OpenShift requires images to run as non-root by default
USER 1001
ENTRYPOINT ["/bin/bash"]

您可以从目录中创建 ConfigMap。此方法允许您使用目录中的多个文件来创建 ConfigMap。

您可以从文件创建 ConfigMap。

您可以多次将 --from-file 选项传递给 CLI。以下示例生成与从目录创建示例相同的结果。

您可以为从文件中导入的内容在 ConfigMap 中指定要设置的键。这可以通过向 --from-file 选项传递 key=value 表达式来设置。例如：

您可以为 ConfigMap 提供字面值。

ConfigMap 可用于在容器中填充各个环境变量或从构成有效环境变量名称的所有键填充容器中的环境变量。

例如,请考虑以下 ConfigMa:

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config 1
  namespace: default 2
data:
  special.how: very 3
  special.type: charm 4

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config 1
  namespace: default
data:
  log_level: INFO 2

ConfigMap 还可用于设置容器中的命令或参数的值。这可以通过 Kubernetes 替换语法 $(VAR_NAME) 来实现。考虑以下 ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

您可以使用 ConfigMap 将内容注入卷。

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm