从零构建私有容器镜像仓库：基于Docker Distribution与MinIO的生产级实践

1. 项目概述：从零构建一个现代化的容器镜像仓库

最近在整理团队内部的开发资产时，发现了一个挺有意思的现象：大家对于公共镜像仓库（比如 Docker Hub）的依赖越来越深，但随之而来的问题也越来越多。下载速度慢、镜像安全审核不可控、某些特定版本镜像突然消失……这些问题在项目紧急上线或者进行安全合规审计时，往往会变成卡住整个流程的“暗礁”。于是，搭建一个私有的、可控的容器镜像仓库，就成了很多技术团队从“会用”到“用好”容器技术的必经之路。

今天要聊的这个项目goondocks-co/myco，就是一个典型的私有容器镜像仓库实现方案。它不是一个简单的docker run registry:2就完事的玩具，而是一个考虑了认证授权、存储管理、安全扫描和CI/CD集成的生产级解决方案。简单来说，myco项目旨在为中小型团队或项目组，提供一个开箱即用、易于维护且功能完备的私有镜像托管服务。无论你是运维工程师需要统一管理公司的基础镜像，还是开发团队想固化自己的构建产出，这个方案都能提供一个清晰的路径。

接下来，我会把自己从零搭建、配置到优化这样一个仓库的完整过程拆解开来，包括技术选型的思考、每一步操作的意图、踩过的坑以及最终沉淀下来的最佳实践。你会发现，搭建一个仓库远不止是启动一个服务，它涉及到网络、存储、安全、运维等多个维度的考量。

2. 核心架构设计与技术选型

在动手敲命令之前，花点时间想清楚架构是至关重要的。一个随意的架构可能在初期跑得起来，但随着镜像数量增长、团队扩大，各种问题就会暴露无遗。myco项目的核心设计目标很明确：安全、可靠、易维护、可扩展。

2.1 核心组件拆解与选型理由

一个完整的私有镜像仓库，通常由以下几个核心部分组成：

1. Registry 服务器：这是提供镜像推送、拉取API的核心服务。我们选择Docker Distribution（即常说的 Registry 2.x）。不选择 Harbor 或 Quay 这类更重量级方案的原因是，myco定位是轻量、核心可控，我们希望从最基础的组件开始构建，以便深入理解每一个环节。Docker Distribution 足够稳定，API 规范，是许多上层产品的基础。

2. 反向代理与 TLS 终结：Registry 服务本身对 HTTPS 的支持需要自行配置证书。更常见的做法是使用一个反向代理（如 Nginx）来处理 HTTPS、负载均衡和基本的访问控制。选择Nginx是因为其轻量、高性能，并且有丰富的模块和社区支持，配置 SSL 证书和基于 IP/Token 的访问控制都非常方便。

3. 认证与授权：这是安全的核心。单纯的 Nginx 基础认证太弱。我们采用Token 认证模式，并引入一个简单的认证服务。这里有一个关键决策点：是集成 LDAP/AD 还是使用独立的账户系统？考虑到myco可能服务于多个独立项目组，我们选择实现一个基于配置文件或数据库的轻量级账户系统，认证服务使用Go或Python编写一个小型 HTTP 服务，与 Nginx 的auth_request模块配合。这样既能实现灵活的权限管理（如项目空间隔离），又避免了维护一套复杂目录服务的开销。

4. 存储后端：镜像数据存哪里？默认的文件系统在单机下可行，但不利于扩展和高可用。我们选择对象存储作为后端。对于云上部署，可以直接使用 AWS S3、阿里云 OSS 或腾讯云 COS 的兼容接口；对于本地化部署，可以搭建MinIO这样一个与 S3 协议兼容的对象存储。这样做的好处是存储层天然具备扩展性和持久性，Registry 服务本身可以无状态部署。

5. 缓存与加速：为了提升团队内拉取公共镜像的速度，并为私有镜像提供边缘缓存，我们引入Registry Mirror功能。可以使用registry:2镜像本身的代理缓存功能，或者单独部署一个缓存服务。这部分属于性能优化范畴，可以在核心服务稳定后再叠加。

