镜像

Cluster Samples Operator 默认配置为 Managed，或者配置了全局代理。在 Managed 状态下，Cluster Samples Operator 会主动管理其资源并保持组件的活跃状态，以便从 registry 中拉取示例镜像流和镜像，并确保安装了必要的示例模板。

在某些情况下，Cluster Samples Operator 会将自身引导为 Removed，包括：

但是，如果 Cluster Samples Operator 检测到它位于 IPv6 网络上，并且配置了 OpenShift Container Platform 全局代理，则 IPv6 检查会替换所有检查。因此，Cluster Samples Operator 会将自身引导为 Removed。

apiVersion: samples.operator.openshift.io/v1
kind: Config
metadata:
  name: cluster
spec:
  architectures:
  - x86_64
  managementState: Removed

在创建或更新示例镜像流后，Cluster Samples Operator 会监控每个镜像流标签镜像导入的进度。

如果导入失败，Cluster Samples Operator 会通过镜像流镜像导入 API（与 oc import-image 命令使用的 API 相同）。重新尝试导入大约每 15 分钟进行一次，直到导入成功，或者 Cluster Samples Operator 的配置已更改为镜像流被添加到 skippedImagestreams 列表中，或者管理状态变为 Removed。

其他资源

在安装过程中，OpenShift Container Platform 在 openshift-cluster-samples-operator 命名空间中创建一个名为 imagestreamtag-to-image 的配置映射。imagestreamtag-to-image 配置映射包含每个镜像流标签的条目（填充镜像）。

配置映射中 data 字段中每个条目的键格式为 <image_stream_name>_<image_stream_tag_name>。

在断开连接的 OpenShift Container Platform 安装过程中，Cluster Samples Operator 的状态被设置为 Removed。如果您将其改为 Managed，它会安装示例。

您可以使用此配置映射作为导入镜像流所需的镜像的引用。

如需了解详细信息，请参阅使用带有备用或镜像 registry 的 Cluster Samples Operator 镜像流。

当 Cluster Samples Operator 开始支持多个架构时，则在处于 Managed 状态时不允许更改架构列表。

要更改构架值，集群管理员必须：

Cluster Samples Operator 在 Removed 状态下仍然会处理 secret。您可在切换到 Removed 之前，或在切换到 Managed 之前仍处于 Removed 时，或切换到 Managed 状态后创建 secret。如果在切换到 Managed 后创建 secret，创建示例会延迟到处理 secret 事件。如果您选择在切换前删除所有样本，则会有助于更改 registry。不需要在切换前删除所有示例。

示例资源将在所处状态下保持以下条件：

在创建镜像 registry 前，您必须准备镜像（mirror）主机。

您可以安装 OpenShift CLI(oc)来使用命令行界面与 OpenShift Container Platform 进行交互。您可以在 Linux、Windows 或 macOS 上安装 oc。

在 Linux 上安装 OpenShift CLI

您可以按照以下流程在 Linux 上安装 OpenShift CLI(oc)二进制文件。

安装 OpenShift CLI 后，可以使用 oc 命令：

$ oc <command>

在 Windows 上安装 OpenShift CLI

您可以按照以下流程在 Windows 上安装 OpenShift CLI(oc)二进制文件。

安装 OpenShift CLI 后，可以使用 oc 命令：

C:\> oc <command>

在 macOS 上安装 OpenShift CLI

您可以按照以下流程在 macOS 上安装 OpenShift CLI(oc)二进制文件。

安装 OpenShift CLI 后，可以使用 oc 命令：

$ oc <command>

在安装过程中，OpenShift Container Platform 在 openshift-cluster-samples-operator 命名空间中创建一个名为 imagestreamtag-to-image 的配置映射。imagestreamtag-to-image 配置映射包含每个镜像流标签的条目（填充镜像）。

配置映射中 data 字段中每个条目的键格式为 <image_stream_name>_<image_stream_tag_name>。

在断开连接的 OpenShift Container Platform 安装过程中，Cluster Samples Operator 的状态被设置为 Removed。如果您将其改为 Managed，它会安装示例。

您可以使用此配置映射作为导入镜像流所需的镜像的引用。

如需了解详细信息，请参阅使用带有备用或镜像 registry 的 Cluster Samples Operator 镜像流。

无论容器镜像是否在 OpenShift Container Platform 中使用，在创建容器镜像时都需要遵循以下指导信息。

重复利用镜像

您的镜像尽可能使用 FROM 语句基于适当的上游镜像。这可确保，在上游镜像更新时您的镜像也可轻松从中获取安全修复，而不必再直接更新依赖项。

此外，请使用 FROM 指令中的标签（如 rhel:rhel7），方便用户准确了解您的镜像基于哪个版本的镜像。使用除 latest 以外的标签可确保您的镜像不受 latest 版上游镜像重大更改的影响。

在标签内维持兼任性

在为自己的镜像添加标签时，建议尽量在标签内保持向后兼容性。例如，如果您提供名为 foo 的镜像，当前包含 1.0 版本，则可提供一个 foo:v1 标签。当您更新了镜像时，只要仍与原始镜像兼容，就可继续使用 foo:v1 做为新镜像的标签。而使用这个标签的下游用户就可获得更新，而不会出现问题。

如果后续发布了不兼容的更新，则需要使用新标签，例如 foo:v2。这样，下游用户就可以根据需要选择是否升级到新版本，而不会因为不兼容的新镜像造成问题。下游用户如果使用 foo:latest，则可能要承担引入不兼容更改的风险。

避免多进程

不要在同一容器中启动多个服务，如数据库和 SSHD。因为容器是轻量级的，可轻松链接到一起以编排多个进程，所以没有在同一个容器中启动多个服务的必要。您可以利用 OpenShift Container Platform 将相关镜像分组到一个 pod 中来轻松并置和共同管理镜像。

这种并置可确保容器共享一个网络命名空间和存储进行通信。因为对每个镜像的更新频率较低且可以独立进行，所以更新所可能带来的破坏风险也较小，单一进程的信号处理流程也更加清晰，因为无需管理将信号路由到多个分散进程的操作。

在 wrapper 脚本中使用 exec

很多镜像在启动正在运行的软件的进程前，会先使用 wrapper 脚本进行一些设置。如果您的镜像使用这类脚本，则该脚本应使用 exec，以便使您的软件可以替代脚本的进程。如果不使用 exec，则容器运行时发送的信号将进入 wrapper 脚本，而非软件的进程。这不是您想要的。

如果您有一个为某些服务器启动进程的 wrapper 脚本。您启动了容器（例如使用 podman run -i），该容器运行 wrapper 脚本，继而启动您的进程。如果要使用 CTRL+C 关闭容器。如果您的 wrapper 脚本使用了 exec 来启动服务器进程，则 podman 会将 SIGINT 发送至服务器进程，一切都可以正常工作。如果您没有在 wrapper 脚本中使用 exec，则 podman 会将 SIGINT 发送至 wrapper 脚本的进程，并且您的进程不会象任何情况一样继续运行。

