DevOps 流程中对于 Docker Image 的分层管理与实践

概念介绍

Docker

Docker 是1个开源的利用容器引擎，让开发者可以打包他们的利用和依赖包到1个可移植的容器中，然后发布到任何流行的 Linux 机器上，也能够实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）；几近没有性能开消，可以很容易地在机器和数据中心中运行。最重要的是,它们不依赖于任何语言、框架包括系统。

DevOps

DevOps（英文 Development 和 Operations 的组合）是1组进程、方法与系统的统称，用于增进开发（利用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日趋清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。愈来愈多的企业和项目将整体的代码管理、构建、集成、发布流程通过 DevOps 自动整合在了1起。同时还融入自动化测试等其他技术，使得全部全部软件产品的生命周期实现了可延续的运转。

Docker Image 分层存储

为了最大化重用 Image，加快运行速度，减少内存和磁盘的占用，Docker container 运行时所构造的运行环境，实际上是由具有依赖关系的多个 Layer 组成的。如图 1 所示，每串数字 ID 就代表了1个 Docker Image Layer。当我们在 pull 1个 Docker Image 的时候我们会发现所有依赖的 Layer 文件将会被 download。

图 1. Docker Image 分层示意图

例如1个 Docker App Image 的运行环境是在基础的 Docker Base Image 的基础上，叠加了包括例如 JDK 等各种工具的 Image，再叠加包括 Liberty 及其相干依赖 Liberty 的 Image，和包括了 J2EE 利用的 EAR 包的 layer。这些 Image 由 AUFS 文件系统加载合并到统1路径中，以只读的方式存在，最后再叠加加载1层可写的空白的 Layer 用作记录对当前运行环境所作的修改。因此，当 Docker Image 每次由1个基础 Image 创建后，新 Image 就自动增加了1层。如图 2 所示

图 2. Docker Image Layer 的叠加

Docker Image 在 DevOps 流程中的利用

虽然 Puppet、Chef、Salt 和其它先行者已在 DevOps 的探索中作出了相当的贡献，但这些工具的主要活动舞台依然集中在运营团队而非开发者群体当中。

由于 Docker 的可移植性和容器的封装性。开发人员可以在容器机制内部工作，而运营工程师则能够在容器外部以并行处理自己的任务，使其成了1款能够在开发人员群体中取得与运营工程师同等认可效果的 DevOps 工具。

Docker 技术在 DevOps 进程中使用方式并没有特别的规定，但大致可分为两类

（1）将产品封装到 Docker 容器中做成 immutable 的 Image 使用

（2）将 docker 容器作为固定并统1的运行环境。与构建出来的产品进行绑定使用。

两种使用方式上并没有本质的差别，完全根据实际情况进行选择。本文下面的章节将主要以将产品封装到 Docker 容器中做成 immutable image 的方式为背景进行介绍。基于 Docker 的 DevOps 流程如图 3 所示：

图 3. 基于 Docker 的 DevOps 流程图

随着项目基于 Docker 的使用逐步增加，Docker Image 的数量也将逐步增加。随之而来的问题就是如何保护这些 Docker Image 的升级。如果缺少计划和设计，每一个 Docker Image 均来自1个最基础的 OS Image，那末就需要对所有的 Docker Image 进行重构。如图 4 所示：

图 4. Docker Image 衍生单1 Base Image

当环境进行更新升级的时候，如果所有的节点均来自1个基础的 OS Image，重复的 layer 层将会被重复更新。也就意味着，这部份重复的内容会被反复的下载。如果1个 Docker Image 到达了 1G 以上的范围，而每一个 Docker Host 节点的更新都需要重新下载新的 Image. 这样环境更新所花费的时间将会是成倍的增加。如图 5 所示，Docker Image 2 和 Docker Image3 均是基于 Docker Image 1

图 5. 基于一样 Base Image 的 Docker Image Layer 的叠加

图 6. Docker Image Layer 在 Docker Host 上的存储关系

