OpenShift的容器映像（第3部分）：使你的映像可用

这是我在2017年欧洲、中东和非洲（EMEA）红帽技术交流会议上的一个会议记录，该会议集合了EMEA所有红帽解决方案架构师和顾问。它主要讨论在创建运行于OpenShift上的映像时需要考虑的事项和好的实践(案例)。第三部分重点介绍如何让应用程序开发者或发布管理员更容易地使用映像。

版本

当你指定映像以启动容器或创建子映像时，你需要提供要使用的版本。如果没有，则使用带有“latest”标签的版本。

让我们来看看红帽创建版本层次结构的方式。这是一个很好的策略示例，你可以重复使用自己的映像。

一个非常重要的方面是在下游用户的标签内保持向后兼容性。新版本的映像的发布不应该破坏子映像。

红帽映像版本与产品相对应，该产品是容器的一部分。举例来说，rhel7 / rhel标记的方式如下：

7.4-81 / 7.4 / latest
7.3-97 / 7.3
7.3-95
7.3-82
...

请注意，没有7标记，因为兼容性在主版本之间不能保证 - 仅在次版本之间可以。看到这篇文章的底部。标签7.4-81,7.4和最新的参考相同的映像。映像用户可以任意使用这些标签中的其中一个，各个标签如下：

• 最新版本：每次推出新版本时，用户都会得到不同的映像。
• 7.4：每次推送次版本7.4的新版本时，用户都会得到不同的映像。子映像自动获取补丁。
• 7.4-81：用户不会得到更新。

对于你想要在生产中验证和运行的任何东西，你应该使用一个稳定的标签，而不是使用最新的。这个建议是适用于小版本，如示例中的7.4，这样你的映像就会自动更新补丁。如果你在这里发布一个特定的版本，比如说7.4-81，你需要有一个合适的工作流程来修补你自己的映像。

你可以在开发映像的项目中使用最新的标签，以自动查看最新的更改。更少情况是，在开发阶段，你可能希望只要最新版本一发布就使用该版本的映像。

文档

使映像可用的下一个方面显然是文档。用户指南肯定是有用的，但你也可以在映像或OpenShift级别上做些其他的事情。

通过提供快速启动的模板，可以演示用户如何根据映像运行应用程序。

使用映像元数据，你可以将最重要的要点记录在映像本身中：

• 你可以使用标签来添加说明，提供维护人员的联系信息，权威来源的地址，构建，发布和组件信息等。
• 公开在Dockerfile中重要的端口也提供了关于如何运行映像和应用程序应该如何连接的重要信息。
• 与公开端口相同。映像使用者然后意识到数据在映像内被写入的地方可能需要被持久化。
• 设置环境变量，如PATH，JAVA_HOME和对映像配置的声音默认设置也有助于一个简单的开始。
• 最后，你必须用CMD或ENTRYPOINT(入口点)来指定你的映像进程如何开始。

以下是RHEL7映像可用的元数据摘录。完整的设置在这里可用。

rhel7 / RHEL：

Env
    PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin  
    container=oci
Cmd
    /bin/bash
Labels
    com.redhat.component rhel-server-docker
    authoritative-source-url registry.access.redhat.com
    distribution-scope public
    vendor Red Hat, Inc.
    description The Red Hat Enterprise Linux Base image...
[...]

扩展点

在第二部分中，我们首先看到了扩展点。使映像使用者能够覆盖映像创建者无法预见的场景和配置，或者使组合数量难以管理的场景和配置非常重要。扩展点旨在避免将你创建的映像层重写为映像的一部分。

运行时注入环境信息

这可以通过两种方式完成：通过设置环境变量或在启动时将文件挂载到容器文件系统中。

环境变量可以添加到部署配置中或由ConfigMap提供。你可以使用这种方式指定应用程序调用的服务的地址。

可以从ConfigMaps中将文件挂载到容器上，以提供日志配置，或从Secrets中以提供应用程序所需的证书或其他凭据。

在生成时配置

如果你创建了一个构建器映像，则可能还需要用户注入构建配置。例如，你可以允许指定一个带有环境变量的Maven仓库。但是，这可能还不够，而且你的构建器映像应允许用户使用源注入完整的settings.xml。

你可能已经在汇编脚本中定义了应用程序的编译和映像的配置。映像库和驱动程序的灵活性可以通过映像采集（参见本系列的第2部分）提供给最终映像，但允许映像用户通过扩展或者取代它的一些逻辑来调整构建过程仍然是个不错的方法。例如，可以通过使在汇编脚本中生成或调用的脚本能够被用户的应用源代码提供的脚本替换，从而实现这一点。

外部构建

在第2部分中，我们也看到允许用户在外部构建应用程序，并只在OpenShift上构建容器映像。这背后的理由是，在引入容器技术之前，公司可能已经投资了自动化和集成的CI / CD管道和相关的基础设施。外部构建允许他们继续使用这个基础设施，因为他们正在转移到一个作为服务平台的容器。

有两个明智的做法。第一个方法是将应用程序工件从其CI工具（例如Jenkins）通过二进制构建流式传输到构建器映像中。

第二种方法是从公司存储库下载工件。这可以使用curl或wget来完成，但对于Java应用程序，你可能已经在构建器映像中拥有Maven，Maven依赖关系插件是一种便捷方式。