“云-边”协同场景的Docker 镜像仓库设计

邢德奇 傅康平 李华夏

（中国电子科技集团公司电子科学研究院 北京市 100041）

容器技术在类Unix 操作系统内核提供的资源隔离特性基础上，通过将应用软件与其所依赖的运行环境共同打包，形成可独立运行且不发生相互干扰的实体，称为“容器”。相较于传统的虚拟化技术，由于共享了宿主计算机的操作系统内核，通过容器技术实现的虚拟化，在实现了各类资源的共享和隔离的同时，其用于虚拟化本身的资源开销显著小于传统虚拟化方法。因此，容器技术已经广泛应用于复杂系统的服务端软件封装。结合以Kubernetes 为代表的容器编排技术，可实现大规模业务容器的集群化运行治理。

容器技术是一种是操作系统层虚拟化技术，代表性的实现方案包括LXC、rkt、Docker 等，其中又以Docker 最为流行。本文也将以Docker 容器技术为例，分析容器镜像仓库的一般架构，并针对弱网络下的“云边”协同场景，提出一种更高效率的容器镜像仓库设计，满足云边场景下的容器镜像仓库应用需求。

1 Docker文件系统和镜像仓库

在Docker 容器技术中，一般将“容器”定义为提供了隔离能力的虚拟化运行时环境，而将“镜像”定义为包含容器运行所需环境配置和文件的容器模版。简单的说，容器是由特定镜像产生的运行实例。本节将简要分析Docker 组织容器和镜像文件系统的一般方法和特性，而本文镜像仓库的设计则正是基于Docker 文件系统的这些特性。

说到Docker 的文件系统，就不得不提“联合文件系统”（Union FileSystem），它是一种面向Linux、FreeBSD 和NetBSD 的文件系统服务，允许不同文件系统的文件和目录（称为“分枝”）透明覆盖，合并形成一个完整的、一致的文件系统。在合并结果中，来自不同分枝的具有相同路径的目录内容将在新的虚拟文件系统内形成一个合并目录，其内容也是各分枝中相应内容的合并。联合文件系统的这一特点可以支持以分层的形式组织文件系统，即上层文件层构建在下层文件层基础上，描述对下层文件层的改动，进而提高文件系统组织和复用的效率。

Docker 支持的文件系统之一是AUFS（Advanced Multilayered Unification FileSystem），其本身是联合文件系统的一种实现。其支持每个成员目录设定为只读、读写或写出权限，并支持以分层的方式进行文件系统组织。

图1 给出的是AUFS 的一个示例。该文件系统下，每个Docker 镜像都可被视为一系列只读的、包含不同内容的文件系统层。在根文件系统（root filesystem）的基础上，各层向上罗列，共同构成了镜像内容。其中，Docker 存储驱动（Docker storage driver）负责组织上述分层文件系统，并对外提供统一的应用视图。

图1：AUFS 示意图

镜像构建过程中，通过特定语法可编写Dockerfile，指定基础镜像，并定义基础镜像之上的系列构建步骤。此后，通过Docker 命令进行镜像构建。在“只读”的基础镜像之上，按照步骤执行命令或将文件添加至镜像，形成一系列新的“文件层”，此类“文件层”可以包含新文件，也可以包含对其下所有“文件层”中文件的修改或删除，“文件层”层层累加，以栈的形式构成最终镜像的文件系统。

从文件系统构成的角度，容器与镜像的区别更加明显。由于容器是镜像的运行实例，容器的文件系统在镜像文件层栈的最上层添加了一层可写层，用来记录其在对应镜像的文件系统基础上，对文件所做的增加、删除和修改。当容器被删除，该可写层将同样被删除。当容器被提交成为镜像，该可写层也将变为只读层，成为新镜像的一部分。

从Docker 文件系统的上述架构特点可以分析出，由相同基础镜像构建出的多个新镜像，其基础镜像部分的文件系统是相同的，由于其具备只读属性，因此也是可共用的。这就为容器镜像的组织提供了一种体积压缩的可能性，这也正是Docker 文件系统的重要特点之一。

前文提到的Docker 存储驱动正是负责管理和组织各只读文件层和可写文件层的模块。图2 给出了上述特性的一个图示。

图2：分层文件系统示意图

Docker 目前支持若干不同的联合文件系统实现，包括OverlayFS、AUFS、btrfs、VFS、ZFD、Device Mapper 等。

实际使用中，Docker 镜像以分层文件系统的方式存放于镜像仓库。特定主机可根据需要从镜像仓库拉取镜像，保存至本地，供后续创建容器等使用。

Docker 镜像仓库方面，Docker 公司提供了名为Docker Hub 的商用服务，Docker 使用者可直接从Docker Hub 拉取镜像。此外，为便于私有云等私有场景下的镜像访问，

Docker 提供了名为Docker Registry 的镜像仓库解决方案。Docker Registry 默认对接本地POSIX 文件系统，也可支持亚马逊S3、微软Azure、阿里云OSS 等一系列云文件系统。

