带数据库迁移的云运行

Question

我想在云运行入口点（例如 php artisan migrate）中运行数据库迁移，以避免在升级修订之前必须使用外部工具来运行这些。

在 kubernetes 中，此功能可以通过在部署上运行 init 容器并将 max Surge 设置为 1 来实现，以确保只有一个 pod 在推出到其他容器之前尝试迁移。

CloudRun 的推出策略是否在任何地方定义？如果 CloudRun 等待修订中的一个容器运行良好，然后再进行批发，这将是很好的，这将满足此目的（尽管如果多个容器尝试迁移，postgres 事务性 DDL 的问题还不算太糟糕）。我认为这是我观察到但不确定的行为。

有没有比在每个入口点运行迁移更好/低维护的方式来运行迁移？

Answer 1

在 kubernetes 中，此功能可以通过在部署上运行 init 容器并将 max Surge 设置为 1 来实现，以确保只有一个 pod 在推出到其他容器之前尝试迁移。

这通常不是一个好的做法，即使在 Kubernetes 中也是如此。

理想情况下，您的数据库迁移代码应该是幂等的。尤其是在无服务器世界中，除非您转变思维方式并思考这些概念，否则您会发现缺少这些原语令人惊讶。

Cloud Run 的推出策略是通过配置手动流量拆分——根据您定义的百分比在修订之间路由流量。

您可以开发 Cloud Run 服务的新版本，接收 0% 的流量。

部署修订版后，Cloud Run 仍将运行至少一个容器，以查看应用程序是否准备就绪（即进程开始侦听 PORT）。但是，您可能不应该仅依赖此过程中出现的1 个实例，因为这不是有保证的行为。

使用这个技巧，您可以在侦听端口号之前执行数据库迁移（请注意启动超时文档的“限制”部分）。但是您需要编写一些逻辑（或使用外部锁定/同步机制）以确保代码路径不会在将来（或在迁移发生的同时）一遍又一遍地执行。