OpenShift 的容器镜像（第 3 部分）：使您的镜像易用

这是我在欧洲，中东和非洲（EMEA）红帽技术交流 2017 会议上的一个会议记录，与会者包括 EMEA 所有红帽解决方案架构师和顾问。会议的主要内容包括了在创建运行于 OpenShift 上的镜像时，需要考虑事项和最佳实践。第三部分重点介绍如何让应用程序开发人员或发布经理创造出更容易使用的镜像。

版本

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

让我们瞧瞧红帽创建版本层次结构的方式。这是一个很好的例子，您可以对号入座到自己的镜像。

一个要点在于对旧版本的 release 保持向后兼容性。新版本的 release 不应该破坏对旧版本的兼容。

红帽镜像版本与产品保持一致，该产品是容器的一部分。举例来说，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 和 latest 均指向相同的镜像, 但是效果不同：

• latest：每次推出新版本时，消费者都会得到最新的镜像。
• 7.4：每次推送次版本 7.4 的新版本时，用户都会得到最新的镜像。子镜像将会自动获取修补程序。
• 7.4-81：用户将不会得到更新。

对于你想要在生产中验证和运行的任何东西，你应该瞅准一个稳定的标签，而不是使用 latest。推荐你重点考察次版本号，在这个例子中是 7.4，这样你的镜像就会自动更新补丁。如果你使用了一个特定的版本，比如 7.4-81，你需要有一个合理的定时任务来给镜像打补丁。

您可能需要在开发中使用 latest 标签，以自动查看最新的改动。也有少数人，在开发阶段，希望任何时候都可以使用最新的镜像。

文档

使镜像易于使用的另一个方面显然是文档。用户指南肯定是功德无量的，但在镜像本身或 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...
[...]

扩展点

在第二部分中，我们谈及了扩展点，不过这只是管中窥豹而已。使用户能够了解镜像创建者没有预见的场景，配置或者是各种难以管理的排列组合非常重要。扩展点旨在避免将您创建的 layers 重写为镜像的一部分。

运行时注入环境信息

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

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

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

在生成时配置

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

您可能已经在汇编脚本中定义了应用程序的编译和镜像的配置。在镜像采集（参见本系列的第2部分）中可以提供镜像库和驱动程序的灵活性， 但仍然允许镜像用户通取代它的一些逻辑。例如，可以通过在汇编脚本中生成或调用脚本来替换用户使用应用程序源提供的脚本。

外部构建

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

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

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