此外，还涌现出了以Harbor 为代表的第三方镜像仓库解决方案，其在标准的Docker Registry 基础上，额外提供权限管理、安全管理等一系列实用功能。

2 弱网络云边协同场景下的容器仓库需求

在以Kubernetes 为代表的容器云场景中，通过Docker Registry 或Harbor 等软件，可便捷地构建中心式的镜像仓库，进而通过镜像仓库进行镜像分发。

随着物联网等技术的快速发展，云边协同场景（如图3 所示）的计算需求越来越大，其通过容器技术在嵌入式等边缘设备上进行软件部署和管理也逐渐称为主流。一系列面向边缘计算场景的容器云管理框架也应运而生，如KubeEdge、K3s 等。

图3：云边协同示意图

云边协同场景的典型约束主要包含两方面：

（1）与中心集群充沛的计算能力形成对比，边缘侧以嵌入式等低功耗、低算力的设备为主，其计算、存储能力相对有限。

（2）边缘节点与中心节点、边缘节点之间的网络资源往往有限。

在野外、海面等网络覆盖不足的场景，或无人机等节点动态变化的场景中，各类设备往往需要以“弱网络”的方式相互连接。该类场景的特点是网络带宽有限、网络通信质量不稳定，且网络拓扑有可能动态变化。在以Docker 为软件封装方式的弱网络云-边协同场景，容器镜像仓库的建立面临若干挑战：

（1）镜像仓库必须以分布式的方式部署，当边缘节点与中心集群的网络连接出现故障时，需要确保边缘节点的镜像仍可不完全依赖于中心节点而拉取。

（2）需要建立适应于较低网络质量的分布式镜像仓库同步机制，确保当网络可用时，通过尽可能少的网络带宽资源完成镜像仓库的同步，当网络不可用时，边缘节点又可通过独立于中心仓库的方式获取镜像。为此，我们设计如下面向云边场景的容器镜像仓库。

3 一种面向云边协同场景的容器镜像仓库设计

基于上述分析，本文针对上一节中的场景设计一种面向云边协同场景的容器镜像仓库设计，解决上文提到的几大挑战。该镜像仓库的组成结构图如图4 所示。

图4：云边协同镜像仓库组成结构

上述镜像仓库主要由如下几个模块组成：

3.1 标准镜像仓库

该模块实现容器镜像分层文件系统的本地管理，可直接采用Docker 提供的Registry，也可采用其他第三方Docker镜像仓库解决方案。该模块通过其对外的REST 接口进行仓库访问操作，包括获取镜像列表、获取镜像标签列表、获取镜像组成信息（manifest）、获取镜像文件数据等。

3.2 分层抽取管理

该模块构建在标准镜像仓库之上，对外提供针对仓库内镜像特定层的操作接口，包括镜像特定层导出至文件接口和由文件导入特定镜像层接口。

3.3 元数据管理

该模块管理仓库内所有镜像的基本信息（包括镜像名称、镜像标签、更新时间等），以及所有镜像的分层文件系统组成信息，并对外提供相应操作接口（包括元数据信息查询接口、元数据信息更新接口、元数据信息导入和导出接口等）。

3.4 同步管理

该模块维护当前仓库的同步状态信息。本文所设计镜像仓库额外设置了同步管理功能，用户可分别指定需要在中心集群和各边缘集群同步的镜像。一般云边协同场景下，中心集群与边缘集群的功能定位大多不同，因此各处需要部署的软件也有所区别。通过同步管理功能，可更明确地管理需要在云边进行同步的镜像，避免有限的网络资源产生浪费。同步管理对外提供的接口包括镜像同步策略查询和设定接口、镜像标签同步策略查询和设定端口等。

3.5 文件可靠传输

该模块基于“分层抽取管理”模块针对所需镜像特定层产生的文件，完成弱网络条件下的文件可靠传输，实现镜像特定层在不同仓库之间的同步。该模块提供的服务包括传输校验、断点续传在内的传输服务。

3.6 运维管理

该模块以BS 的方式提供对镜像仓库的管理页面，提供的功能包括镜像仓库信息（如各类统计信息、存储信息等）查阅、镜像及元数据信息查阅和操作、同步策略管理、用户及用户权限管理等。

在云边协同应用场景中，上述镜像仓库的运行架构如图5 所示。

图5：镜像仓库运行架构

上述镜像仓库设计的主要特点有如下几方面：

针对中心集群与边缘集群之间网络不稳定且带宽有限，而边缘小集群内部网络质量相对较好的特点，在原有中心仓库的基础上，设计了边缘侧仓库。这样，当边缘集群中某个节点暂时无法访问中心集群资源时，可通过边缘侧的仓库实现镜像的同步。

针对中心仓库与边缘侧仓库的镜像同步问题，在“元数据管理”和“同步管理”两个模块的基础之上，确定仓库间需要同步的文件层，基于需同步文件层生成状态标记，并设计基于状态标记的周期性同步机制。如上文所分析，在一般的云边协同场景中，不同边缘集群往往需要部署不同类别的应用。因此，不同边缘侧仓库所要从中心仓库同步的内容是有所差别的。为了更有效地利用中心集群和边缘侧集群之间的网络带宽，通过仓库的“同步管理”模块在中心仓库处维护各边缘侧仓库所需要同步的镜像列表，并基于该列表中所有镜像的最新状态，形成基于最后更新时间戳的状态标记。当仓库间所持的状态标记相同时，仓库不需要同步；当仓库间状态标记不同时，触发基于分层文件系统的增量式镜像同步。

