我在全球三大云服务商部署镜像源的踩坑实录

我的公网环境部署多区域镜像源

大家好，我是33blog的运维老司机。上周为了给团队搭建一套全球分布的镜像源服务，我同时折腾了AWS、阿里云和GCP三个平台。今天就把这次跨云部署的经验教训分享给大家，特别是那些和我一样喜欢”自讨苦吃”的同仁们。

为什么需要多区域镜像源？

我们团队最近开始全球化协作，开发者在北美、欧洲和亚洲三地办公。每次拉取Docker镜像时，新加坡的同事总是抱怨速度慢得像蜗牛。实测发现，从单一区域拉取镜像，跨洋延迟能高达800ms+，这谁顶得住啊！

于是老板拍板：“搞套全球同步的镜像服务，预算嘛…你懂的”。得，又要开始我的”花小钱办大事”表演了。

技术选型：Harbor还是Nexus？

在方案设计阶段，我首先排除了直接使用云厂商的容器镜像服务——太贵！一个region每月就要上百刀。最终在Harbor和Nexus之间纠结了很久：

Harbor：专为容器镜像设计，自带漏洞扫描
Nexus：老牌神器，支持多种包格式

考虑到我们主要用Docker，最终选择了Harbor。但这里有个血泪教训：Harbor的跨区域同步功能在社区版是阉割的！差点让我白忙活一场，幸好发现得早。

三云部署的配置差异

本以为同样的Harbor配置可以通吃三大云，结果每个平台都给我准备了”惊喜”：

# AWS上必须调整EC2的max_map_count
sudo sysctl -w vm.max_map_count=262144

# 阿里云经典网络需要额外配置安全组
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# GCP的Persistent Disk挂载点权限问题
sudo chown -R 10000:10000 /data

最坑的是阿里云的内网带宽限制。文档里小字写着”不同实例规格内网带宽不同”，我们的2核4G机器同步时直接跑满，导致其他服务卡成PPT。

同步策略优化之路

最初使用定时全量同步，结果：

凌晨3点同步任务触发
东京region的SSD磁盘写爆IOPS
账单出现$200的突发性能费用

后来改用事件驱动+增量同步，配合这个巧妙的nginx配置：

# 根据客户端IP自动路由到最近镜像源
geo $nearest_mirror {
    default harbor-us.example.com;
    116.128.0.0/11 harbor-asia.example.com;
    85.128.0.0/10 harbor-eu.example.com;
}

server {
    listen 443;
    server_name mirror.example.com;
    return 301 https://$nearest_mirror$request_uri;
}