将 Docker 部署到 Google Cloud Run：生产环境指南

在 Google Cloud Run 上部署 Docker 容器，可让开发人员无需管理虚拟机、操作系统补丁或传统服务器基础设施，即可运行容器化的 Web 应用程序。.

Google Cloud Run 是一个完全托管的应用平台，支持基于容器的服务、自动扩展、HTTPS 端点，并可与 Google Cloud 服务集成。.

不过，生产环境部署不仅仅是上传一个 Docker 镜像那么简单。你还需要配置容器端口、权限、密钥、监控、资源限制以及可靠的发布流程。.

在本指南中，您将学习如何使用 Cloud Build 和 Artifact Registry 将 Docker 容器部署到 Google Cloud Run，然后为应用程序处理生产环境流量做好准备。.

Google Cloud Run Docker 部署：快速概述

组件	目的
Dockerfile	定义应用程序容器镜像
Cloud Build	构建容器镜像
Artifact Registry	存储容器镜像
Cloud Run	运行并扩展容器化服务
IAM	控制部署和服务权限
秘密管理器	存储敏感的配置值
云日志记录	收集应用程序日志
云监控	监控服务状态和性能

部署工作流： 准备应用程序、构建镜像、将其推送到 Artifact Registry、部署到 Cloud Run、配置安全设置，并监控生产环境中的服务。.

1. 什么是 Google Cloud Run？

Google Cloud Run 是一个用于运行以容器形式打包的应用程序的托管平台。.

与传统的虚拟机不同，Cloud Run 无需开发人员管理底层的服务器操作系统。.

对于受支持的工作负载，它提供了自动扩展、基于版本的部署以及托管式 HTTPS 端点。.

Cloud Run 通常用于：

REST API
容器化Web应用程序
后端微服务
Webhook 接收器
事件驱动处理
内部应用服务

Cloud Run 还支持其他执行模型，包括作业和面向工作者的工作负载，但本教程主要介绍如何部署一个 HTTP 服务。.

如果您正在考虑托管容器平台是否适合您，请阅读我们的 Google Cloud Run 与 Compute Engine 的对比在继续之前。.

2. 将 Docker 部署到 Cloud Run 的先决条件

开始之前，请准备：

一个已启用计费功能的 Google Cloud 项目
已安装并完成身份验证的 Google Cloud CLI
已打包为 Docker 镜像的应用程序或应用程序源代码
使用 Cloud Build、Artifact Registry 和 Cloud Run 的权限
合适的 Google Cloud 区域
关于密钥、数据库和应用程序访问的方案

对于生产项目，应使用最小权限的 IAM 角色，而不是不必要地授予广泛的管理权限。.

Cloud Build 的构建服务账户和 Cloud Run 的运行时服务账户是不同的身份，可能需要不同的权限。.

3. 创建一个 Docker 应用程序

本示例使用了一个小型 Node.js HTTP 应用程序。相同的通用部署流程也可适用于 Python、Go、Java、PHP 以及其他受支持的运行时环境。.

创建 package.json 文件

{
  "name": "cloud-run-demo",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "start": "node server.js"
  },
  "engines": {
    "node": ">=22"
  }
}

创建 server.js 文件

const http = require("node:http");

const port = Number(process.env.PORT || 8080);

const server = http.createServer((req, res) => {
  if (req.url === "/health") {
    res.writeHead(200, {
      "Content-Type": "application/json"
    });
    res.end(JSON.stringify({ status: "ok" }));
    return;
  }

  res.writeHead(200, {
    "Content-Type": "application/json"
  });

  res.end(JSON.stringify({
    message: "Hello from Google Cloud Run!"
  }));
});

server.listen(port, "0.0.0.0", () => {
  console.log(`Listening on port ${port}`);
});

重要的配置是 process.env.PORT 结合 0.0.0.0 网络绑定。.

