AWS分销商 AWS亚马逊云私有仓库搭建

为什么要在 AWS 上搭私有仓库

做容器化项目的人，大概率都经历过这种场面：本地镜像一跑就行，推到线上突然就开始“闹脾气”；镜像版本像家里的遥控器，明明放在眼前却总找不到；团队协作时，谁拉了哪个镜像、谁又偷偷改了 tag，最后大家都像在破案。这个时候，私有仓库的价值就出来了。

把镜像放到 AWS 的私有仓库里，最大的好处不是“看起来很云”，而是管理清晰、安全可控、权限明确。你可以限制谁能推镜像、谁能拉镜像、镜像什么时候过期、镜像是否加密，甚至还能和 CI/CD 流程打通，做到代码一提交，镜像自动构建、自动上传、自动部署。说白了，它就是容器世界里的专属储物柜，而且还是带密码锁、监控和保洁服务的那种。

AWS 上常见的私有仓库方案，基本绕不开 Amazon ECR，也就是 Elastic Container Registry。它是专门为容器镜像准备的，和 ECS、EKS、CodeBuild、CodePipeline 等服务配合得相当顺手。如果你的项目已经在 AWS 上跑，选择 ECR 基本属于少走弯路；如果你的系统还在别的地方，ECR 也依然能用，只是认证和网络配置会稍微多动点脑筋。

先搞清楚：你要搭的到底是什么

很多人一提“私有仓库”，脑海里立刻浮现出一堆账号、密码、证书、端口和防火墙规则，感觉像在修一台会说英文的洗衣机。其实先别慌，搭仓库之前，先把需求理顺，事情会简单很多。

如果你的目标是存放 Docker 镜像，那么 AWS ECR 基本就是正解；如果你还要管理 Helm chart、二进制包或者其他制品，那就得考虑额外的制品管理方案，或者和 S3、CodeArtifact 配合使用。本文重点放在容器镜像私有仓库，也就是 ECR 的搭建与使用。

另外，私有仓库大致分两类：一种是内部私有仓库，只允许公司内网或特定账号访问；另一种是跨账号共享仓库，适合多个 AWS 账号协同开发、测试、生产环境分离的场景。AWS 原生支持跨账号授权，这一点非常实用，尤其适合“开发一套账号，测试一套账号，生产再一套账号”的经典三板斧。

AWS ECR 的核心概念

仓库、镜像、标签

先把几个基本词掰开揉碎说清楚。ECR 里最重要的单位是 repository，也就是仓库。一个仓库里可以存多个镜像版本，而版本通常通过 tag 来区分，比如 latest、v1.0.0、v1.0.1、2024-08-01 之类。你要是乐意，也可以用一串特别“有个性”的标签，比如 final-final-really-final，但建议少这么干，不然后面只有上帝知道哪个是正式版本。

镜像本体就是你 build 出来的 Docker image。它被分成一层一层的 layer 存在 ECR 中，拉取时按需下载，效率不错。ECR 还支持镜像扫描、生命周期策略和加密存储，基本能满足大多数企业环境的需求。

区域和命名

AWS 服务有个老规矩：区域很重要。你在哪个 Region 创建 ECR，就尽量在哪个 Region 的 ECS、EKS 或 EC2 实例里使用它。否则跨区域拉镜像虽然也不是完全不行，但网络延迟、流量费用和管理复杂度都会上来，最后你会发现为了省事，反而花了更多时间解释为什么部署这么慢。

仓库命名也建议规范一点。最好按项目名、环境名、服务名去组织，比如 frontend、backend、payment-service 之类。如果团队规模更大，可以再加命名规范，例如 dev/backend-api、prod/backend-api。仓库名字一规范，后续排查问题时脑袋会轻松不少。

搭建前的准备工作

账号与权限

搭建 ECR 之前，最先要准备的是 AWS 账号和 IAM 权限。别一上来就拿 root 账号四处乱点，那样很容易把事情做成“权限事故现场”。建议创建专门的 IAM 用户或角色，并赋予最小必要权限。对 ECR 来说，常见的权限包括创建仓库、上传镜像、拉取镜像、查看镜像列表等。

如果是团队协作，最好结合 IAM Role 和临时凭证使用。比如开发人员通过角色访问测试环境仓库，CI/CD 通过专用角色自动推送镜像，生产环境则只允许部署服务拉取镜像。这样一来，权限边界清晰，审计也方便。

本地工具

本地环境至少需要安装 AWS CLI 和 Docker。AWS CLI 用来登录 ECR、创建仓库、配置权限；Docker 则负责构建和推送镜像。如果你用的是 Windows 或 macOS，装个 Docker Desktop 会省不少事；Linux 用户则基本就是命令行老朋友，熟练度高了甚至能靠键盘声判断构建是否成功。

