GCP Cloud Run with PostgreSQL - 如何进行迁移？ [关闭]答案

【问题标题】：GCP Cloud Run with PostgreSQL - how to do migrations? [closed]GCP Cloud Run with PostgreSQL - 如何进行迁移？ [关闭]
【发布时间】：2021-03-03 19:06:51
【问题描述】：

我们从我们的第一个云运行项目开始。过去我们将 postgres 与 spring boot 结合使用。当应用启动时，我们通过 flyway（类似于 liquibase）运行迁移。

现在使用云运行，由于以下（拐角）情况，这种方法可能会达到极限：

多个传入请求（http、消息）路由到并行实例，这些实例在引导容器时可以并行执行相同的迁移。这将导致异常和重试失败消息或 http 错误
每次启动容器时，引导程序上的 flyway 检查会额外减慢冷启动时间，如果我们没有“热”实例的持续流量，这可能会很多

将 springboot/flyway 和 postgres 作为跨实例共享的后备数据库是什么好方法？当您用 nosql 数据存储替换 postgres 时会出现类似的问题，我猜您是否想要/需要迁移新结构....

现在我能想到的：

在云修订被替换之前迁移 postgres 架构作为部署管道的一部分，这会带来新的挑战（回滚等）

请分享您的想法？期待您的回答？马塞尔

【问题讨论】：

我没有比你更好的idea了，去掉启动检查加快实例启动。请注意，未优化的 Spring Boot 需要很长时间才能启动并准备好服务请求。我wrote an article 来缓解 Cloud Run 冷启动
@guillaumeblaquiere 感谢您的回答。我会看看你的文章。

标签： postgresql google-cloud-platform flyway google-cloud-run

【解决方案1】：

对于在提交或回滚时引入重大更改的迁移，必须完全停止，当然，还需要相应地计划回滚。

还要注意，提交/推送不应立即触发新的迁移。通常这些不是投入生产的常规 CI/CD 管道的一部分。

部署服务后，您可以创建一个新修订版并分配一个标签，使您可以在特定 URL 访问修订版无需提供流量。

一个常见的用例是运行和控制对该容器的首次访问。然后，您可以使用该标记将流量逐渐迁移到标记的修订版，并回滚标记的修订版。

要将现有服务的新修订版部署到生产环境：

gcloud beta run deploy myservice --image IMAGE_URL  --no-traffic --tag TAG_NAME

该标签允许您直接测试（或通过此迁移运行 - 第一个请求）特定 URL 处的新修订，而无需提供流量。 URL 以您提供的标签名称开头：例如，如果您在服务 myservice 上使用标签名称 green，您将在 URL https://green---myservice-abcdef.a.run.app 处测试标记的修订版

【讨论】：

感谢您的回答。我会看看你的解决方案。
查看您的解决方案，这意味着拥有数据存储的副本，进行迁移，然后将流量转移到新修订版（又名绿/蓝）部署？如果它是同一个实例，那么您只能应用非破坏性更改......对吗？
@niesfisch 是的，这听起来不错，您的运营工作对我们来说是未知的，因此请与您的团队讨论
谢谢...已经开始讨论这些东西了 :) 再次感谢。
虽然我同意 DB 迁移应该与代码部署分开的观点，但在 staging/dev 设置的情况下，将迁移作为 CI/CD 管道的一部分运行可能是一个不错的选择。在 GCP、Cloud Run 和 Cloud SQL 的上下文中，配置/支持没有以易于开发人员的方式记录。我在这个线程的 Dockerfile 中添加了使用 ENTRYPOINT 的说明（希望它有助于在需要时执行，具体取决于您的用例）：stackoverflow.com/a/69088911/867451