使用构建策略 - 使用 BuildConfig 进行构建 | CI/CD | OpenShift 容器平台 4.17

Docker 构建

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

如果使用buildArgs数组设置 Docker 构建参数，请参阅 Dockerfile 参考文档中的了解 ARG 和 FROM 如何交互。

替换 Dockerfile FROM 镜像

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

步骤

要将 Dockerfile 的FROM指令替换为BuildConfig对象的from参数，请将以下设置添加到BuildConfig对象

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

使用 Dockerfile 路径

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

dockerfilePath字段允许构建使用不同的路径来查找 Dockerfile，相对于BuildConfig.spec.source.contextDir字段。它可以与默认的 Dockerfile 不同的文件名，例如MyDockerfile，或者子目录中 Dockerfile 的路径，例如dockerfiles/app1/Dockerfile。

步骤

设置构建的dockerfilePath字段以使用不同的路径来查找 Dockerfile

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

使用 docker 环境变量

要使环境变量可用于 docker 构建过程和生成的镜像，您可以将环境变量添加到构建配置的dockerStrategy定义中。

此处定义的环境变量会作为单个的ENV Dockerfile 指令插入到FROM指令之后，以便之后在Dockerfile中引用。

这些变量在构建期间定义，并保留在输出镜像中，因此它们也会出现在运行该镜像的任何容器中。

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

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

您还可以使用oc set env命令管理构建配置中定义的环境变量。

添加Docker构建参数

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

请参阅Dockerfile参考文档中的了解ARG和FROM如何交互。

步骤

要设置Docker构建参数，请向BuildConfig对象的dockerStrategy定义中的buildArgs数组添加条目，例如
```
dockerStrategy:
...
  buildArgs:
    - name: "version"
      value: "latest"
```
仅支持name和value字段。valueFrom字段上的任何设置都会被忽略。

使用Docker构建压缩层

Docker构建通常会为Dockerfile中的每个指令创建一个层。将imageOptimizationPolicy设置为SkipLayers会将所有指令合并到基础镜像顶部的单个层中。

步骤

将imageOptimizationPolicy设置为SkipLayers

strategy:
  dockerStrategy:
    imageOptimizationPolicy: SkipLayers

使用构建卷

您可以挂载构建卷，以便运行的构建可以访问您不希望保留在输出容器镜像中的信息。

构建卷提供敏感信息，例如存储库凭据，构建环境或配置仅在构建时需要这些信息。构建卷不同于构建输入，构建输入的数据可以保留在输出容器镜像中。

构建卷的挂载点（运行的构建从中读取数据）在功能上类似于Pod卷挂载。

先决条件

您已将输入密钥、配置映射或两者都添加到BuildConfig对象。

步骤

在BuildConfig对象的dockerStrategy定义中，将任何构建卷添加到volumes数组中，例如

spec:
  dockerStrategy:
    volumes:
      - name: secret-mvn (1)
        mounts:
        - destinationPath: /opt/app-root/src/.ssh (2)
        source:
          type: Secret (3)
          secret:
            secretName: my-secret (4)
      - name: settings-mvn (1)
        mounts:
        - destinationPath: /opt/app-root/src/.m2  (2)
        source:
          type: ConfigMap (3)
          configMap:
            name: my-config (4)
      - name: my-csi-volume (1)
        mounts:
        - destinationPath: /opt/app-root/src/some_path (2)
        source:
          type: CSI (3)
          csi:
            driver: csi.sharedresource.openshift.io (5)
            readOnly: true (6)
            volumeAttributes: (7)
              attribute: value

1	必需。唯一的名称。
2	必需。挂载点的绝对路径。它不能包含`..`或`:`，并且不会与构建器生成的目的地路径冲突。`/opt/app-root/src`是许多Red Hat S2I启用镜像的默认主目录。
3	必需。源的类型，`ConfigMap`、`Secret`或`CSI`。
4	必需。源的名称。
5	必需。提供临时CSI卷的驱动程序。
6	必需。此值必须设置为`true`。提供只读卷。
7	可选。临时CSI卷的卷属性。请参阅CSI驱动程序的文档以了解支持的属性键和值。