另请注意，您的进程在容器中运行时，将作为 PID 1 运行。这意味着，如果主进程终止，则整个容器都会停止，取消您从 PID 1 进程启动的所有子进程。

清理临时文件

删除构建过程中创建的所有临时文件。这也包括通过 ADD 命令添加的任何文件。例如，在执行 yum install 操作后运行 yum clean 命令。

您可按照如下所示创建 RUN 语句来防止 yum 缓存最终留在镜像层：

RUN yum -y install mypackage && yum -y install myotherpackage && yum clean all -y

请注意，如果您改写为：

RUN yum -y install mypackage
RUN yum -y install myotherpackage && yum clean all -y

则首次 yum 调用会将额外文件留在该层，后续运行 yum clean 操作时无法删除这些文件。最终镜像中看不到这些额外文件，但它们存在于底层中。

如果在较早层中删除了一些内容时，当前容器构建进程不允许在较晚的层中运行一个命令来缩减镜像使用的空间。但是，这个行为可能会在以后的版本中有所改变。这表示，如果在较晚层中执行 rm 命令，虽然被这个命令删除的文件不会出现在镜像中，但它不会使下载的镜像变小。因此，与 yum clean 示例一样，最好尽可能使用创建文件的同一命令删除文件，以免文件最终写入层中。

另外，在单个 RUN 语句中执行多个命令可减少镜像中的层数，缩短下载和提取时间。

按正确顺序放置指令

容器构建程序读取 Dockerfile，并自上而下运行指令。成功执行的每个指令都会创建一个层，可在下次构建该镜像或其他镜像时重复使用。务必要将很少更改的指令放置在 Dockerfile 的顶部。这样做可确保下次构建相同镜像会非常迅速，因为缓存不会因为上层变化而失效。

例如：如果您正在使用 Dockerfile，它包含一个用于安装正在迭代的文件的 ADD 命令，以及一个用于 yum install 软件包的 RUN 命令，则最好将 ADD 命令放在最后：

FROM foo
RUN yum -y install mypackage && yum clean all -y
ADD myfile /test/myfile

这样，您每次编辑 myfile 和重新运行 podman build 或 docker build 时，系统都可重复利用 yum 命令的缓存层，仅为 ADD 操作生成新层。

如果您将 Dockerfile 改写为：

FROM foo
ADD myfile /test/myfile
RUN yum -y install mypackage && yum clean all -y

则您每次更改 myfile 和重新运行 podman build 或 docker build 时，ADD 操作都会导致 RUN 层缓存无效，因此 yum 操作也必须要重新运行。

标记重要端口

EXPOSE 指令使主机系统和其它容器可使用容器中的端口。尽管可以指定应当通过 podman run 调用来公开端口，但在 Dockerfile 中使用 EXPOSE 指令可显式声明您的软件需要运行的端口，让用户和软件更易于使用您的镜像：

设置环境变量

设置环境变量的最佳做法是使用 ENV 指令设置环境变量。一个例子是设置项目版本。这让人可以无需通过查看 Dockerfile 便可轻松找到版本。另一示例是在系统上公告可供其他进程使用的路径，如 JAVA_HOME。

避免默认密码

避免设置默认密码。许多人扩展镜像时会忘记删除或更改默认密码。如果在生产环境中的用户被分配了众所周知的密码，则这可能引发安全问题。可以使用环境变量来配置密码。

如果您的确要选择设置默认密码，请确保在容器启动时显示适当的警告消息。消息中应告知用户默认密码的值并说明如何修改密码，例如要设置什么环境变量。

避免 sshd

最好避免在您的镜像中运行 sshd。您可使用 podman exec 或 docker exec 命令访问本地主机上运行的容器。另外，也可使用 oc exec 命令或 oc rsh 命令访问 OpenShift Container Platform 集群上运行的容器。在镜像中安装并运行 sshd 会为安全攻击打开额外通道，因而需要安装安全补丁。

对持久性数据使用卷

镜像应对持久性数据使用卷。这样，OpenShift Container Platform 便可将网络存储挂载至运行容器的节点，如果容器移至新节点，存储也将重新连接至该节点。通过使用卷来满足所有持久性存储需求，即使容器重启或移动，其内容也会保留下来。如果您的镜像将数据写入容器中的任意位置，则其内容可能无法保留。

所有在容器销毁后仍需要保留的数据都必须写入卷中。容器引擎支持容器的 readonly 标记，可用于严格执行不将数据写入容器临时存储的良好做法。现在围绕该功能设计您的镜像，将更便于以后利用。

在 Dockerfile 中显式定义卷可方便镜像用户轻松了解在运行您的镜像时必须要定义的卷。

有关如何在 OpenShift Container Platform 中使用卷的更多信息，请参阅 Kubernetes 文档。

以下是创建 OpenShift Container Platform 上专用的容器镜像时适用的准则。

启用 Source-to-Image (S2I) 的镜像

对于计划运行由第三方提供的应用程序代码的镜像，例如专为运行由开发人员提供的 Ruby 代码而设计的 Ruby 镜像，您可以让镜像与 Source-to-Image (S2I) 构建工具协同工作。S2I 是一个框架，便于编写以应用程序源代码为输入的镜像和生成以运行汇编应用程序为输出的新镜像。

支持任意用户 id

默认情况下，OpenShift Container Platform 使用任意分配的用户 ID 来运行容器。这对因容器引擎漏洞而逸出容器的进程提供了额外的安全防护，从而避免在主机节点上出现未授权的权限升级的问题。

对于支持以任意用户身份运行的镜像，由镜像中进程写入的目录和文件应归 root 组所有，并可由该组读/写。待执行文件还应具有组执行权限。

向 Dockerfile 中添加以下内容可将目录和文件权限设置为允许 root 组中的用户在构建镜像中访问它们：

RUN chgrp -R 0 /some/directory && \
    chmod -R g=u /some/directory

因为容器用户始终是 root 组的成员，所以容器用户可以读写这些文件。

此外，容器中运行的进程不是以特权用户身份运行，因此不得监听特权端口（低于 1024 的端口）。

使用服务进行镜像间通信

对于您的镜像需要与另一镜像提供的服务通信的情况，例如需要访问数据库镜像来存储和检索数据的 web 前端镜像，则您的镜像应使用一个 OpenShift Container Platform 服务。服务为访问提供静态端点，该端点不会随着容器的停止、启动或移动而改变。此外，服务还会为请求提供负载均衡。

提供通用库

