2.5. 使用构建策略


以下小节定义了受支持的主要构建策略,以及它们的使用方法。

2.5.1. Docker 构建

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

提示

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

2.5.1.1. 替换 Dockerfile FROM 镜像

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

流程

将 Dockerfile 中的 FROM 指令替换为 BuildConfig 中的 from

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

2.5.1.2. 使用 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

2.5.1.3. 使用 Docker 环境变量

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

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

流程

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

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

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

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

2.5.1.4. 添加 Docker 构建参数

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

提示

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

流程

要设置 docker 构建参数,请在 buildArgs 中添加条目,它位于 BuildConfig 对象的 dockerStrategy 定义中。例如:

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

只支持 namevalue 字段。valueFrom 字段上的任何设置都会被忽略。

2.5.1.5. 使用 docker 构建的 Squash 层

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

流程

  • imageOptimizationPolicy 设置为 SkipLayers

    strategy:
      dockerStrategy:
        imageOptimizationPolicy: SkipLayers

2.5.1.6. 使用构建卷

您可以挂载构建卷,为运行的构建授予您不想在输出容器镜像中保留的信息的访问权限。

构建卷提供仅在构建时需要的敏感信息,如存储库凭据。构建卷与构建输入不同,后者的数据可以保留在输出容器镜像中。

构建卷的挂载点(运行中的构建从中读取数据)在功能上与 pod 卷挂载 类似。

流程

  • 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 5
            mounts:
            - destinationPath: /opt/app-root/src/.m2  6
            source:
              type: ConfigMap 7
              configMap:
                name: my-config 8
          - name: my-csi-volume 9
            mounts:
            - destinationPath: /opt/app-root/src/some_path  10
            source:
              type: CSI 11
              csi:
                driver: csi.sharedresource.openshift.io 12
                readOnly: true 13
                volumeAttributes: 14
                  attribute: value
    1 5 9
    必需。唯一的名称。
    2 6 10
    必需。挂载点的绝对路径。它不能包含 .. 或 : 且不与构建器生成的目的地路径冲突。/opt/app-root/src 是许多支持 Red Hat S2I 的镜像的默认主目录。
    3 7 11
    必需。源类型,ConfigMapSecretCSI
    4 8
    必需。源的名称。
    12
    必需。提供临时 CSI 卷的驱动程序。
    13
    必需。这个值必须设为 true。提供只读卷。
    14
    可选。临时 CSI 卷的卷属性。如需支持的属性键和值,请参阅 CSI 驱动程序的文档。
注意

共享资源 CSI 驱动程序作为技术预览提供。

2.5.2. Source-to-image 构建

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

2.5.2.1. 执行 source-to-image 增量构建

Source-to-image (S2I) 可以执行增量构建,也就是能够重复利用过去构建的镜像中的工件。

流程

  • 要创建增量构建,请创建对策略定义进行以下修改:

    strategy:
      sourceStrategy:
        from:
          kind: "ImageStreamTag"
          name: "incremental-image:latest" 1
        incremental: true 2
    1
    指定支持增量构建的镜像。请参考构建器镜像的文档,以确定它是否支持此行为。
    2
    此标志(flag)控制是否尝试增量构建。如果构建器镜像不支持增量构建,则构建仍将成功,但您会收到一条日志消息,指出增量构建因为缺少 save-artifacts 脚本而未能成功。

其他资源

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

2.5.2.2. 覆盖 source-to-image 构建器镜像脚本

您可以覆盖构建器镜像提供的 assemblerunsave-artifacts source-to-image(S2I)脚本。

流程

要覆盖构建器镜像提供的 assemblerunsave-artifacts S2I 脚本,请执行以下任一操作:

  • 在应用程序源存储库的 .s2i/bin 目录中提供 assemblerunsave-artifacts 脚本。
  • 提供包含脚本的目录的 URL,作为策略定义的一部分。例如:

    strategy:
      sourceStrategy:
        from:
          kind: "ImageStreamTag"
          name: "builder-image:latest"
        scripts: "http://somehost.com/scripts_directory" 1
    1
    此路径会将 runassemblesave-artifacts 附加到其中。如果找到任何或所有脚本,将使用它们代替镜像中提供的同名脚本。
注意

位于 scripts URL 的文件优先于源存储库的 .s2i/bin 中的文件。

2.5.2.3. Source-to-image 环境变量

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

2.5.2.3.1. 使用 Source-to-image 环境文件

