OpenShift的容器镜像（第1部分）：目标
本文来源于2017 EMEA （Europe, the Middle East and Africa，欧洲，中东和非洲） 红帽技术交流会议的会议记录，与会者包括了来自于欧洲、中东和非洲的所有的红帽解决方案架构师及顾问，会议内容是关于构建 OpenShift 镜像的思考和最佳实践案例，文章分为以下四个板块进行叙述：
- 目标
- 构建您的镜像
- 保证镜像的可用
- 云就绪
本文是该系列的首篇文章，在这一篇文章中我们将看到通过使用容器 (container) 能够达到的常规目标，并在镜像的设计阶段去审视这些目标。
黄金镜像
容器令我着迷的原因之一是，容器允许应用程序所需要的所有依赖项打包到单个部署单元中，这个部署单元被称为黄金镜像，黄金镜像为运行环境的迁移提供了便利。例如，您可以环境其从集成 (integration) 环境迁移到 UAT (User Acceptance Test，用户验收测试) 环境或从准上线 (staging) 环境迁移到生产 (production)环境。因为单个单元中部署了所有依赖关系，所以可以保证在前一个单元的环境下可以正常运行的应用，在后一个单元的环境下仍然可以正常运行。
在容器崛起之前，很多公司困于应用程序的推广上，其中有些人为此写了详细的安装步骤说明，并且必须手动安装应用程序和严格遵循应用程序安装步骤，而另一些人也为此投入了大量的精力，他们利用 Puppet ， Chef 或者 Python 开发软件自动化构建脚本。此外，除了初始的投入外，还需要大量的维护工作来应对软件的升级和变更所带来的各种各样的难题。容器带来的是一套简单的标准化解决方案，因为容器镜像涵盖了应用程序的依赖关系（操作系统，运行时环境（例如：JVM (Java Virtual Machine, Java虚拟机)），库以及一些配置），通过启动容器镜像实例，可以将应用程序部署于不同的环境之中。
可再生性
之后相同的镜像构建方式会产生相同的结果，这对于可用于补丁、升级和进一步演进至稳定环境是非常重要的，因为创建容器镜像的依赖项（库或其他镜像）应具有相同的引用和版本。
敏捷的标准运行环境
同质化的企业软件环境具有以下鲜明的优势：
- 通过限制支持潜在的软件的运行环境的数量，来节省维护时间及成本。
- 方便搭建适用于业务部门的软件运行环境，这对于及时解决突发事件是至关重要的。
- 在多个不同的环境下，更容易建立合规 (
Compliance)。 - 方便工作人员，因为软件运行环境相同，有利于员工更容易适应岗位地变更。
在定义镜像格局时，应该考虑上述优势带来的便利性。而严格执行 SOE (Server Object Extension, 服务对象扩展) 和缓慢迭代 SOE 会造成企业反应迟缓，容器镜像可以帮助您实现高可重用性和方便对多个目标进行集中更改。
可重用性
第一次创建 SOE 时，限制能注入镜像的区域的数量是非常重要的，比如框架、应用程序服务器、驱动程序和脚本等，这些区域涉及基础功能、连接性、监听、资源跟踪管理、安全性等。可以依靠继承和组合的分层方法支持可重用性，在实现可重用性上重点考虑全局镜像而不是单一镜像。
可维护性
上一节提到的中央注入点也是修补和升级的关键，这些更改（可能由软件提供商作为容器镜像提供）需要自动级联，以便使维护变得简单。
在前容器时代，我看到很多公司困于 Java 或应用服务器版本更新和安全修复，容器技术具备在中心位置应用和变更的可能性，并使容器在软件环境中推出既不费力，也不需要停机支持，这在安全性和可靠性方面影响巨大。因此，镜像设计时需要考虑可维护性。
资源利用效率
在创建应用程序时，显而易见的目标是尽量小的消耗资源（RAM，CPU，存储等）。使用镜像进行包装意味着密度更高，成本更低，与虚拟机相比，容器的优势是共享相同内核而不是创建额外实例，这可以通过容器共享层来进一步实现，遵循上述目标的容器让 SOE 和可重用成为可能，尽管镜像容量大小确实影响读取和释放镜像所需的时间，但用于 RAM 和存储的容量有比用于镜像容量更大的作用。
安全
除了保证操作系统、应用程序服务器和其他库的补丁及时更新至最新安全性版本之外，在创建镜像时，还需要考虑一些安全性方面的其他重要内容：
- 减少攻击面：通过将镜像内部安装的内容限制在运行容器所需的内容来实现。
- 限制功能：高权限容器应该有额外的执行特定安全措施的手段。如安装主机文件系统，绑定主机端口，或使用与主机用户相匹配的特定用户标识识别，其他功能仅在没有其他选项可用时才被授权，并且在仔细检查安全性影响风险之后得到释放。
- 有限资源：容器镜像应该在有限资源（
CPU，RAM，网络，存储）下构建，以便单个容器受到拒绝服务 (DOS) 攻击时，保证同一台主机上其他容器正常运行。
弹性
像 Kubernetes 和 OpenShift 这样的 PaaS (Platform-as-a-Service, 平台即服务) 平台提供了监控和自我修复机制。PaaS 依靠容器准备就绪和容器监测探针 (Liveness Probes) 确保以下行为：
- 当容器没有准备好时，请求不会被发送到容器。实际上，这意味着容器没有完成启动，正在进行终止操作或者其中一个依赖项（数据库，服务）不可用。
- 容器监测探针检测失败时，容器将重新启动，重新启动后容器将恢复到初始状态，类似于返厂重置。
作为一名镜像设计师，您的责任是保证容器的稳定就绪和提高容器监测探针的可用性。
另一个方面是，当 OpenShift 想要终止一个容器时，它首先将容器从请求处理旋转中移出，并发送一个 SIGTERM 信号，它为应用程序在中止前正常关闭提供了时间，如果允许的期限已过，则使用 SIGKILL 信号。在这方面，镜像内的应用程序完成了处理正在进行的请求，释放资源，并在接收到 SIGTERM 信号时终止。
易于使用
可复用性经常被作为一个目标提及，但是，只有在镜像易于使用的情况下可复用性才能较好的实施，容器的易于使用包括以下几个方面：
- 首先应该考虑扩展点的构建。方便通过继承、组成或利用扩展点来进行扩展。作为一名镜像设计师，您有责任思考如何以简单的方式添加功能或自定义镜像。
- 其次应该考虑文档。文档应包括记录镜像的使用目的，使用情况以及运行参数，例如它的起始位置，使用的端口，可供写入数据的目录等，镜像快速启动方便终端用户了解并使用镜像。
我希望您会觉得第一篇文章是有趣的，在下面的文章中，我们将会使用技术和方法实现本篇已经提到过的目标。敬请关注！