安装好后，先执行 aws configure 配置访问密钥、默认区域和输出格式，或者使用更安全的临时凭证方式。然后检查一下 Docker 能不能正常跑，别等到镜像已经构建到一半，才发现 Docker 根本没启动，这种剧情很像厨师备菜三小时，发现没开火。

创建 ECR 私有仓库

通过控制台创建

如果你喜欢图形界面，可以直接进入 AWS 控制台，打开 ECR 服务，选择创建仓库。创建时主要关注以下几项：仓库名称、可见性、加密方式、镜像扫描和标签变更策略。

可见性选择私有仓库。加密方式一般默认使用 AWS 管理的密钥就可以，如果企业有更严格的安全要求，也可以使用 KMS 自定义密钥。镜像扫描建议开启，这样在镜像入库时可以自动检查常见漏洞。虽然它不能保证一切安全无虞，但至少能帮你提前揪出一些“藏在镜像里准备搞事”的包。

标签变更策略也建议根据团队习惯来决定。如果你希望同一个 tag 不能重复覆盖，可以开启更严格的策略；如果你们经常用 latest 做滚动更新，那就得结合发布流程谨慎设计，不然 latest 就会变成“最后谁上传谁说了算”的混乱现场。

通过 CLI 创建

对自动化要求高的团队来说，最好直接用 CLI 或基础设施即代码工具创建仓库。比如用 AWS CLI 可以直接执行创建命令，把仓库名称、扫描、加密等参数一次性写清楚。这样做的好处是可重复、可审计、可版本化，今天新建仓库，明天删了重建，命令都不会走样。

如果团队已经在用 Terraform、CloudFormation 或 CDK，那么更建议把 ECR 资源纳入代码管理。毕竟仓库本身也是基础设施的一部分，手工点出来的仓库一多，过几个月谁都不知道哪个仓库是谁建的、为什么建、有没有人还在用。基础设施代码化的最大意义，不只是省事，更是少扯皮。

登录、推送和拉取镜像

获取登录凭证

创建好仓库后，下一步就是把本地 Docker 和 ECR 连起来。ECR 的认证方式和普通 Docker Hub 不太一样，它通常使用 AWS CLI 生成的临时登录令牌。简单理解就是：你先向 AWS 证明自己是谁，AWS 再给你一张临时通行证，让你在一段时间内可以操作仓库。

登录成功后，Docker 就能往 ECR 推送镜像了。这个过程虽然看起来多了一步，但安全性高了不少。毕竟如果仓库直接暴露一个永久密码，那就跟把家门钥匙挂在门把手上一样，实在不太讲武德。

构建并打标签

先在项目目录里构建镜像，通常使用 Docker build 命令。构建完成后，需要给镜像打上符合 ECR 规范的完整标签。ECR 的镜像地址一般包括账号 ID、Region、仓库名和 tag，形式类似于“账号.dkr.ecr.Region.amazonaws.com/仓库名:tag”。

打标签这一步非常关键。很多新手常犯的错是镜像已经 build 出来了，却直接 push，结果 Docker 只认识本地标签，ECR 只认完整仓库地址，双方像两个人在不同频道里聊天，最后自然谁也没听懂谁。

推送到 ECR

AWS分销商 完成登录和打标签后，就可以执行 push。上传过程中，Docker 会把镜像层逐个上传到 ECR。首次推送时间可能稍长，尤其是基础镜像比较大、依赖比较多的时候。后续如果镜像层变化不大，增量推送速度会快很多。

推送成功后，可以在控制台里看到对应镜像及其 tag、digest、推送时间等信息。digest 比 tag 更像镜像的“身份证号”，tag 则更像昵称。昵称可以改，身份证号通常不会变，所以在严肃环境里，部署时最好优先依赖 digest 而不是只看 tag。

AWS分销商 从服务端拉取

服务端拉取镜像时，ECS、EKS 或 EC2 实例都需要具备相应权限。如果是 ECS，通常通过任务执行角色或任务角色来访问 ECR；如果是 EKS，则要给节点实例角色或 Pod 绑定合适权限；如果是 EC2 上直接跑 Docker，则实例角色需要允许拉取镜像。

这里最容易出问题的地方不是镜像不存在，而是权限不足。报错表面上五花八门，根子往往就一个：没授权。调试时先别怀疑人生，先查 IAM 权限和仓库策略，很多问题都能当场认罪。

权限与安全怎么做才像样

仓库策略

ECR 支持仓库级别策略，这意味着你可以单独控制哪个账号、哪个角色、哪个服务可以访问这个仓库。对跨账号协作特别友好。比如开发账号负责 push，生产账号只负责 pull，测试账号既能拉也能做验证。职责分明之后，问题追踪会轻松很多。

建议不要直接给“全世界都能访问”的权限，尤其是生产仓库。私有仓库的意义就是私有，一旦权限开得像广场大门，那和公有仓库就差一张嘴的距离了。

加密与审计

