将 Docker 映像从 Google 容器注册表 (GCR) 迁移到具有大量标签的 ArtifactRegistry 的最佳实践

Question

社区！

我正在将 Docker 映像从已弃用的 Google 容器注册表 (GCR) 迁移到 Google Cloud ArtifactRegistry。我正在寻求有关最佳实践和策略的建议，以有效地处理此迁移，特别是考虑到我们的 Docker 镜像的规模很大。

我们当前的设置涉及欧盟的 GCR 存储库

eu.gcr.io/my-company/

，其中包含 500 多个 Docker 镜像，每个镜像都被标记了 500 多次。

我们最初考虑使用“镜像”功能从 GCR 过渡到 ArtifactRegistry，方法是在 ArtifactRegistry 中创建一个具有相同

eu.gcr.io/my-company/

域的新项目。然而，这种方法带来了一些挑战：

1. 新功能的丢失：通过镜像 ArtifactRegistry，我们无法利用 ArtifactRegistry 提供的新功能。
2. 旧映像无法访问：设置 ArtifactRegistry 并将流量重定向到该注册表后，GCR 中的旧映像将变得无法访问。有没有办法在迁移后保持对这些旧图像的访问，或者有策略在工件注册表中重新托管它们而不丢失它们的引用？
3. 工具限制：我们研究了使用 gcrane 进行迁移，但它仅支持直接从*.gcr.io

   迁移到

   pkg.dev

   。对于这种迁移类型，是否有推荐的替代工具或脚本可以有效地处理许多图像和标签？

鉴于这些挑战，我正在寻求以下方面的建议：

考虑到我们存储库的规模，从 GCR 迁移到 Artifact Registry 的最佳方法。
确保平稳过渡而又不会失去对现有图像和标签的访问的策略。
促进此迁移的任何工具或服务，特别是对于具有大量图像和标签的存储库。

提前感谢您的见解和建议

Answer 1

将此作为社区维基共享以造福他人

正如@BMitch提到的

为了复制数据本身，有各种工具，包括 skopeosync（来自 RedHat）、crane copy --all-tags（来自 Google）和 regclient/regsync（我自己的项目）。它们在 OCI 级别运行，因此您仍然需要一些东西来转换这些存储库的任何管理，包括身份验证。对于处理 500 个存储库，这将取决于 _catalog 是否受支持（可能不在 GCR 上）或您对多少脚本感到满意。