docker registry的核心职责是集中存储、分发和管理容器镜像，作为构建与运行之间的可信中间枢纽；它通过内容寻址、分层复用、访问控制及元数据管理，实现镜像一致性、存储优化与devops流程闭环。
Docker 架构中，Registry 不是 Docker 引擎的一部分，而是独立运行的镜像仓库服务，它的核心职责是**集中存储、分发和管理容器镜像**，在构建与运行之间充当可信的“中间枢纽”。
Registry 是镜像的统一交付中心
开发人员用 docker build 生成镜像后，必须通过 docker push 上传到 Registry；部署时再用 docker pull 从 Registry 下载。这个过程把镜像构建（开发侧）和镜像使用（运行侧）彻底解耦，确保“一次构建、处处运行”的一致性基础。
- 同一镜像 digest（如
sha256:abc123...）在任何环境拉取都保证内容完全一致 - 不同团队或集群只需配置相同 Registry 地址，就能共享同一套镜像版本
- 避免了直接拷贝 tar 包、手动导入导出等不可审计、易出错的操作
Registry 支持内容寻址与分层复用
它不把镜像当作整体文件存储，而是按 layer 拆解，每层用 SHA256 哈希唯一标识。上传时只传本地没有的 layer，拉取时也只下载缺失的 layer。
- 比如 base 镜像（如
alpine:3.18）被多个应用复用，物理上只存一份 - 两个基于相同基础镜像的应用，即使 tag 不同，只要 layer 相同就自动去重
- 这大幅降低存储开销和网络带宽消耗，尤其适合 CI/CD 中高频构建场景
Registry 提供可扩展的访问控制与元数据管理
它本身是无状态服务，但可通过插件或配置集成认证、授权、审计等能力：
- Basic Auth、OAuth2 或 LDAP 可限制谁可以 push/pull 特定命名空间下的镜像
- Manifest 文件记录镜像结构、layer 列表、config 配置等元数据，支持标签（tag）与 digest 的映射管理
- 企业级方案（如 Harbor）还内置漏洞扫描、镜像签名、复制策略和操作日志，满足合规要求
Registry 是 DevOps 流水线的关键锚点
在自动化流程中，Registry 承担着“质量出口”和“部署入口”的双重角色：
- CI 系统构建成功后，自动 push 到 Registry —— 这一步常作为发布门禁（gate）
- CD 系统从 Registry 拉取指定 digest 的镜像部署 —— 避免 tag 被覆盖导致的不确定性
- 结合 webhook 或事件通知，还可触发后续动作，如更新 Kubernetes 部署清单、启动测试任务