ECR 默认支持静态加密，你也可以使用 KMS 做更细粒度的密钥管理。如果企业对合规要求比较高，KMS 几乎是标配。配合 CloudTrail，你还可以记录谁在什么时间做了什么操作。这样出了问题，不至于只能靠“我记得好像是昨天下午三点吧”来回忆。

镜像扫描也值得认真开启。虽然扫描报告未必能百分之百覆盖所有风险，但至少能帮你过滤掉一些常见漏洞包，避免把明显不该进生产环境的东西直接送上去。把扫描当成一道门卫程序，总比让漏洞自己刷脸进门强。

和 CI/CD 集成，才算真正好用

自动构建镜像

私有仓库如果只靠手工上传，时间长了就会变成“仓库是仓库，流程是流程，大家各忙各的”。真正顺手的做法，是把它接入 CI/CD。比如代码提交到 Git 后，CodeBuild 或 Jenkins 触发构建，构建完成后自动登录 ECR、打标签、推送镜像，再通知后续部署流程。

这样做的好处很直接：版本可追踪、发布更稳定、回滚更简单。哪怕线上出问题，也能立刻定位到某次提交对应的镜像版本，而不是翻聊天记录猜“到底是谁周五晚上点的发布按钮”。

自动部署

如果你的应用运行在 ECS 或 EKS 上，ECR 就能和部署流程自然衔接。镜像推送到仓库后，部署系统拉取最新镜像，完成滚动更新。对于多环境发布，还可以按不同 tag 区分 dev、staging、prod，或者直接使用 digest 锁定版本，避免标签漂移。

一个成熟的流程应该是：开发提交代码，CI 构建镜像，镜像进 ECR，部署系统拉取指定版本，健康检查通过后再切流量。每一步都尽量自动化，人的作用保留在“做决定”上，而不是“反复敲同样的命令”。

常见坑位和处理方法

镜像推不上去

最常见的报错之一就是 push 失败。原因通常有几个：没登录 ECR、登录过期、仓库地址写错、标签格式不对、权限不够。排查顺序建议从最简单的开始，先看是否已执行正确登录，再看仓库地址是否与 Region 和账号一致，最后检查 IAM 权限。

尤其要注意，ECR 的登录令牌是有时效的，不是你今天登录一次就能用到天荒地老。临时凭证这东西，本来就是给安全加一道保险，不是给懒人提供永久通行证。

拉取镜像超时

如果服务端拉取镜像很慢或者超时，要考虑网络、Region、带宽和实例配置。尤其是在私有子网里部署时，最好给 ECR 配置 VPC Endpoint，这样实例可以在不经过公网的情况下访问 ECR 和 S3，既安全又稳定。否则每次拉镜像都要绕远路，慢得像周一早高峰挤地铁。

AWS分销商 仓库里镜像越堆越多

这是所有仓库都会遇到的问题。测试镜像、临时镜像、旧版本镜像长期堆积，不仅占空间，还会让列表看起来像一间从来没收拾过的储物间。ECR 支持生命周期策略，可以设置保留最近多少个版本、多少天前的镜像自动清理。建议尽早配置，不然仓库迟早会长胖。

推荐的实践方式

按环境拆分

如果项目不小，建议按环境拆分仓库或至少拆分 tag 规范。开发、测试、生产不要混在一个“通用仓库”里。仓库一混，权限一乱，后面问题基本都要靠猜。拆分之后，审计和回滚都会更简单。

固定版本，不迷信 latest

latest 这个标签，最适合做演示，不太适合做严肃生产。它的问题在于太灵活，灵活到有点像“今天到底指向谁，全看上传顺序”。更稳妥的方式是使用版本号 tag，或者直接在部署清单里引用 digest。这样即便仓库里后续又推了新镜像，当前服务也不会被“悄悄换包”。

把权限收紧

仓库该开的权限开，不该开的别开。开发人员能推开发仓库，不代表能碰生产仓库；自动化构建能上传镜像，不代表能删仓库。最小权限原则看起来老生常谈，但真到了出事的时候，它就是最值钱的那条原则。

总结

AWS 亚马逊云私有仓库搭建，本质上不是“建一个能存镜像的地方”这么简单，而是把镜像管理、权限控制、安全审计和自动化发布串成一条完整链路。用 ECR 搭私有仓库，优势很明显：和 AWS 生态贴合、权限和加密能力完善、与 CI/CD 集成方便、维护成本相对可控。

如果只是个人练手，控制台点几下也能搭起来；如果是团队正式使用，建议一开始就把仓库、权限、扫描、生命周期策略和自动化流程设计好。因为仓库这种东西，一旦有人用起来，后面的规范就不是“建议”了，而是“别再折腾我”。

说到底，私有仓库不是用来展示技术感的，它是为了让团队少踩坑、少重复劳动、少在深夜里追着一个“明明昨天还能拉下来”的镜像满地跑。把 AWS ECR 用顺手了，你会发现容器交付这件事，终于有了点“该自动的自动、该稳定的稳定”的样子。