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"
只支持 name
和 value
字段。valueFrom
字段上的任何设置都会被忽略。
2.5.1.5. 对 Docker 的构建层进行压缩
通常,Docker 构建会为 Dockerfile 中的每条指令都创建一个层。将 imageOptimizationPolicy
设置为 SkipLayers
,可将所有指令合并到基础镜像顶部的单个层中。
流程
将
imageOptimizationPolicy
设置为SkipLayers
:strategy: dockerStrategy: imageOptimizationPolicy: SkipLayers
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
其他资源
- 如需有关如何创建支持增量构建的构建器镜像的信息,请参阅 S2I 要求。
2.5.2.2. 覆盖 source-to-image 构建器镜像脚本
您可以覆盖构建器镜像提供的 assemble
、run
和 save-artifacts
source-to-image(S2I)脚本。
流程
要覆盖构建器镜像提供的 assemble
、run
和 save-artifacts
S2I 脚本,请执行以下任一操作:
-
在应用程序源存储库的
.s2i/bin
目录中提供assemble
、run
或save-artifacts
脚本。 提供包含脚本的目录的 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
中的文件。
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
脚本的选项。每次构建时按以下顺序检查所有这些位置:
- 构建配置中指定的脚本。
-
在应用程序源
.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
脚本 | 描述 |
---|---|
|
|
|
|
|
这些依赖项会收集到一个 |
|
借助 |
|
借助
注意
建议将 |
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.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 列表。
2.5.3.3. 使用环境变量进行自定义构建
要将环境变量提供给自定义构建过程使用,您可以在构建配置的 customStrategy
定义中添加环境变量。
这里定义的环境变量将传递给运行自定义构建的 Pod。
流程
定义在构建期间使用的自定义 HTTP 代理:
customStrategy: ... env: - name: "HTTP_PROXY" value: "http://myproxy.net:5187/"
要管理构建配置中定义的环境变量,请输入以下命令:
$ oc set env <enter_variables>
2.5.3.4. 使用自定义构建器镜像
OpenShift Container Platform 的自定义构建策略允许您定义负责整个构建过程的特定构建器镜像。当您需要构建来生成单独的工件,如软件包、JAR、WAR、可安装的 ZIP 或基础镜像时,请使用自定义构建器镜像。
自定义构建器镜像是嵌入构建过程逻辑的普通容器镜像,用于构建工件,如 RPM 或基础容器镜像。
另外,自定义构建器允许实施任何扩展构建过程,如运行单元或集成测试的 CI/CD 流。
2.5.3.4.1. 自定义构建器镜像
在调用时,自定义构建器镜像将接收以下环境变量以及继续进行构建所需要的信息:
变量名称 | 描述 |
---|---|
|
|
| 包含要构建的源代码的 Git 存储库的 URL。 |
|
使用与 |
| 指定要在构建时使用的 Git 存储库的子目录。只有定义后才出现。 |
| 要构建的 Git 引用。 |
| 创建此构建对象的 OpenShift Container Platform master 的版本。 |
| 镜像要推送到的容器镜像 registry。 |
| 所构建镜像的容器镜像标签名称。 |
|
用于运行 |
2.5.3.4.2. 自定义构建器工作流
虽然自定义构建器镜像作者在定义构建过程时具有很大的灵活性,但构建器镜像仍必须遵循如下必要的步骤,才能在 OpenShift Container Platform 内无缝运行构建:
-
Build
对象定义包含有关构建的输入参数的所有必要信息。 - 运行构建过程。
- 如果构建生成了镜像,则将其推送到构建的输出位置(若已定义)。可通过环境变量传递其他输出位置。
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
应用程序。
流程
创建 Jenkins master:
$ oc project <project_name>
选择要使用的项目,或使用
oc new-project <project_name>
创建一个新项目。$ oc new-app jenkins-ephemeral 1
如果要使用持久性存储,请改用
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
告知管道做什么:注意本例没有为应用程序设置 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 风格也受到支持。
在 OpenShift Container Platform 集群中创建管道
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 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 控制台访问私有存储库:
- 创建一个新的 OpenShift Container Platform 项目。
- 创建一个包含用于访问私有源代码存储库的凭证的 secret。
- 创建构建配置。
-
在构建配置编辑器页面上或在 Web 控制台的
create app from builder image
页面中,设置 Source Secret。 - 点击 Save。
2.5.6. 启用拉取 (pull) 和推送 (push)
您可以通过在构建配置中设置 pull secret 来启用拉取到私有 registry,也可以通过设置 push secret 来启用推送。
流程
启用拉取到私有 registry:
- 在构建配置中设置 pull secret。
启用推送:
- 在构建配置中设置 push secret。