使用构建策略 - 使用 BuildConfig 进行构建 | CI/CD | OpenShift Dedicated

Docker 构建

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

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

替换 Dockerfile FROM 镜像

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

步骤

要使用BuildConfig对象的from参数替换 Dockerfile 的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)

1	必需。唯一名称。
2	必需。挂载点的绝对路径。它不能包含`..`或`:`，并且不会与构建器生成的目的地路径冲突。`/opt/app-root/src`是许多启用 Red Hat S2I 的镜像的默认主目录。
3	必需。源的类型，`ConfigMap`、`Secret`或`CSI`。
4	必需。源的名称。

附加资源

Source-to-image 构建

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

执行 Source-to-image 增量构建

Source-to-image (S2I) 可以执行增量构建，这意味着它会重用先前构建的镜像中的工件。

步骤

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

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

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

附加资源

有关如何创建支持增量构建的构建器镜像的信息，请参阅 S2I 要求。

覆盖 Source-to-image 构建器镜像脚本

您可以覆盖构建器镜像提供的assemble、run和save-artifacts Source-to-image (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中的文件。

Source-to-image 环境变量

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

使用 Source-to-image 环境文件

源构建使您可以通过在源存储库中的.s2i/environment文件中指定环境值（每行一个）来设置环境值。此文件中指定的环境变量在构建过程中和输出镜像中都存在。

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

步骤

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

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

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

将RAILS_ENV=development添加到.s2i/environment文件。

支持的环境变量的完整列表可在每个镜像的“使用镜像”部分中找到。

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

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

步骤

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

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

附加资源

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

忽略源到镜像的源文件

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

使用源到镜像从源代码创建镜像

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

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

了解源到镜像构建过程

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

源代码
源到镜像 (S2I) 脚本
构建器镜像

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

如何编写源到镜像脚本

您可以使用任何编程语言编写源到镜像 (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)

1	必需。唯一名称。
2	必需。挂载点的绝对路径。它不能包含`..`或`:`，并且不会与构建器生成的目的地路径冲突。`/opt/app-root/src`是许多启用 Red Hat S2I 的镜像的默认主目录。
3	必需。源的类型，`ConfigMap`、`Secret`或`CSI`。
4	必需。源的名称。

附加资源

流水线构建

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

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

流水线构建策略允许开发人员定义 Jenkins 流水线供 Jenkins 流水线插件使用。构建可以以与任何其他构建类型相同的方式由 OpenShift Dedicated 启动、监控和管理。

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

了解 OpenShift Dedicated 流水线

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

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

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

OpenShift Dedicated Jenkins 同步插件

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

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

OpenShift Dedicated Jenkins 客户端插件

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

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

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

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

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

为流水线构建提供Jenkinsfile

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

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

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

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

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

当使用第一种方法时，jenkinsfile必须包含在您的应用程序源代码仓库的以下位置之一：

名为jenkinsfile的文件，位于仓库的根目录。
名为jenkinsfile的文件，位于仓库源contextDir的根目录。
通过BuildConfig的JenkinsPipelineStrategy部分的jenkinsfilePath字段指定的文件名，该文件名相对于源contextDir（如果已提供），否则默认为仓库的根目录。

jenkinsfile在Jenkins agent pod上运行，如果您打算使用OpenShift Dedicated DSL，则该pod必须具有可用的OpenShift Dedicated客户端二进制文件。

步骤

要提供Jenkinsfile，您可以：

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

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 Dedicated 4 中已弃用流水线构建策略。OpenShift Dedicated 基于 Tekton 的流水线中提供了等效且改进的功能。

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

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

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

步骤

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

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

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

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

根据流水线策略构建配置的更改创建或更新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处理过程的性能。

流水线构建教程

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

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

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

步骤

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

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

这将创建一个BuildConfig对象，该对象使用Jenkins流水线策略来构建、部署和扩展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告诉流水线要做什么。

此示例未设置应用程序的Git仓库。

以下jenkinsfile内容使用OpenShift Dedicated DSL以Groovy编写。对于此示例，请在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，在其上运行此构建。
4	为该流水线设置20分钟的超时时间。
5	删除具有此模板标签的所有内容。
6	删除具有此模板标签的任何密钥。
7	根据`templatePath`创建一个新的应用程序。
8	等待最多五分钟以完成构建。
9	等待最多五分钟以完成部署。
10	如果所有其他操作都成功，则将`$ {templateName}:latest`镜像标记为`$ {templateName}-staging:latest`。暂存环境的流水线构建配置可以监视`$ {templateName}-staging:latest`镜像的变化，然后将其部署到暂存环境。

前面的示例使用的是声明式流水线样式，但也支持较旧的脚本式流水线样式。

在OpenShift Dedicated集群中创建流水线BuildConfig

$ oc create -f nodejs-sample-pipeline.yaml

如果您不想创建自己的文件，您可以使用Origin仓库中的示例，方法是运行：

$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml

启动流水线

$ oc start-build nodejs-sample-pipeline

或者，您可以通过OpenShift Dedicated Web控制台启动流水线，方法是导航到“构建”→“流水线”部分，然后单击“启动流水线”，或者访问Jenkins控制台，导航到您创建的流水线，然后单击“立即构建”。

启动流水线后，您应该会看到在您的项目中执行以下操作：

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

可视化流水线执行的最佳方式是在 OpenShift Dedicated Web 控制台中查看。您可以登录 Web 控制台并导航到构建 → 流水线来查看您的流水线。

使用 Web 控制台添加密钥

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

步骤

要向构建配置添加密钥，以便它可以从 OpenShift Dedicated Web 控制台访问私有仓库

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

启用拉取和推送

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

步骤

要启用拉取到私有注册表

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

要启用推送

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