对于要运行由第三方提供的应用程序代码的镜像，请确保您的镜像包含适用于您的平台的通用库。特别要为平台使用的通用数据库提供数据库驱动程序。例如，在创建 Java 框架镜像时，要为 MySQL 和 PostgreSQL 提供 JDBC 驱动程序。这样做可避免在应用程序汇编期间下载通用依赖项，从而加快应用程序镜像构建。此外还简化了应用程序开发人员为确保满足所有依赖项而需要做的工作。

使用环境变量进行配置

您的镜像用户应在无需基于您的镜像创建下游镜像的情况下也可进行配置。这意味着运行时配置使用环境变量进行处理。对于简单的配置，运行中的进程可直接使用环境变量。对于更为复杂的配置或对于不支持此操作的运行时，可通过定义启动过程中处理的模板配置文件来配置运行时。在此处理过程中，可将使用环境变量提供的值替换到配置文件中，或用于决定要在配置文件中设置哪些选项。

此外，也可以使用环境变量将证书和密钥等 secret 传递到容器中，这是建议操作。这样可确保 secret 值最终不会提交到镜像中，也不会泄漏到容器镜像 registry 中。

提供环境变量可方便您的镜像用户自定义行为，如数据库设置、密码和性能调优，而无需在镜像顶部引入新层。相反，用户可在定义 pod 时简单定义环境变量值，且无需重新构建镜像也可更改这些设置。

对于极其复杂的场景，还可使用在运行时挂载到容器中的卷来提供配置。但是，如果选择这种配置方式时，您必须确保当不存在必要卷或配置时，您的镜像可在启动时提供清晰的错误消息。

本主题与“使用服务进行镜像间通信”主题之间的相关之处在于，数据源等配置应当根据提供服务端点信息的环境变量来定义。这使得应用程序在不修改应用程序镜像的情况下即可动态使用 OpenShift Container Platform 环境中定义的数据源服务。

另外，调整应通过检查容器的 cgroups 设置来实现。这使得镜像可根据可用内存、CPU 和其他资源自行调整。例如，基于 Java 的镜像应根据 cgroup 最大内存参数调整其堆大小，以确保不超过限值且不出现内存不足错误。

设置镜像元数据

定义镜像元数据有助于 OpenShift Container Platform 更好地使用您的容器镜像，允许 OpenShift Container Platform 使用您的镜像为开发人员创造更好的体验。例如，您可以添加元数据以提供有用的镜像描述，或针对可能也需要的其他镜像提供建议。

集群

您必须充分了解运行镜像的多个实例的意义。在最简单的情况下，服务的负载均衡功能会处理将流量路由到镜像的所有实例。但是，许多框架必须共享信息才能执行领导选举机制或故障转移状态，例如在会话复制中。

设想您的实例在 OpenShift Container Platform 中运行时如何完成这一通信。尽管 pod 之间可直接相互通信，但其 IP 地址会随着 pod 的启动、停止和移动而变化。因此，集群方案必须是动态的。

日志记录

最好将所有日志记录发送至标准输出。OpenShift Container Platform 从容器收集标准输出，然后将其发送至集中式日志记录服务，以供查看。如果必须将日志内容区分开来，请在输出前添加适当关键字，这样便可过滤消息。

如果您的镜像日志记录到文件，则用户必须通过手动操作进入运行中的容器，并检索或查看日志文件。

存活 (liveness) 和就绪 (readiness) 探针

记录可用于您的镜像的示例存活和就绪探针。有了这些探针，用户便可放心部署您的镜像，确保在容器准备好处理流量之前，流量不会路由到容器，并且如果进程进入不健康状态，容器将重启。

模板

考虑为您的镜像提供一个示例模板。用户借助模板可轻松利用有效的配置快速部署您的镜像。模板应包括与镜像一同记录的存活和就绪探针，以保证完整性。

您可使用 Dockerfile 中的 LABEL 指令来定义镜像元数据。标签与环境变量的相似之处在于标签是附加到镜像或容器中的键值对。标签与环境变量的不同之处在于标签对运行中的应用程序不可见，可用于快速查找镜像和容器。

有关 LABEL 指令的更多信息，请参阅 Docker 文档。

标签名称通常具有命名空间。命名空间会进行相应设置，以反映将要提取和使用标签的项目。对于 OpenShift Container Platform，命名空间应设置为 io.openshift；而对于 Kubernet，命名空间应设置为 io.k8s。

有关格式的详细信息，请参阅 Docker 自定义元数据文档。

LABEL io.openshift.tags   mongodb,mongodb24,nosql

LABEL io.openshift.wants   mongodb,redis

LABEL io.k8s.description The MySQL 5.5 Server with master-slave replication support

LABEL io.openshift.non-scalable     true

LABEL io.openshift.min-memory 16Gi
LABEL io.openshift.min-cpu     4

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

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

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

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

S2I 脚本示例

以下示例 S2I 脚本采用 Bash 编写。每个示例都假定其 tar 内容解包到 /tmp/s2i 目录中。

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

#!/bin/bash

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

#!/bin/bash

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

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

test 脚本的标准位置为 test/run。该脚本由 OpenShift Container Platform S2I 镜像构建程序调用，可以是简单的 Bash 脚本，也可以是静态的 Go 二进制文件。

test/run 脚本会执行 S2I 构建，因此您的 $PATH 中必须有 S2I 二进制文件。必要情况下，请遵循 S2I README 中的安装说明。

S2I 结合了应用程序源代码与构建程序镜像，因此为了对其进行测试，您需要一个示例应用程序源来验证该源是否成功转换成了可运行的容器镜像。示例应用程序应简单，但也应执行 assemble 和 run 脚本的关键步骤。

S2I 工具随附功能强大的生成工具，可加快新 S2I 镜像的创建过程。s2i create 命令生成所有必要的 S2I 脚本和测试工具以及 Makefile：

$ s2i create _<image name>_ _<destination directory>_

所生成的 test/run 脚本必须经过调整才可使用，但它为开始开发提供了一个良好起点。

本地运行 S2I 镜像测试的最简单方法是使用所生成的 Makefile。

如果未使用 s2i create 命令，则可复制以下 Makefile 模板，并将 IMAGE_NAME 参数替换为您的镜像名称。

IMAGE_NAME = openshift/ruby-20-centos7
CONTAINER_ENGINE := $(shell command -v podman 2> /dev/null | echo docker)

build:
	${CONTAINER_ENGINE} build -t $(IMAGE_NAME) .

.PHONY: test
test:
	${CONTAINER_ENGINE} build -t $(IMAGE_NAME)-candidate .
	IMAGE_NAME=$(IMAGE_NAME)-candidate test/run

test 脚本会假定您已构建要测试的镜像。如果需要，请先构建 S2I 镜像。运行以下任一命令：

以下步骤描述测试 S2I 镜像构建程序的默认工作流：

通常，运行这些步骤便足以说明构建程序镜像是否按预期工作。