Cloud Run 需要 ingress 容器监听配置的端口，并接受来自容器环回接口外部的流量。.

4. 创建一个适合生产环境的 Dockerfile

创建一个名为 Dockerfile 在应用程序目录中：

FROM node:22-alpine

ENV NODE_ENV=production

WORKDIR /app

COPY package.json ./
COPY server.js ./

USER node

EXPOSE 8080

CMD ["node", "server.js"]

此示例使用受支持的 Node.js 主版本镜像系列，避免了不必要的依赖项，并以非 root 用户身份运行应用程序。.

对于生产环境部署，请使用当前受支持且已打补丁的基础镜像，并考虑将镜像固定到经过验证的摘要上，以确保构建结果可重复。.

创建一个 .dockerignore 文件

node_modules
.git
.env
.env.*
*.log
Dockerfile.local

A .dockerignore 该文件有助于防止不必要的文件和本地密钥进入构建上下文。.

切勿将生产环境的 API 密钥或数据库密码直接硬编码到容器镜像中。.

5. 配置您的 Google Cloud 项目

打开一个已安装 Google Cloud CLI 的终端。.

请将示例项目 ID 和区域替换为您自己的值。.

export PROJECT_ID="您的项目 ID"
export REGION="us-central1"
export REPOSITORY="cloud-run-images"
export SERVICE="docker-web-app"

gcloud auth login

gcloud config set project "$PROJECT_ID"

启用所需的 API：

gcloud services enable \
  run.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com \
  secretmanager.googleapis.com

启用 API 和创建资源需要在所选项目中具备相应的权限。.

6. 创建一个 Artifact Registry 存储库

Artifact Registry 用于存储您的 Cloud Run 部署所使用的容器镜像。.

创建一个 Docker 仓库：

gcloud artifacts repositories create "$REPOSITORY" \
  --repository-format=docker \
  --location="$REGION" \
  --description="Cloud Run 容器镜像"

如果仓库已经存在，请直接复用它，而不是创建一个重复的仓库。.

构建图像名称：

export IMAGE="$REGION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/$SERVICE:v1"

使用专用仓库可以更轻松地管理镜像权限、清理策略和部署工件。.

7. 使用 Cloud Build 构建 Docker 镜像

在包含您的 Dockerfile 的目录中运行构建命令：

gcloud builds submit \
  --tag "$IMAGE" \
  .

Cloud Build 会上传源代码上下文，构建容器镜像，并将其推送到 Artifact Registry。.

构建身份必须具有将构建产物上传至所选存储库的权限。.

根据项目设置的不同，您可能需要在构建成功之前配置 Cloud Build 服务账户，并授予相应的 Artifact Registry 权限。.

构建完成后，请确认该镜像是否已出现在 Artifact Registry 中。.

8. 将容器部署到 Google Cloud Run

将镜像部署为 Cloud Run 服务：

gcloud run deploy "$SERVICE" \
  --image "$IMAGE" \
  --region "$REGION" \
  --port 8080 \
  --memory 512Mi \
  --cpu 1 \
  --concurrency 40 \
  --max-instances 10 \
  --no-allow-unauthenticated

此配置将服务部署为默认需要身份验证。.

它还设置了初始内存分配、CPU 分配、并发限制以及最大实例数。.

这些数值仅供参考，并非通用的生产建议。请在进行负载测试和成本分析后进行调整。.

在必要时允许公众访问

如果该应用程序旨在作为公共网站或公共 API，请有意识地配置未经过身份验证的访问权限。.

对于支持基于 IAM 的公共访问的环境，在部署过程中可以使用以下选项：

--允许未认证

某些组织会限制公共 IAM 绑定。在组织策略允许的情况下，Google Cloud 还支持针对公共服务的 Cloud Run Invoker IAM 检查配置。.

不要仅仅为了方便测试，就暴露管理端点、内部 API 或敏感的应用程序数据。.

9. 测试 Cloud Run 部署

