我想在云运行入口点（例如php artisan migration）中运行数据库迁移，以避免在升级之前必须使用外部工具来运行数据库迁移。
在kubernetes中，可以通过使部署中的初始化容器运行迁移并将最大浪涌设置为1来确保此功能，以确保只有一个pod尝试迁移，然后才能部署到其他容器。
CloudRun的推出策略是否在任何地方定义？如果CloudRun在修订之前等待一个容器中的某个容器运行正常，然后再进行批发，这将很好地满足此目的（尽管如果多个容器尝试迁移，则Postgres事务性DDL的问题还算不错），那将是一个很好的选择。我认为这是我观察到的但不确定的行为。
与在每个入口点运行迁移相比，是否有更好的/低维护的方式来运行迁移？
答案 0 :(得分：3)
在kubernetes中，可以通过使部署中的初始化容器运行迁移并将最大浪涌设置为1来确保此功能，以确保只有一个pod尝试迁移，然后才能部署到其他容器。
即使在Kubernetes中，这通常也不是一个好习惯。
理想情况下，您的数据库迁移代码应为idempotent。尤其是在无服务器的世界中，除非您改变思维方式并考虑这些概念，否则您会发现缺少这些原语是令人惊讶的。
Cloud Run的推出策略是通过配置手动流量拆分–根据定义的百分比在修订版之间路由流量。
您可以开发新版的Cloud Run Service，接收到的流量为0％。
在部署修订版后，Cloud Run仍将至少运行一个容器，以查看应用程序是否准备就绪（即进程开始监听PORT）。不过，在此过程中，您可能不应该仅依赖 1个实例，因为这不是保证的行为。
使用此技巧，您可以在监听PORT号之前先执行数据库迁移（请注意文档中的“限制”部分，以了解启动超时）。但是您需要编写一些逻辑（或使用外部锁定/同步机制），以确保将来不会（或在迁移发生时）一次又一次地执行代码路径。
答案 1 :(得分：1)
“ Cloud Run”上没有“准备就绪”探针。部署新修订版时：
通过最后一步，新流量将路由到新修订版，先前接收到的请求并且已经路由到先前修订版将继续在先前实例上进行处理。
那是简单的版本。如果要实现可持续的流量，同时并行处理多个实例，则更为复杂。
希望这些输入对您有所帮助！