有了 Dockerfile 和组成新 S2I 构建程序镜像的其他工件后，您可以将它们放入 git 存储库中，并使用 OpenShift Container Platform 来构建和推送（push）镜像。定义指向您的存储库的 Docker 构建。

如果 OpenShift Container Platform 实例托管在一个公共 IP 地址上，则每次推送（push）到您的 S2I 构建程序镜像 GitHub 存储库时，均可触发构建。

您还可使用 ImageChangeTrigger 来基于您所更新的 S2I 构建程序镜像来触发应用程序的重新构建。

镜像流包含由标签识别的任意数量的容器镜像。提供相关镜像的单一虚拟视图，类似于容器镜存储库。

通过监控镜像流，构建和部署可在添加或修改新镜像时收到通知，并通过分别执行构建或部署来作出反应。

镜像标签（tag）是应用于存储库中容器镜像的标签，用于将特定镜像与镜像流中的其他镜像区分开来。标签通常代表某种版本号。例如，这里 :v3.11.59-2 是标签：

registry.access.redhat.com/openshift3/jenkins-2-rhel7:v3.11.59-2

您可以向镜像添加其他标签。例如，可为镜像分配 :v3.11.59-2 和 :latest 标签。

OpenShift Container Platform 提供 oc tag 命令，该命令类似于 docker tag 命令，但是在镜像流上运行，而非直接在镜像上运行。

镜像随时间不断发展，其标签反应了这一点。一般来说，镜像标签会始终指向最新镜像构建。

如果标签名称中嵌入太多信息，如 v2.0.1- May-2019，则标签仅指向镜像的一个版本，不会更新。使用默认镜像修剪选项，此类镜像不会被删除。在庞大集群中，为每个修改后的镜像创建新标签这种模式最终可能会使用早已过期的镜像的多余标签元数据来填充 etcd 数据存储。

如果标签命名为 v2.0，则镜像修改的可能性更大。这会导致标签历史记录更长，镜像修剪器 (pruner) 也更有可能删除旧的和未使用的镜像。

您可自行决定标签命名惯例，下面提供了一些 <image_name>:<image_tag> 格式的示例：

如果标签名称中需要日期，请定期检查旧的和不受支持的镜像以及 istags，并予以删除。否则，您可能遇到保留的旧镜像导致资源使用量增加的情况。

OpenShift Container Platform 中的镜像流包含 0 个或更多由标签标识的容器镜像。

有各种不同类型的标签可用。默认行为使用 permanent 标签，指向一段时间内的特定镜像。如果正在使用 permanent 标签并且源更改，则目的地的标签不会更改。

tracking 标签表示，在导入源标签期间对目的地标签的元数据进行了更新。

您可以从镜像流中删除标签。

您可以通过以下引用类型，使用标签来引用镜像流中的镜像。

查看镜像流定义示例时，您可能会发现它们包含 ImageStreamTag 的定义以及对 DockerImage 的引用，但与 ImageStreamImage 无关。

这是因为当您将镜像导入或标记到镜像流时，OpenShift Container Platform 中会自动创建 ImageStreamImage 对象。您不必在用于创建镜像流的任何镜像流定义中显式定义 ImageStreamImage 对象。

OpenShift Container Platform 在创建容器时，会使用容器的 imagePullPolicy 来决定是否应在启动容器前拉取（pull）镜像。imagePullPolicy 有三个可能的值：

如果没有指定容器的 imagePullPolicy 参数，OpenShift Container Platform 会根据镜像标签来设置。

使用内部容器镜像仓库（registry）时，为允许 project-a 中的 pod 引用 project-b 中的镜像，project-a 中的服务帐户必须绑定到 project-b 中的 system:image-puller 角色。

Docker 客户端的 .dockercfg $HOME/.docker/config.json 文件是一个 Docker 凭证文件，如果您之前已登录安全或不安全的 registry，则该文件会保存您的身份验证信息。

要拉取（pull）并非来自 OpenShift Container Platform 内部 registry 的安全容器镜像，您必须从 Docker 凭证创建一个 pull secret，并将其添加到您的服务帐户。

您可以通过替换当前的 pull secret 或附加新的 pull secret 来更新集群的全局 pull secret。

您可获取有关镜像流的常规信息及其指向的所有标签的详细信息。

您可以向镜像流添加其他标签。

您可为外部镜像添加标签。

您可以更新标签以反映镜像流中的另一标签。

您可以从镜像流中删除旧标签。

如需有关 Cluster Samples Operator 如何处理已弃用的镜像流标签的更多信息，请参阅从 Cluster Samples Operator 中删除已弃用的镜像流标签。

使用外部容器镜像 registry 时，如需定期重新导入镜像（例如为了获取最新安全更新），可使用 --scheduled 标志。

Docker 客户端的 .dockercfg $HOME/.docker/config.json 文件是一个 Docker 凭证文件，如果您之前已登录安全或不安全的 registry，则该文件会保存您的身份验证信息。

要拉取（pull）并非来自 OpenShift Container Platform 内部 registry 的安全容器镜像，您必须从 Docker 凭证创建一个 pull secret，并将其添加到您的服务帐户。

您可以通过编辑 image.config.openshift.io/cluster 自定义资源（CR）在 registry 中添加允许进行镜像拉取（pull）和推送（push）操作的 registry 列表（可选）。OpenShift Container Platform 会将对此 CR 的更改应用到集群中的所有节点。

在拉取或推送镜像时，容器运行时会搜索 image.config.openshift.io/cluster CR 的 registrySources 参数中列出的 registry。如果您在 allowedRegistries 参数下创建了 registry 列表，则容器运行时仅搜索这些 registry。不在列表中的 registry 会被阻断。

spec:
  registrySources:
    insecureRegistries:
    - insecure.com
    allowedRegistries:
    - example.com
    - quay.io
    - registry.redhat.io
    - insecure.com
    - image-registry.openshift-image-registry.svc:5000

您可以通过编辑 image.config.openshift.io/cluster 自定义资源（CR）来阻止任何 registry 以及 registry 中的单独存储库。OpenShift Container Platform 会将对此 CR 的更改应用到集群中的所有节点。

在拉取或推送镜像时，容器运行时会搜索 image.config.openshift.io/cluster CR 的 registrySources 参数中列出的 registry。如果您在 blockedRegistries 参数下创建了 registry 列表，则容器运行时不会搜索这些 registry。允许所有其他 registry。

您可以通过编辑 image.config.openshift.io/cluster 自定义资源（CR）来添加不安全的 registry 及 registry 中的特定存储库（可选）。OpenShift Container Platform 会将对此 CR 的更改应用到集群中的所有节点。

没有使用有效 SSL 证书或不需要 HTTPS 连接的 registry 被视为是不安全的 registry。

您可以通过编辑 image.config.openshift.io/cluster 自定义资源（CR）来添加 registry 来搜索镜像短名称。OpenShift Container Platform 会将对此 CR 的更改应用到集群中的所有节点。