利用源代码构建,您可以在应用程序内设置环境值(每行一个),方法是在源存储库中的 .s2i/environment 文件中指定它们。此文件中指定的环境变量存在于构建过程和输出镜像。

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

流程

例如,在构建期间禁用 Rails 应用程序的资产编译:

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

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

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

使用镜像部分中提供了各个镜像支持的环境变量的完整列表。

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

您可以在构建配置的 sourceStrategy 定义中添加环境变量。这里定义的环境变量可在 assemble 脚本执行期间看到,也会在输出镜像中定义,使它们能够供 run 脚本和应用程序代码使用。

流程

  • 例如,禁用 Rails 应用程序的资产编译:

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

其他资源

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

2.5.2.4. 忽略 source-to-image 源文件

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

2.5.2.5. 使用 Source-to-image 从源代码创建镜像

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

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

2.5.2.5.1. 了解 source-to-image 构建过程

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

  • Source-to-image(S2I)脚本
  • 构建器镜像

S2I 生成带有构建器镜像的 Dockerfile 作为第一个 FROM 指令。然后,由 S2I 生成的 Dockerfile 会被传递给 Buildah。

2.5.2.5.2. 如何编写 Source-to-image 脚本

您可以使用任何编程语言编写 S2I 脚本,只要脚本可在构建器镜像中执行。S2I 支持多种提供 assemble/run/save-artifacts 脚本的选项。每次构建时按以下顺序检查所有这些位置:

  1. 构建配置中指定的脚本。
  2. 在应用程序源 .s2i/bin 目录中找到的脚本。
  3. 在默认镜像 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
表 2.1. S2I 脚本
脚本描述

assemble

assemble 用来从源代码构建应用程序工件,并将其放置在镜像内部的适当目录中的脚本。这个脚本是必需的。此脚本的工作流为:

  1. 可选:恢复构建工件。如果要支持增量构建,确保同时定义了 save-artifacts
  2. 将应用程序源放在所需的位置。
  3. 构建应用程序工件。
  4. 将工件安装到适合它们运行的位置。

run

run 脚本将执行您的应用程序。这个脚本是必需的。

save-artifacts

save-artifacts 脚本将收集所有可加快后续构建过程的依赖项。这个脚本是可选的。例如:

  • 对于 Ruby,由 Bundler 安装的 gem
  • 对于 Java,.m2 内容。

这些依赖项会收集到一个 tar 文件中,并传输到标准输出。

usage

借助 usage 脚本,可以告知用户如何正确使用您的镜像。这个脚本是可选的。

test/run

借助 test/run 脚本,可以创建一个进程来检查镜像是否正常工作。这个脚本是可选的。该流程的建议工作流是:

  1. 构建镜像。
  2. 运行镜像以验证 usage 脚本。
  3. 运行 s2i build 以验证 assemble 脚本。
  4. 可选:再次运行 s2i build,以验证 save-artifactsassemble 脚本的保存和恢复工件功能。
  5. 运行镜像,以验证测试应用程序是否正常工作。
注意

建议将 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

2.5.2.6. 使用构建卷

您可以挂载构建卷,为运行的构建授予您不想在输出容器镜像中保留的信息的访问权限。

构建卷提供仅在构建时需要的敏感信息,如存储库凭据。构建卷与构建输入不同,后者的数据可以保留在输出容器镜像中。

构建卷的挂载点(运行中的构建从中读取数据)在功能上与 pod 卷挂载 类似。

流程

  • 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 5
            mounts:
            - destinationPath: /opt/app-root/src/.m2 6
            source:
              type: ConfigMap 7
              configMap:
                name: my-config 8
          - name: my-csi-volume 9
            mounts:
            - destinationPath: /opt/app-root/src/some_path  10
            source:
              type: CSI 11
              csi:
                driver: csi.sharedresource.openshift.io 12
                readOnly: true 13
                volumeAttributes: 14
                  attribute: value
1 5 9
必需。唯一的名称。
2 6 10
必需。挂载点的绝对路径。它不能包含 .. 或 : 且不与构建器生成的目的地路径冲突。/opt/app-root/src 是许多支持 Red Hat S2I 的镜像的默认主目录。
3 7 11
必需。源类型,ConfigMapSecretCSI
4 8
必需。源的名称。
12
必需。提供临时 CSI 卷的驱动程序。
13
必需。这个值必须设为 true。提供只读卷。
14
可选。临时 CSI 卷的卷属性。如需支持的属性键和值,请参阅 CSI 驱动程序的文档。
注意