共享资源CSI驱动程序仅为技术预览功能。技术预览功能不受Red Hat生产服务级别协议（SLA）的支持，并且可能功能不完整。Red Hat不建议在生产环境中使用它们。这些功能提供对即将推出的产品功能的早期访问，使客户能够在开发过程中测试功能并提供反馈。

有关Red Hat技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

其他资源

源到镜像构建

源到镜像 (S2I) 是一个用于构建可重复容器镜像的工具。它通过将应用程序源注入容器镜像并组装新的镜像来生成可立即运行的镜像。新镜像包含基础镜像、构建器和已构建的源，并可与buildah run命令一起使用。S2I支持增量构建，它可以重复使用以前下载的依赖项、以前构建的工件等等。

执行源到镜像增量构建

源到镜像 (S2I) 可以执行增量构建，这意味着它可以重复使用以前构建的镜像中的工件。

步骤

要创建增量构建，请使用以下对策略定义的修改来创建

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

1	指定支持增量构建的镜像。请参阅构建器镜像的文档以确定它是否支持此行为。
2	此标志控制是否尝试增量构建。如果构建器镜像不支持增量构建，构建仍会成功，但您会收到一条日志消息，说明由于缺少`save-artifacts`脚本而增量构建未成功。

其他资源

请参阅S2I要求，了解如何创建支持增量构建的构建器镜像。

覆盖源到镜像构建器镜像脚本

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

步骤

要覆盖构建器镜像提供的assemble、run和save-artifacts S2I脚本，请完成以下操作之一
- 在应用程序源存储库的.s2i/bin目录中提供assemble、run或save-artifacts脚本。
- 在BuildConfig对象中，提供包含脚本的目录的URL作为策略定义的一部分，例如
  strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "builder-image:latest" scripts: "http://somehost.com/scripts_directory" (1)
  1 构建过程将run、assemble和save-artifacts附加到路径。如果存在任何或所有具有这些名称的脚本，构建过程将使用这些脚本替换镜像中提供的同名脚本。
  
  位于scripts URL 的文件优先于位于源存储库.s2i/bin中的文件。

源到镜像环境变量

有两种方法可以使环境变量可用于源构建过程和生成的镜像：环境文件和BuildConfig环境值。使用任一方法提供的变量都将在构建过程和输出镜像中存在。

使用源到镜像环境文件

源构建使您能够在应用程序内部设置环境值（每行一个），方法是在源存储库中的.s2i/environment文件中指定它们。此文件中指定的环境变量在构建过程和输出镜像中都存在。

如果在源存储库中提供.s2i/environment文件，则源到镜像 (S2I) 将在构建期间读取此文件。这允许自定义构建行为，因为assemble脚本可能会使用这些变量。

步骤

例如，要在构建期间禁用 Rails 应用程序的资源编译

在.s2i/environment文件中添加DISABLE_ASSET_COMPILATION=true。

除了构建之外，指定的环境变量在运行中的应用程序本身中也可用。例如，要使 Rails 应用程序以development模式而不是production模式启动

在.s2i/environment文件中添加RAILS_ENV=development。

每个镜像的“使用镜像”部分提供了受支持的环境变量的完整列表。

使用 source-to-image 构建配置环境

您可以将环境变量添加到构建配置的sourceStrategy定义中。在那里定义的环境变量在assemble脚本执行期间可见，并将定义在输出镜像中，使其也可用作run脚本和应用程序代码。

步骤

例如，要禁用 Rails 应用程序的资源编译

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

其他资源

“构建环境”部分提供了更高级的说明。
您还可以使用oc set env命令管理构建配置中定义的环境变量。

忽略 source-to-image 源文件

Source-to-image (S2I) 支持一个.s2iignore文件，其中包含应忽略的文件模式列表。各种输入源提供的构建工作目录中的文件，如果与.s2iignore文件中找到的模式匹配，则不会提供给assemble脚本。

使用 source-to-image 从源代码创建镜像

Source-to-image (S2I) 是一个框架，它简化了编写镜像的过程，这些镜像将应用程序源代码作为输入，并生成一个运行已组装应用程序的新镜像作为输出。

使用 S2I 构建可重现容器镜像的主要优势在于开发人员易于使用。作为构建器镜像的作者，您必须了解两个基本概念才能使您的镜像提供最佳的 S2I 性能：构建过程和 S2I 脚本。

了解 source-to-image 构建过程

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

