大规模容器镜像管理方案

大规模容器镜像管理方案

随着容器技术的深入和广泛应用,容器镜像的管理成为了一个关键的环节,在大规模并发访问镜像中心的时候,镜像仓库的高可用性、性能及安全性都是值得关注的问题。目前市场上存在一些开源及商业的解决方案,旨在满足特定场景下的需求,本篇文章就针对容器镜像管理的一些场景和方案进行梳理。

常用的容器镜像中心

容器镜像管理中心是云原生应用持续交付体系中的一个非常底层且关键的部分,目前市场上主流的容器镜像管理中心主要有开源的 Docker Registry,VMWare Harbor, Sonatype Nexus3 及商业的JFrog Artifactory,这些产品适用于不同的场景,但都支持相同的标准协议。

Docker Registry

Docker Registry 应该是我们认识最早的容器镜像中心,是由 Docker 公司开发的一款开源软件,采用 Apache License 开源协议。很多小规模开发团队喜欢在私有的开发测试环境使用它,因为它轻巧灵便,非常适合在规模不大的场景下提供镜像存储和分发服务。

在著名的公有 Docker 镜像中心 - Docker Hub 上,我们可以查找到创建Docker Registry 的镜像,因此 Docker 镜像中心 registry 也可以以容器方式运行,特殊点在于其应用本身就是管理容器镜像的。

VMWare Harbor

Harbor 是一个开源的企业级 Docker 镜像中心,也是目前唯一原创于中国的CNCF 项目。Harbor 所做的事情并不是取代 Docker Registry,而是为其增加了诸多企业级特性,如 UI, RBAC, Security 及 Replication 等等。

Harbor 主要分5个大部分:

  • 由 Nginx 服务器构成的反向代理
  • 由 Docker 官方的开源 registry 镜像构成的容器实例
  • 架构中的 core services, 此部分是 Harbor 项目的主体
  • 由官方 MySql 镜像构成的数据库容器
  • 运行着 rsyslogd 的容器,通过 log-driver 的形式收集其他容器的日志
    大规模容器镜像管理方案_第1张图片

Harbor 在业内使用较为广泛,作为镜像管理中心,Harbor 还提供了用户权限、镜像安全及复制分发等企业特性,使得更多企业用户在研发测试环境中使用。在很多云厂商产品中也有集成 Harbor 作为整体解决方案的一部分,并且在云原生领域已经开始支持Helm仓库,使得云原生应用的部署更加便捷。

Sonatype Nexus

Sonatype Nexus 是一款优秀的Java私服仓库,集中管理Java语言的制品,后来加入了其他语言的支持,如Python, NuGet 及 Docker 镜像。众多用户都是使用其开源版本,而并未使用带高可用特性的企业版本,于此同时企业版也将Helm仓库纳入其 RoadMap,不过是通过社区插件的形式来支持,由于 Sonatype 主要关注安全领域,未来在制品仓库领域的发展策略尚不明朗。大规模容器镜像管理方案_第2张图片

JFrog Artifactory

JFrog Artifactory 是目前原生支持开发语言类型最多的制品仓库,除了传统的Java、.NET、Python、Php等等还支持Docker、Helm等仓库,甚至还可以支持Debian/RPM仓库,针对应用配置管理也有其独特的解决方案,深受广大用户的欢迎。

Artifactory 除了存储镜像还可以记录镜像整个生命周期数据,为用户在镜像复用、阶段交付及上线发布时提供数据决策支撑。很多企业都有镜像安全审计需求,该制品仓库可以清晰地展现容器镜像中的内容,如RUN命令的所有指令,可在镜像上传时检查指令合规性。于此同时,针对企业关心的正反向依赖解析也有很好的支持,可快速分析某个其他语言的制品(比如java语言JAR包)被哪些镜像层所引用,以及镜像层被其他哪些镜像所公用。
大规模容器镜像管理方案_第3张图片

容器镜像中心面临的挑战

容器镜像中心在实际生产环境中依然会遇到一些棘手的问题,比如并发量比较大的场景下的性能问题,安全相关的问题及数据热备容灾等等。

镜像中心的多活及容灾热备

单节点容器镜像中心在高并发下载场景下会出现性能瓶颈,从而需要多节点来共同分担下载请求负载,因此多活节点是保证性能的必要手段。由于上传流量相对于下载流量小很多,因此常常被人忽略,集群模式下写入必须满足数据一致性,即必须由Leader负责与集群其他节点的数据同步。因此由多活节点保证并行性能及容灾备份节点提供冗余机制的模型就成为大规模镜像管理集群的标准架构。
大规模容器镜像管理方案_第4张图片

镜像中心的多数据中心投送

容器应用在本地数据中心内会由于升级、迁移、回滚等动作而需要实时拉取镜像,如果此时镜像在异地数据中心,那么性能肯定会收到较大影响,最终用提体验较差。因此,在跨地多数据中心部署架构下,比如能够实现镜像的多数据中心投送,确保应用在本地数据中心获取镜像,这与缓存的基本思想类似。

镜像的多数据中心投送场景不仅仅局限于应用部署,在常见的多地域研发中心协同的时候,也会存在这种跨数据中心依赖的情形,需要能够按需从异地数据中心获取镜像,然后再本地数据中心进行缓存,以提升研发或构建时依赖获取的效率。
大规模容器镜像管理方案_第5张图片

