0

我们正在为使用 React-Native 与 GCP 后端对话的客户端开发/支持移动应用程序。数据库是 Firestore，对象存储使用 GCP Storage，我们使用 GCP app-engine 进行一些 REST 调用，以及一系列 Cloud Functions 来处理一些 Firestore 和 GCP Storage 处理。

我们的产品部署包括将移动应用程序构建文件交付给客户端（他们在自己的服务器上内部分发应用程序），对于后端，我们使用 GCP CloudBuild 从我们的主/产品分支部署我们的应用程序引擎和云功能。然而，在过去的六个月里，我们进行了一系列粗略的产品部署，主要归结为我们在 dev 或 qa 环境（或忘记）上没有遇到的意外环境配置问题，以及一些数据库更新问题（数据模型更改）。这让我们对客户感到很困惑，因为在我们解决问题时，推出可能会延迟几个小时。

为了尝试解决这个问题，我们一直在考虑GCP 后端的蓝绿部署策略。这将包括创建一个新的 GCP 项目，为其部署最新的 master/prod 分支，并允许我们在将更新的移动应用程序交付给客户端之前进行全面测试——这并不奇怪。这在理论上听起来很棒，但在实践中并不是那么简单。主要问题是 Firestore 数据库和 GCP 存储——我们还需要将存储对象和 Firestore 数据库转移到新项目。可行，但又是一个复杂的问题。

所以我们的蓝绿理念是这样的：

  1. 我们创建了一个新的“Firestore/GCP 存储”项目，其唯一目的是充当“产品”数据存储位置（此项目中没有应用程序引擎或云功能），并充当身份验证提供者。该项目将是静态的，不会在产品部署之间更新
  2. 我们创建了一个新的“prod”（绿色）GCP 项目，该项目将为绿色部署托管最新的 App-Engine 和 Cloud Functions。此项目将被授予访问“Firestore/GCP 存储”项目数据和存储对象的权限
  3. 移动应用程序将与“数据存储”项目连接以与 Firestore 通信和上传文件，并将与新的“绿色”项目连接以进行 App-Engine REST 调用

我们希望这种模式能够让我们进行蓝绿后端逻辑部署，而无需担心数据/对象传输。我的问题是：有没有人在 GCP 中使用过这种类型的部署模式？它是推荐的模式，还是回避的反模式？

任何反馈表示赞赏。谢谢

4

1 回答 1

0

我同意必须在发布之前测试像移动后端这样重要的东西。

使用 gcloud 访问虚拟机的 API，或相应地迁移流量以批准新的更新，是 Cloud Build 使用提供的构建器熟悉的事情。

https://cloud.google.com/cloud-build/docs/cloud-builders#supported_builder_images_provided_by

Cloud Build 让您可以根据之前定义的概念阶段或阶段进行部署（例如蓝/绿策略）。在定义期间，您必须牢记要部署的应用程序的类型；在这种情况下，您提到了 Firestore 实例，一般建议是在另一个实例中复制以进行所有安排。

https://cloud.google.com/appengine/docs/flexible/nodejs/migrating-traffic

另一方面，您可以拥有一个 kubernetes 集群，允许您以更自然的方式管理这些功能，因此您可能必须评估应用程序的工作负载并尝试超越模式的云构建。

我希望这个观点对你有用。

于 2020-07-15T00:39:59.253 回答