时间戳

首页 > 解决方案 > 将新容器映像部署到 GCP 上的自动缩放托管实例组的最佳实践？

docker - 将新容器映像部署到 GCP 上的自动缩放托管实例组的最佳实践？

问题描述

我们在 GCP 上有一个托管实例组，它配置了自动缩放规则。

实例组引用通过创建的实例模板gcloud compute instance-templates create-with-container。容器镜像托管在 GCR 上。

我试图了解将频繁更新部署到此实例组的最佳方式，例如在 CI/CD 管道中。

根据我目前的理解，程序似乎是：

  1. 构建一个新的 docker 镜像并将其推送到 GCR
  2. 创建一个新的实例模板。
  3. 向指向新实例模板的实例组提交滚动更新。

然而，在 CI/CD 管道中，似乎：

  1. 这将创建数百甚至可能数千个仅使用一次且永远不会再次使用的悬空实例模板。这有问题吗？
  2. 不清楚应该如何命名或版本化实例模板。我正在考虑在创建模板时将 docker 图像的哈希写入实例模板名称，但这似乎是不必要的手动操作。

这真的是将更新部署到实例组的最佳方式，还是我遗漏了什么？部署管理器是否简化了这一切，例如在名称生成或模板清理中？

标签： dockergoogle-cloud-platformgoogle-compute-enginecontinuous-deploymentgoogle-deployment-manager

解决方案

为了使部署的行为更可预测，最好遵循“确定性”方法，该方法涉及使用精确的构建版本或哈希指定标签。这样做的结果是许多模板实例必须在以后进行管理。

另一方面，这提供了版本控制和回滚机会。MIG 对象的versions和instanceTemplate属性以及实例模板的容器映像名称和标记，可用于版本控制。

在像您这样的情况下，Kubernetes Engine 看起来是一种公理化的方法。但如果 GKE 因客观因素不适合，可以考虑Cloud Run。它支持自动缩放、服务修订，并处理imageDigest. 与实例模板一样，每个修订版的配置都是不可变的。

Deployment Manager 的优势在于构建复杂的部署。使用 DM，每个构建都应该采用单独部署的形式。基于 Python 或 Jinja2 的模板可以帮助生成有意义的名称、标签、元数据，这些可以在以后的清理过程中使用。但是无论如何，部署本身都必须进行管理和清理：使用gcloud deployment-manager deployments delete.

无论您喜欢什么，都需要对过时的“托管项目”进行分类和清理：实例模板、修订或部署。这取决于用户，Google 不提供生命周期管理服务。

gcloud可以从运行在 VM 上的作业调用原始生命周期解决方案，该cron作业具有被授予适当权限的服务帐户。可以根据 ID、时间戳、哈希、摘要等关键属性请求托管项目。项目列表可以按时间戳或版本标签排序，以便删除，例如，最旧的 100 个项目或保留最新的 100 个项目。

Compute Engine > Doc > Deterministic 实例模板

Compute Engine > Doc > 在 VM 和 MIG 上部署容器 > 将托管实例组更新为新版本的容器映像

Compute Engine > Doc > 创建 MIG > 更改 MIG 的实例模板

Compute Engine > Doc > 推出对 MIG 的更新 > 托管实例组的版本和 instanceTemplate 属性之间的关系

推荐阅读