面向全球的镜像分发网络
原创
原文 https://www.chenshaowen.com/blog/a-global-images-distribution-network.html
1. 全球的网络规划
很多面向全球的多区域基础设施，在设计之初并没有在网络规划上花费太多心思。当业务复杂到一定程度时，又被逼着进行网络调整和优化。而任何网络上的大调整，都将对业务产生巨大影响。最终会陷入进退两难之地，只能投入更多人力，背上历史包袱，一次又一次行走于悬崖之颠。
如下图是我认为比较理想的一种网络拓扑:
网络规划主要有如下几点:
- 网段划分
在面向全球的业务形态下，网络被割裂为两部分: 海外和中国内地。我更倾向于建立两个中心，国内的核心节点设置在北京，主要面向国内业务；海外的核心节点设置在新加坡，主要面向海外业务。
因此将 10.128.0.0/16 及以上网段划分给海外，10.127.0.0/16 及以下划分给国内。同时，每个区的网段之间相隔 8，预留一定的扩展空间。
- 实现连通
如果是同一个 VPC，那么内网是可达的。但是如果是不同 VPC、不同的厂商、不同的区域之间，我们通常会借助一定的方法实现连通：公网或者专线。
公网是比较普适的一种方法。我们可以基于公网，搭建 V**内网，实现网络连通。但是，公网的连通质量不能得到保障，因此还有一种方式就是专线。
专线能够实现跨区域的网络连通，但是云专线通常限于同一家云厂商。也就是说，华为云北京的云专线只能连通华为云新加坡，而不能连通 AWS 新加坡。
- 配置路由
实现连通只是相当于插上了网线，但是转发数据包时，并不清楚 IP 包的下一跳是哪里，因此还需要配置路由。
由于设置有两个网络核心，海外的区域与海外的核心节点需要互通，国内的区域与国内的核心节点需要互通。至于其他各区域是否互通，需要看是否有需求。比如，我们需要在内网进行镜像数据的 P2P 分发，那么就需要各区域也互通。
2. 建设全球镜像分发能力
全球的镜像分发能力是建立在全球 IDC 内网互通的前提下的。我们不能让基础设施暴露于公网之上，全部的镜像数据都是通过内网流量进行传输的。
如下图是一个全球镜像分发系统:
我们的研发部门在国内，而部署的服务遍布全球。镜像数据的流转会经过以下流程:
- 国内构建镜像并推送到国内的 Habor 中
- 国内 Habor 同步镜像到海外的 Habor 中
- 在某个区域，部署海外的应用，拉取镜像
- 由于每个 Docker 中都配置了 Dget 的地址作为 registry-mirrors，应用镜像被缓存到 Dget 中
- 在同一个区域，多个副本部署时，都将直接拉取 Dget 中的镜像
3. Habor 的部署与高可用
3.1 部署 Habor
Harbor 部署主要有两种方式 Helm Chart 和 Docker Compose。这里推荐的是 Docker Compose，因为作为一个不会频繁变更、稳定性要求高的服务，VM 比 Kubernetes 更适合作为 Habor 的基础设施。
3.2 高可用 Harbor
Harbor 的高可用主要有两种方式:
- 共享存储。一致性高，需要部署双活\主备的存储后端。
- 多 Harbor 之间同步。一致性不高，镜像同步需要时间。
我建议采用的方案是共享存储，不想等待 Harbor 同步完成，推送完的镜像即可用。如下图，共享存储方案下，需要以双活\主备的形式部署存储组件:
关于 LB 的配置有一个小细节：
如果使用七层 LB 卸载证书，那么后端主机提供的是 80 端口，此时需要在 LB 层将 80 端口转发到 443，否则 docker login 将无法登录。如果使用的是四层 LB，可以不用考虑这个问题。在调试时，还遇到一个问题，由于 V**、LB 都会修改 IP 包，这可能会导致一些诡异的问题，比如连不上、连接不稳定等。此时，需要关注 MTU 值。
这里需要共享的组件有:
- 共享 PGSQL
可以直接购买云厂商的服务，然后初始化创建表。
1 2 3 4 5 6 7 8 9 10 11 12 | CREATE DATABASE notary_server; CREATE DATABASE notary_signer; CREATE DATABASE harbor ENCODING 'UTF8'; CREATE USER harbor; ALTER USER harbor WITH ENCRYPTED PASSWORD '123456'; GRANT ALL PRIVILEGES ON DATABASE notary_server TO harbor; GRANT ALL PRIVILEGES ON DATABASE notary_signer TO harbor; GRANT ALL PRIVILEGES ON DATABASE registry TO harbor; GRANT ALL PRIVILEGES ON DATABASE harbor TO harbor; GRANT ALL PRIVILEGES ON DATABASE clair TO harbor; |
|---|
在 harbor.yaml 文件中添加外部数据库配置即可。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | external_database: harbor: host: 1.1.1.1 port: 5432 db_name: harbor username: harbor password: 123456 ssl_mode: disable max_idle_conns: 10 max_open_conns: 100 notary_server: host: 1.1.1.1 port: 5432 db_name: notary_server username: harbor password: 123456 ssl_mode: disable max_idle_conns: 10 max_open_conns: 30 notary_signer: host: 1.1.1.1 port: 5432 db_name: notary_signer username: harbor password: 123456 ssl_mode: disable max_idle_conns: 10 max_open_conns: 30 |
|---|
- 共享 Redis
Harbor 的 Redis 主要存储的是用户登录的会话 Session 信息和 Job Services 的同步、定时任务。如果对可用性要求不太高，可以使用自建的 Redis 实例，因为即使 Redis 的存储数据丢失，对 Harbor 的数据完整性没有影响。
- 共享 S3 对象存储
我使用的是华为 OBS 对象存储，这里的 AKSK 需要给 full 权限。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | storage_service: s3: accesskey: xxx secretkey: xxx region: ap-southeast-3 regionendpoint: https://obs.ap-southeast-3.myhuaweicloud.com bucket: xxx encrypt: false secure: true v4auth: true chunksize: 5242880 multipartcopychunksize: 33554432 multipartcopymaxconcurrency: 100 multipartcopythresholdsize: 33554432 rootdirectory: /registry/ |
|---|
如果担心 S3 的单点问题，可以购买两个 Bucket，相互同步镜像数据。这样，当其中一个 Bucket 有异常时，可以迅速切换到另外一个 Bucket 恢复服务。
4. 利用 Dragonfly 节省带宽
为什么需要 Dragonfly 分发镜像? 其中很大的一个原因在于节省带宽，还有就是避免 Habor 的负载过大。
如果不使用 Dragonfly 镜像分发，那么每次拉取镜像都会向 Habor 请求数据。如下图:
而采用 Dragonfly 之后，同一个区域只需要请求一次 Harbor，其他请求都可以通过区域内的流量完成。这种方式大大加快了镜像拉取过程，节省了跨区域的带宽，减轻了 Habor 的负载压力。
5. 总结
最近在给业务重新规划部署一套镜像管理系统，本篇是相关思考和实践的一些总结。
本文主要从网络规划开始，聊到全球镜像的分发。网络规划主要涉及网段规划、实现连通、配置路由三个部分。而镜像分发主要采用的是 Habor + Dragonfly 的方案。同时，推荐的是采用共享存储的方式部署高可用的 Harbor。
实际上，在部署完 Habor 之后，我还对各区域拉取镜像的速度进行了测试。另外，还需要将影响 Habor 服务的依赖项配置监控，持续的改进，才能打造好的镜像仓库及分发系统。
6. 参考
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
腾讯云开发者