源代码
Source-to-image (S2I) 脚本
构建器镜像

S2I 使用构建器镜像作为第一个FROM指令生成一个 Dockerfile。然后将 S2I 生成的 Dockerfile 传递给 Buildah。

如何编写 source-to-image 脚本

您可以使用任何编程语言编写 source-to-image (S2I) 脚本，只要脚本在构建器镜像内可执行即可。S2I 支持多个选项，提供assemble/run/save-artifacts脚本。在每次构建中，都会按以下顺序检查所有这些位置

构建配置中指定的脚本。
在应用程序源代码.s2i/bin目录中找到的脚本。
在具有io.openshift.s2i.scripts-url标签的默认镜像 URL 中找到的脚本。

镜像中指定的io.openshift.s2i.scripts-url标签和构建配置中指定的脚本都可以采用以下形式之一

image:///path_to_scripts_dir：镜像内 S2I 脚本所在的目录的绝对路径。
file:///path_to_scripts_dir：主机上 S2I 脚本所在的目录的相对或绝对路径。
http(s)://path_to_scripts_dir：S2I 脚本所在的目录的 URL。

脚本描述

assemble

assemble脚本从源代码构建应用程序工件，并将它们放置到镜像内的相应目录中。此脚本是必需的。此脚本的工作流程为：

可选：恢复构建工件。如果您想支持增量构建，请确保也定义save-artifacts。
将应用程序源代码放置在所需位置。
构建应用程序工件。
将工件安装到适合它们运行的位置。

run

run脚本执行您的应用程序。此脚本是必需的。

save-artifacts

save-artifacts脚本收集所有可以加快后续构建过程的依赖项。此脚本是可选的。例如：

对于 Ruby，由 Bundler 安装的gems。
对于 Java，.m2 内容。

这些依赖项被收集到一个tar文件中，并流式传输到标准输出。

usage

usage脚本允许您告知用户如何正确使用您的镜像。此脚本是可选的。

test/run

test/run脚本允许您创建一个进程来检查镜像是否正常工作。此脚本是可选的。该进程的建议流程是：

构建镜像。
运行镜像以验证usage脚本。
运行s2i build以验证assemble脚本。
可选：再次运行s2i build以验证save-artifacts和assemble脚本的保存和恢复工件功能。
运行镜像以验证测试应用程序是否正常工作。

建议将test/run脚本构建的测试应用程序放在镜像存储库中的test/test-app目录中。

S2I 脚本示例

以下 S2I 脚本示例是用 Bash 编写的。每个示例都假设其tar内容已解压到/tmp/s2i目录中。

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

run脚本

#!/bin/bash

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

save-artifacts脚本

#!/bin/bash

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

usage脚本

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

其他资源

S2I 镜像创建教程

使用构建卷

您可以挂载构建卷，以便运行的构建可以访问您不希望保留在输出容器镜像中的信息。

构建卷的挂载点（运行的构建从中读取数据）在功能上类似于Pod卷挂载。

先决条件

您已将输入密钥、配置映射或两者都添加到BuildConfig对象。

步骤

在BuildConfig对象的sourceStrategy定义中，将任何构建卷添加到volumes数组中。例如

spec:
  sourceStrategy:
    volumes:
      - name: secret-mvn (1)
        mounts:
        - destinationPath: /opt/app-root/src/.ssh (2)
        source:
          type: Secret (3)
          secret:
            secretName: my-secret (4)
      - name: settings-mvn (1)
        mounts:
        - destinationPath: /opt/app-root/src/.m2 (2)
        source:
          type: ConfigMap (3)
          configMap:
            name: my-config (4)
      - name: my-csi-volume (1)
        mounts:
        - destinationPath: /opt/app-root/src/some_path (2)
        source:
          type: CSI (3)
          csi:
            driver: csi.sharedresource.openshift.io (5)
            readOnly: true (6)
            volumeAttributes: (7)
              attribute: value

1	必需。唯一的名称。
2	必需。挂载点的绝对路径。它不能包含`..`或`:`，并且不会与构建器生成的目的地路径冲突。`/opt/app-root/src`是许多Red Hat S2I启用镜像的默认主目录。
3	必需。源的类型，`ConfigMap`、`Secret`或`CSI`。
4	必需。源的名称。
5	必需。提供临时CSI卷的驱动程序。
6	必需。此值必须设置为`true`。提供只读卷。
7	可选。临时CSI卷的卷属性。请参阅CSI驱动程序的文档以了解支持的属性键和值。

