GCP国际版 谷歌云私有仓库搭建

为什么要在谷歌云上搭建私有仓库

做容器开发的人，大多都经历过一个共同的阶段：一开始镜像都往公共仓库里扔，图省事；后来项目一多，版本一乱，权限一复杂，就开始怀念“自己家后院有个仓库”的日子。所谓私有仓库，说白了就是把镜像、包、制品这些东西放进一个只有自己人能进的地方，避免泄露，也方便统一管理。尤其在谷歌云环境里，项目通常会和 Kubernetes、CI/CD、自动化部署绑在一起，这时候如果没有一个靠谱的私有仓库，流程就像炒菜没盐——也能吃，但总觉得差点意思。

GCP国际版 谷歌云本身就很适合做这件事。它有成熟的身份认证体系，有可扩展的存储和网络能力，也能和 GKE、Cloud Build、IAM 这些服务顺手串起来。你可以把它理解成：不是单纯在云上放个“镜像柜子”，而是顺手把门禁、监控、搬运工、钥匙串都配齐了。搭好了之后，开发同学 push 镜像，运维同学拉镜像，CI 负责自动构建，权限控制则交给 IAM 管。各司其职，谁也别越界，省心不少。

先想清楚：你要搭的到底是哪种私有仓库

很多人一上来就问“怎么搭”，其实更应该先问“搭哪种”。在谷歌云里，和镜像仓库相关的方案不止一种，常见思路大体有三类：一类是使用谷歌云原生的制品仓库服务，适合大多数现代化项目；一类是自己在 Compute Engine 或 GKE 上部署 Docker Registry，灵活但更费心；还有一类是借助第三方仓库系统，比如 Harbor，再配合谷歌云基础设施使用。不同选择对应不同成本、维护复杂度和可控程度。

如果你的需求比较简单，主要是存放 Docker 镜像，并且希望少折腾，那么直接用谷歌云原生方案通常是最稳的。它的优势是省运维，不用自己管存储后端、证书、备份和高可用，基本把繁琐工作交给平台处理。缺点也很明显：想完全按自己的习惯定制，灵活度不如自建。反过来说，如果你特别在意私有化控制、定制化扫描策略、细粒度权限、镜像同步和多环境隔离，那自建 Harbor 这类方案会更有“折腾的快乐”。当然，快乐的另一面，往往是凌晨两点排查配置文件。

本文主要围绕谷歌云上的常见私有仓库搭建思路来讲，重点放在实际可操作、能落地、少踩坑。你会看到从项目准备到上传拉取，再到权限和自动化的一整条路径。目标只有一个：让镜像从“谁都能碰”变成“只有该碰的人能碰”。

搭建前的准备工作

开项目、开计费、开权限

在谷歌云上做任何事，第一步基本都是项目。没有项目，就像没有文件夹，后面东西再多也没地方放。先创建一个专门的项目，比如叫 registry-demo、prod-images 之类，名字不重要，重要的是别和生产环境混着来。然后确认计费已开启，否则很多服务点进去都像门口挂着“暂不营业”。

接下来是权限。谷歌云的权限管理核心是 IAM，也就是谁能做什么。建议给仓库相关操作单独分配账号或服务账号，不要拿管理员大钥匙到处乱开门。人类最喜欢的误操作之一，就是“先用超管试试，回头再说”。结果通常是回头找不到了。若仓库要被 CI 使用，可以创建专门的服务账号，让它只负责构建和推送镜像，不要顺便给它删项目的能力。

确认网络与访问方式

仓库搭好后，镜像要从哪里访问，这件事也得先想。若是团队内网使用，建议尽量通过谷歌云内置访问或受控网络出口；如果要给外部环境拉取，则要考虑公网地址、身份认证和防火墙策略。别小看这一步，仓库本身不一定难，难的是“别人能不能随便进来”。仓库不是菜市场，不能想拿就拿。

准备命令行工具

实际操作时，通常会用到 gcloud、docker、kubectl 等工具。先保证本地环境已经登录谷歌云账号，且能切换到目标项目。docker 负责镜像构建和 push/pull，gcloud 负责身份认证和资源管理。很多时候你以为是仓库有问题，实际上只是本地还没执行认证命令。这个锅，仓库一般不背。

方案一：使用谷歌云原生制品仓库

如果你想要的是“尽快上线、稳定能用、少管闲事”的方案，谷歌云原生制品仓库通常最合适。它可以存放容器镜像，配合身份认证和权限控制，能比较自然地融入谷歌云生态。对很多团队来说，这就像买现成的柜子，拼装说明书虽然长，但总比自己拿木板钉强。

