OpenShift的容器镜像（第1部分）：目标

这是我在EMEA红帽技术2017交流会议（Red Hat Tech Exchange 2017）上所做的文字记录，这是一个由所有的Red Hat解决方案架构师和顾问组成的会议。在创建将在OpenShift上运行的镜像时，需要对此进行考虑和良好实践。该内容由四篇帖子构成：

• 目标
• 构建您的镜像
• 使您的镜像更易使用
• 云服务准备

这是第一篇文章，我们将看到与使用容器镜像的使用相关的共同目标。这些目标将在镜像的设计阶段会被考虑到。

镜像

容器让人们充满兴趣的原因之一是，它允许将具有所有依赖项的应用程序打包到单个部署单元中。这个部署单元，就是镜像，可以从一个环境迁移到下一个环境。例如，您可以将其从集成环境迁移到UAT（User Acceptance Test：用户验收测试）或从分段环境迁移到生产环境。将所有依赖关系放在一个单元中，可以保证在前一阶段验证的内容也将被部署到下一个阶段。

01.png

在容器崛起之前，我看到很多公司在应用推广上苦苦挣扎。其中有些人已经编写了详细的安装程序，必须手动安装还有小心得遵守说明。其他人则根据Puppet，Chef或Python脚本的自动化构建方面投入了大量的精力。此外，最初的努力还需要大量的维护工作来应对演化和变化。他们中的大多数人都经历过各种各样的问题。容器带来的是一个标准和简单的方法。应用程序依赖关系（操作系统，系统运行时环境（JVM等），库以及一些配置信息和环境）是容器镜像的一部分，它只是用于在一个或另一个环境中启动容器实例。

可重复

随后的镜像创建应该产生相同的结果。这对于获得可用于补丁，升级和进一步演进的稳定参考非常重要。这要求用于创建容器镜像的依赖项（库或其他镜像）被唯一引用和版本化。

敏捷的标准操作环境

02.png

企业软件领域的同质化水平有明显的好处:

• 通过限制可能需要支持的组合的数量来节省维护的时间和成本。
• 在需要操作时拥有已知的环境。运营商知道该期待什么，这对于及时解决事件可能是至关重要的。
• 在几个不同的环境下，合作更容易。
• 对员工来说更容易。员工可以更容易地从一个领域转移到另一个领域，因为他们依赖相同的技术。

定义镜像范围时应该考虑到这几点。这就是说，严格执行和缓慢发展的 SOE（参与型系统：Systems of engagement） 有时成为企业快速反应的障碍。容器镜像可以帮助解决这方面的问题，通过可重用性和将中心更改应用于多个目标的易用性操作。

可重用性

限制组件注入像框架，应用服务器，驱动程序和脚本等镜像中是非常重要的。这些可以用于基础功能，连接，监控，资产跟踪和管理，安全等。使用继承和组合的分层方法可能支持这一点。在这方面，考虑到全球的镜像范围而不是单一的镜像是很重要的。

可维护性

上一节提到的中央注入点也是修补和升级的中心点。这些更改（可能由软件提供商提供的容器镜像）需要自动级联，以便进行维护。

在容器出现以前的时代，我看到很多公司都在努力保持他们Java或应用服务器的补丁版本和安全修复服务是最新的。容器技术结合了核心应用变化更新的可能性，并使这些应用在软件环境中毫不费力，也不需要停机的情况下更新。这在安全性和可靠性方面会产生巨大的影响。因此，镜像设计时需要考虑可维护性。

资源效率

在创建应用程序时，资源（RAM，CPU，存储等）的最小消耗是一个明显的目标，用于打包的镜像。它意味着密度更高，成本更低。与虚拟机相比，容器具有共享相同内核而不是创建额外实例的优势。这可以通过使用容器共享层来进一步推动。这是通过以下几个已经提到的目标实现的:SOE（参与型系统：Systems of engagement）和可重用性。尽管大小确实影响推送和拉取镜像所需的时间，但它在最终的RAM和存储使用方面起着更大的作用。

安全

除了保持操作系统，应用服务器和其他库及时修补最新的安全性补丁之外，在创建镜像时还需要考虑一些其他重要方面安全性的问题：

• 减少攻击面：这可以通过将镜像内部安装的内容限制为运行容器所需的操作来实现。
• 限制功能：特权容器应该是执行特定安全措施的例外。其他功能，如安装主机文件系统，绑定主机端口，或使用可能与主机上的用户相匹配的特定用户标识运行，只有在没有其他选项可用时才被授予，并且在安全影响被检查和风险减轻之后才授予。
• 有限的资源：容器镜像应该以这样一种方式构建，它能够在有限的资源(CPU、RAM、网络、存储)下运行，以便它不会成为拒绝服务攻击主机并且和其他容器在同一台主机上运行。

弹性

像Kubernetes和OpenShift这样的PaaS平台提供了监控和自我修复的机制。事先准备和活性探测服务确保了：

• 当没有准备好时，没有请求被发送到容器，实际上，这意味着它没有完成启动，它正在终止，或者它的一个依赖项（数据库，服务）不可用。
• 活性探测失败时，容器将重新启动。重新启动一个容器将其恢复到初始状态，类似于工厂重置。

作为一名镜像设计师，您的责任是提供可用的事先准备和活性探测服务。

另一个方面是，当OpenShift想要终止一个容器时，它首先将容器从请求处理循环中移出并发送一个SIGTERM信号。它为应用程序在结束之前正常关闭提供了时间。如果允许的期限已经过期，则使用SIGKILL信号。在这方面，镜像内的应用程序应该完成处理正在进行的请求的处理，同时释放资源，并在接收到SIGTERM信号时终止。

容易使用（易用行）

可复用性已经被提及作为一个指标了。但是，只有在镜像容易使用的情况下，这才能达到一个良好的水平，易用性包括以下几个方面：

• 通过继承，组成或利用扩展点来扩展。但是扩展点需要首先考虑。作为一名镜像设计师，您有责任思考如何添加功能或自定义镜像，并以简单的方式实现。
• 文档：这包括记录镜像的目的，用法以及运行时的重要信息，例如它的入口点，使用的端口，应用程序可以写入数据的目录等。为镜像提供快速启动入口也是一种方法，可以帮助用户了解如何使用镜像。

我希望你发现这第一部分很有趣。在下面的文章中，我们将会了解到实现这些目标的技术和方法。敬请关注！