基于以上分析，myco的架构简图如下：用户通过 HTTPS 访问 Nginx，Nginx 先将认证请求转发给自定义的 Auth Service，验证通过后，请求被代理到后端的 Registry 服务，Registry 最终将镜像的 Blob 数据存储到 S3 兼容的对象存储中。

2.2 存储与网络规划

存储规划是另一个重点。假设我们使用 MinIO 作为本地对象存储。

• Bucket 规划：为镜像仓库单独创建一个 Bucket，例如myco-registry。可以在 Bucket 内部通过路径前缀区分不同环境，如prod/,dev/，但这通常不是最佳实践，更好的隔离是通过不同的 Registry 实例或命名空间实现。
• 存储策略：在 MinIO 或云对象存储中，可以设置生命周期规则，自动清理未被引用的镜像层（通过垃圾回收后标记为孤立的 Blob），但切记，镜像仓库的垃圾回收是一个需要谨慎手动触发的操作，不能完全依赖对象存储的生命周期，否则可能误删正在使用的数据层。

网络规划：

• 域名：为服务分配一个内部域名，如registry.mycompany.internal。所有 Docker Client 都需要配置信任该域名或其所使用的证书。
• 端口：Nginx 对外暴露 443 端口。Registry 服务本身可以在本地监听一个高位端口，如 5000，由 Nginx 反向代理。
• 防火墙：确保运行 Docker Client 的机器（构建服务器、开发机）能够访问该域名的 443 端口。

注意：千万不要在公网直接暴露未配置任何认证的 Registry 服务端口（如 5000）。即使有内网防火墙，也建议始终通过配置了认证的反向代理来访问，这是安全底线。

3. 分步实施与核心配置详解

理论说完，我们进入实战环节。以下操作假设在一个干净的 Linux 服务器（如 Ubuntu 22.04）上进行。

3.1 基础环境与依赖安装

首先，更新系统并安装必要工具：

sudo apt update && sudo apt upgrade -y sudo apt install -y docker.io docker-compose nginx certbot python3-certbot-nginx

这里选择了docker.io（Ubuntu 仓库版本）而非 Docker 官方源，是为了版本稳定性。docker-compose用于编排多容器服务。certbot用于从 Let‘s Encrypt 申请免费的 SSL 证书（如果使用内部 CA，则不需要）。

启动并设置 Docker 开机自启：

sudo systemctl start docker sudo systemctl enable docker

3.2 部署 MinIO 对象存储

我们使用 Docker Compose 来部署 MinIO，配置文件docker-compose.minio.yml：

version: '3.8' services: minio: image: minio/minio:latest container_name: myco-minio command: server /data --console-address ":9001" environment: MINIO_ROOT_USER: mycoadmin # 强烈建议在生产环境使用更复杂的密钥 MINIO_ROOT_PASSWORD: mycoadmin123 # 生产环境务必使用强密码并存入 secrets volumes: - ./minio-data:/data # 挂载数据目录，实现数据持久化 ports: - "9000:9000" # API 端口，Registry 将使用这个端口 - "9001:9001" # 控制台端口，用于管理 restart: unless-stopped

启动 MinIO：

docker-compose -f docker-compose.minio.yml up -d

访问http://<服务器IP>:9001，使用上面设置的用户名密码登录。在控制台中：

1. 创建一个 Bucket，命名为myco-registry。
2. 为了安全，可以创建一个专用于 Registry 服务的 Access Key 和 Secret Key。在 MinIO 控制台的Access Keys页面创建，记下生成的Access Key和Secret Key，后面配置 Registry 时会用到。这样做的目的是遵循最小权限原则，Registry 服务只有操作这个 Bucket 的权限。

3.3 配置私有镜像仓库核心服务

这是最核心的一步。我们编写 Registry 和 Nginx 的配置。

首先，创建目录结构：

mkdir -p myco/{auth,config,certs,data} cd myco

1. 准备 SSL 证书：如果是内部使用，可以使用自签名证书，但需要让所有 Docker Client 信任它，比较麻烦。这里演示使用 Let‘s Encrypt 的免费证书，前提是你有公网域名并解析到了该服务器。

sudo certbot --nginx -d registry.yourdomain.com

