本文档介绍了 Container Registry 和 Artifact Registry 在使用 Docker 进行身份验证、推送和拉取容器映像方面的差异。
本指南主要比较标准 Artifact Registry 代码库,以及独立于 Container Registry 且支持所有 Artifact Registry 功能的常规 Artifact Registry 代码库。
如果您的管理员为代码库设置了 gcr.io 网域支持,则对 gcr.io
主机名的请求会自动重定向到相应的 Artifact Registry 代码库。如需使用托管在 Artifact Registry 上的 gcr.io 代码库,您必须具有适当的 Artifact Registry 角色或具有同等权限的角色。
如需了解使用 Cloud Build 进行构建以及部署到 Cloud Run 或 Google Kubernetes Engine 时 Container Registry 和 Artifact Registry 之间的差异,请参阅 Cloud Build、Cloud Run 和 GKE 的变更。
使用此信息可以帮助您调整侧重于使用 Docker 的 Container Registry 的现有命令、配置或文档。
准备工作
本文档假定您满足以下条件:
- 在您的项目中启用了 Artifact Registry。
- 已安装 Docker。Docker 包含在 Cloud Shell 中。
概览
大体上讲,将 Docker 与 Container Registry 或 Artifact Registry 搭配使用的工作流是相同的。
Container Registry | Artifact Registry |
---|---|
管理员
|
管理员
|
注册表用户
|
注册表用户
|
但是,Container Registry 的快捷方式是将管理员和用户角色合并到单个工作流中。此快捷键常用于:
- 快速入门和教程,您在拥有广泛权限的环境中进行测试。
- 使用 Cloud Build 的 Workflows,因为 Cloud Build 服务帐号有权在同一 Google Cloud 项目中添加注册表主机。
快捷键工作流程如下所示:
- 启用 Container Registry API
- 向将要访问 Container Registry 的帐号授予权限。
对注册表进行身份验证。最简单的身份验证选项是使用 Google Cloud CLI 中的 Docker 凭据帮助程序。这是一个一次性的配置步骤。
gcloud auth configure-docker
构建并标记该映像。例如,以下命令会构建并标记映像
gcr.io/my-project/my-image:tag1
:docker build -t gcr.io/my-project/my-image:tag1
将映像推送到注册表。例如:
docker push gcr.io/my-project/my-image:tag1
如果项目中不存在
gcr.io
注册表主机,Container Registry 会在上传映像之前添加该主机。从注册表中拉取映像或将其部署到 Google Cloud 运行时。例如:
docker pull gcr.io/my-project/my-image:tag1
此工作流依赖于以下快捷方式:
- 推送映像的帐号具有 Storage Admin 角色或具有相同权限的角色(例如 Owner)。此角色的广泛权限允许对项目中的所有存储分区(包括 Container Registry 未使用的存储分区)进行读写访问。
- 当您启用某些 Google Cloud API 时,系统会自动启用 Container Registry API。这意味着这些服务的用户对于同一项目中的 Container Registry 具有隐式访问权限。例如,可以在 Cloud Build 中运行构建的用户可以将映像推送到注册表并添加注册表主机。
在 Artifact Registry 中,管理员和代码库用户角色明确分离,这可以改变构建和部署工作流中的步骤。如需针对 Artifact Registry 调整 Container Registry 工作流,请进行以下更改。每个步骤都链接到有关修改工作流的其他信息。
新版:启用 Artifact Registry API。
您必须启用 Artifact Registry API。Cloud Build 和运行时环境(如 Cloud Run 和 GKE)不会自动启用 API。
New:创建目标 Docker 代码库(如果尚不存在)。您必须先创建代码库,然后才能向其推送任何映像。推送映像无法触发代码库的创建,并且 Cloud Build 服务帐号无权创建代码库。
向将与 Artifact Registry 互动的帐号授予权限。
已更改:对代码库进行身份验证。如果您在 gcloud CLI 中使用凭据帮助程序,则必须指定要添加到 Docker 客户端配置的主机。例如,以下命令会添加主机
us-central1-docker.pkg.dev
:gcloud auth configure-docker us-central1-docker.pkg.dev
已更改:构建和标记映像。
以下示例命令与 Container Registry 示例相同,但使用了映像的 Artifact Registry 代码库路径。
docker build -t us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
已更改:使用 Artifact Registry 路径将映像推送到代码库。例如:
docker push us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
已更改:使用 Artifact Registry 路径从代码库中拉取映像。例如:
docker pull us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
启用 API
要点:
- 除了为其他 Google Cloud 服务(例如 Cloud Build、Cloud Run 和 GKE)启用的 API 之外,您还必须启用 Artifact Registry API。
以下比较显示了为每项服务启用 API 的过程:
Container Registry
您必须先启用 Container Registry API,然后才能将 Docker 或其他第三方客户端与 Container Registry 搭配使用。
启用以下 Google Cloud API 时,Container Registry API 也会自动启用:
- App Engine 柔性环境
- Cloud Build
- Cloud Functions
- Cloud Run
- Artifact Analysis 中的容器扫描或按需扫描
- Google Kubernetes Engine
使用默认权限时,可以在 Cloud Build 中运行构建、使用 Artifact Analysis 扫描容器或将容器部署到 Google Cloud 运行时的用户隐式访问 Container Registry 中的映像(如果注册表位于同一项目中)。
Artifact Registry
您必须先启用 Artifact Registry API,然后才能将 Docker 客户端或其他 Google Cloud 服务与 Artifact Registry 搭配使用。
Cloud Build、Cloud Run 和 GKE 等服务不会自动启用 Artifact Registry API。
您可以使用 gcloud 在同一项目中启用多个 API。例如,如需启用 Cloud Build API 和 Artifact Registry API,请运行以下命令:
gcloud services enable
artifactregistry.googleapis.com \
cloudbuild.googleapis.com
添加注册表和代码库
要点:
您必须先创建 Artifact Registry Docker 代码库,然后才能向其推送映像。
在介绍如何将映像推送到 Container Registry 的文档中,通常不会执行注册表创建步骤,因为具有 Storage Admin 权限的帐号可以在初始推送到注册表主机时将注册表添加到项目中。
Container Registry 将单个多区域中的所有映像存储在同一个存储桶中。在 Artifact Registry 中,您可以使用单独的访问权限政策在同一区域或多区域创建多个代码库。
以下比较说明了每项服务中的代码库设置:
Container Registry
在 Container Registry 中,您最多可以向项目添加四个注册表主机。您可以通过推送第一个映像来添加注册表主机。
如需向您的项目添加注册表(如
gcr.io
),具有项目级 Storage Admin 角色的帐号会推送初始映像。例如,如果项目
my-project
中不存在gcr.io
主机,则推送映像gcr.io/my-project/my-image:1.0
会触发以下步骤:- 将
gcr.io
主机添加到项目中 - 为项目中的
gcr.io
创建一个存储桶。 - 将图片存储为
gcr.io/my-project/my-image:1.0
- 将
初次推送之后,您可以为其他用户授予对存储桶的权限。
在项目中,注册表主机将所有映像存储在同一个存储桶中。在以下示例中,项目 my-project
在注册表 gcr.io
中有两个名为 web-app
的映像。一个项目直接位于项目 ID my-project
下。另一个映像位于代码库 team1
中。
gcr.io/my-project/web-app
gcr.io/my-project/team1/web-app
Artifact Registry
具有 Artifact Registry Repository Administrator 角色的帐号必须先创建代码库,然后才能将映像推送到该代码库。然后,您可以为其他用户授予对代码库的权限。
在 Artifact Registry 中,每个代码库都是单独的资源。因此,所有映像路径都必须包含代码库。
有效的映像路径:
us-central1-docker.pkg.dev/my-project/team1/web-app:1.0
us-central1-docker.pkg.dev/my-project/team2/web-app:1.0
映像路径无效(不包含代码库):
us-central1-docker.pkg.dev/my-project/web-app:1.0
以下示例展示了将映像推送到缺失的代码库失败的情况。
- 如果
us-central1-docker.pkg.dev/my-project/team1
不存在,则将映像推送到us-central1-docker.pkg.dev/my-project/team1
。 - 当
us-central1-docker.pkg.dev/my-project/team1
存在但us-central1-docker.pkg.dev/my-project/team2
不存在时,将映像推送到us-central1-docker.pkg.dev/my-project/team2
。
授予权限
要点:
- 向您用于 Artifact Registry 的帐号授予适当的 Artifact Registry 角色。
- Google Cloud 服务对 Container Registry 和 Artifact Registry 具有等效的读写权限。但是,默认的 Cloud Build 服务帐号无法创建代码库。
- Container Registry 支持在存储桶层级进行访问权限控制。 Artifact Registry 支持代码库层级的访问权限控制。
以下比较说明了每项服务的权限设置:
Container Registry
Container Registry 使用 Cloud Storage 角色来控制访问权限。
- 存储桶级 Storage Object Viewer
- 从项目中的现有注册表主机拉取(读取)映像。
- 存储桶级存储空间旧存储桶写入者
- 为项目中的现有注册表主机推送(写入)和拉取(读取)映像。
- 项目级的 Storage Admin
- 通过将初始映像推送到主机,将注册表主机添加到项目中。
在将映像最初推送到注册表后,您可以向需要访问该存储桶的其他帐号授予 Cloud Storage 角色。请注意,具有 Storage Admin 角色所有权限的任何帐号都可以在整个项目中读取、写入和删除存储分区及存储对象。
针对存储桶的权限适用于注册表中的所有代码库。例如,对 gcr.io/my-project
的存储桶具有 Storage Object Viewer 权限的任何用户都可以读取以下所有代码库中的图片:
gcr.io/my-project/team1
gcr.io/my-project/team2
gcr.io/my-project/test
gcr.io/my-project/production
Artifact Registry
Artifact Registry 有自己的角色来控制访问权限。这些角色明确区分管理员和代码库用户角色。
只有管理代码库的帐号才应具有 Artifact Registry Repository Administrator 或 Artifact Registry Administrator 角色。
- Artifact Registry Reader
- 列出工件和代码库。下载工件。
- Artifact Registry Writer
- 列出工件和代码库。下载工件、上传新的工件版本,以及添加或更新标记。
- Artifact Registry Repository Administrator
- Artifact Registry Writer 权限和删除工件和标记的权限。
- Artifact Registry Administrator
- Artifact Registry Repository Administrator 权限,以及创建、更新、删除代码库和向其授予权限的权限。
您可以在代码库级别应用这些权限。例如:
- 向团队 1 授予
us-central1-docker.pkg.dev/my-project/team1
的访问权限 - 向团队 2 授予
us-central1-docker.pkg.dev/my-project/team2
的访问权限。
如需详细了解如何授予 Artifact Registry 权限,请参阅访问权限控制文档。
向注册表进行身份验证
要点:
- Artifact Registry 支持与 Container Registry 相同的身份验证方法。
- 对于 Docker 凭据帮助程序,您必须指定要添加到 Docker 客户端配置的主机。
- 如需使用
docker login
进行身份验证,请使用 Artifact Registry 主机,而不是 Container Registry 主机。
使用凭据帮助程序
默认情况下,gcloud auth configure-docker
命令和独立凭据帮助程序仅会为 *.gcr.io
主机名配置 Docker。对于 Artifact Registry,您必须指定要添加到 Docker 客户端配置的 Artifact Registry 主机列表。
例如,如需在区域 us-central1
中设置对 Docker 代码库的身份验证,请运行以下命令:
gcloud auth configure-docker us-central1-docker.pkg.dev
如果您稍后在 us-east1
和 asia-east1
中添加代码库,则必须再次运行该命令,以将相应的区域主机名添加到 Docker 配置中。
gcloud auth configure-docker us-east-docker.pkg.dev,asia-east1-docker.pkg.dev
如需详细了解 Artifact Registry 身份验证方法,请参阅为 Docker 设置身份验证。
使用密码身份验证
登录 Docker 时,请使用 Artifact Registry 主机名,而不是 *.gcr.io
主机名。以下示例展示了如何使用 base64 编码的服务帐号密钥向主机 us-central1-docker.pkg.dev
进行身份验证:
cat key.json | docker login -u _json_key_base64 --password-stdin \
https://us-central1-docker.pkg.dev
构建和标记映像
要点: - Artifact Registry 为代码库使用不同的主机名。
在标记映像时,请使用 Artifact Registry 路径,而不是 Container Registry 路径。例如:
docker tag my-image us-central1-docker.pkg.dev/my-project/my-repo/my-image:1.0
将映像推送到注册表
要点: - 在 Artifact Registry 中,目标代码库必须已存在,您才能将映像推送到该代码库。 - Artifact Registry 为代码库使用不同的主机名。
推送映像时,请使用 Artifact Registry 路径,而不是 Container Registry 路径。例如:
docker push us-central1-docker.pkg.dev/my-project/my-repo/my-image:1.0
从注册表中拉取映像
要点:
- Artifact Registry 主机名与 Container Registry 主机名不同。
拉取映像时,请使用 Artifact Registry 路径,而不是 Container Registry 路径。例如:
docker pull us-central1-docker.pkg.dev/my-project/my-repo/my-image:1.0
如需查看将映像部署到 Google Cloud 运行时(如 Cloud Run 和 GKE)的示例,请参阅部署映像。