使用构建策略 - 使用 BuildConfig 进行构建 | CI/CD | Red Hat OpenShift Service on AWS

编辑

Docker 构建

Red Hat OpenShift Service on AWS 使用 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 构建参数，请向buildArgs数组添加条目，该数组位于BuildConfig对象的dockerStrategy定义中。例如
```
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命令管理在构建配置中定义的环境变量。

编辑

忽略 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目录中找到的脚本。
在默认镜像 URL（带有io.openshift.s2i.scripts-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脚本允许您告知用户如何正确使用您的镜像。此脚本是可选的。

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	必填。源的名称。

其他资源

编辑

流水线构建

在AWS上的Red Hat OpenShift服务4中已弃用Pipeline构建策略。AWS上的Red Hat OpenShift服务基于Tekton的流水线中提供了等效且改进的功能。

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

Pipeline构建策略允许开发人员定义Jenkins流水线供Jenkins流水线插件使用。AWS上的Red Hat OpenShift服务可以像任何其他构建类型一样启动、监控和管理构建。

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

编辑

了解AWS上的Red Hat OpenShift服务流水线

在AWS上的Red Hat OpenShift服务4中已弃用Pipeline构建策略。AWS上的Red Hat OpenShift服务基于Tekton的流水线中提供了等效且改进的功能。

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

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

AWS上的Red Hat OpenShift服务Jenkins同步插件

AWS上的Red Hat OpenShift服务Jenkins同步插件使构建配置和构建对象与Jenkins作业和构建保持同步，并提供以下功能：

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

AWS上的Red Hat OpenShift服务Jenkins客户端插件

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

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

对于项目中的AWS上的Red Hat OpenShift服务流水线，您必须使用Jenkins Pipeline构建策略。此策略默认使用源代码库根目录中的jenkinsfile，但也提供以下配置选项：

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

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

编辑

为流水线构建提供Jenkins文件

在AWS上的Red Hat OpenShift服务4中已弃用Pipeline构建策略。AWS上的Red Hat OpenShift服务基于Tekton的流水线中提供了等效且改进的功能。

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

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

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

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

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

存储库根目录下名为jenkinsfile的文件。
存储库源contextDir根目录下名为jenkinsfile的文件。
BuildConfig的JenkinsPipelineStrategy部分的jenkinsfilePath字段指定的文件名，如果提供了该字段，则相对于源contextDir，否则默认为存储库的根目录。

jenkinsfile在Jenkins代理pod上运行，如果要使用AWS上的Red Hat OpenShift服务DSL，则该pod必须具有可用的AWS上的Red Hat OpenShift服务客户端二进制文件。

步骤

要提供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`。

编辑

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

在AWS上的Red Hat OpenShift服务4中已弃用Pipeline构建策略。AWS上的Red Hat OpenShift服务基于Tekton的流水线中提供了等效且改进的功能。

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

要使环境变量可用于Pipeline构建过程，您可以将环境变量添加到构建配置的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处理性能。

编辑

流水线构建教程

在AWS上的Red Hat OpenShift服务4中已弃用Pipeline构建策略。AWS上的Red Hat OpenShift服务基于Tekton的流水线中提供了等效且改进的功能。

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

此示例演示如何创建在AWS上的Red Hat OpenShift服务流水线，该流水线将使用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流水线策略来构建、部署和扩展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内容使用Groovy和AWS上的Red Hat OpenShift服务DSL编写。在此示例中，使用YAML字面量样式在BuildConfig对象中包含内联内容，尽管在源代码存储库中包含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`镜像的变化，然后将其部署到暂存环境。

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

在您的AWS上的Red Hat OpenShift服务集群中创建流水线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

启动流水线

$ oc start-build nodejs-sample-pipeline

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

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

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

如果流水线需要agent pod，则会删除它。

可视化流水线执行的最佳方法是通过AWS上的Red Hat OpenShift服务Web控制台查看它。您可以通过登录Web控制台并导航到“构建”→“流水线”来查看您的流水线。

编辑

使用Web控制台添加密钥

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

步骤

要向构建配置添加密钥，以便它可以从AWS上的Red Hat OpenShift服务Web控制台访问私有源代码存储库：

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

编辑

启用拉取和推送

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

步骤

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

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

要启用推送：

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