GCP Cloud Run 容器服务部署

要解决什么问题

把 Web 应用或 API 跑在 Google Cloud Run 上，常见卡点不在「能不能跑」，而在镜像体积、PORT 约定、请求与 CPU 的并发关系，以及 SIGTERM 下的优雅退出。若仍按虚拟机或长期驻留进程的思路写代码，很容易在缩容、冷启动或内存配额上踩坑。

技能如何帮你落地

本技能以 Cloud Run 服务模式 为主线，面向无状态、容器化的 HTTP 工作负载，典型场景包括多路由 API、需要自选运行时/依赖栈的服务，以及需要对外暴露多个端点的复杂服务。

核心交付物包括：

• 多阶段 Dockerfile：分离构建与运行层，只拷贝生产依赖，缩小镜像并缩短拉取时间。
• Node/Express 示例：/health 健康检查、JSON API 路由，以及监听 process.env.PORT（默认 8080）的启动方式。
• cloudbuild.yaml 流水线：构建镜像 → 推送到 gcr.io/$PROJECT_ID → 用 gcloud run deploy 指定 region、内存/CPU、min-instances / max-instances 等参数完成发布。
• 冷启动与容量：文档强调启动 CPU 加速、最小实例、镜像瘦身、延迟加载重依赖，以及通过提高内存间接获得更多 CPU 等实践。

适用边界与反模式

Cloud Run 在无请求时会大幅节流 CPU，不适合把长时间后台任务当作主路径；/tmp 走内存文件系统，大文件写入会直接吃掉内存配额并触发 OOM。CPU 密集型逻辑若在高 concurrency 下并发执行，会拖垮同实例上的其它请求，这类 workload 往往需要 concurrency=1 或拆到其它执行环境。

文档中的「尖锐边缘」还提醒：规划内存时要算上 /tmp 用量、显式设置并发与超时、按需启用始终分配 CPU、为出站连接配置带 Keep-Alive 的连接池，并明确执行环境（如 gen2）以避免行为不一致。