从图 6 可以看出在同1个 Docker host 上 download 来自一样 Base Image 的 Docker Image, Docker 在下载 Image layer 的时候，对已存在的 layer 是不会重复下载的。但是如果 layer 不同，即便内部包括的内容1样，也还是会重复下载的。

利用分层机制优化 Docker Image

通过上1节的介绍，可以看缺少良好设计的 Docker Image 会给往后的保护和 DevOps 的效力带来较大的问题。本文接下来就将重点介绍如何利用分层机制对项目的 Docker Image 进行公道的计划。从而大幅提升 Docker 在 DevOps 进程中的可延续性。并提升 DevOps 的效力。

设计基于分层机制的 Docker Image

以基于云平台的散布式利用为例. 在散布式系统中我们假定有两个利用 App1 和 App2。 这两个节点所的环境信息以下：

表 1. 散布式利用环境配置需求对比表

通过表 1 环境信息的对照，我们发现在这两个不同援用的节点上，不同的部份只是 logstash 的 config 文件和最后的 Ear 包。

图 7. 散布式利用环境配置树状图 1

然后以 Docker Image Layer 最多不超过 4 层的标准，将1些不会常常产生变化或可以用于其他 Docker Image 的层合并。如图 8 所示：

图 8. 散布式利用环境配置树状图 2

最后将图中的两个树状结构图进行叠加将重复的节点进行合并，最后得出以下树状结构图：

图 9. 散布式利用环境配置树状图 3

到目前为止我们已基于 Docker Image 的分层存储机制完成了1个基于云平台散布式系统的 Docker Image 的计划。接下来就能够根据上图结构分别制作 Image。终究我们将会有3个 Base Image。如图 10 所示，其中 Base OS Image，将作为项目中所有 Docker Image 的 base，JDK Image 可以在其基础上继续衍生出其他的 Image。 例如以该 Image 为基础创建 Tomcat Image 等。Liberty Image 可以在其基础上创建更多类型的利用 Image。

图 10. 基于分层存储的 Docker Image 树的多版本衍生

如果其中的 Liberty Image 产生变化的时候，例如需要升级 Liberty 版本的时候，只需要重新更新该节点和该节点以后的其他 Image 节点，而不会影响到 Liberty Image 节点的兄弟节点或父亲节点和由这些节点衍生出来的其他的 Docker Image。当更新 App Image 的时候，由于其均来自一样的父亲节点 Liberty Image。 所以每次更新的时候只会做 EAR 包的增量更新。

基于分层机制的 Docker Image 的实践

如图 11 所示, 依照之前介绍的安装 JDK、Logstash、Liberty 的 Docker Image 大小在 1.8 G 左右。以此为基础创建的的 App Image 的大小在 1.9G 左右。

图 11. Docker Image 分层存储实验 1

在1个已 download 了 Liberty Docker Image 的环境下下载 App Image。如图 12 所示，可以看到已存在的 layer 已是 complete 状态。 唯1 download 的部份只有新增加的 EAR 所产生的新的 layer。所需时间仅仅为 1 分 33 秒。

图 12. Docker Image 分层存储实验 2

如果直接在1个不存在 Liberty Docker Image 的 server 上去 download App Docker Image, 如图 13 所示，我们可以看到所需要的时间将超过 7 分钟。

图 13. Docker Image 分层存储实验 3

通过图 14 可以发现其他 layer 的 download 时间要超过 4 分钟，如果反复对这些重复的 Docker Image layer 进行下载更新，将会严重影响环境更新的效力。随着不同 Image 之间在 Docker Image Layer 上的差异越大，所花费的下载 Docker Image 的代价也将越大。

图 14. Docker Image 分层存储实验 4

小结

本文通过对 DevOps 和 Docker 基本概念的介绍和 Docker Image 分层存储的原理和实践结果说明，希望带给您1个思路，从而根据本身项目的实际情况计划和设计自己的 Docker Image。从而将 Docker 技术和 DevOps 更好的结合起来，构建1个可延续的产品生产，测试，发布的生态环境。