2. 容器镜像仓库基础：Docker Registry、Harbor、AWS ECR、Azure ACR、Google GCR/GAR 核心概念与对比
容器镜像仓库是云原生交付链路的起点。本章从自建方案与托管方案两个维度，梳理 Docker Registry、Harbor、AWS ECR、Azure ACR、Google GCR/GAR 的核心概念、架构差异与选型要点，为后续流水线集成打下基础。
2.1 镜像仓库核心概念
无论使用哪种仓库，以下概念是所有镜像仓库的通用抽象层：
| 概念 | 说明 | 类比 |
|---|---|---|
| Repository（仓库） | 存储同一镜像不同标签的集合，通常对应一个软件组件 | Git 仓库 |
| Tag（标签） | 镜像的版本标识，如 nginx:1.25 |
Git 标签 |
| Digest（摘要） | 镜像内容的 SHA256 哈希值，不可变标识 | Git commit SHA |
| Manifest（清单） | 描述镜像层、配置、架构的 JSON 元数据 | 包索引文件 |
| Blob（数据块） | 镜像层的实际内容，通过 Content-Addressable 存储 | Git 对象 |
| Registry（注册表） | 提供镜像存储、分发、认证的服务器 | Git 远程服务器 |
关键认知： 镜像仓库的核心操作是
push（上传 Manifest + Blob）和 pull（拉取 Manifest + 按需下载 Blob）。所有仓库都遵循 OCI Distribution Spec，因此上层工具（如 Docker CLI、containerd）可以跨仓库使用。
2.2 自建方案：Docker Registry 与 Harbor
2.2.1 Docker Registry（Distribution）
Docker Registry 是 OCI 标准的最简实现，官方镜像为 registry:2。适合开发测试环境或边缘节点缓存。
- 存储后端： 本地文件系统、S3、GCS、Azure Blob、Swift。
- 认证： 无内置认证，需前置 Nginx Basic Auth 或 认证。
- UI： 无 Web UI，需配合第三方工具（如 Portus、docker-registry-ui）。
- 清理： 无自动 GC，需手动执行
registry garbage-collect。 - 多租户： 不支持命名空间隔离。
# 快速启动 Docker Registry
docker run -d -p 5000:5000 --name registry registry:2
# 推送镜像
docker tag nginx:latest localhost:5000/nginx:latest
docker push localhost:5000/nginx:latest
# 拉取镜像
docker pull localhost:5000/nginx:latest2.2.2 Harbor
Harbor 是 CNCF 毕业项目，基于 Docker Registry 构建，增加了企业级功能：
- RBAC： 项目级用户权限管理，支持 LDAP/AD/OIDC。
- 漏洞扫描： 集成 Trivy、Clair，推送时自动扫描。
- 镜像复制： 基于规则的跨机房/跨云异步同步。
- 垃圾回收： 自动清理未引用的 Blob。
- Webhook： 镜像推送/扫描完成时触发回调。
- 审计日志： 记录所有操作行为。
生产建议： 企业内网环境首选 Harbor。它解决了 Docker Registry 缺少的认证、扫描、复制三大痛点，且与 Kubernetes 集成成熟（通过 OIDC 或 Robot Account 实现拉取凭证自动轮换）。
2.3 托管方案：AWS ECR / Azure ACR / Google GCR & GAR
三大公有云均提供托管镜像仓库，免运维、与云原生服务深度集成。以下从核心特性、定价模型、集成能力三个维度对比。
| 特性 | AWS ECR | Azure ACR | Google GCR / GAR |
|---|---|---|---|
| 服务名称 | Amazon Elastic Container Registry | Azure Container Registry | Google Container Registry (GCR) / Artifact Registry (GAR) |
| 仓库地址格式 | <account>.dkr.ecr.<region>.amazonaws.com |
<name>.azurecr.io |
gcr.io/<project> / <region>-docker.pkg.dev/<project> |
| 认证方式 | IAM + 临时 （aws ecr get-login-password） |
Azure AD + 管理员凭据 / Managed Identity | GCP Service Account + JSON Key / Workload Identity |
| 漏洞扫描 | Amazon Inspector（增强版） | Microsoft Defender for Cloud | Container Analysis（自动） |
| 跨区域复制 | 单区域，需手动跨区域推送 | Geo-replication（多主复制） | GAR 支持多区域仓库 |
| 不可变标签 | 支持（仓库级配置） | 支持（仓库级配置） | 支持（GAR 仓库级配置） |
| 生命周期策略 | 支持（基于标签数量/天数） | 支持（保留策略） | 支持（GAR 清理策略） |
| Webhook | EventBridge + SNS | ACR Tasks + Event Grid | Pub/Sub + Cloud Functions |
| 免费额度 | 500MB/月 | 100GB 存储（基本 SKU） | GCR 免费 500MB；GAR 按量计费 |
注意： Google 已宣布 GCR 进入维护模式，新项目应直接使用 Artifact Registry（GAR）。GAR 支持 Docker、Maven、npm、Python 等多种制品格式，是 GCP 的统一制品仓库。
2.4 架构对比：自建 vs 托管
以下 SVG 图展示自建仓库（Harbor）与托管仓库（以 AWS ECR 为例）的架构差异，重点对比认证、存储、扫描、复制链路。
2.5 选型决策矩阵
根据团队规模、合规要求、云绑定程度，推荐以下选型路径：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 个人开发 / 单机测试 | Docker Registry | 最轻量，一条命令启动 |
| 企业内网 / 合规要求高 | Harbor | RBAC、扫描、审计、离线部署 |
| 深度使用 AWS 生态 | AWS ECR | 与 EKS、CodeBuild、Lambda 原生集成 |
| 深度使用 Azure 生态 | Azure ACR | 与 AKS、DevOps、Managed Identity 集成 |
| 深度使用 GCP 生态 | Google Artifact Registry | 统一制品管理，与 GKE、Cloud Build 集成 |
| 多云 / 混合云 | Harbor + 云仓库同步 | Harbor 作为中心，云仓库作为分发边缘 |
2.6 镜像仓库同步基础模式
流水线集成中，镜像同步是核心需求。以下 SVG 图展示三种常见同步拓扑：
流水线集成要点： 在 CI/CD 中，推荐使用
skopeo copy 或 crane copy 进行跨仓库同步，它们不依赖 Docker daemon，支持多架构镜像（manifest list）的完整复制，且性能优于 docker pull + docker push。
# 使用 skopeo 跨仓库同步（无需 Docker daemon）
skopeo copy --src-creds aws:$(aws ecr get-login-password) \
docker://123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:latest \
--dest-creds admin:Harbor12345 \
docker://harbor.internal/library/myapp:latest
# 使用 crane 同步（Google 工具）
crane copy gcr.io/my-project/myapp:latest us-central1-docker.pkg.dev/my-project/myapp:latest2.7 本章小结
- Docker Registry 适合轻量场景，但缺少企业级功能。
- Harbor 是自建首选，提供 RBAC、扫描、复制、审计。
- AWS ECR / Azure ACR / Google GAR 是云原生最佳选择，与各自云生态深度绑定。
- 镜像同步有 Pull、Push、Proxy Cache 三种模式，流水线中优先使用
skopeo或crane工具。 - 选型时需综合考虑：合规要求、运维成本、云绑定程度、多架构支持、同步拓扑。