Harbor

概述 你大概率见过这种发布流程：开发同学构建一个 Docker 镜像，打上 dev 标签推到开发仓库；测试通过后，重新打 staging 标签再推一遍；最后上线时，又打 prod 标签推第三次。同一个镜像，构建一次，推送三次，标签换了三个。 这看起来没什么问题——直到有一天，你发现 staging 环境验证的镜像和 prod 环境运行的镜像根本不是同一个。 制品晋升（Artifact Promotion）解决的就是这个问题。核心思想很简单：镜像只构建一次，通过 digest（内容哈希）唯一标识，跨环境晋升时复制的是同一个不可变制品，而不是重新打标签。这听起来像是常识，但我在多个团队落地后发现，真正把这条流水线跑通的团队不到三成。原因不是技术多复杂，而是涉及仓库架构、权限模型、安全门禁、回滚策略等多层决策，每层都有坑。 这篇文章拆解制品晋升流水线的分层设计，结合我在某新能源物流平台 120+ 微服务 K8s 迁移中落地的晋升管道，聊 4 个关键生产决策和踩过的坑。 制品晋升到底是什么 先说清楚概念。很多团队把"制品晋升"和"重新打标签"混为一谈，这是第一个误区。 重新打标签的做法： # 构建一次 docker build -t registry.company.com/app:dev-1.0.0 . docker push registry.company.com/app:dev-1.0.0 # "晋升"到 staging —— 重新 tag 再推 docker tag registry.company.com/app:dev-1.0.0 registry.company.com/app:staging-1.0.0 docker push registry.company.com/app:staging-1.0.0 # "晋升"到 prod —— 又 tag 又推 docker tag registry.company.com/app:staging-1.0.0 registry.company.com/app:prod-1.0.0 docker push registry.company.com/app:prod-1.0.0 这有什么问题？表面上三次推送的都是同一个镜像 ID，但 docker tag 只是在仓库里创建了一个新的标签引用。标签是可变的——有人可以在你不知情的情况下覆盖 staging-1....

概述 凌晨两点，手机震了一下。磁盘告警——95%。 爬起来一看，Harbor 服务器 /data/registry 目录占了 200GB，里面堆了 3000 多个 tag。有去年测试时推的 app:v0.0.3-beta，有构建失败残留的 app:feature-branch-xxx，还有十个版本的 base image 副本——每个都 800MB 起步。 这不是个例。我在多个团队见过同样的剧本：CI/CD 跑起来之后，镜像只管推不管清，三个月后磁盘就炸。更麻烦的是，有些镜像带着已知 CVE 漏洞跑在生产上，权限管理形同虚设——谁都能推、谁都能拉，项目之间没有隔离。 这篇文章解决三个问题：镜像怎么管权限、怎么拦漏洞、怎么清垃圾。我会用 Harbor（CNCF 毕业项目，目前 GitHub 29k+ star）从安装到生产配置走一遍，每一步都给出可直接复制的配置。如果你刚开始搭制品仓库，或者已经有了但管得稀里糊涂，这篇能帮你少走弯路。 为什么需要制品仓库 先说清楚一个概念：制品仓库（Artifact Repository）不是 Docker Hub。 Docker Hub 是公共镜像托管平台，类似 npm 的 registry。你在上面拉官方镜像没问题，但拿它存公司业务镜像？有几个硬伤： 没有细粒度权限。Docker Hub 的 organization 只有 admin 和普通成员，做不到"测试团队能推 dev 项目、不能碰 prod 项目" 没有漏洞扫描。推上去就推上去了，CVE 该有还是有 没有保留策略。镜像只增不减，除非手动删 网络不稳定。国内拉 Docker Hub 限速、超时是家常便饭 Harbor 解决的就是这些问题。说白了，Harbor = Docker Registry + 权限管理 + 漏洞扫描 + 复制同步 + 审计日志。它像一个带安保、带分拣、带回收站的仓库，而不是一个露天堆场。 类比一下：Docker Hub 像公共停车场，谁都能进；Harbor 像企业内部车库，分区域（项目）、刷卡进（RBAC）、进门安检（漏洞扫描）、定期清退僵尸车（GC + 保留策略）。...