有关Red Hat技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

其他资源

自定义构建

自定义构建策略允许开发人员定义一个负责整个构建过程的特定构建器镜像。使用您自己的构建器镜像允许您自定义构建过程。

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

自定义构建以高权限运行，默认情况下用户无法使用。只有可以信任具有集群管理权限的用户才能被授予运行自定义构建的权限。

为自定义构建使用 FROM 镜像

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

步骤

设置customStrategy.from部分

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

在自定义构建中使用密钥

除了可以添加到所有构建类型的源代码和镜像的密钥之外，自定义策略还允许将任意密钥列表添加到构建器 pod。

步骤

要在特定位置挂载每个密钥，请编辑strategy YAML 文件的secretSource和mountPath字段

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

1	`secretSource`是对与构建相同的命名空间中的密钥的引用。
2	`mountPath`是应挂载密钥的自定义构建器内的路径。

在自定义构建中使用环境变量

要使环境变量可用于自定义构建过程，您可以将环境变量添加到构建配置的customStrategy定义中。

在那里定义的环境变量将传递到运行自定义构建的Pod。

步骤

定义在构建期间使用的自定义HTTP代理

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

要管理构建配置中定义的环境变量，请输入以下命令
```
$ oc set env <enter_variables>
```

使用自定义构建器镜像

OpenShift Container Platform 的自定义构建策略使您可以定义负责整个构建过程的特定构建器镜像。当您需要构建生成单个工件（例如包、JAR、WAR、可安装 ZIP 或基础镜像）时，请使用自定义构建策略使用自定义构建器镜像。

自定义构建器镜像是一个嵌入构建过程逻辑的普通容器镜像，用于构建 RPM 或基础容器镜像等工件。

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

自定义构建器镜像

调用时，自定义构建器镜像会接收以下环境变量，其中包含继续构建所需的信息

表 2. 自定义构建器环境变量
变量名称	描述
`BUILD`	`Build` 对象定义的整个序列化 JSON。如果您必须使用特定 API 版本进行序列化，则可以在构建配置的自定义策略规范中设置`buildAPIVersion`参数。
`SOURCE_REPOSITORY`	包含要构建的源代码的 Git 存储库的 URL。
`SOURCE_URI`	使用与`SOURCE_REPOSITORY`相同的值。两者都可以使用。
`SOURCE_CONTEXT_DIR`	指定构建时要使用的 Git 存储库的子目录。仅在定义时存在。
`SOURCE_REF`	要构建的 Git 引用。
`ORIGIN_VERSION`	创建此构建对象的 OpenShift Container Platform 主版本的版本。
`OUTPUT_REGISTRY`	要将镜像推送到其中的容器镜像注册表。
`OUTPUT_IMAGE`	正在构建的镜像的容器镜像标签名称。
`PUSH_DOCKERCFG_PATH`	运行`podman push`操作的容器注册表凭据的路径。

自定义构建器工作流程

虽然自定义构建器镜像作者在定义构建过程中具有灵活性，但您的构建器镜像必须遵守在 OpenShift Container Platform 内运行构建所需的以下步骤

Build 对象定义包含有关构建输入参数的所有必要信息。
运行构建过程。
如果您的构建生成镜像，如果已定义，则将其推送到构建的输出位置。其他输出位置可以通过环境变量传递。

流水线构建

流水线构建策略在 OpenShift Container Platform 4 中已弃用。OpenShift Container Platform Pipelines（基于 Tekton）中提供了等效且改进的功能。

OpenShift Container Platform 上的 Jenkins 镜像完全受支持，用户应遵循 Jenkins 用户文档在作业中定义其jenkinsfile或将其存储在源代码管理系统中。

流水线构建策略允许开发人员定义 Jenkins 流水线以供 Jenkins 流水线插件使用。构建可以像任何其他构建类型一样由 OpenShift Container Platform 启动、监控和管理。

流水线工作流程在jenkinsfile中定义，可以直接嵌入到构建配置中，也可以在 Git 存储库中提供并由构建配置引用。