共享资源 CSI 驱动程序作为技术预览提供。

2.5.3. Custom 构建

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

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

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

2.5.3.1. 使用 FROM 镜像进行自定义构建

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

流程

  • 设置 customStrategy.from 部分:

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

2.5.3.2. 在自定义构建中使用 secret

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

流程

  • 要将各个 secret 挂载到特定位置,编辑 策略 YAML 文件的 secretSourcemountPath 字段:

    strategy:
      customStrategy:
        secrets:
          - secretSource: 1
              name: "secret1"
            mountPath: "/tmp/secret1" 2
          - secretSource:
              name: "secret2"
            mountPath: "/tmp/secret2"
    1
    secretSource 是对与构建相同的命名空间中的 secret 的引用。
    2
    mountPath 是自定义构建器中应挂载 secret 的路径。

2.5.3.3. 使用环境变量进行自定义构建

要将环境变量提供给自定义构建过程使用,您可以在构建配置的 customStrategy 定义中添加环境变量。

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

流程

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

    customStrategy:
    ...
      env:
        - name: "HTTP_PROXY"
          value: "http://myproxy.net:5187/"
  2. 要管理构建配置中定义的环境变量,请输入以下命令:

    $ oc set env <enter_variables>

2.5.3.4. 使用自定义构建器镜像

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

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

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

2.5.3.4.1. 自定义构建器镜像

在调用时,自定义构建器镜像将接收以下环境变量以及继续进行构建所需要的信息:

表 2.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 master 的版本。

OUTPUT_REGISTRY

镜像要推送到的容器镜像 registry。

OUTPUT_IMAGE

所构建镜像的容器镜像标签名称。

PUSH_DOCKERCFG_PATH

用于运行 podman push 操作的容器 registry 凭证的路径。

2.5.3.4.2. 自定义构建器工作流

虽然自定义构建器镜像作者在定义构建过程时具有很大的灵活性,但构建器镜像仍必须遵循如下必要的步骤,才能在 OpenShift Container Platform 内无缝运行构建:

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

2.5.4. Pipeline 构建

重要

Pipeline 构建策略在 OpenShift Container Platform 4 中弃用。基于 Tekton 的 OpenShift Container Platform Pipelines 中带有等效且改进的功能。

OpenShift Container Platform 上的 Jenkins 镜像被完全支持,用户可以按照 Jenkins 用户文档在作业中定义 jenkinsfile,或者将其存储在 Source Control Management 系统中。

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

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

2.5.4.1. 了解 OpenShift Container Platform 管道

重要

Pipeline 构建策略在 OpenShift Container Platform 4 中弃用。基于 Tekton 的 OpenShift Container Platform Pipelines 中带有等效且改进的功能。

OpenShift Container Platform 上的 Jenkins 镜像被完全支持,用户可以按照 Jenkins 用户文档在作业中定义 jenkinsfile,或者将其存储在 Source Control Management 系统中。

通过管道(pipeline),您可以控制在 OpenShift Container Platform 上构建、部署和推进您的应用程序。通过结合使用 Jenkins Pipeline 构建策略、jenkinsfile 和 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 插件。
  • 将 secret 同步到 Jenkins 凭证条目。

OpenShift Container Platform Jenkins 客户端插件

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

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

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

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

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

2.5.4.2. 为管道构建提供 Jenkins 文件

重要

Pipeline 构建策略在 OpenShift Container Platform 4 中弃用。基于 Tekton 的 OpenShift Container Platform Pipelines 中带有等效且改进的功能。

OpenShift Container Platform 上的 Jenkins 镜像被完全支持,用户可以按照 Jenkins 用户文档在作业中定义 jenkinsfile,或者将其存储在 Source Control Management 系统中。

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

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

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

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

  • 存储库根目录下名为 jenkinsfile 的文件。
  • 存储库的源 contextDir 的根目录下名为 jenkinsfile 的文件。
  • 通过 BuildConfig 的 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

2.5.4.3. 使用环境变量进行 Pipeline 构建

重要

Pipeline 构建策略在 OpenShift Container Platform 4 中弃用。基于 Tekton 的 OpenShift Container Platform Pipelines 中带有等效且改进的功能。

