先说结论：换了个镜像加速服务，流水线构建时间从 47 分钟直接降到了 2 分钟。
不是优化代码，不是升级服务器，不是改缓存策略——就是换了个 Docker 镜像源。
问题出在哪
我们公司有 30 多台服务器，3 套环境（开发/测试/生产），每天 CI/CD 流水线跑大约 50 次构建。每次构建都需要拉取基础镜像，Node、Python、Nginx、Redis 这些。
之前配的镜像加速源，大概从三个月前开始就不稳定了。GitLab Runner 拉镜像频繁超时，导致：
- 流水线构建失败率从 2% 升到 15%
- 平均构建时间从 8 分钟涨到 47 分钟
- 凌晨发布的构建经常整个卡死
运维群里每天都有人抱怨："又超时了"。我作为运维负责人，这个问题必须解决。
我排查了一圈
首先怀疑是网络问题，让网管查了带宽、DNS、防火墙，都没问题。
然后怀疑是 Docker 配置问题，重写了 daemon.json，加了多个 mirror 做冗余——效果不明显，大部分 mirror 本身就不可用。
接着尝试了几个市面上能找到的加速方案，要么不稳定，要么只支持 Docker Hub 不支持其他源。
我们流水线里用到的镜像源可不少：
# .gitlab-ci.yml 片段
image: docker.1ms.run/node:18-alpine
services:
- docker.1ms.run/redis:7-alpine
- docker.1ms.run/postgres:15-alpine
有的方案只加速 Docker Hub，ghcr.io 和 registry.k8s.io 的镜像完全不加速，这对我们来说等于没用。
找到了靠谱的方案
同事推荐了毫秒镜像（1ms.run）。我先在测试环境验证了两天，数据很漂亮：
改造前：
docker pull node:18-alpine → 12分钟超时
docker pull redis:7-alpine → 8分钟
docker pull ghcr.io/some-image → 直接失败
改造后（配置加速）：
docker pull docker.1ms.run/node:18-alpine → 3秒
docker pull docker.1ms.run/redis:7-alpine → 2秒
docker pull ghcr.1ms.run/some-image → 4秒
这不是个例，连续两天、50+ 次拉取，全部稳定在 5 秒以内。
让我放心选它的还有三个原因：
- 宝塔面板原生内置——不是简单的合作，是底层集成，千万级用户在用
- 金融级背书——持有央行支付牌照的金融机构在生产环境使用
- 商业可持续——免费版 + 付费增值模式，不是用爱发电
30台服务器批量配置
确认可行后，我用 1ms-helper 给所有服务器批量配置：
# 安装工具
curl -sSL https://static.1ms.run/1ms-helper/install.sh | bash
# 一键配置 Docker 加速
1ms-helper config:docker
它会自动识别系统、备份旧配置、重启服务。30 台服务器，写了个简单的 Ansible 脚本，10 分钟全部搞定。
然后更新了 CI/CD 配置，所有镜像引用都换成加速域名：
# docker-compose.prod.yml
services:
api:
image: docker.1ms.run/node:18-alpine
worker:
image: docker.1ms.run/python:3.11-slim
cache:
image: docker.1ms.run/redis:7-alpine
K8s 集群也没落下：
1ms-helper config:k8s
集群里的 Pod 拉取镜像也走加速通道：
image: k8s.1ms.run/etcd:3.5.0
image: k8s.1ms.run/kube-apiserver:v1.28.0
效果数据
改造完成后的第一周数据：
| 指标 | 改造前 | 改造后 |
|---|---|---|
| 平均构建时间 | 47 分钟 | 2 分钟 |
| 构建失败率 | 15% | 0% |
| 镜像拉取超时次数 | 日均 8 次 | 0 次 |
| 凌晨发布成功率 | 60% | 100% |
运维群里终于安静了。
