边缘容器镜像仓库，提供一类镜像仓库边缘BaaS后端即服务。
5.1 边缘容器镜像仓库的设计目标
Serverless需要BaaS提供后台服务应用需求。边缘容器镜像仓库需服务要为边缘终端设备就近地拉取镜像，提供访问控制功能，进行身份验证。本文基于Harbor、Consul等设计了基于Nomad的边缘容器镜像仓库方案。
边缘容器镜像仓库当前的设计目标是：
l 与主流的镜像仓库提供方镜像同步互操作。
l 镜像仓库功能包括安全、访问控制、镜像同步等核心功能。
l 适合边缘场景下的跨区域、多层级等特点。
l 在边缘端寻找最近的镜像仓库拉取镜像，减少拉取镜像的延时。
5.2 Harbor镜像仓库技术分析
容器注册表（Container Registry）也叫做容器镜像仓库，几种开源的镜像仓库技术有Docker Registry、VMware Harbor、Sonatype Nexus、SUSE Portus等。Nexus是一个软件仓库管理器，但除了容器镜像还支持很多其他的软件仓库，仅做存储并不满足边缘容器镜像仓库的大部分功能需求。Docker Registry v1版一直存在着安全漏洞，存在着镜像造假的隐患已经被废弃。Docker Distribution以安全性和性能为重点的新API设计取代了Docker Registry项目。Portus面向Docker Registry v2版本的API，提供了的授权服务和前端界面。Harbor也是基于Docker Distribution，提供了比Portus更为丰富全面的功能。云原生生态系统正在快速发展，其中镜像仓库及其功能集也在扩充，Harbor活跃的社区发展支持了大部分的核心功能。本文的边缘容器镜像仓库方案基于Harbor。
Harbor架构图如图5.1所示，Harbor在Docker Distribution的基础上提供了安全、访问控制、用户界面、管理、作业、打包等服务。Harbor的镜像复制功能是通过Docker Distribution的API去拷贝，既能够屏蔽繁琐的底层文件操作，利用现有镜像Registry功能不必重复造轮子，又可以解决冲突和一致性的问题。
图5.1 Harbor架构图
Harbor提供服务中使用了其他的第三方组件，如API路由组件采用Nginx反向代理，代理用户认证授权、Notary镜像认证、Docker镜像上传下载和浏览器的访问请求给后端的各服务；持久化组件使用了Redis键值对存储和PostgreSQL关系型数据库；借助Notary使用保持高度安全的密钥离线发布和验证内容；集成Clair根据CVE信息扫描各层镜像对比的容器漏洞静态分析等。Harbor能够满足边缘容器镜像仓库的功能需求和安全性需求。
与主流的镜像仓库提供方镜像同步互操作性上，Harbor通过同步适配器（Replication Adapters）支持，基于Harbor v1.9统计如表5.1所示。Pull模式将工件（Artifacts）从指定的源Registry同步到Harbor，Push模式将工件从Harbor同步到指定的目标Registry。Harbor支持与Docker Hub以及主流公有云容器镜像仓库间拉取和推送镜像，能够满足边缘容器镜像仓库的同步互操作性目标。
表5.1 Harbor与主流镜像仓库镜像同步互操作情况
| Registry | Pull模式 | Push模式 | 自动化管道 |
|---|---|---|---|
| Harbor | 支持 | 支持 | 支持 |
| Docker Distribution | 支持 | 支持 | 支持 |
| Docker Hub | 支持 | 支持 | 支持 |
| Huawei SoftWare Repository for Container | 支持 | 支持 | 不支持 |
| Google Container Registry | 支持 | 支持 | 支持 |
| Amazon Elastic Container Registry | 支持 | 支持 | 支持 |
| Azure Container Registry | 支持 | 支持 | 不支持 |
| Alibaba Container Registry | 支持 | 支持 | 不支持 |
| Helm Hub | 支持 | N/A | 不支持 |
5.3 边缘容器镜像仓库方案设计
本文边缘容器镜像仓库基于Nomad，组件架构基本还是Harbor开源容器镜像仓库的架构。
镜像同步是从一个Harbor实例向另一个Harbor实例复制仓库（repository）。根据边缘场景下的跨区域、多层级等特点，越往边缘端镜像仓库越多，同时每个镜像仓库之间的带宽和同步频率也各有区别，设计了如图5.2所示的三个层级的镜像同步方式。
图5.2 边缘容器镜像仓库三级同步设计
主节点到区域（Region，RG）二级节点，适用于和源节点之间带宽比较充裕同时需要同步的应用较多的节点。二级节点到边缘中心（Datacenter，DC）三级节点，适用于和源节点带宽比较有限同时需要同步的应用频率比较低的节点。采用三个层级，对一个边缘服务器的计算作业的描述是某个区域的某个中心的，这也和Nomad的基础设施划分模型相对应起来。
每个镜像仓库节点都有配置一个长域名（如harbor.service.beijing.consul）和一个相同的短域名（如harbor.service.consul）。短域名作为边缘客户端拉取镜像的统一的仓库域名，任何区域的边缘终端都使用同一个短域名拉取仓库镜像，如docker pull harbor.service.consul/library/busybox；长域名用于标识区域，在主干节点做控制时指定，如北京仓库要同步到浙江仓库，指定的仓库是harbor.service.zhejiang.consul，如图5.3所示，通过Consul的服务发现、DNS和跨区域联邦实现该功能。
图5.3 仓库管理用长域名指定仓库
使用长域名指定仓库能够保证镜像仓库节点IP发生变动时及时解析到提供正确仓库服务的节点，便于运维，提高容错性，进而也可以进行负载均衡等方案，增强可用性。本文基于Consul使用Fabio进行负载均衡。短域名能够使得任一边缘端的设备使用相同的域名去边缘镜像仓库拉取镜像，提供统一的服务入口，当边缘设备跨区域移动时正常提供服务，但这一点上Consul的DNS功能需要一些改造。
边缘镜像仓库镜像同步策略，继承了处理镜像的同步的方案，其核心是三个概念：
l 使用API来进行镜像下载和传输，做到与底层存储环境解耦。
l 利用任务调度和监控机制进行复制任务的管理，保障复制任务的健壮性。
l 提供复制策略机制保证项目级的复制需求。在Harbor中，可以在项目中创建复制策略，来实现对镜像的同步。
当系统管理员为该工程设置了相应的规则，当触发条件被触发的话该工程下所有匹配相应规则的仓库都会被复制到远程注册表中。 每一个仓库都会启动一个作业来进行复制。假如该工程在远程镜像仓库中并不存在，则会自动的创建出一个新的工程。但是假如该工程已经存在并且被用户配置为没有写权限的话，则这个同步过程会失败。根据不同的网络状况，这个复制过程可能会有一定的延迟。假若是因为网络的原因导致镜像同步失败，则在几分钟之后Harbor会尝试再进行同步（该同步过程会一直进行，直到网络恢复，同步成功）。
基于Harbor的边缘容器镜像仓库同步策略支持基于镜像名称和镜像版本号的通配符的镜像过滤器（Image Filter）：
l lRepository：复制时会根据镜像名称的repository部分来进行
l lTag：复制时会根据镜像名称的标签（Tag）部分来进行
在过滤器中支持两种不同的过滤匹配模式：
l l*：匹配除/之外的任何字符
l l?：匹配除/之外的任何单个字符
支持三种触发模式：
l 手动触发：当需要的时候，通过手工方式来触发repositories的同步。注意，对镜像的删除操作并不会被复制。
l 基于事件触发：当有一个新的repository被push到工程中时，会被马上同步到远程容器注册表。
l 定时调度触发：每天或者每周复制仓库。注意，对镜像的删除操作并不会被复制。
为了实现镜像的实时更新同步，本文推荐采取基于事件触发的方式来实现各个仓库的实时同步。镜像同步策略如下：
l 制定仓库的镜像前缀字典
l 镜像命名规范：Location + Image，比如B-Nginx
l 根据镜像同步的需求，基于镜像名称新建对应的同步规则，如表5.2所示。
表5.2 同步规则示例
| 镜像仓库 | 缩写 | 规则 |
|---|---|---|
| 区域1 | RG1 | RG1-** |
| 区域2 | RG2 | RG2-** |
| 区域1-边缘中心1 | RG1-1 | RG1-1-**，基于二级节点的缩写添加字母或者数字 |
镜像清理分为按时间和按数量两种规则类型对镜像进行清理。
l 时间规则：根据镜像的创建时间进行判断，如果这个版本的镜像创建时间在规则设置的时间之前，则该镜像会被删除。
l 数量规则：将镜像的版本根据创建时间进行排序，保留最新的指定数量版本的镜像，之前的镜像会被删除。
保留tag的版本会排除计算，不参与镜像清理。如果有服务正在使用该镜像，也不会被删除。
Harbor支持不同的身份验证模式：db_auth、ldap_auth、oidc_auth。边缘镜像仓库是分散的，不推荐使用db_auth方式进行用户认证管理，否则每个仓库都维护着零散孤立的用户信息，随着服务器的增加，用户权限的复杂性也随之增加。本文边缘镜像仓库用户认证推荐使用SSO单点登录，建议结合企业已有的用户登录认证系统，选择ldap_auth或oidc_auth方式。
当集群规模较大时，镜像分发可能对镜像仓库造成很大压力，可以使用阿里巴巴的开源项目Dragonfly作为镜像P2P分发的工具。本文规划的边缘容器镜像仓库方案中暂不涉及。
镜像仓库的高可用设计对于整个平台的稳定性起到决定性作用，目前主流的高可用方案为：用多个实例和一套分布式的共享存储卷系统，同时兼顾性能和数据一致性，用户的请求通过虚拟IP（Virtual IP，VIP）实现服务的高可用性，如图5.4所示。
图5.4 主节点镜像仓库集群架构
该高可用方案适合主节点镜像仓库，在上述三个层级结构中，主节点易出现单点故障。但并不适合边缘分节点容器镜像仓库，共享存储卷的方案响应延时会比向就近边缘仓库访问延时高。由于主节点镜像仓库采用的镜像仓库高可用方案是以共享存储的方式实现，因此需要镜像的全量备份来实现数据的备份。通过Habor提供的定时同步功能，可以实现在晚上时段实现主节点的镜像数据备份和保存。除了主节点，对于一个区域（距离相近）中多台服务器，也可以使用上述方式，提供高可用服务。在该区域Consul中注册镜像仓库服务时，将服务地址修改为以上VIP即可。
为了边缘端寻找最近的镜像仓库拉取镜像，减少拉取镜像的延时，同时保证高可用性，本文采用DNS域名的方式（如harbor.service.consul）来访问边缘镜像仓库，也需要改造Consul DNS实现。需要将Harbor作为Service在Consul中定义，复用边缘DC的Consul集群，使用Consul DNS复用Consul节点作为DNS服务器。该方案如图5.5所示，首先在Consul服务发现中注册Harbor服务包含服务地址IP，每个DC的Consul注册一个同名Harbor服务，注册的服务会在Consul中分配到如harbor.service.consul的域名，由此边缘镜像仓库服务与具体服务地址解耦。多个区域的Consul彼此联邦。
图5.5 边缘镜像仓库Consul DNS解析
边缘终端将某个Consul节点配置为域名解析服务器，Consul所在节点指定域名解析服务器为它自身。使用该域名解析服务解析该区域内的harbor.service.consul服务域名，在拉取镜像时，通过Consul DNS解析到该区域的Harbor服务地址。原理是Consul可以使用Serf库提供的网络层析成像系统来计算集群中节点的网络坐标，选择就近的服务节点，这里需要改造，因为Consul DNS的默认策略是轮询。同时，通过Consul对Service的健康检查机制，当就近节点宕机时，将该IP从harbor.service.consul域名解析到的IP地址列表中排除，这里也需要改造，进行透明的故障转移，如果本区域没有边缘镜像仓库服务，解析另行选择就近区域的边缘镜像仓库服务。
