代码库概览

在创建代码库时，请考虑创建工件的内部过程和工件消费者的使用情况。

代码库格式

每个代码库都与特定的制品格式相关联。例如，Docker 代码库用于存储 Docker 映像。您可以在同一 Google Cloud 项目中为每种格式创建多个代码库。

代码库模式

代码库模式有多种。每种模式都有不同的用途，因此创建代码库后，您便无法更改代码库模式。

标准代码库

标准制品库是用于存放私有制品的常规 Artifact Registry 制品库。您可以直接使用这些制品库上传和下载制品，并使用 Artifact Analysis 扫描漏洞和其他元数据。

如需创建标准代码库，请按照创建标准代码库中的步骤操作。

远程代码库

远程代码库是只读代码库，可充当代理来存储来自以下上游来源的制品：

• 标准 Artifact Registry 制品库。
• 外部来源，例如 Docker Hub、Maven Central、Python Package Index (PyPI)、Debian 或 CentOS。

首次请求制品版本时，代码库会从上游来源下载该版本并缓存其副本。当再次请求同一版本时，远程代码库会提供缓存的副本。

远程代码库可减少 Google Cloud上构建和部署的延迟时间，并提高可用性。您还可以使用 Artifact Analysis 扫描缓存的软件包是否存在漏洞和其他元数据。

如需详细了解远程代码库，请参阅远程代码库概览。如需创建远程代码库，请按照创建远程代码库中的步骤操作。

虚拟代码库

一个只读的存储库，充当从一个或多个上游存储库下载、安装或部署相同格式工件的单一访问点。上游代码库可以是标准代码库、远程代码库或虚拟代码库。

虚拟代码库可简化制品使用者的客户端配置。您还可以通过配置上游政策来缓解依赖项混淆攻击，使包含私有制品的代码库优先于缓存公共制品的远程代码库。

如需详细了解虚拟代码库，请参阅虚拟代码库概览。如需创建虚拟代码库，请按照创建虚拟代码库中的步骤操作。

代码库使用示例

下图展示了以不同模式一起使用代码库的多种可能方式之一。该图显示了跨两个Google Cloud 项目的工作流。在开发项目中，开发者构建 Java 应用。在单独的运行时项目中，另一个 build 会创建一个包含应用的容器映像，以便部署到 Google Kubernetes Engine。

1. 在开发项目中，Java 开发团队使用 Cloud Build 构建 Java 应用。

   • 构建可以使用虚拟制品库请求公共 Java 依赖项。虚拟制品库提供来自远程制品库的依赖项，该远程制品库是 Maven Central 的缓存代理。
   • Cloud Build 会将软件包上传到组件项目中的标准 Maven 代码库。

2. 在运行时项目中，Cloud Build 会将 Java 应用容器化。

   构建使用 Maven 虚拟制品库下载应用。虚拟代码库用于提供开发项目中的标准代码库中的软件包。构建还可以从同一虚拟代码库下载公共 Java 依赖项。

3. 在运行时项目中，Cloud Build 会将构建的容器映像上传到标准 Docker 代码库。

4. GKE 从 Docker 虚拟代码库中拉取映像。

   • 上游标准 Docker 代码库提供私有映像，例如容器化的 Java 应用。
   • 上游远程代码库提供 GKE 从 Docker Hub 请求的映像。

在此示例中，所有代码库、build 和 GKE 集群都位于同一区域。为 Google Cloud 服务使用同一位置具有诸多优势，如代码库位置中所述。

代码库位置

位置注意事项

本部分介绍了您可能希望在与 Google Cloud 服务相同的区域中创建代码库的原因。

您可以在运行 GKE、Cloud Run、Cloud Build 和其他与代码库交互的 Google Cloud 服务的同一区域中创建代码库，从而缩短延迟时间并降低网络出站流量费用。从 Artifact Registry 到同一区域中的其他 Google Cloud 服务的出站流量不会产生费用。

虽然从多区域向相应区域中的Google Cloud 服务出站不收取费用，但此价格仅适用于有限的一组区域。