获取服务 URL：

gcloud run services describe "$SERVICE" \
  --region "$REGION" \
  --format="value(status.url)"

如果是面向公众的服务，请在浏览器中打开该网址。.

对于需要身份验证的服务，请使用具有调用该服务权限的身份。.

例如，在拥有适当的 IAM 权限的情况下：

export SERVICE_URL="$(gcloud run services describe "$SERVICE" \
  --region "$REGION" \
  --format='value(status.url)')"

curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
  "$SERVICE_URL/health"

该测试应返回一个成功的 JSON 状态响应。.

如果身份验证失败，请验证调用方的身份、Cloud Run Invoker 的权限以及令牌受众要求。.

10. 配置环境变量和密钥

应用程序通常需要一些配置值，例如数据库主机名、功能开关和 API 端点。.

非敏感值可以作为环境变量提供。.

gcloud run services update "$SERVICE" \
  --region "$REGION" \
  --update-env-vars APP_ENV=production

对于密码、API 密钥和其他敏感值，请使用 Google Cloud Secret Manager，而不是将密钥直接放在源代码或容器镜像中。.

创建一个密钥

对于示例密钥，请通过受支持的 Secret Manager 工作流安全地提供其值。.

授予 Cloud Run 运行时服务账户所需的最低 Secret Manager 访问权限。.

然后配置该服务以引用该密钥：

gcloud run services update "$SERVICE" \
  --region "$REGION" \
  --update-secrets API_KEY=app-api-key:latest

此命令假设该密钥已存在，且运行时服务账户具有访问该密钥的权限。.

对于生产环境，请考虑将密钥与特定版本绑定，并采用受控的轮换流程。.

11. 配置 Cloud Run 自动缩放

Cloud Run 可以根据需求和配置的扩展行为自动调整服务实例数量。.

重要设置包括：

最小实例数
最大实例数
请求并发性
CPU 分配
内存分配
请求超时

最小实例数

保持一定数量的实例处于可用状态，有助于降低对延迟敏感的应用程序的启动延迟。.

然而，保留闲置产能可能会增加成本。.

最大实例数

“最大实例数”设置有助于限制服务在正常情况下可扩展的范围。.

不应将其视为绝对的财务保证，因为其他可计费服务和使用模式仍会影响总支出。.

并发

并发控制着单个实例能够同时处理的请求数量。.

对于某些应用程序而言，更高的并发数可能有助于提高资源利用率，但对于CPU密集型或对内存要求较高的负载，采用较低的并发设置可能效果更好。.

在确定生产限制之前，先对实际流量进行基准测试。.

12. Cloud Run 定价与成本优化

Cloud Run 的定价取决于所选的计费模式、分配的资源、使用情况以及其他计费服务。.

潜在的成本构成包括：

CPU 使用率或分配的 CPU 时间
内存使用情况或内存分配时间
适用计费模式下的请求
最小实例容量
Artifact Registry 存储
Cloud Build 的使用情况
网络流量
日志记录与监控
外部数据库及配套服务

当配置和工作负载允许时，Cloud Run 服务可以缩放至零。.

然而，规模归零的行为并不意味着整个应用程序架构没有空闲开销。.

对于需要操作系统持续运行、专用网络或持久性本地服务的应用，传统虚拟机可能更合适。.

我们的 Google Cloud 虚拟机定价指南介绍了在比较 Cloud Run 与 Compute Engine 时需要考虑的机器类型、折扣、存储费用及其他费用。.

13. 什么时候应该改用 Docker VPS 呢？

Cloud Run 非常适合许多 HTTP 应用程序，但某些容器化工作负载需要更多对基础设施的控制权。.

例如，需要自定义主机操作系统、具有特权容器行为、需要专用网络功能，或者与受管 Cloud Run 执行模型不兼容的软件等应用。.

对于这些工作负载，传统云VPS或许值得考虑。.