OpenShift Container Platform 上的 Jenkins 镜像被完全支持,用户可以按照 Jenkins 用户文档在作业中定义 jenkinsfile,或者将其存储在 Source Control Management 系统中。

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

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

流程

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

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

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

2.5.4.3.1. 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 处理期间的性能。

2.5.4.4. Pipeline 构建教程

重要

Pipeline 构建策略在 OpenShift Container Platform 4 中弃用。基于 Tekton 的 OpenShift Container Platform Pipelines 中带有等效且改进的功能。

OpenShift Container Platform 上的 Jenkins 镜像被完全支持,用户可以按照 Jenkins 用户文档在作业中定义 jenkinsfile,或者将其存储在 Source Control Management 系统中。

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

流程

  1. 创建 Jenkins master:

      $ oc project <project_name>

    选择要使用的项目,或使用 oc new-project <project_name> 创建一个新项目。

      $ oc new-app jenkins-ephemeral 1

    如果要使用持久性存储,请改用 jenkins-persistent

  2. 使用以下内容,创建名为 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
  3. 使用 jenkinsPipelineStrategy 创建 BuildConfig 对象后,通过使用内联 jenkinsfile 告知管道做什么:

    注意

    本例没有为应用程序设置 Git 存储库。

    以下 jenkinsfile 内容使用 OpenShift Container Platform DSL 以 Groovy 语言编写。在本例中,请使用 YAML Literal Style 在 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
    要使用的模板的路径。
    1 2
    要创建的模板的名称。
    3
    启动 node.js 代理 pod 以针对其运行此构建。
    4
    为此管道设置 20 分钟超时。
    5
    使用此模板标签删除所有内容。
    6
    使用此模板标签删除任何 secret。
    7
    templatePath 创建一个新应用程序。
    8
    等待最多五分钟以完成构建。
    9
    等待最多五分钟以完成部署。
    10
    如果其余部分都成功,则将 $ {templateName}:latest 镜像标记为 $ {templateName}-staging:latest。stage 环境的管道 BuildConfig 可以监控 $ {templateName}-staging:latest 镜像更改,并将它部署到 stage 环境中。
    注意

    上例使用 declarative pipeline 风格编写,但较旧的 scripted pipeline 风格也受到支持。

  4. 在 OpenShift Container Platform 集群中创建管道 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
  5. 启动管道:

    $ oc start-build nodejs-sample-pipeline
    注意

    此外,也可以通过 OpenShift Container Platform Web 控制台启动管道,方法是导航到 Builds Pipeline 部分并点击 Start Pipeline,或者访问 Jenkins 控制台,再导航到您创建的管道并点击 Build Now

    管道启动之后,您应该看到项目中执行了以下操作:

    • 在 Jenkins 服务器上创建了作业实例。
    • 如果管道需要,启动一个代理 pod。
    • 管道在代理 Pod 上运行,如果不需要代理,则管道在 master 上运行。

      • 将删除之前创建的具有 template=nodejs-mongodb-example 标签的所有资源。
      • nodejs-mongodb-example 模板创建一个新应用程序及其所有相关资源。
      • 使用 nodejs-mongodb-example BuildConfig 启动构建。

        • 管道将等待到构建完成后触发下一阶段。
      • 使用 nodejs-mongodb-example 部署配置启动部署。

        • 管道将等待到部署完成后触发下一阶段。
      • 如果构建和部署都成功,则 nodejs-mongodb-example:latest 镜像将标记为 nodejs-mongodb-example:stage
    • 如果管道需要,则代理 pod 会被删除。

      注意

      视觉化管道执行的最佳方法是在 OpenShift Container Platform Web 控制台中查看它。您可以通过登录 Web 控制台并导航到 Builds Pipelines 来查看管道。

2.5.5. 使用 web 控制台添加 secret

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

流程

将 secret 添加到构建配置中,以便它可以从 OpenShift Container Platform Web 控制台访问私有存储库:

  1. 创建一个新的 OpenShift Container Platform 项目。
  2. 创建一个包含用于访问私有源代码存储库的凭证的 secret。
  3. 创建构建配置。
  4. 在构建配置编辑器页面上或在 Web 控制台的 create app from builder image 页面中,设置 Source Secret
  5. 点击 Save

2.5.6. 启用拉取 (pull) 和推送 (push)

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

流程

启用拉取到私有 registry:

  • 在构建配置中设置 pull secret。

启用推送:

  • 在构建配置中设置 push secret。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.