镜像简短名称允许您搜索镜像，而无需在 pull spec 中包含完全限定域名。例如： 您可以使用 rhel7/etcd 而不是 registry.access.redhat.com/rhe7/etcd。

在无法使用完整路径的情况下，您可以使用简短名称。例如，如果您的集群引用了 DNS 频繁变化的多个内部 registry，则需要更新 pull spec 中的完全限定域名并进行每次更改。在这种情况下，使用镜像简短名称可能很有用。

在拉取或推送镜像时，容器运行时会搜索 image.config.openshift.io/cluster CR 的 registrySources 参数中列出的 registry。如果您在 containerRuntimeSearchRegistries 参数下创建了 registry 列表，则容器运行时会搜索这些 registry。

Machine Config Operator（MCO）会监控 image.config.openshift.io/cluster 资源以了解对 registry 的任何更改。当 MCO 检测到更改时，它会排空节点，应用更改，并对节点进行 uncordon 处理。节点返回 Ready 状态后，如果添加了 containerRuntimeSearchRegistries 参数，MCO 会在每个带有列出 registry 的节点的 /etc/containers/registries.conf.d 目录中创建一个文件。该文件覆盖 /host/etc/containers/registries.conf 文件中的非全限定搜索 registry 的默认列表。没有办法回退到非全限定搜索 registry 的默认列表。

containerRuntimeSearchRegistries 参数只适用于 Podman 和 CRI-O 容器引擎。列表中的 registry 只能用于 pod 规格，不能用于构建和镜像流。

Image.config.openshift.io/cluster 自定资源可包含对配置映射的引用，该配置映射包含要在镜像 registry 访问期间被信任的额外证书颁发机构。

对于每个要信任的额外 registry CA，配置映射键是带有信任此 CA 的端口的 registry 的主机名，而使用 base64 编码的证书是它的值。

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-registry-ca
data:
  registry.example.com: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  registry-with-port.example.com..5000: | 1
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

您可以按照以下过程配置其他CA。

通过设置容器 registry 存储库镜像，您可以进行以下操作：

OpenShift Container Platform 中存储库镜像的属性包括：

可通过以下方式设置存储库镜像：

以下流程提供安装后镜像配置，您可在此处创建 ImageContentSourcePolicy 对象来识别：

标签 (label) 用于管理和组织所生成的对象，如 pod。模板中指定的标签应用于从模板生成的每个对象。

模板的 parameter 部分列出了可覆盖的参数列表。

您可以使用 CLI 来处理定义模板的文件，以便将对象列表返回到标准输出。

快速启动模板是 OpenShift Container Platform 上运行的应用程序的基本示例。Quickstarts 提供多种语言和框架，并在模板中定义，模板由一组服务、构建配置和部署配置组成。该模板引用了构建和部署应用程序所需的镜像和源存储库。

要探索快速启动，请从模板创建应用程序。您的管理员必须已在 OpenShift Container Platform 集群中安装了这些模板，在这种情况下，您只需从 web 控制台中选择即可。

快速开始引用包含应用源代码的源存储库。要自定义 Quickstart，请分叉存储库，并在从模板创建应用程序时，用分叉的存储库替换默认的源存储库名称。这将导致使用您的源代码而非所提供的示例源来执行构建。然后，您可以更新源存储库中的代码，并启动新的构建来查看反映在所部署的应用程序中的更改。

模板描述向用户介绍模板的作用，有助于用户在 web 控制台中搜索查找模板。除模板名称以外的其他元数据均为可选，但若有则会非常有用。除常规描述性信息外，元数据还应包含一组标签。实用标签包括与模板相关的语言名称，如 Java、PHP、Ruby 等。

以下是模板描述性元数据的示例：

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: cakephp-mysql-example 1
  annotations:
    openshift.io/display-name: "CakePHP MySQL Example (Ephemeral)" 2
    description: >-
      An example CakePHP application with a MySQL database. For more information
      about using this template, including OpenShift considerations, see
      https://github.com/sclorg/cakephp-ex/blob/master/README.md.


      WARNING: Any data stored will be lost upon pod destruction. Only use this
      template for testing." 3
    openshift.io/long-description: >-
      This template defines resources needed to develop a CakePHP application,
      including a build configuration, application DeploymentConfig, and
      database DeploymentConfig.  The database is stored in
      non-persistent storage, so this configuration should be used for
      experimental purposes only. 4
    tags: "quickstart,php,cakephp" 5
    iconClass: icon-php 6
    openshift.io/provider-display-name: "Red Hat, Inc." 7
    openshift.io/documentation-url: "https://github.com/sclorg/cakephp-ex" 8
    openshift.io/support-url: "https://access.redhat.com" 9
message: "Your admin credentials are ${ADMIN_USERNAME}:${ADMIN_PASSWORD}" 10

模板可包括一组标签。这些标签添加到模板实例化时创建的各个对象中。采用这种方式定义标签可方便用户查找和管理从特定模板创建的所有对象。

以下是模板对象标签的示例：

kind: "Template"
apiVersion: "v1"
...
labels:
  template: "cakephp-mysql-example" 1
  app: "${NAME}" 2

允许用户提供一个值或在实例化模板时生成一个值作为参数。然后，该值将在引用参数的任意位置上被替换。可在对象列表字段中的任意字段中定义引用。这有助于生成随机密码，或允许用户提供自定义模板时所需的主机名或其他用户特定值。可通过以下两种方式引用参数：

使用 ${PARAMETER_NAME} 语法时，可将多个参数引用合并到一个字段中，并可将引用嵌入到固定数据中，如 "http://${PARAMETER_1}${PARAMETER_2}"。两个参数值均将被替换，结果值将是一个带引号的字符串。

使用 ${{PARAMETER_NAME}} 语法时，仅允许单个参数引用，不允许使用前导/尾随字符。执行替换后，结果值将不加引号，除非结果不是有效的 JSON 对象。如果结果不是有效的 JSON 值，则结果值会被添加引号并视为标准字符串。

单个参数可在模板中多次引用，且可在单个模板中使用两种替换语法来引用。

可提供默认值，如果您未提供其他值则使用默认值：

以下是将确切值设置为默认值的示例：

parameters:
  - name: USERNAME
    description: "The user name for Joe"
    value: joe

还可根据参数定义中指定的规则生成参数值，例如：

parameters:
  - name: PASSWORD
    description: "The random user password"
    generate: expression
    from: "[a-zA-Z0-9]{12}"

在上例中，处理生成一个由大小写字母和数字组成的 12 个字符长的随机密码。

可用语法并非完整的正则表达式语法。但是，您可以使用 \w、\d、\a 和 \A 修饰符：

  parameters:
  - name: singlequoted_example
    generate: expression
    from: '[\A]{10}'
  - name: doublequoted_example
    generate: expression
    from: "[\\A]{10}"