Vultr 对于正在比较可配置虚拟服务器和 Docker 托管基础设施的开发者而言，这是一个可选方案。.

Cherry 服务器 对于正在考虑为持续运行的容器工作负载配置专用资源的团队而言，这可能具有参考价值。.

这些服务并不能直接替代 Cloud Run 的全托管部署和自动扩展功能。.

在迁移之前，请比较操作系统管理、网络要求、备份职责以及应用程序的可用性。.

在将容器化应用程序从托管平台迁移到虚拟服务器之前，请查阅我们的云托管与VPS对比了解在可扩展性、基础设施控制、性能和管理职责方面的差异。.

14. 保障生产环境中的 Cloud Run 服务安全

生产环境中的容器安全应同时涵盖应用程序及其部署基础设施。.

使用专用的运行时服务帐户

为服务账户分配仅包含应用程序所需权限的权限。.

当仅需更细粒度的资源级访问权限时，应避免使用宽泛的项目级权限。.

保护秘密

请使用 Secret Manager 管理敏感配置值。.

保持容器镜像更新

当安全补丁发布后，请重新构建并重新部署镜像。.

限制应用程序访问权限

选择合适的身份验证和入口模型。.

对于内部应用程序，请考虑私有访问模式及支持的网络控制措施。.

验证输入和依赖项

应用标准的应用程序安全措施，包括输入验证、依赖项扫描以及适当的身份验证。.

遵循最小权限原则

在可行的情况下，应将构建、部署和运行时的权限分开。.

15. 配置日志记录、监控和警报

Cloud Run 与 Google Cloud 的可观测性服务集成。.

写入标准输出和标准错误的应用程序输出可由 Cloud Logging 收集。.

显示器：

请求延迟
错误率
实例数量
CPU 和内存使用情况
初创企业失败
应用程序异常
服务可用性

针对有实际意义的生产问题配置警报，而不是仅依赖手动检查仪表盘。.

尽可能使用结构化日志，并避免将密码、访问令牌或其他敏感数据写入日志输出中。.

16. 安全地部署新版本并回滚

Cloud Run 支持基于版本的部署，允许团队发布新的应用程序版本，并在不同版本之间管理流量。.

更安全的生产工作流程包括：

构建一个新的容器镜像。.
部署一个新版本。.
运行健康检查和烟雾测试。.
在适当的情况下，逐步调整交通流向。.
监控错误和延迟。.
如有必要，请将流量恢复到之前的正常版本。.

例如，在部署时不立即将流量引导至新版本，可以支持分阶段验证：

gcloud run deploy "$SERVICE" \
  --image "$IMAGE" \
  --region "$REGION" \
  --no-traffic

测试完成后，可通过 Google Cloud 控制台或受支持的 Cloud Run CLI 命令管理修订版本的流量。.

应用程序数据库迁移需要进行额外规划，因为回滚容器并不会自动撤销模式更改。.

17. 适用于专用容器的 Cloud Run 替代方案

某些工作负载与以 HTTP 为核心的托管容器服务并不十分匹配。.

例如，对GPU依赖程度较高的AI应用、专用处理管道以及需要专用硬件的工作负载，可能需要不同的部署环境。.

RunPod 在评估适用于兼容AI容器工作负载的GPU基础设施时，这一点至关重要。.

云集群 根据所提供的具体服务，还值得研究其支持的应用程序托管和基础设施要求。.

不应假设二者均提供与 Cloud Run 完全一致的 API、部署行为或安全模型。.

如需了解更广泛的基础设施选项，请参阅我们的最佳云托管解决方案指南.

18. Google Cloud Run 中常见的 Docker 部署错误

容器无法启动并在端口上监听

请确认应用程序正在监听配置的端口，并绑定到 0.0.0.0。.

验证 Dockerfile 中的启动命令，并查看容器日志。.

推送图片时权限被拒绝