• 对于 us 多区域，出站流量到美国境内的区域（例如 us-central）不收费，到加拿大或南美洲境内的任何区域则收费。
• 对于 asia 多区域，出站流量到亚洲（例如 asia-northeast1）区域不收费，但出站流量到澳大利亚区域会收费。

考虑 Google Cloud以外的消费者的地理位置。例如，如果澳大利亚的开发者团队需要从 Artifact Registry 下载工件到其本地工作站，那么位于澳大利亚区域的代码库将比位于其他大陆的代码库延迟更低，并产生更低的出口费用。

限制代码库位置

如果您需要遵守要求您在特定区域存储数据的法规或政策，可以在 Google Cloud组织政策中添加资源位置限制条件，以仅允许在合规区域中创建代码库。只有在组织政策中添加相应限制条件后，Artifact Registry 才会强制执行该限制条件。如果您的现有代码库位于不合规的位置，您必须自行将工件移至合规位置的代码库，然后删除不合规的代码库。

清理政策

Artifact Registry 清理政策用于定义以下条件：自动删除您不再需要的制品版本，或无限期保留您想要存储的制品。

如果您存储了许多版本的工件，但只需要保留发布到生产环境的特定版本，那么清理政策非常有用。您可以定义删除政策（包含用于删除制品的条件）和保留政策（包含用于保留制品的条件）。

如果某个制品版本同时符合删除政策和保留政策中的条件，Artifact Registry 会应用保留政策。

删除政策

删除政策会删除符合以下必需条件的制品：

• 标记状态：指示政策应检查已标记的制品还是未标记的制品。在将映像推送到代码库或从代码库拉取映像时，系统会标记制品。如需详细了解 Docker 标记，请参阅容器概念。

  • 任何标记状态：忽略标记状态，适用于已标记和未标记的制品。
  • 已标记：仅适用于已标记的制品。
  • 未标记：仅适用于未标记的制品。

  不支持标记的格式会被视为 untagged。如果启用了不可变标记，则无法删除具有标记的制品。

  如需详细了解与清理政策相关的标记状态，请参阅 TagState 参考。

以下是定义删除政策的可选方法：

• 标记前缀：是以英文逗号分隔的标记前缀列表。例如，前缀 test 和 staging 将匹配带有标记 testenv 和 staging-1.5 的图片。必须将 tagState 设置为 TAGGED 才能使用代码前缀。
  • 版本前缀：- 是以英文逗号分隔的制品版本前缀列表。例如，v1、v2 将匹配版本 v1.5、v2.0alpha 和 v10.2。
• 软件包前缀：是制品名称前缀的列表。您可以在前缀之间按 Enter 或 , 来输入多个前缀。例如，red, blue 会创建两个前缀，即 red 和 blue，并匹配制品名称 red-team、redis 和 bluebird。
• 早于：是指制品版本上传到代码库的最短时间，以时长表示。 例如，30d 为 30 天。您可以通过分别添加 s、m、h 或 d 来指定以秒、分钟、小时或天为单位的时长。
• 新于：是指自制品版本上传到代码库以来的最长时间，以时长形式指定。例如，30d 为 30 天。

保留政策

保留政策会保留符合与删除政策相同条件的制品，或保留指定数量的最新版本。

例如，假设有一个包含以下制品的代码库：

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v1
DIGEST: sha256:1b0a26bd07a3d17473d8d8468bea84015e27f87124b2831234581bce13f61370
TAGS:
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:10

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

IMAGE: us-west1-docker.pkg.dev/my-project/release-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

如果您的保留最新版本政策设置为保留与软件包前缀 {release-xyz} 匹配的软件包的 3 个版本，则系统只会保留 release-xyz-v1 和 release-xyz-v2。

由删除政策触发的删除操作会计入 Artifact Registry 的每个项目的删除请求配额。

如需为代码库创建和应用清理政策，请参阅配置清理政策。

gcr.io 网域支持