{
    "parameters": [
       {"name": "json_example",
        "generate": "expression",
        "from": "[\\A]{10}"
       }
    ]
}

下面是附带参数定义和参考的完整模板示例：

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: my-template
objects:
  - kind: BuildConfig
    apiVersion: build.openshift.io/v1
    metadata:
      name: cakephp-mysql-example
      annotations:
        description: Defines how to build the application
    spec:
      source:
        type: Git
        git:
          uri: "${SOURCE_REPOSITORY_URL}" 1
          ref: "${SOURCE_REPOSITORY_REF}"
        contextDir: "${CONTEXT_DIR}"
  - kind: DeploymentConfig
    apiVersion: apps.openshift.io/v1
    metadata:
      name: frontend
    spec:
      replicas: "${{REPLICA_COUNT}}" 2
parameters:
  - name: SOURCE_REPOSITORY_URL 3
    displayName: Source Repository URL 4
    description: The URL of the repository with your application source code 5
    value: https://github.com/sclorg/cakephp-ex.git 6
    required: true 7
  - name: GITHUB_WEBHOOK_SECRET
    description: A secret string used to configure the GitHub webhook
    generate: expression 8
    from: "[a-zA-Z0-9]{40}" 9
  - name: REPLICA_COUNT
    description: Number of replicas to run
    value: "2"
    required: true
message: "... The GitHub webhook secret is ${GITHUB_WEBHOOK_SECRET} ..." 10

模板主要部分为对象列表，将在模板实例化时创建。这可以是任何有效的 API 对象，如构建配置、部署配置或服务。该对象按照此处定义创建，创建前替换任意参数值。这些对象的定义可引用前面定义的参数。

以下是对象列表的示例：

kind: "Template"
apiVersion: "v1"
metadata:
  name: my-template
objects:
  - kind: "Service" 1
    apiVersion: "v1"
    metadata:
      name: "cakephp-mysql-example"
      annotations:
        description: "Exposes and load balances the application pods"
    spec:
      ports:
        - name: "web"
          port: 8080
          targetPort: 8080
      selector:
        name: "cakephp-mysql-example"

Template Service Broker 会在目录中为其了解的每个模板对象公告一个服务。默认情况下，每个服务均会公告为“可绑定”，表示允许最终用户绑定制备的服务。

模板创建者可指定模板中的特定对象字段应公开。Template Service Broker 会识别 ConfigMap、Secret、Service 和 Route 上公开的字段，并在用户绑定代理支持的服务时返回公开字段的值。

要公开对象的一个或多个字段，请在模板中为对象添加以 template.openshift.io/expose- 或 template.openshift.io/base64-expose- 为前缀的注解。

每个移除前缀的注解键均会被传递成为 bind 响应中的一个键。

每个注解值是一个 Kubernetes JSONPath 表达式，该表达式将在绑定时解析，以指示应在 bind 响应中返回值的对象字段。

以下是被公开的不同对象字段的示例：

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: my-template
objects:
- kind: ConfigMap
  apiVersion: v1
  metadata:
    name: my-template-config
    annotations:
      template.openshift.io/expose-username: "{.data['my\\.username']}"
  data:
    my.username: foo
- kind: Secret
  apiVersion: v1
  metadata:
    name: my-template-config-secret
    annotations:
      template.openshift.io/base64-expose-password: "{.data['password']}"
  stringData:
    password: bar
- kind: Service
  apiVersion: v1
  metadata:
    name: my-template-service
    annotations:
      template.openshift.io/expose-service_ip_port: "{.spec.clusterIP}:{.spec.ports[?(.name==\"web\")].port}"
  spec:
    ports:
    - name: "web"
      port: 8080
- kind: Route
  apiVersion: route.openshift.io/v1
  metadata:
    name: my-template-route
    annotations:
      template.openshift.io/expose-uri: "http://{.spec.host}{.spec.path}"
  spec:
    path: mypath

下面是在遵守上述部分模板情况下，对 bind 操作的一个响应示例：

{
  "credentials": {
    "username": "foo",
    "password": "YmFy",
    "service_ip_port": "172.30.12.34:8080",
    "uri": "http://route-test.router.default.svc.cluster.local/mypath"
  }
}

模板创建者可指定：在服务目录、Template Service Broker 或 TemplateInstance API 进行的模板实例化被视为完成之前，应等待模板中的某些对象。

要使用该功能，请使用以下注解在模板中标记一个或多个Build、BuildConfig、Deployment、DeploymentConfig、Job 或 StatefulSet 类型的对象：

"template.alpha.openshift.io/wait-for-ready": "true"

直到标有注解的所有对象报告就绪时，模板实例化才算完成。同样，如果任何注解的对象报告失败，或者模板未能在一小时的固定超时内就绪，则模板实例化将失败。

就实例化而言，各种对象类型的就绪和失败定义如下：

以下是使用 wait-for-ready 注解的模板提取示例。更多示例可在 OpenShift Container Platform 快速启动模板中找到。

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: my-template
objects:
- kind: BuildConfig
  apiVersion: build.openshift.io/v1
  metadata:
    name: ...
    annotations:
      # wait-for-ready used on BuildConfig ensures that template instantiation
      # will fail immediately if build fails
      template.alpha.openshift.io/wait-for-ready: "true"
  spec:
    ...
- kind: DeploymentConfig
  apiVersion: apps.openshift.io/v1
  metadata:
    name: ...
    annotations:
      template.alpha.openshift.io/wait-for-ready: "true"
  spec:
    ...
- kind: Service
  apiVersion: v1
  metadata:
    name: ...
  spec:
    ...

您可以 YAML 格式从项目中导出现有对象，然后通过添加参数和其他自定义作为模板表单来修改 YAML，而无需从头开始编写整个模板。

由于 Rails 4 在生产中不再提供静态 public/index.html 页面，您必须创建一个新的 root 页面。

要想具有自定义欢迎页面，必须执行以下步骤：

Rails 提供了一个生成器，用于完成您所有必要的步骤。

要让您的应用程序与 OpenShift Container Platform 中运行的 PostgreSQL 数据库服务通信，必须编辑 config/database.yml 中的 default 部分，以便在创建数据库服务时使用环境变量，稍后会对这些变量进行定义。

在 OpenShift Container Platform 中构建应用程序通常需要将源代码存储在 git 存储库中，因此如果还没有 git，必须要安装。

您的 Rails 应用程序需要一个正在运行的数据库服务。对于此服务，请使用 PostgreSQL 数据库镜像。

要创建数据库服务，使用 oc new-app 命令。您必须将一些在数据库容器中使用的必要环境变量传递给此命令。设置用户名、密码和数据库名称需要这些环境变量。您可随意更改这些环境变量的值。变量如下：