创建仓库的基本思路

创建仓库时，核心就是选区域、定名称、设权限。区域建议尽量靠近你的集群或构建环境，减少拉取延迟。比如你的 GKE 集群在某个地区，仓库最好也放在相近区域。镜像不是快递，但延迟大了也会让人心烦。

权限方面，可以按“读”和“写”拆开。开发者或 CI 账号负责写入，部署环境负责读取，管理员则负责管理仓库配置。这样即便某个账号泄露，影响面也有限。权限细一点，事故就少一点，这不是哲学，是经验。

镜像命名与版本规范

仓库搭起来之后，别急着一股脑往里扔镜像。先定命名规则。建议采用“项目名/服务名/版本号”的方式，比如 app/backend:1.0.3 或 app/frontend:20240513。版本号不要总用 latest。latest 看起来很潇洒，实际很容易变成“今天拉到什么全靠运气”。生产环境尤其不建议把 latest 当唯一标识，不然故障排查时，你会发现每次上线都像拆盲盒。

更稳妥的做法是同时使用版本号和提交哈希。版本号给人看，哈希给机器看。一个讲人话，一个讲事实，刚刚好。

登录、构建与推送

使用谷歌云原生仓库时，通常需要先让本地 Docker 或 CI 环境完成身份认证，然后再推送镜像。这个过程本质上就是：先证明你是谁，再让你把东西放进去。认证通过后，按标准流程构建镜像，打上目标仓库地址的标签，再执行 push。完成后去控制台查看，镜像应当已经出现在仓库列表中。

这里最容易犯的错有几个。第一，项目切错了，镜像推到另一个项目去了；第二，标签写错了，推的是 A，拉的是 B；第三，认证没生效，表面上命令跑完了，实际啥也没进去。很多报错都不复杂，复杂的是你以为自己没错。建议遇到问题时，先从项目、区域、标签和认证四件事查起，十有八九有线索。

方案二：自建 Docker Registry，更自由也更操心

如果你对仓库有很强的定制需求，或者希望完全掌控镜像存储和访问逻辑，那么可以考虑在谷歌云上自建 Docker Registry。这个方案的好处是灵活，坏处是要自己负责更多细节。就像自己做饭，味道可以很不错，但洗碗也得自己来。

适合什么场景

GCP国际版 自建 Registry 比较适合小而精的内部团队、对外网依赖不强的私有环境，或者有特殊网络隔离要求的企业场景。比如你希望镜像仓库只对某个 VPC 可见，或者想把镜像存储和对象存储、内部证书体系、审计系统深度整合，这时自建方案就更有发挥空间。

部署思路

常见做法是在 Compute Engine 上起一台或多台实例，运行官方 Registry 镜像，前面挂 Nginx 或负载均衡，再配上 HTTPS 证书和认证机制。镜像数据最好落到持久化存储中，避免机器重启后“仓库没了，人生也没了”。如果数据量较大，建议使用对象存储作为后端，或者直接把仓库与持久卷方案结合起来。

安全方面尤其不能偷懒。Registry 默认不应该裸奔在公网，更不应该无认证开放写权限。否则你的私有仓库很快就会变成“公共练习场”，别人往里塞什么你都拦不住。认证方式可以用 Basic Auth，也可以结合更高级的身份验证机制。若需要按组织管理，还可以通过反向代理和谷歌云 IAM 进一步控制入口。

证书与 HTTPS

容器仓库几乎离不开 HTTPS。原因很简单：镜像内容敏感，认证信息更敏感，明文传输容易给自己埋雷。可以使用谷歌云负载均衡配合证书，也可以自己部署证书并由 Nginx 终止 TLS。若是内部使用，至少也应该保证传输链路加密。别觉得“内网就安全”，内网里最容易发生“自己人把自己人坑了”的故事。

权限设计：别把仓库做成万能钥匙箱

仓库真正的价值，不只是“存”，而是“谁能存、谁能取、谁能改”。很多人搭仓库时很热情，结果权限全开，过两周就开始追悔莫及。私有仓库最怕两件事：一是别人随便推镜像，二是别人随便删镜像。前者会污染版本体系，后者会直接断生产。

在谷歌云中，建议尽量使用服务账号和角色分离。构建系统一个账号，部署系统一个账号，人工操作另一个账号。不同角色做不同的事，权限最小化，心里才踏实。若团队较大，还可以按环境拆分仓库，例如 dev、test、prod 分开管理。这样即使测试环境出问题，也不会把生产镜像顺手带沟里去。

