1. 全球的网络规划

很多面向全球的多区域基础设施，在设计之初并没有在网络规划上花费太多心思。当业务复杂到一定程度时，又被逼着进行网络调整和优化。而任何网络上的大调整，都将对业务产生巨大影响。最终会陷入进退两难之地，只能投入更多人力，背上历史包袱，一次又一次行走于悬崖之颠。

如下图是我认为比较理想的一种网络拓扑:

网络规划主要有如下几点:

• 网段划分

在面向全球的业务形态下，网络被割裂为两部分: 海外和中国内地。我更倾向于建立两个中心，国内的核心节点设置在北京，主要面向国内业务；海外的核心节点设置在新加坡，主要面向海外业务。

因此将 10.128.0.0/16 及以上网段划分给海外，10.127.0.0/16 及以下划分给国内。同时，每个区的网段之间相隔 8，预留一定的扩展空间。

• 实现连通

如果是同一个 VPC，那么内网是可达的。但是如果是不同 VPC、不同的厂商、不同的区域之间，我们通常会借助一定的方法实现连通：公网或者专线。

公网是比较普适的一种方法。我们可以基于公网，搭建 VPN 内网，实现网络连通。但是，公网的连通质量不能得到保障，因此还有一种方式就是专线。

专线能够实现跨区域的网络连通，但是云专线通常限于同一家云厂商。也就是说，华为云北京的云专线只能连通华为云新加坡，而不能连通 AWS 新加坡。

• 配置路由

实现连通只是相当于插上了网线，但是转发数据包时，并不清楚 IP 包的下一跳是哪里，因此还需要配置路由。

由于设置有两个网络核心，海外的区域与海外的核心节点需要互通，国内的区域与国内的核心节点需要互通。至于其他各区域是否互通，需要看是否有需求。比如，我们需要在内网进行镜像数据的 P2P 分发，那么就需要各区域也互通。

2. 建设全球镜像分发能力

全球的镜像分发能力是建立在全球 IDC 内网互通的前提下的。我们不能让基础设施暴露于公网之上，全部的镜像数据都是通过内网流量进行传输的。

如下图是一个全球镜像分发系统:

我们的研发部门在国内，而部署的服务遍布全球。镜像数据的流转会经过以下流程:

1. 国内构建镜像并推送到国内的 Habor 中
2. 国内 Habor 同步镜像到海外的 Habor 中
3. 在某个区域，部署海外的应用，拉取镜像
4. 由于每个 Docker 中都配置了 Dget 的地址作为 registry-mirrors，应用镜像被缓存到 Dget 中
5. 在同一个区域，多个副本部署时，都将直接拉取 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，可以不用考虑这个问题。在调试时，还遇到一个问题，由于 VPN、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. 参考

• https://github.com/dragonflyoss/Dragonfly2
• https://github.com/goharbor/harbor