设置这些变量可确保：

要将应用程序添加到 OpenShift Container Platform 中，您必须指定应用程序所在存储库。

您可公开服务来为您的应用程序创建路由。

您可采用两种方式管理 Jenkins 身份验证：

Jenkins 服务器可通过以下环境变量进行配置：

如果要在与您的项目不同的其他位置运行 Jenkins，则必须向 Jenkins 提供访问令牌来访问您的项目。

可使用挂载卷运行 Jenkins 镜像，以便为配置启用持久性存储：

要自定义官方 OpenShift Container Platform Jenkins 镜像，您可以使用该镜像作为 Source-to-image（S2I）构建程序。

您可使用 S2I 来复制自定义 Jenkins 任务定义，添加其它插件，或使用您自己的自定义配置来替换所提供的 config.xml 文件。

要在 Jenkins 镜像中包括您的修改，必须要有采用以下目录结构的 Git 存储库：

pluginId:pluginVersion

configuration/ 目录的内容会被复制到 /var/lib/jenkins/ 目录中，以便也可以包括其他文件，如 credentials.xml。

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: custom-jenkins-build
spec:
  source:                       1
    git:
      uri: https://github.com/custom/repository
    type: Git
  strategy:                     2
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: jenkins:2
        namespace: openshift
    type: Source
  output:                       3
    to:
      kind: ImageStreamTag
      name: custom-jenkins:latest

OpenShift Container Platform Jenkins 镜像包含预装的 Kubernetes 插件，支持使用 Kubernes 和 OpenShift Container Platform 在多个容器主机上动态置备 Jenkins 代理。

为了使用 Kubernetes 插件，OpenShift Container Platform 提供了适合用作 Jenkins 代理的镜像，包括 Base、Maven 和 Node.js 镜像。

Maven 和 Node.js 代理镜像均会在 OpenShift Container Platform Jenkins 镜像的 Kubernetes 插件配置中自动配置为 Kubernetes Pod 模板镜像。该配置包含各个镜像的标签，可应用于 “Restrict where this project can be run” 设置下的任何 Jenkins 任务。如果应用了标签，任务将在运行相应代理镜像的 OpenShift Container Platform Pod 下运行。

Jenkins 镜像还为 Kubernetes 插件提供附加代理镜像的自动发现和自动配置。

使用 OpenShift Container Platform Sync 插件，Jenkins 启动上的 Jenkins 镜像会在其运行的项目中或插件配置中特别列出的项目中搜索以下内容：

当找到具有适当标签的镜像流或带有适当注解的镜像流标签时，它会生成对应的 Kubernetes 插件配置，以便您可以将 Jenkins 任务分配在运行镜像流提供的容器镜像的 pod 中运行。

镜像流或镜像流标签的名称和镜像引用映射到 Kubernetes 插件 pod 模板中的名称和镜像字段。您可以通过使用 agent-label 键在镜像流或镜像流标签对象上设置注解来控制 Kubernetes 插件 pod 模板的标签字段。否则，名称将用作标签。

当找到具有适当标签的配置映射时，它会假定配置映射的键值数据有效负载中的任何值均包含与 Jenkins 和 Kubernetes 插件 pod 模板的配置格式一致的 XML。使用配置映射而非镜像流或镜像流标签时，需要注意的一个关键区别在于，您可以控制 Kubernetes 插件 pod 模板的所有参数。

kind: ConfigMap
apiVersion: v1
metadata:
  name: jenkins-agent
  labels:
    role: jenkins-agent
data:
  template1: |-
    <org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
      <inheritFrom></inheritFrom>
      <name>template1</name>
      <instanceCap>2147483647</instanceCap>
      <idleMinutes>0</idleMinutes>
      <label>template1</label>
      <serviceAccount>jenkins</serviceAccount>
      <nodeSelector></nodeSelector>
      <volumes/>
      <containers>
        <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
          <name>jnlp</name>
          <image>openshift/jenkins-agent-maven-35-centos7:v3.10</image>
          <privileged>false</privileged>
          <alwaysPullImage>true</alwaysPullImage>
          <workingDir>/tmp</workingDir>
          <command></command>
          <args>${computer.jnlpmac} ${computer.name}</args>
          <ttyEnabled>false</ttyEnabled>
          <resourceRequestCpu></resourceRequestCpu>
          <resourceRequestMemory></resourceRequestMemory>
          <resourceLimitCpu></resourceLimitCpu>
          <resourceLimitMemory></resourceLimitMemory>
          <envVars/>
        </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
      </containers>
      <envVars/>
      <annotations/>
      <imagePullSecrets/>
      <nodeProperties/>
    </org.csanchez.jenkins.plugins.kubernetes.PodTemplate>

安装后，OpenShift Container Platform Sync 插件会监控 OpenShift Container Platform 的 API 服务器，以获取对镜像流、镜像流标签和配置映射的更新，并调整 Kubernetes 插件的配置。

适用以下规则：

要将容器镜像用作 Jenkins 代理，镜像必须运行该代理作为入口点。有关此方面的更多详情，请参阅官方 Jenkins 文档。

在 ConfigMap 中，如果 Pod 模板 XML 的 <serviceAccount> 元素是用于生成的 pod 的 OpenShift Container Platform 服务帐户，则服务帐户凭证将挂载到 pod 中。权限与服务帐户关联，并控制允许从 pod 对 OpenShift Container Platform master 执行的操作。

考虑以下场景，服务帐户用于 OpenShift Container Platform Jenkins 镜像中运行的 Kubernetes 插件启动的 pod：

如果您使用 OpenShift Container Platform 提供的 Jenkins 示例模板，则 jenkins 服务帐户将由运行 Jenkins 的项目的 edit 角色定义，且 master Jenkins Pod 已挂载了该服务帐户。

注入 Jenkins 配置的两个默认 Maven 和 NodeJS Pod 模板也将设置为使用与 Jenkins master 相同的服务帐户。

模板提供参数字段来定义具有预定义默认值的所有环境变量。OpenShift Container Platform 提供模板，以简化 Jenkins 服务的新建操作。在初始集群设置期间，您的集群管理员应在默认 openshift 项目中注册 Jenkins 模板。

提供的两个模板均定义了部署配置和服务。两个模板的不同之处在于存储策略，这会影响在 Pod 重启后是否保留 Jenkins 内容。

要使用 PV 存储，集群管理员必须在 OpenShift Container Platform 部署中定义一个 PV 池。

选好所需模板后，您还必须对模板进行实例化，才能使用 Jenkins。

在以下示例中，openshift-jee-sample BuildConfig 对象会导致 Jenkins Maven 代理 pod 动态置备。pod 会克隆一些 Java 源代码，构建一个 WAR 文件，并导致第二个 BuildConfig openshift-jee-sample-docker 运行。第二个 BuildConfig 会将新的 WAR 文件分层到一个容器镜像中。