了解 OpenShift Container Platform 流水线

流水线构建策略在 OpenShift Container Platform 4 中已弃用。OpenShift Container Platform Pipelines（基于 Tekton）中提供了等效且改进的功能。

OpenShift Container Platform 上的 Jenkins 镜像完全受支持，用户应遵循 Jenkins 用户文档在作业中定义其jenkinsfile或将其存储在源代码管理系统中。

流水线使您可以控制在 OpenShift Container Platform 上构建、部署和推广应用程序。通过结合使用 Jenkins 流水线构建策略、jenkinsfiles和 Jenkins 客户端插件提供的 OpenShift Container Platform 领域特定语言 (DSL)，您可以为任何场景创建高级构建、测试、部署和推广流水线。

OpenShift Container Platform Jenkins 同步插件

OpenShift Container Platform Jenkins 同步插件使构建配置和构建对象与 Jenkins 作业和构建保持同步，并提供以下功能：

在 Jenkins 中动态创建作业和运行。
从镜像流、镜像流标签或配置映射动态创建代理 Pod 模板。
注入环境变量。
在 OpenShift Container Platform Web 控制台中可视化流水线。
与 Jenkins Git 插件集成，该插件将提交信息从 OpenShift Container Platform 构建传递到 Jenkins Git 插件。
将密钥同步到 Jenkins 凭据条目。

OpenShift Container Platform Jenkins 客户端插件

OpenShift Container Platform Jenkins 客户端插件是一个 Jenkins 插件，旨在为与 OpenShift Container Platform API 服务器进行丰富的交互提供可读、简洁、全面和流畅的 Jenkins 流水线语法。该插件使用 OpenShift Container Platform 命令行工具oc，该工具必须在执行脚本的节点上可用。

必须在您的 Jenkins master 上安装 Jenkins 客户端插件，以便 OpenShift Container Platform DSL 可用于应用程序的jenkinsfile中。使用 OpenShift Container Platform Jenkins 镜像时，默认情况下会安装和启用此插件。

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

构建配置中的内联jenkinsfile字段。
构建配置中的jenkinsfilePath字段，该字段引用相对于源contextDir要使用的jenkinsfile的位置。

可选的jenkinsfilePath字段指定要使用的文件名，相对于源contextDir。如果省略contextDir，则默认为存储库的根目录。如果省略jenkinsfilePath，则默认为jenkinsfile。

提供流水线构建的 Jenkins 文件

流水线构建策略在 OpenShift Container Platform 4 中已弃用。OpenShift Container Platform Pipelines（基于 Tekton）中提供了等效且改进的功能。

OpenShift Container Platform 上的 Jenkins 镜像完全受支持，用户应遵循 Jenkins 用户文档在作业中定义其jenkinsfile或将其存储在源代码管理系统中。

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

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

位于源代码存储库中的文件。
使用jenkinsfile字段嵌入到构建配置中。

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

存储库根目录中名为jenkinsfile的文件。
存储库的源contextDir根目录中名为jenkinsfile的文件。
通过构建配置的JenkinsPipelineStrategy部分的jenkinsfilePath字段指定的文件名，该字段相对于源contextDir（如果已提供），否则默认为存储库的根目录。

jenkinsfile在 Jenkins 代理 Pod 上运行，如果要使用 OpenShift Container Platform DSL，则必须提供 OpenShift Container Platform 客户端二进制文件。

步骤

要提供 Jenkins 文件，您可以：

将 Jenkins 文件嵌入到构建配置中。
在构建配置中包含对包含 Jenkins 文件的 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')
        }

对 Git 存储库的引用

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)

1	可选的`jenkinsfilePath`字段指定要使用的文件名，相对于源`contextDir`。如果省略`contextDir`，则默认为存储库的根目录。如果省略`jenkinsfilePath`，则默认为`jenkinsfile`。

为流水线构建使用环境变量

流水线构建策略在 OpenShift Container Platform 4 中已弃用。OpenShift Container Platform Pipelines（基于 Tekton）中提供了等效且改进的功能。

OpenShift Container Platform 上的 Jenkins 镜像完全受支持，用户应遵循 Jenkins 用户文档在作业中定义其jenkinsfile或将其存储在源代码管理系统中。

