我正在考虑使用 Cloud Scheduler 在 Cloud Run 上触发 Python 应用程序的日常执行。该应用从第三方 API 提取数据并将其插入 BigQuery。唯一的问题是，根据我阅读的许多文章，Cloud Run 有 15 分钟的执行时间限制，这可能太短了。
查看 Cloud Run 文档：https://cloud.google.com/run/quotas#cloud_run_limits 似乎表明最长执行时间为 60 分钟。
哪个是正确的？云运行实际上可以运行长达 60 分钟的进程吗？如果该过程花费的时间超过 30 分钟，我在使用 Cloud Schedular 触发 Cloud run 时可能会遇到任何问题吗？
【问题讨论】：
标签： python google-cloud-run google-cloud-scheduler
这是一个常见问题：您可以使用 Cloud Run，它可以运行长达 60 分钟的超时作业，但可以触发它的无服务器产品的限制更大（Cloud Scheduler 为 30 分钟，PubSub 为 10 分钟）。
如果您不想使用 Cloud Scheduler 执行重试，只需调用 Cloud Run 服务即可。 Cloud Scheduler 会将调度视为失败（超时），但 Cloud Run 上的进程将继续（如果 Cloud Scheduler 客户端停止侦听应答的事件）。
如果您想处理错误和重试，或者如果您想在 Cloud Scheduler UI 中获得“成功”状态，解决方案是使用Cloud Workflow。工作流程非常简单：使用参数（如果适用）调用您的 API。那么这里的流程：
终于，你有了它，没有优化，但它可以工作。
【讨论】：
写：
哪个是正确的？
目前这里说：https://cloud.google.com/run/docs/configuring/request-timeout：
The timeout is set by default to 5 minutes and can be extended up to 60 minutes.
写：
云运行实际上可以运行长达 60 分钟的进程吗？我有可能吗 在使用 Cloud Schedular 触发 Cloud 运行时遇到任何问题，如果 过程耗时超过 30 分钟？
目前这里说：https://cloud.google.com/run/docs/configuring/request-timeout：
Important: For a timeout longer than 15 minutes, Google recommends implementing retries and making sure the service is tolerant to clients re-connecting in case the connection is lost (either by ensuring requests are idempotent, or by designing request handlers in such a way that they can resume from the point where they left off). The longer the timeout is, the more likely the connection can be lost due to failures on the client side or the Cloud Run side. When a client re-connects, a new request is initiated and the client isn't guaranteed to connect to the same container instance of the service.
【讨论】：
Cloud Run 的默认超时时间为 5 分钟
您可以通过在gcloud run deploy 中指定--timeout 标志来增加它
如果你的超时时间超过 15 分钟，你必须使用gcloud beta run deploy
如果您尝试使用gcloud run deploy 超过15m 的超时，您将收到以下错误 - Timeout duration must be less than 15m. Timeouts above 15m are in Beta. Use "gcloud beta run ..."
【讨论】：