kind: List
apiVersion: v1
items:
- kind: ImageStream
  apiVersion: image.openshift.io/v1
  metadata:
    name: openshift-jee-sample
- kind: BuildConfig
  apiVersion: build.openshift.io/v1
  metadata:
    name: openshift-jee-sample-docker
  spec:
    strategy:
      type: Docker
    source:
      type: Docker
      dockerfile: |-
        FROM openshift/wildfly-101-centos7:latest
        COPY ROOT.war /wildfly/standalone/deployments/ROOT.war
        CMD $STI_SCRIPTS_PATH/run
      binary:
        asFile: ROOT.war
    output:
      to:
        kind: ImageStreamTag
        name: openshift-jee-sample:latest
- kind: BuildConfig
  apiVersion: build.openshift.io/v1
  metadata:
    name: openshift-jee-sample
  spec:
    strategy:
      type: JenkinsPipeline
      jenkinsPipelineStrategy:
        jenkinsfile: |-
          node("maven") {
            sh "git clone https://github.com/openshift/openshift-jee-sample.git ."
            sh "mvn -B -Popenshift package"
            sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war"
          }
    triggers:
    - type: ConfigChange

它还可覆盖动态创建的 Jenkins 代理 pod 的规范。下面是对前一示例的修改，可覆盖容器内存并指定环境变量：

kind: BuildConfig
apiVersion: build.openshift.io/v1
metadata:
  name: openshift-jee-sample
spec:
  strategy:
    type: JenkinsPipeline
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        podTemplate(label: "mypod", 1
                    cloud: "openshift", 2
                    inheritFrom: "maven", 3
                    containers: [
            containerTemplate(name: "jnlp", 4
                              image: "openshift/jenkins-agent-maven-35-centos7:v3.10", 5
                              resourceRequestMemory: "512Mi", 6
                              resourceLimitMemory: "512Mi", 7
                              envVars: [
              envVar(key: "CONTAINER_HEAP_PERCENT", value: "0.25") 8
            ])
          ]) {
          node("mypod") { 9
            sh "git clone https://github.com/openshift/openshift-jee-sample.git ."
            sh "mvn -B -Popenshift package"
            sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war"
          }
        }
  triggers:
  - type: ConfigChange

构建完成后会默认删除 pod。可以使用插件或在 Jenkinsfile 管道中修改此行为。

使用所提供的 Jenkins Ephemeral 或 Jenkins Persistent 模板部署时，默认内存限值为 1 Gi。

默认情况下，Jenkins 容器中运行的所有其他进程使用的内存总量不超过 512 MiB。如果这些进程需要更多内存，容器将停止。因此，我们强烈建议管道尽可能在代理容器中运行外部命令。

如果 Project 配额允许，请参阅 Jenkins 文档，了解 Jenkins master 应具有多少内存的建议。这些建议禁止为 Jenkins master 分配更多内存。

建议您为 Jenkins Kubernetes 插件创建的代理容器指定内存请求和限制值。管理员用户可通过 Jenkins 配置基于每个代理镜像设置默认值。内存请求和限值参数也可基于每个容器覆盖。

在实例化 Jenkins Ephemeral 或 Jenkins Persistent 模板时，您可通过覆盖 MEMORY_LIMIT 参数来增加 Jenkins 的可用内存量。

OpenShift Container Platform Jenkins 代理镜像在 Quay.io 或 registry.redhat.io 上提供。

Jenkins 镜像通过 Red Hat Registry 提供：

$ docker pull registry.redhat.io/openshift4/ose-jenkins:<v4.5.0>

$ docker pull registry.redhat.io/openshift4/jenkins-agent-nodejs-10-rhel7:<v4.5.0>

$ docker pull registry.redhat.io/openshift4/jenkins-agent-nodejs-12-rhel7:<v4.5.0>

$ docker pull registry.redhat.io/openshift4/ose-jenkins-agent-maven:<v4.5.0>

$ docker pull registry.redhat.io/openshift4/ose-jenkins-agent-base:<v4.5.0>

要使用这些镜像，您可直接从 Quay.io 或 registry.redhat.io 访问或将其推送（push）到 OpenShift Container Platform 容器镜像 registry 中。

每个 Jenkins 代理容器均可通过以下环境变量进行配置。

所有 Jenkins 代理均使用 JVM 来托管 Jenkins JNLP 代理和运行任何 Java 应用程序，如 javac、Maven 或 Gradle。

默认情况下，Jenkins JNLP 代理 JVM 会将容器内存限值的 50% 用于其堆。该值可通过 CONTAINER_HEAP_PERCENT 环境变量修改，还可设置上限或整个覆盖。

默认情况下，Jenkins 代理容器中运行的其它进程（如 shell 脚本或从管道运行的 oc 命令）在不引发 OOM 终止的情况下，所用内存均不得超过剩余的 50% 内存限值。

默认情况下，Jenkins 代理容器中运行的每个其他 JVM 进程最多可将 25％ 的容器内存限值用于其堆。对于很多构建工作负载，可能还需调整此限值。

在 OpenShift Container Platform 上的 Jenkins 代理中托管 Gradle 构建会出现其他复杂情况，因为除了 Jenkins JNLP 代理和 Gradle JVM 外，Gradle 还会生成第三个 JVM 来运行测试（若已指定）。

建议将以下设置作为起始点，在 OpenShift Container Platform 上内存受限的 Jenkins 代理中运行 Gradle 构建。您还可按需修改这些设置。

构建完成后或停止后会默认删除 Jenkins 代理 pod。此行为可通过 Kubernetes 插件 pod 保留设置来更改。Pod 保留可针对所有 Jenkins 构建设置，并覆盖每个 pod 模板。支持以下行为：

您可覆盖管道 Jenkinsfile 中的 pod 保留：

podTemplate(label: "mypod",
  cloud: "openshift",
  inheritFrom: "maven",
  podRetention: onFailure(), 1
  containers: [
    ...
  ]) {
  node("mypod") {
    ...
  }
}

Source-to-Image（S2I）通过将源代码注入准备要运行的源代码的容器来生成可随时运行的镜像。它执行以下步骤：

然后，Buildah 会创建容器镜像。

构建器镜像提供自己的 Source-to-image（S2I）脚本版本，它适用于最常用的用例。如果这些脚本无法满足您的需要，S2I 提供了在 .s2i/bin 目录中添加自定义脚本覆盖它们的方法。但是，这样做代表完全替换了标准脚本。在某些情况下，替换脚本是可以接受的，但在其他情况下，您可以在脚本之前或之后运行一些命令，同时保留镜像中提供的脚本逻辑。要重复使用标准脚本，您可以创建一个运行自定义逻辑的 wrapper 脚本，并将它进一步分配给镜像中的默认脚本。