镜像的核心历史元信息管理

镜像本身也是线上运行的交付制品,隐含着很多的背景信息,比如构建信息、测试信息及安全信息等等,这些信息对于线上应用的可用性和稳定性都有着千丝万缕的联系,这些信息如果没有集中进行管理,会导致整个交付信息流中断,不利于线上问题的排查及对交付流程的评估分析。
大规模容器镜像管理方案_第6张图片

镜像的动态及静态安全管理

镜像本身由各个镜像层组成,每个镜像层又由若干二进制文件组成,这些文件中绝大多数都不是由开发者开发的,而是第三方或者开源的内容,然而开源并不等同于安全,这些安全状态未知的内容的潜在风险非常大,而这些问题的影响范围如何更加不得而知。

其实安全不仅仅来自于外部,内部开发的组件在被层层引用时也可能会造成整个业务组件发生问题,比如存在内存溢出等,甚至是老版本的升级对受影响的组件的回归测试不完整也会造成不可预知的问题。
大规模容器镜像管理方案_第7张图片

镜像除了静态一些安全因素之外,动态安全也应该是受到关注的内容,如镜像中哪些指令是允许执行的,而哪些不允许执行的,如何动态学习一些频发执行且需要root权限的系统调用(syscall)等行为,给管理者进行风险告警和快速阻断,这些都是生产环境需要解决的重要课题。
大规模容器镜像管理方案_第8张图片

容器应用编排及配置管理

容器引用发布其实不仅仅设计镜像,而且还设计很多容器应用本身的参数,比如实例数、服务、config、Volume等等,这些资源要进行一个统一的编排其实还是有一定的复杂度的。大型开发项目人员众多,各自有各自的习惯和做法,缺乏有效的标准和工具,很容易造成碎片化、难以复用共享等问题。

Helm 是Kubernetes官方的包管理器(Package Manager),除了提供Chart的仓库,还能够对容器应用的生命周期管理,比如部署、升级、回滚等,配置其生命周期事件的扩展(Hook)及插件机制,可以很方便地实现灰度、蓝绿等策略支持,这个对于容器应用编排有着很大的促进作用。
大规模容器镜像管理方案_第9张图片

容器应用的灰度及蓝绿发布策略需要一些基础条件,比如应用需建立起与配置的关联关系,配置需要建立与运行环境中配置Key的关联关系,这样才能通过自动化的手段实现在检测到异常时自动回滚,并且配置中心还必须保证高可用。这些基础条件必须与开发工具、语言无关,最好是通过同一个平台进行管理。
大规模容器镜像管理方案_第10张图片

容器镜像存储及分发优化

容器镜像是分层存储的,除了最上层是读写层之外,其余的全部是只读层,从存储优化的角度来说,这时候就需要在多个镜像之间来共享某些层。在物理层如果镜像层物理文件依然是目录递归查询的方式,显然查询效率会大大降低,而比较合适的一种设计是通过建立二进制文件的SHA2码的索引,从而实现快速定位具体二进制文件的物理位置,类似存储虚拟化的设计思路。

容器镜像分发解决方案

容器镜像分发通常有两种模式,一种是Push模式,即一个中心节点向多个远端节点进行推送,另一种是由远端节点进行定时轮询,发现有新的内容则拉取到本地。对于触发方式,也分为定时触发和事件触发两种。

边缘节点CDN加速

通过CDN形式进行分发是最直观的加速方式,在边缘网络提供只读节点,供用户就近访问可以减少中心节点的访问流量,达到提升镜像下载速度的目的。在实际的分发架构中,制品库对接分发者,分发者可以控制分发策略等,分发者对接各个边缘节点(Edge Node),最后用户可以从多个边缘节点的负载均衡进行下载,进一步提升和下载速度,因为边缘节点支持缓存机制。
大规模容器镜像管理方案_第11张图片

P2P 分发

目前通过P2P协议分发镜像也是一种逐渐成为主流的方案,国内的华为、阿里及百度均在此领域有探索,企业级开源容器镜像中心VMWare Harbor也有类似方案。例如阿里的Dragonfly已经成为正式的CNCF项目,华为容器技术团队也发表了相应的技术方案。整体来看,P2P分发协议是通过Controller下发镜像分发任务,由Tracker去跟踪各个客户端下载的二进制层的元数据信息,最终进行汇总决定任务是否完成。整体架构如下:

大规模容器镜像管理方案_第12张图片

Docker镜像是按照Layer存储的,意味着不同的镜像可共享Layer,这种机制不仅减少了物理存储空间的消耗,也在分发时减少了带宽的损耗。当查询到需要下载Layer时先通过export的方式导出和压缩Layer文件,然后为其制作BT种子,并由控制器分发下载任务给各个客户端代理,客户端代理收到任务会检查要下载Layer本地是否已存在,若不存在则根据任务中的Layer相关信息进行下载,然后由Docker Daemon进行导入,整个下载的过程都是并发执行的。

总结

随着容器规模的快速增长,容器镜像中心的高可用性保障遇到的挑战将会越来越大,本质上来说也是对分布式文件系统的可靠性的检验,企业级容器镜像中心将会是云原生时代应用基础设施的关键组成部分,各种管理架构和技术也在不断深化和发展中,期望这篇文章对于关注相关技术的读者有所帮助。

你可能感兴趣的:(Docker,DevOps)