证书会自动配置到 Nginx。证书路径通常为/etc/letsencrypt/live/registry.yourdomain.com/。我们将用到的fullchain.pem和privkey.pem链接到我们的配置目录（或直接在 Nginx 配置中引用绝对路径）。

2. 编写 Registry 配置文件config/config.yml：

version: 0.1 log: fields: service: registry storage: s3: accesskey: "YOUR_MINIO_ACCESS_KEY" # 替换为 MinIO 创建的 Access Key secretkey: "YOUR_MINIO_SECRET_KEY" # 替换为对应的 Secret Key region: us-east-1 # MinIO 默认 region bucket: myco-registry secure: false # 如果是 HTTP 连接 MinIO，设为 false endpoint: minio:9000 # MinIO 服务地址，这里用容器名，需在同一网络 pathstyle: true # MinIO 需要使用路径风格 delete: enabled: true # 允许通过 API 删除镜像（需谨慎） maintenance: uploadpurging: enabled: true age: 168h # 上传中断的 Blob 保留 7 天 interval: 24h readonly: enabled: false http: addr: :5000 headers: X-Content-Type-Options: [nosniff] auth: token: realm: http://auth-service:8080/auth # 认证服务地址，稍后实现 service: "myco-registry" issuer: "MyCo Auth Service" rootcertbundle: /etc/registry/auth/root.crt # 认证服务的根证书（如果认证服务用 HTTPS） health: storagedriver: enabled: true interval: 10s threshold: 3

3. 编写 Nginx 配置文件config/nginx.conf：