在上述同步策略下，由状态标记触发同步行为，而同步内容则在分层文件系统基础上，基于“分层抽取管理”模块产生增量式镜像同步文件，避免重复传输两侧已有的镜像文件层。同时，通过“文件可靠传输”模块实现弱网络上的断点续传，进一步降低文件传输过程中的带宽浪费。

4 镜像仓库同步算法

综合上述镜像仓库分布策略和同步算法设计，本节对本文所设计的面向云边协同的容器镜像仓库的应用场景分析如下：

4.1 中心仓库存在新增镜像时

（1）新增镜像时，“标准镜像仓库”处将保存新增镜像的相关基本信息和各类镜像文件，“元数据管理”模块通过标准镜像仓库的相关接口，获取新增镜像的基础数据；

（2）通过“运维管理”模块，用户可为新增镜像补充元数据信息，并设定起在边缘仓库的同步策略（包括“不同步”、“全部同步”和“只同步特定标签”）；

（3）当“同步管理”模块监测到满足特定同步策略的新增镜像时，基于“元数据管理”的接口获取新增镜像的元数据信息，信息压缩后导出成为二进制数据流，交由“文件可靠传输”模块传递至待同步的边缘仓库处；

（4）边缘仓库处的“文件可靠传输”模块接收到中心仓库传递的文件后，解压缩并传递至边缘仓库处的“同步管理”模块，边缘处同步管理模块对比新镜像文件层组成和本地镜像文件层，确定需要同步的文件层清单，并将清单压缩后导出为二进制数据流，交由“文件可靠传输”模块回传中心仓库；

（5）中心仓库的“同步管理”接收到同步需求后，通过“分层抽取管理”模块，将需要同步的文件层及其元数据信息导出为压缩的二进制文件，交由“文件可靠传输”，传递至边缘侧；

（6）边缘侧的“同步管理”收到“文件可靠传输”传递的文件后，通过“分层抽取管理”完成文件的导入，进而完成新增镜像在中心仓库和边缘仓库间的同步。

4.2 中心仓库既有镜像出现更新时：

（1）镜像更新时，“标准镜像仓库”处将更新新增镜像的相关基本信息和各类镜像文件，“元数据管理”模块通过标准镜像仓库的相关接口，更新镜像基础数据；

（2）当“同步管理”模块监测到满足特定同步策略的镜像出现更新时，基于“元数据管理”的接口获取更新镜像的元数据信息，信息压缩后导出成为二进制数据流，交由“文件可靠传输”模块传递至待同步的边缘仓库处；

（3）边缘仓库处的“文件可靠传输”模块接收到中心仓库传递的文件后，解压缩并传递至边缘仓库处的“同步管理”模块，边缘处同步管理模块对比新镜像文件层组成和本地镜像文件层，确定需要同步的文件层清单，并将清单压缩后导出为二进制数据流，交由“文件可靠传输”模块回传中心仓库；

（4）中心仓库的“同步管理”接收到同步需求后，通过“分层抽取管理”模块，将需要同步的文件层及其元数据信息导出为压缩的二进制文件，交由“文件可靠传输”，传递至边缘侧；

（5）边缘侧的“同步管理”收到“文件可靠传输”传递的文件后，通过“分层抽取管理”完成文件的导入，删除更新前的旧镜像，进而完成更新镜像在中心仓库和边缘仓库间的同步。

4.3 中心仓库删除特定镜像时

（1）镜像删除时，“标准镜像仓库”处将删除镜像的相关基本信息和各类镜像文件，“元数据管理”模块将镜像元数据标记为“待删除”状态；

（2）当“同步管理”模块监测到满足特定同步策略的镜像出现删除时，基于“元数据管理”的接口获取被删除镜像的元数据信息，信息压缩后导出成为二进制数据流，交由“文件可靠传输”模块传递至待同步的边缘仓库处；

（3）边缘仓库处的“文件可靠传输”模块接收到中心仓库传递的文件后，解压缩并传递至边缘仓库处的“同步管理”模块，完成待删除镜像在边缘仓库处的删除，并产生“删除完成响应”发送至中心仓库；

（4）中心仓库的“同步管理”接收到来自所有待删除边缘仓库返回的“删除完成响应”后，通知“元数据管理”模块，删除镜像元数据，至此完成镜像的删除。

5 总结

本文设计了一种面向弱网络下“云边”协同场景的容器镜像仓库架构，并针对性设计了同步算法。基于该设计，可在弱网络下实现云-边之间的仓库可靠同步，提升仓库同步成功率、降低同步的网络要求。该方法可应用于各类网络覆盖不足或网络质量不佳的云边协同场景，是对现有容器镜像仓库的功能完善。