通过 Cloud Build 优化 Google Artifact Registry 中 docker 镜像的缓慢推送时间

Question

在与 Google 的 Artifact Registry 合作使用 Google Cloud Build 时，我们发现构建时间长达数十分钟。只有一小部分时间花在实际的“构建”操作上，其余时间（例如构建 1 分钟——仅推送 8 分钟）用于推送工件（这是一个只有一个单一的 docker 镜像）更改图层）到 AR.

• 构建操作只有一个步骤，该步骤使用 google 提供的 docker builder 和以下图像（并且图像不是直接推送而是标记为由 Cloud Build 自动推送的工件）：

FROM python:3.9
RUN pip install $deps
CMD ["python", "-m", "something-something"]

• Cloud Build 构建（worker）和 Artifact Registry 都在同一区域（us-central1）。

• 对于小层，操作可以忽略不计（在我们的用例中，只有最后一层发生变化，如果该层为 25MB，则推送可能需要 20 秒；但如果该层为 4.5G，则推送需要 6- 7 分钟），这表明没有固定开销。

• 时间直接取自 Cloud Build 的“构建摘要”页面，该页面将整个构建分为三个阶段：“获取源”、“构建步骤”、“推送”。我们的问题与“推送”阶段特别相关。

• 已尝试使用默认机器和更大的机器（例如 e2-highcpu-8）以获得更好的网络。

Answer 1

此 文档 提供了加速 Cloud Build 构建的最佳实践。

构建更精简的容器

为了帮助减小容器映像的大小，请将应用程序的构建以及用于构建它的工具与运行时容器的程序集分开。

使用 Kaniko 缓存

在容器镜像注册表中，例如 Google 自己的 Container Registry，Kaniko 缓存，一种 Cloud Build 功能，通过存储和索引中间层来缓存容器构建工件，以便以后的构建可以使用它们。

使用缓存的 Docker 镜像

提高 Docker 镜像构建速度的最简单方法是指定可用于后续构建的缓存镜像。您可以通过在构建配置文件中添加 --cache-from 参数来指定缓存图像，这将指示 Docker 使用该图像作为缓存源进行构建。

使用谷歌云存储缓存目录

要提高构建速度，请重用先前构建的结果。您可以将之前构建的结果复制到 Google Cloud Storage 存储桶，使用这些结果进行更快的计算，然后将新结果复制回存储桶

Answer 2

如果layer是4.5GB，push需要7分钟，那么传输速率是

4.5 * 10^9 * 8 / (7 * 60) = 85.7 Mbit/sec

。这是一个合理/良好的传输速度。

考虑到 Artifact Registry 的管理开销、数据一致性和传输时间，85.7 Mbit/秒的总传输速度可能被认为非常好。

你的问题，也就是上传的总时间，是没有问题的。你的期望是不现实的。