events { worker_connections 1024; } http { upstream registry { server registry:5000; # 指向 registry 容器 } upstream auth_service { server auth-service:8080; # 指向认证服务容器 } server { listen 443 ssl; server_name registry.yourdomain.com; # SSL 证书路径 (使用 Certbot 生成的证书) ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; # 禁用不必要的 HTTP 方法 if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 405; } # 对 /v2/ 路径下的所有请求进行认证 location /v2/ { # 将认证请求转发给认证服务 auth_request /auth; auth_request_set $auth_status $upstream_status; # 如果认证通过，将用户信息传递给 Registry auth_request_set $user $upstream_http_x_user; proxy_set_header X-Forwarded-User $user; # 代理到 Registry 服务 proxy_pass http://registry; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 900; # 处理 Docker 客户端需要的特定头部 client_max_body_size 0; chunked_transfer_encoding on; } # 内部认证接口，对外不可见 location = /auth { internal; proxy_pass http://auth_service/auth; proxy_pass_request_body off; proxy_set_header Content-Length ""; proxy_set_header X-Original-URI $request_uri; proxy_set_header X-Original-Method $request_method; } # 健康检查端点，无需认证 location /v2/ { limit_except GET { deny all; } proxy_pass http://registry; } location /health { proxy_pass http://registry; } } }

4. 实现一个简单的认证服务（示例）：这是一个极度简化的 Go 语言示例，实际生产环境需要连接数据库、支持更多权限模型。创建auth/main.go：

package main import ( "encoding/json" "fmt" "log" "net/http" "strings" ) // 模拟用户数据库 var users = map[string]string{ "developer": "readwrite", "ci-bot": "write", "viewer": "read", } func authHandler(w http.ResponseWriter, r *http.Request) { authHeader := r.Header.Get("Authorization") if authHeader == "" { http.Error(w, `{"errors":[{"code":"UNAUTHORIZED","message":"authentication required"}]}`, http.StatusUnauthorized) return } // 简单解析 Basic Auth parts := strings.SplitN(authHeader, " ", 2) if len(parts) != 2 || parts[0] != "Basic" { http.Error(w, "Invalid authorization header", http.StatusUnauthorized) return } // 这里应该正确解码 Base64 并验证用户名密码 // 示例中硬编码一个成功逻辑 username := "developer" // 实际应从解码后的字符串中提取并验证 // 根据路径和方法检查权限 (极简版) path := r.Header.Get("X-Original-URI") method := r.Header.Get("X-Original-Method") // 示例权限逻辑：viewer 只能拉取(GET)， developer 可以推送和拉取 userScope := users[username] if userScope == "read" && method != "GET" { http.Error(w, "Forbidden", http.StatusForbidden) return } // 认证通过，返回用户信息和权限范围给 Nginx w.Header().Set("X-User", username) // 可以返回更细粒度的 scope，如 `repository:myproject/myimage:pull,push` w.WriteHeader(http.StatusOK) } func main() { http.HandleFunc("/auth", authHandler) log.Println("Auth service starting on :8080") log.Fatal(http.ListenAndServe(":8080", nil)) }

为其编写auth/Dockerfile：

FROM golang:1.19-alpine AS builder WORKDIR /app COPY main.go . RUN go mod init auth && go build -o auth . FROM alpine:latest WORKDIR /root/ COPY --from=builder /app/auth . EXPOSE 8080 CMD ["./auth"]

5. 编写主 Docker Compose 文件docker-compose.yml：

version: '3.8' services: nginx: image: nginx:alpine container_name: myco-nginx ports: - "443:443" volumes: - ./config/nginx.conf:/etc/nginx/nginx.conf:ro - /etc/letsencrypt/live/registry.yourdomain.com:/etc/nginx/ssl:ro # 挂载证书 depends_on: - registry - auth-service networks: - myco-net registry: image: registry:2 container_name: myco-registry environment: - REGISTRY_HTTP_SECRET=somereallystrongsecretkey # 用于签名状态，需随机生成 volumes: - ./config/config.yml:/etc/docker/registry/config.yml:ro depends_on: - minio networks: - myco-net auth-service: build: ./auth container_name: myco-auth networks: - myco-net minio: # 为了演示，这里直接引用。更佳实践是单独运行 MinIO，或通过 external_links 连接 image: minio/minio container_name: myco-minio command: server /data --console-address ":9001" environment: MINIO_ROOT_USER: minioadmin MINIO_ROOT_PASSWORD: minioadmin123 volumes: - minio-data:/data networks: - myco-net # 注意：如果 MinIO 单独部署，此处不需要定义，但需确保 network 互通 networks: myco-net: driver: bridge volumes: minio-data:

3.4 启动与验证服务

在myco目录下，启动所有服务：

docker-compose up -d

使用docker-compose logs -f查看日志，确保没有报错。

验证服务：

1. 登录仓库：在另一台安装了 Docker 的机器上，首先确保/etc/hosts或 DNS 将registry.yourdomain.com解析到了服务器 IP。

   docker login registry.yourdomain.com

   输入用户名developer和任意密码（因为我们示例认证服务直接通过了）。如果看到Login Succeeded，说明认证和网络通路正常。

2. 推送镜像：

   # 拉取一个测试镜像 docker pull alpine:latest # 重新打标签，指向我们的私有仓库 docker tag alpine:latest registry.yourdomain.com/myproject/alpine:latest # 推送 docker push registry.yourdomain.com/myproject/alpine:latest

   观察推送过程是否成功。成功后，可以登录 MinIO 控制台，在myco-registryBucket 中看到新增的目录和文件。

3. 拉取镜像：

   # 先删除本地镜像 docker rmi registry.yourdomain.com/myproject/alpine:latest # 从私有仓库拉取 docker pull registry.yourdomain.com/myproject/alpine:latest

4. 高级配置、优化与运维实践

基础服务跑通只是第一步，要让其稳定服务于生产，还需要进行一系列优化和加固。

4.1 认证与权限的深度定制

上面的认证服务示例过于简单。一个生产级的认证服务应该：

• 支持多种后端：连接数据库（如 PostgreSQL）、LDAP/AD 或 OAuth2 提供商。
• 实现命名空间隔离：用户alice只能推送/拉取alice/*下的镜像，bob只能操作bob/*下的镜像。这需要在认证服务解析请求路径（X-Original-URI），并根据用户身份和路径进行匹配。
• 集成 CI/CD 系统：为 Jenkins、GitLab Runner 等创建机器人账户（Robot Account），授予特定的推送权限。
• 签发有效的 JWT Token：Registry 的 Token 认证协议期望认证服务返回一个标准的 JWT Token，其中包含了授权的access字段，详细描述了权限范围。这比我们示例中简单的头部传递更规范、更安全。

4.2 存储优化与垃圾回收

存储优化：

• 使用云厂商对象存储：如果服务器在云上，强烈建议直接使用云厂商的对象存储服务（如 S3、OSS）。它们通常提供更高的持久性、可用性和带宽。只需修改config.yml中的s3配置部分，替换endpoint、accesskey、secretkey和region，并设置secure: true。
• 启用存储分层：对于云对象存储，可以配置生命周期规则，将30天前的镜像层转移到低频访问或归档存储层，以节省成本。

垃圾回收（Garbage Collection）：Registry 中删除镜像标签（docker rmi）并不会立即释放物理存储空间，因为镜像层（Blob）可能被其他镜像引用。需要手动执行垃圾回收来删除未被任何清单（Manifest）引用的 Blob。

1. 首先，将 Registry 设置为只读模式，防止在 GC 期间有新的推送。

   # 在 config.yml 的 maintenance 部分 readonly: enabled: true

   然后重启 Registry 服务。
2. 执行垃圾回收命令。由于我们使用容器部署，需要进入容器执行：

   docker exec myco-registry /bin/registry garbage-collect /etc/docker/registry/config.yml

   这个命令会进行“试运行”，显示哪些 Blob 会被删除。确认无误后，加上-m参数真正删除：

   docker exec myco-registry /bin/registry garbage-collect -m /etc/docker/registry/config.yml

3. GC 完成后，记得将readonly改回false并重启服务。

重要警告：垃圾回收是一个危险操作，务必在业务低峰期进行，并确保有完整的备份。错误操作可能导致数据丢失。

4.3 日志、监控与高可用考虑

日志收集：将 Nginx、Registry 和认证服务的日志统一收集到 ELK（Elasticsearch, Logstash, Kibana）或 Loki 中，便于审计和排查问题。在 Docker Compose 中可以使用logging驱动配置。

监控指标：Registry 服务内置了 Prometheus 指标端点（默认在/metrics）。可以通过配置，让 Prometheus 来抓取这些指标，监控镜像推送/拉取次数、延迟、错误率、存储用量等。

高可用（HA）部署： 对于核心生产环境，单点部署风险高。可以考虑以下方向：

1. Registry 服务无状态化：因为数据已存储在共享的对象存储（如 S3）中，可以轻松部署多个 Registry 实例，前面通过 Nginx 或云负载均衡器做负载均衡。
2. Nginx 高可用：使用 Keepalived + VIP 或者直接使用云负载均衡器（如 AWS ALB、Nginx Ingress Controller）。
3. 认证服务高可用：同样可以多实例部署，使用数据库共享会话或状态。
4. 对象存储：云厂商的对象存储服务本身通常就是高可用和持久化的。

一个简化的 HA 架构可以是：对象存储（S3）作为唯一数据源 -> 多个 Registry 实例（无状态） -> 负载均衡器 -> 多个 Nginx/Auth 实例。

4.4 安全加固清单

1. 使用强密码与密钥：MinIO 的 root 密码、Registry 的http.secret、认证服务的密钥等，必须使用强随机字符串，并通过 Docker Secrets 或环境变量文件（.env，且加入.gitignore）管理，切勿硬编码在 Compose 文件中。
2. 网络隔离：将服务部署在内部网络，通过跳板机或 VPN 访问。如果必须暴露公网，除了 HTTPS 和认证，还可以配置 Nginx 的 IP 白名单、限流（limit_req模块）和 WAF 规则。
3. 镜像安全扫描：集成镜像漏洞扫描工具（如 Trivy、Clair），在镜像推送后自动扫描，并阻止包含高危漏洞的镜像被部署到生产环境。这通常需要在 CI/CD 流水线或 Registry 的 Webhook 中实现。
4. 定期更新：定期更新 Docker 镜像（如registry:2、nginx）到最新稳定版，以获取安全补丁。
5. 审计日志：确保所有认证、推送、拉取、删除操作都被完整记录，并定期审查。

5. 常见问题与故障排查实录

在实际搭建和运维过程中，你肯定会遇到各种各样的问题。这里记录几个典型问题及其解决方法。

5.1 推送镜像时报错 “blob upload unknown” 或 “received unexpected HTTP status: 500 Internal Server Error”

问题分析：这通常是 Registry 与存储后端（如 S3）通信出现问题，或者存储后端权限配置不正确。排查步骤：

1. 检查 Registry 日志：docker logs myco-registry。这是最直接的错误信息来源。可能会看到 S3 访问被拒绝（Access Denied）或连接超时的具体错误。
2. 验证 S3/MinIO 配置：
   • 确认config.yml中的accesskey和secretkey正确无误，且该密钥对目标 Bucket 拥有PutObject、GetObject、ListBucket等必要权限。
   • 确认endpoint地址和端口正确，并且从 Registry 容器内可以访问到这个地址（docker exec myco-registry ping minio或curl http://minio:9000）。
   • 如果使用 MinIO 且通过 HTTP（非 HTTPS）连接，确保secure: false。
3. 检查网络连通性：确保 Registry、MinIO/Nginx 容器在同一个 Docker 网络（myco-net）中，并且防火墙规则允许相关端口通信。

5.2 Docker 客户端登录或操作时证书错误

错误信息：x509: certificate signed by unknown authority或Error response from daemon: Get "https://registry...": tls: failed to verify certificate。

问题分析：Docker 客户端不信任私有仓库使用的 SSL 证书。如果是自签名证书，必须让客户端信任它；如果是 Let‘s Encrypt 证书，可能是中间证书问题或客户端版本过旧。

解决方案：

• 对于自签名证书：
  1. 将自签名证书的 CA 公钥（或服务器证书本身）复制到 Docker 客户端机器的/etc/docker/certs.d/registry.yourdomain.com/ca.crt目录下。注意目录结构，registry.yourdomain.com是仓库地址的域名部分。
  2. 重启 Docker 服务：sudo systemctl restart docker。
• 对于 Let‘s Encrypt 证书：确保 Certbot 成功续期，并且 Nginx 配置中引用的证书路径正确。可以尝试在客户端用curl -v https://registry.yourdomain.com/v2/测试，看 SSL 握手是否成功。

5.3 拉取镜像速度慢

问题分析：可能原因有网络带宽不足、镜像层太大、或者没有配置缓存。优化方案：

1. 配置 Registry Mirror（缓存）：在 Docker 客户端机器上，配置/etc/docker/daemon.json，为 Docker Hub 等公共仓库设置镜像加速器，同时也可以为私有仓库设置一个本地缓存镜像。

   { "registry-mirrors": ["https://<your-mirror-domain>"], "insecure-registries": [], "dns": ["8.8.8.8"] }

   可以部署一个专门的缓存 Registry 实例，配置为代理模式（proxy.remoteurl），缓存公共镜像。
2. 优化存储后端：如果使用自建 MinIO，确保 MinIO 服务器有足够的磁盘 I/O 性能。如果使用云存储，检查是否同地域访问，并考虑启用传输加速等功能。
3. 压缩镜像：在构建镜像时，优化 Dockerfile，减少层数，清理不必要的中间文件，使用更小的基础镜像（如 Alpine Linux）。

5.4 认证服务故障导致所有操作被拒绝

问题分析：Nginx 的auth_request模块依赖认证服务返回 2xx 状态码才算认证成功。如果认证服务挂掉、返回 5xx 错误或 4xx 错误，所有请求都会被拒绝。高可用方案：

1. 健康检查与熔断：在 Nginx 的upstream配置中为auth_service添加health_check，并配置proxy_next_upstream在超时或错误时尝试备用节点（如果你部署了多个认证服务实例）。
2. 降级策略（谨慎使用）：对于某些只读操作（如拉取公开的基础镜像），可以考虑在认证服务不可用时，绕过认证或使用一个默认的只读令牌。但这会降低安全性，需权衡。
3. 监控与告警：对认证服务的存活和接口响应时间设置监控告警，确保能第一时间发现并处理故障。

搭建和维护一个私有镜像仓库，就像打理一个数字化的“货仓”，初期规划好“货架”（存储）、“门禁”（认证）和“流水线”（CI/CD集成），后期做好“巡检”（监控）和“盘点”（垃圾回收），才能让它长久、稳定、高效地支撑起整个团队的容器化交付流程。goondocks-co/myco这个项目标题背后，正是这样一套从简到繁、持续演进的工程实践。希望这份超详细的拆解，能帮你避开我当年踩过的那些坑，顺利搭建起属于自己团队的、靠谱的镜像仓库服务。