另外，审计日志一定要开。仓库被谁拉过、推过、删过，至少要能查得出来。出了问题，最怕的不是错误本身，而是你连错误是谁干的都不知道。那种场面，堪称技术版“案发现场无人认领”。

和 CI/CD 结合，才能算真用起来

仓库搭好以后，如果还要手动登录、手动构建、手动 push，那它的价值只发挥了一半。真正顺手的做法，是把仓库接入 CI/CD 流水线。比如每次代码提交后自动构建镜像，自动打标签，自动推送到私有仓库，再由部署任务去拉取新版本。这样整个流程就像流水线一样，少人肉，多自动，出错率也更低。

自动构建的建议

构建镜像时，建议在标签里写明构建时间、分支信息或 Git 提交哈希。这样后续查问题时，能很快定位“这个镜像是哪个提交出的”。不要只用一个模糊的版本号，不然回滚时就像闭眼翻抽屉。你知道有东西在那儿，但不确定是哪一件。

在谷歌云环境中，可以使用 Cloud Build 或其他 CI 工具接入服务账号完成推送。关键在于让构建环境拿到足够的权限，但又不要给得过头。能推镜像就够了，不需要让它去改网络、防火墙或者删数据库。工具是工具，别把它当成万能超人。

部署端如何拉取镜像

如果部署目标是 GKE，可以通过节点或工作负载的身份机制直接访问仓库。若是其他环境，则需要确保部署节点具备读取权限，并且网络可以访问仓库地址。推荐把拉取动作纳入部署清单中，避免人工逐台机器登录处理。人工操作一多，错误也就跟着开会了。

常见坑点：不是仓库不行，是你我都可能粗心

镜像拉不下来

最常见的问题就是 pull 失败。原因通常包括：仓库地址写错、标签不存在、权限不足、认证未配置、网络不通。排查时不要只盯着报错最后一行看，很多时候前面几行才是真相。仓库报错像讲笑话，包袱往往藏在前文。

版本覆盖与 tag 误用

有人喜欢把同一个标签反复覆盖，比如始终用 latest。这样虽然省事，但出了问题很难定位历史版本。建议至少保留稳定版本标签，不要把所有镜像都压成“同名不同命”。版本管理不是形式主义，它是事故发生时的救生绳。

存储增长太快

镜像仓库还有一个隐藏大坑：存储会越长越大。CI 每构建一次就推一次，日积月累，仓库很快就鼓成一个胖子。要定期清理旧镜像、无用标签和废弃分支产物。谷歌云存储不是无限宽容，账单也不是永远温柔。仓库养肥了，成本就开始跟你谈人生。

权限太宽或太窄

权限太宽，安全出事；权限太窄，团队天天报错。比较合理的做法是，先按最小权限配置，再根据真实工作流逐步放开。别一上来就“全开体验版”，也别为了安全把自己锁在门外。权限配置这件事，讲究一个刚刚好。

更推荐的实践：把仓库当基础设施，而不是临时工具

很多团队一开始把私有仓库当临时方案，等系统规模上来后才发现，它其实是整个交付链路里的基础设施。既然如此，就别只考虑“能不能用”，还要考虑“能不能长期用”。建议从一开始就做好命名规范、权限分层、日志审计、镜像清理和自动化接入。这样后面项目变多了，也不会把仓库搞成杂物间。

如果团队已经全面使用谷歌云，那么尽量让仓库和现有云资源保持一致的管理方式。例如统一用项目隔离环境，统一用服务账号做自动化，统一保留审计记录，统一按区域部署。统一不是为了好看，是为了减少“到处都能用，但哪里都不一样”的混乱局面。

再说得直白一点，仓库搭得好，大家都安静；仓库搭得糙，所有人都在问“为什么我拉不下来”。前者是基础设施，后者是客服中心。你大概率不想后者。

结语：搭仓库不难，搭得顺手才算本事

谷歌云私有仓库搭建这件事，表面看像一个纯技术操作，实际上更像一次流程设计。你不仅要考虑怎么建，还要考虑谁来用、怎么用、用完怎么管。用谷歌云原生方案，优势是省心、集成度高、维护少；用自建方案，优势是灵活、可控、定制强。无论选哪条路，核心都一样：把镜像放在一个可靠、可控、可审计的地方，让构建和部署真正自动起来。

如果你是第一次做，建议从简单方案开始，先把流程跑通，再按需要逐步增强权限、审计和自动化。别一上来就把仓库做成航天级别，那样很可能不是系统复杂，是自己先迷路。先能用，再好用，最后才是优雅地用。能把这三步走稳，私有仓库才算真的落地，而不是“看起来很忙，实际很悬”。