要使环境变量可用于流水线构建过程，您可以将环境变量添加到构建配置的jenkinsPipelineStrategy定义中。

定义环境变量后，这些变量将被设置为与构建配置关联的任何 Jenkins 作业的参数。

步骤

要定义构建期间使用的环境变量，请编辑 YAML 文件

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

您还可以使用oc set env命令管理构建配置中定义的环境变量。

BuildConfig 环境变量与 Jenkins 作业参数之间的映射

根据 Pipeline 策略构建配置的更改创建或更新 Jenkins 作业时，构建配置中的任何环境变量都将映射到 Jenkins 作业参数定义，其中 Jenkins 作业参数定义的默认值是关联环境变量的当前值。

Jenkins 作业初始创建后，您仍然可以从 Jenkins 控制台向作业添加其他参数。参数名称与构建配置中环境变量的名称不同。在为这些 Jenkins 作业启动构建时，将考虑这些参数。

启动 Jenkins 作业构建的方式决定了参数的设置方式。

如果使用 oc start-build 启动，则构建配置中环境变量的值将作为相应作业实例设置的参数。您从 Jenkins 控制台对参数默认值所做的任何更改都将被忽略。构建配置值优先。
如果使用 oc start-build -e 启动，则 -e 选项中指定的环境变量的值将优先。
- 如果指定了构建配置中未列出的环境变量，则将其添加为 Jenkins 作业参数定义。
- 您从 Jenkins 控制台对对应于环境变量的参数所做的任何更改都将被忽略。构建配置以及使用 oc start-build -e 指定的内容优先。
如果使用 Jenkins 控制台启动 Jenkins 作业，则可以在 Jenkins 控制台中控制参数的设置，作为启动作业构建的一部分。

建议在构建配置中指定所有可能与作业参数关联的环境变量。这样做可以减少磁盘 I/O 并提高 Jenkins 处理期间的性能。

Pipeline 构建教程

流水线构建策略在 OpenShift Container Platform 4 中已弃用。OpenShift Container Platform Pipelines（基于 Tekton）中提供了等效且改进的功能。

OpenShift Container Platform 上的 Jenkins 镜像完全受支持，用户应遵循 Jenkins 用户文档在作业中定义其jenkinsfile或将其存储在源代码管理系统中。

此示例演示如何创建一个 OpenShift Container Platform Pipeline，该 Pipeline 将使用 nodejs-mongodb.json 模板构建、部署和验证 Node.js/MongoDB 应用程序。

步骤

创建 Jenkins 主节点
```
  $ oc project <project_name>
```
选择要使用的项目，或使用 oc new-project <project_name> 创建一个新项目。
```
  $ oc new-app jenkins-ephemeral (2)
```
如果要使用持久性存储，请使用 jenkins-persistent 代替。

创建一个名为 nodejs-sample-pipeline.yaml 的文件，内容如下：

这将创建一个 BuildConfig 对象，该对象采用 Jenkins pipeline 策略来构建、部署和扩展 Node.js/MongoDB 示例应用程序。

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "nodejs-sample-pipeline"
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: <pipeline content from below>
    type: JenkinsPipeline

使用 jenkinsPipelineStrategy 创建 BuildConfig 对象后，请使用内联 jenkinsfile 来告诉 pipeline 执行什么操作。

此示例未为应用程序设置 Git 存储库。

以下 jenkinsfile 内容使用 Groovy 和 OpenShift Container Platform DSL 编写。对于此示例，请在 BuildConfig 对象中使用 YAML 文字样式包含内联内容，尽管在源存储库中包含 jenkinsfile 是首选方法。