检查 Cloud Build 所用身份的 Artifact Registry 权限。.

部署时权限被拒绝

请查看 Cloud Run 的部署权限和服务账户模拟要求。.

调用该服务时出现 403 禁止访问错误

确认是否需要身份验证，以及调用方的身份是否具有调用该服务的权限。.

应用程序在高负载下崩溃

检查内存使用情况、CPU 分配、并发情况、依赖项超时以及应用程序日志。.

意料之外的 Cloud Run 成本

检查最小实例数、流量模式、请求时长、网络使用情况、Artifact Registry 存储以及已连接的 Google Cloud 服务。.

应用程序重启后丢失文件

Cloud Run 的本地文件系统并非持久化应用程序存储。.

将持久化数据迁移到合适的外部存储或数据库服务中。.

生产环境部署检查清单

请使用受支持且已打补丁的容器基础镜像。.
将应用程序绑定到已配置的端口。.
将秘密置于图像之外。.
请使用具有最低权限的运行时服务帐户。.
选择适当的身份验证和入站设置。.
配置 CPU、内存、并发数和扩展限制。.
在需要时使用外部持久化存储。.
启用日志记录和有意义的警报。.
测试生产流量和启动行为。.
记录部署和回滚流程。.

常见问题解答

Google Cloud Run 能否部署 Docker 容器？

是的。Cloud Run 支持打包为兼容容器镜像的应用程序，包括使用 Docker 构建的镜像。.

使用 Cloud Run 需要 Kubernetes 吗？

不。Cloud Run 负责管理底层的容器基础设施，因此开发人员无需为标准的 Cloud Run 服务运维 Kubernetes 集群。.

Cloud Run 是否需要使用 8080 端口？

8080 端口是一个常见的默认端口，但服务端口可以进行配置。应用程序必须监听通过 PORT 环境变量指定的端口。.

Cloud Run 能否缩减到零？

是的，符合条件的服务在空闲时可根据其配置缩减至零。实例的最低配置和工作负载要求可能会影响空闲容量。.

Cloud Run 能存储上传的文件吗？

执行过程中可以使用临时文件，但不应将本地容器存储视为持久化存储。如需实现持久化上传，请使用外部存储。.

Cloud Run 比 Compute Engine 更便宜吗？

这取决于工作负载模式、资源需求、计费配置以及配套服务。间歇性工作负载可能更适合采用托管式弹性扩展，而持续运行的工作负载则需要进行全面的成本比较。.

Cloud Run 可以使用自定义域名吗？

是的，可以通过支持的域名配置选项实现。对于生产环境架构，请根据您的区域和具体需求，查看当前推荐的自定义域名和负载均衡方法。.

如何保障 Cloud Run API 的安全性？

使用基于 IAM 的调用控制或合适的应用程序身份验证、最小权限的服务账户、Secret Manager 以及适当的网络访问限制。.

我可以回滚 Cloud Run 的部署吗？

是的。Cloud Run 的版本功能允许将流量切换回之前的版本，但需考虑应用程序的兼容性以及外部状态的变化。.

最终结论：在 Cloud Run 上部署 Docker 并实施生产环境管控

Google Cloud Run 提供了一个便捷的平台，用于部署容器化的 Web 应用程序，而无需管理虚拟机。.

一个成功的生产环境部署应包括可靠的镜像构建流程、Artifact Registry、受控的服务权限、安全的配置、资源限制、监控以及经过测试的回滚方案。.

对于需要直接控制虚拟机、专用基础设施或专用 GPU 资源的工作负载，可考虑使用 Vultr、Cherry Servers、Cloud Clusters 等替代方案，以及 RunPod 或许值得评估一下。.

构建 → 存储 → 部署 → 安全 → 监控 → 回滚。.

最佳的部署并非仅仅是能够成功启动，而是随着应用程序的扩展，仍能保持安全、可监控、可靠且易于管理。.