Artifact Registry 支持在 gcr.io 网域上托管映像。如果您要从 Container Registry 迁移到 Artifact Registry，可以设置 gcr.io 代码库 Artifact Registry，以尽可能减少对现有自动化和工作流程的更改。这些代码库提供：

• 将请求重定向到 gcr.io 网域。
• 在第一个映像推送到 gcr.io 主机名时创建 gcr.io 代码库，以实现与 Container Registry 行为的兼容性。

如需了解详情，请参阅转换到具有 gcr.io 网域支持的存储库

项目结构

资源层次结构是指您在 Google Cloud 项目之间整理资源的方式。您选择的结构取决于数据治理要求、信任边界和团队结构等因素。

在多项目组织中设置代码库有两种常规方法。

集中管理代码库

在一个项目中创建所有代码库，然后在代码库级层向其他项目中的正文授予访问权限。如果组织中只有一个人或一个团队负责处理整个组织的代码库管理和代码库访问权限，那么这种方法会更有效。

它还可以简化虚拟代码库的设置，因为您只需启用和管理一个 Artifact Registry 实例。

项目专用代码库

在用于存储和下载制品的项目中创建代码库。如果您有数据治理政策或信任边界，需要更精细的项目级资源分离和控制，则可能需要采用此方法。

访问权限控制

除非您将代码库配置为公开访问，否则只有拥有相应权限的用户才能访问代码库。您可以在项目或代码库级层授予权限。

部分 Google Cloud 服务使用默认服务账号，对同一 Google Cloud 项目中的代码库具有默认权限。不过，这些默认设置可能不适合您的软件开发流程，或者可能不符合您组织中的安全或政策要求。如果出现以下情况，您的代码库管理员必须明确授予这些服务对代码库的访问权限：

• Artifact Registry 与与之互动的服务位于不同的项目中。
• 您使用的是具有默认服务账号的自定义 IAM 角色，而不是预定义角色。
• 您未为 Google Cloud服务使用默认服务账号。
• 您正在设置虚拟代码库。您必须明确授予 Artifact Registry 服务账号对上游代码库的访问权限。

对于需要访问代码库的其他正文，您的代码库管理员必须授予访问权限。遵循最小权限安全原则，授予所需的最低权限。例如：

• 您将 Artifact Registry 中的容器映像部署到多个不同项目中的 GKE 集群。这些集群中节点的相应服务账号只需要对代码库具有读取权限。
• 您有一个用于开发中应用的开发代码库，以及一个用于已发布应用的正式版代码库。 开发者需要对开发代码库具有读写权限，对生产代码库具有只读权限。
• 您有一个包含示例应用的演示代码库。您的销售团队只需拥有只读权限即可下载演示。

限制制品下载

您可以使用下载规则限制制品下载。 下载规则可让您允许或拒绝从代码库和软件包下载制品。您还可以设置条件，以便规则适用于特定代码或版本。

如需详细了解下载规则的运作方式，请参阅“控制访问权限并保护制品”概览中的限制制品下载部分。

数据加密

默认情况下， Google Cloud 会使用Google 拥有和管理的 加密密钥自动加密静态数据。如果您有与保护数据的密钥相关的特定合规性或监管要求，则可以创建使用客户管理的加密密钥 (CMEK) 加密的代码库。

Artifact Registry 还支持组织政策限制条件，这些限制条件可以要求使用 CMEK 来保护资源。

标签和标记

标签提供了一种整理特定于服务的资源的方式。 Google Cloud在 Artifact Registry 中，您可以向代码库添加标签，以便将它们分组在一起或按标签过滤代码库列表。例如，您可以使用标签按开发阶段或团队对代码库进行分组，以实现自动化或结算。如需详细了解如何创建和使用代码库标签，请参阅为代码库添加标签。

您还可以为代码库应用标记。标签主要用于整理和过滤特定于服务的资源，而标记用于以程序化方式控制整个 Google Cloud 组织的政策。如需了解详情，请参阅为代码库添加标记。

后续步骤

• 创建标准代码库
• 详细了解远程仓库
• 详细了解虚拟代码库
• 创建远程代码库
• 创建虚拟代码库