def templatePath = 'https://raw.githubusercontent.com/openshift/nodejs-ex/master/openshift/templates/nodejs-mongodb.json' (1)
def templateName = 'nodejs-mongodb-example' (2)
pipeline {
  agent {
    node {
      label 'nodejs' (3)
    }
  }
  options {
    timeout(time: 20, unit: 'MINUTES') (4)
  }
  stages {
    stage('preamble') {
        steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                        echo "Using project: ${openshift.project()}"
                    }
                }
            }
        }
    }
    stage('cleanup') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.selector("all", [ template : templateName ]).delete() (5)
                  if (openshift.selector("secrets", templateName).exists()) { (6)
                    openshift.selector("secrets", templateName).delete()
                  }
                }
            }
        }
      }
    }
    stage('create') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.newApp(templatePath) (7)
                }
            }
        }
      }
    }
    stage('build') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  def builds = openshift.selector("bc", templateName).related('builds')
                  timeout(5) { (8)
                    builds.untilEach(1) {
                      return (it.object().status.phase == "Complete")
                    }
                  }
                }
            }
        }
      }
    }
    stage('deploy') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  def rm = openshift.selector("dc", templateName).rollout()
                  timeout(5) { (9)
                    openshift.selector("dc", templateName).related('pods').untilEach(1) {
                      return (it.object().status.phase == "Running")
                    }
                  }
                }
            }
        }
      }
    }
    stage('tag') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.tag("${templateName}:latest", "${templateName}-staging:latest") (10)
                }
            }
        }
      }
    }
  }
}

1	要使用的模板的路径。
2	将创建的模板的名称。
3	启动一个 `node.js` agent pod，在此 pod 上运行此构建。
4	为此 pipeline 设置 20 分钟的超时时间。
5	删除所有带有此模板标签的内容。
6	删除所有带有此模板标签的密钥。
7	根据 `templatePath` 创建一个新的应用程序。
8	最多等待五分钟，直到构建完成。
9	最多等待五分钟，直到部署完成。
10	如果其他所有操作都成功，则将 `$ {templateName}:latest` 镜像标记为 `$ {templateName}-staging:latest`。预发布环境的 pipeline 构建配置可以监视 `$ {templateName}-staging:latest` 镜像的变化，然后将其部署到预发布环境。

前面的示例使用声明式 pipeline 样式编写，但也支持较旧的脚本化 pipeline 样式。

在 OpenShift Container Platform 集群中创建 Pipeline BuildConfig
```
$ oc create -f nodejs-sample-pipeline.yaml
```
1. 如果您不想创建自己的文件，则可以通过运行以下命令使用 Origin 存储库中的示例：
  $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml

启动 Pipeline

$ oc start-build nodejs-sample-pipeline

或者，您可以通过 OpenShift Container Platform Web 控制台启动 pipeline，方法是导航到“构建”→“Pipeline”部分并单击“启动 Pipeline”，或者访问 Jenkins 控制台，导航到您创建的 Pipeline 并单击“立即构建”。

启动 pipeline 后，您应该会看到项目中执行了以下操作：

在 Jenkins 服务器上创建了一个作业实例。
如果您的 pipeline 需要，则会启动一个 agent pod。
pipeline 在 agent pod 或主节点上运行（如果不需要 agent）。
- 将删除以前使用 template=nodejs-mongodb-example 标签创建的任何资源。
- 将根据 nodejs-mongodb-example 模板创建一个新的应用程序及其所有关联资源。
- 将使用 nodejs-mongodb-example BuildConfig 启动构建。
  - pipeline 将等待构建完成，然后触发下一阶段。
- 将使用 nodejs-mongodb-example 部署配置启动部署。
  - pipeline 将等待部署完成，然后触发下一阶段。
- 如果构建和部署成功，则 nodejs-mongodb-example:latest 镜像将被标记为 nodejs-mongodb-example:stage。

如果 pipeline 需要 agent pod，则会将其删除。

可视化 pipeline 执行的最佳方法是在 OpenShift Container Platform Web 控制台中查看它。您可以通过登录 Web 控制台并导航到“构建”→“Pipelines”来查看您的 pipelines。

使用 Web 控制台添加密钥

您可以向构建配置添加密钥，以便它可以访问私有存储库。

步骤

要向构建配置添加密钥，以便它可以从 OpenShift Container Platform Web 控制台访问私有源代码存储库：

创建一个新的 OpenShift Container Platform 项目。
创建一个包含访问私有源代码存储库的凭据的密钥。
创建一个构建配置。
在构建配置编辑器页面或 Web 控制台的“根据构建器镜像创建应用程序”页面上，设置“源密钥”。
单击“保存”。

启用拉取和推送

您可以通过在构建配置中设置拉取密钥来启用拉取到私有注册表，并通过设置推送密钥来启用推送。

步骤

要启用拉取到私有注册表：

在构建配置中设置拉取密钥。

要启用推送：

在构建配置中设置推送密钥。