将容器映像部署到 Cloud Run

本页面介绍如何将容器映像部署到新的 Cloud Run 服务或现有 Cloud Run 服务的新修订版本。

容器映像在部署时由 Cloud Run 导入。只要容器映像的副本由服务修订版本使用，Cloud Run 就会保留该副本。启动新的 Cloud Run 实例时，系统不会从容器仓库拉取容器映像。

如需查看部署新服务的示例演示，请参阅部署示例容器快速入门。

前期准备

如果您通过网域限制组织政策来限制项目的未经身份验证的调用，则您需要按照测试专用服务中的说明访问已部署的服务。

所需的角色

如需获得部署 Cloud Run 服务所需的权限，请让您的管理员为您授予以下 IAM 角色：

针对 Cloud Run 服务的 Cloud Run Developer (roles/run.developer) 角色
针对服务身份的 Service Account User (roles/iam.serviceAccountUser) 角色
已部署容器映像的 Artifact Registry 仓库的 Artifact Registry Reader (roles/artifactregistry.reader) 角色
如果您要使用跨项目服务账号部署服务：服务身份的 Service Account Token Creator (roles/iam.serviceAccountTokenCreator)

如需查看与 Cloud Run 关联的 IAM 角色和权限的列表，请参阅 Cloud Run IAM 角色和 Cloud Run IAM 权限。如果您的 Cloud Run 服务与Google Cloud API（例如 Cloud 客户端库）进行交互，请参阅服务身份配置指南。如需详细了解如何授予角色，请参阅部署权限和管理访问权限。

支持的容器存储库和映像

您可以直接使用已存储在 Artifact Registry 或 Docker Hub 中的容器映像。Google 建议使用 Artifact Registry。 Docker Hub 映像的缓存时间最长为一小时。

您可以通过设置 Artifact Registry 远程代码库，使用其他公共或私有注册表（如 JFrog Artifactory、Nexus 或 GitHub Container Registry）中的容器映像。

您应仅考虑使用 Docker Hub 部署常用的容器映像，例如 Docker 官方映像或 Docker 赞助的 OSS 映像。为了获得更高的可用性，Google 建议您使用 Artifact Registry 远程仓库部署这些 Docker Hub 映像。

从 Docker Hub 或包含外部注册表的 Artifact Registry 远程仓库部署时，Cloud Run 不支持大于 9.9 GB 的容器映像层。

部署新的服务

您可以使用标记（例如 us-docker.pkg.dev/my-project/container/my-image:latest）或确切摘要（例如 us-docker.pkg.dev/my-project/container/my-image@sha256:41f34ab970ee...）指定容器映像。

首次部署到服务时会创建第一个修订版本。请注意，修订版本是不可变的。如果使用容器映像标记进行部署，则该标记会被解析为摘要，并且修订版本将始终提供此特定摘要。

点击相应标签页即可获取有关所选工具的使用说明。

控制台

要部署容器映像，请执行以下操作：

在 Google Cloud 控制台中，前往 Cloud Run 页面。

转到 Cloud Run
点击部署容器，以显示创建服务表单。
1. 在该表单中选择部署选项：
  1. 如果您要手动部署容器，请选择从现有容器映像部署一个修订版本并指定容器映像。
  2. 如果要自动进行持续部署，请选择“从源代码库中持续部署新修订版本”并按照持续部署的说明进行操作。
2. 输入所需的服务名称。服务名称不得超过 49 个字符，并且在每个区域和项目中必须是唯一的。服务名称一旦指定便无法更改，并且公开显示。
3. 选择您想要使用的服务区域。区域选择器会显示价格层级、网域映射的可用性，并突出显示碳影响最低的区域。
4. 根据需要设置结算。
5. 在服务扩缩下，如果您使用默认的 Cloud Run 自动扩缩，请视情况指定实例数下限。如果您使用手动扩缩，请为服务指定实例数。
6. 根据需要设定表单中的 Ingress 设置。
7. 在“身份验证”下，配置以下内容：
  - 如果您要创建公共 API 或网站，请选择允许公开访问。选中此复选框后，系统会将 IAM Invoker 角色分配给特殊标识符 allUser。您可以在创建服务后使用 IAM 修改此设置。
  - 如果您需要通过身份验证加以保护的安全服务，请选择需要身份验证。
点击容器、卷、网络、安全性以在相应的标签页中设置其他可选设置：
完成服务配置后，请点击创建以将映像部署到 Cloud Run，然后等待部署完成。
点击显示的网址链接，以打开已部署服务的唯一、稳定的端点。

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
要部署容器映像，请执行以下操作：
1. 运行以下命令：
```
gcloud run deploy SERVICE --image IMAGE_URL
```
  替换以下内容：
  - SERVICE：您要部署到的服务的名称。服务名称不得超过 49 个字符，并且在每个区域和项目中必须是唯一的。如果服务尚不存在，则此命令会在部署期间创建服务。您可以完全省略此参数，但如果省略它，系统将提示您输入服务名称。
  - IMAGE_URL：对容器映像的引用，例如 us-docker.pkg.dev/cloudrun/container/hello:latest。如果您使用 Artifact Registry，则必须预先创建制品库 REPO_NAME。网址采用 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG 格式。请注意，如果您未提供 --image 标志，则部署命令将尝试从源代码进行部署。
  如果您要创建公共 API 或网站，则可以使用 --allow-unauthenticated 标志来允许公开访问您的服务。此操作会将 Cloud Run Invoker IAM 角色分配给 allUsers。您还可以指定 --no-allow-unauthenticated 以禁止公开访问。如果您省略其中任一标志，则系统会在 deploy 命令运行时提示您确认。
2. 等待部署完成。成功完成后，系统将显示一条成功消息以及已部署服务的网址。
请注意，如需将映像部署到其他位置，而不部署到通过 run/region gcloud 属性设置的位置，请使用以下命令：
```
gcloud run deploy SERVICE --region REGION
```

YAML

您可以将服务规范存储在 YAML 文件中，然后使用 gcloud CLI 进行部署。

创建包含以下内容的新 service.yaml 文件：
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: IMAGE
```
替换以下内容：
- SERVICE：Cloud Run 服务的名称。服务名称不得超过 49 个字符，并且在每个区域和项目中必须是唯一的。
- IMAGE：容器映像的网址。
您还可以指定更多配置，例如环境变量或内存限制。

使用以下命令部署新服务：

gcloud run services replace service.yaml

（可选）如果您想允许对服务进行未经身份验证的访问，请将服务设为公开。

Terraform

如需了解如何应用或移除 Terraform 配置，请参阅基本 Terraform 命令。

将以下内容添加到 Terraform 配置中的 google_cloud_run_v2_service 资源：

  provider "google" {
    project = "PROJECT-ID"
  }

  resource "google_cloud_run_v2_service" "default" {
    name     = "SERVICE"
    location = "REGION"
    client   = "terraform"

    template {
      containers {
        image = "IMAGE_URL"
      }
    }
  }

  resource "google_cloud_run_v2_service_iam_member" "noauth" {
    location = google_cloud_run_v2_service.default.location
    name     = google_cloud_run_v2_service.default.name
    role     = "roles/run.invoker"
    member   = "allUsers"
  }

替换以下内容：

PROJECT-ID： Google Cloud 项目 ID
REGION： Google Cloud 区域
SERVICE：Cloud Run 服务的名称。服务名称不得超过 49 个字符，并且在每个区域和项目中必须是唯一的。
IMAGE_URL：对容器映像的引用，例如 us-docker.pkg.dev/cloudrun/container/hello:latest。如果您使用 Artifact Registry，则必须预先创建制品库 REPO_NAME。网址采用 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG 格式

此配置允许公共访问（相当于 --allow-unauthenticated）。如需将该服务设为不公开，请移除 google_cloud_run_v2_service_iam_member 节。

写邮件

您可以将 Compose 规范存储在 YAML 文件中，然后使用单个 gcloud 命令将其部署为 Cloud Run 服务。

如需将 compose.yaml 文件部署为 Cloud Run 服务，请按以下步骤操作：

在项目目录中，创建一个包含服务定义的 compose.yaml 文件。
```
services:
  web:
    image: IMAGE
    ports:
      - "8080:8080"
```
将 IMAGE 替换为容器映像的网址。

您还可以指定更多配置选项，例如环境变量、Secret 和卷装载。
如需部署服务，请运行 gcloud beta run compose up 命令：
```
gcloud beta run compose up compose.yaml
```
在系统提示时，通过响应 y 来响应任何提示，以安装所需组件或启用 API。
可选：如果您想允许对服务进行未经身份验证的访问，请将服务设为公开。

部署完成后，系统会显示 Cloud Run 服务网址。复制此网址并将其粘贴到浏览器中，即可查看正在运行的容器。您可以通过 Google Cloud 控制台停用默认身份验证。

客户端库

如需通过代码部署新服务，请使用以下客户端库：

REST API

如需部署新服务，请向 Cloud Run Admin API service 端点发送 POST HTTP 请求。

例如，使用 curl：

curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X POST \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services?serviceId=SERVICE

替换以下内容：

ACCESS_TOKEN：具有部署服务的 IAM 权限的账号的有效访问令牌。例如，如果您已登录 gcloud，则可以使用 gcloud auth print-access-token 检索访问令牌。在 Cloud Run 容器实例中，您可以使用容器实例元数据服务器检索访问令牌。
IMAGE_URL：对容器映像的引用，例如 us-docker.pkg.dev/cloudrun/container/hello:latest。如果您使用 Artifact Registry，则必须预先创建制品库 REPO_NAME。网址采用 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG 格式。
SERVICE：您要部署到的服务的名称。服务名称不得超过 49 个字符，并且在每个区域和项目中必须是唯一的。
REGION：服务的 Google Cloud 区域。
PROJECT-ID： Google Cloud 项目 ID。

Cloud Run 位置

Cloud Run 是区域级的，这意味着运行 Cloud Run 服务的基础架构位于特定区域，并且由 Google 代管，以便在该区域内的所有可用区以冗余方式提供。

选择用于运行 Cloud Run 服务的区域时，主要考虑该区域能否满足您的延迟时间、可用性或耐用性要求。通常，您可以选择距离用户最近的区域，但除此之外，您还应该考虑 Cloud Run 服务使用的其他 Google Cloud产品的位置。跨多个位置使用 Google Cloud 产品可能会影响服务的延迟时间和费用。

Cloud Run 可在以下区域使用：

基于层级 1 价格

asia-east1（台湾）
asia-northeast1（东京）
asia-northeast2（大阪）
asia-south1（印度孟买）
europe-north1（芬兰）二氧化碳排放量低
europe-north2（斯德哥尔摩）二氧化碳排放量低
europe-southwest1（马德里）二氧化碳排放量低
europe-west1（比利时）二氧化碳排放量低
europe-west4（荷兰）二氧化碳排放量低
europe-west8（米兰）
europe-west9（巴黎）二氧化碳排放量低
me-west1（特拉维夫）
northamerica-south1（墨西哥）
us-central1（爱荷华）二氧化碳排放量低
us-east1（南卡罗来纳）
us-east4（北弗吉尼亚）
us-east5（哥伦布）
us-south1（达拉斯）二氧化碳排放量低
us-west1（俄勒冈）二氧化碳排放量低

基于层级 2 价格

africa-south1（约翰内斯堡）
asia-east2（香港）
asia-northeast3（韩国首尔）
asia-southeast1（新加坡）
asia-southeast2 （雅加达）
asia-south2（印度德里）
australia-southeast1（悉尼）
australia-southeast2（墨尔本）
europe-central2（波兰，华沙）
europe-west10（柏林）
europe-west12（都灵）
europe-west2（英国伦敦）二氧化碳排放量低
europe-west3（德国法兰克福）
europe-west6（瑞士苏黎世）二氧化碳排放量低
me-central1（多哈）
me-central2（达曼）
northamerica-northeast1（蒙特利尔）二氧化碳排放量低
northamerica-northeast2（多伦多）二氧化碳排放量低
southamerica-east1（巴西圣保罗）二氧化碳排放量低
southamerica-west1（智利圣地亚哥）二氧化碳排放量低
us-west2（洛杉矶）
us-west3（盐湖城）
us-west4（拉斯维加斯）

如果您已创建 Cloud Run 服务，可在Google Cloud 控制台的 Cloud Run 信息中心内查看区域。

部署现有服务的新修订版本

您可以使用 Google Cloud 控制台、gcloud 命令行或 YAML 配置文件部署新的修订版本。

请注意，更改任何配置设置都会导致新修订版本的创建，即使容器映像没有变化也是如此。创建的每个修订版本都是不可变的。

容器映像在部署时由 Cloud Run 导入。只要容器映像的副本由服务修订版本使用，Cloud Run 就会保留该副本。

点击相应标签页即可获取有关所选工具的使用说明。

控制台

要部署现有服务的新修订版本，请执行以下操作：

在 Google Cloud 控制台中，前往 Cloud Run 服务页面：

转到 Cloud Run
在服务列表中找到要更新的服务，然后点击以打开其详细信息。
点击修改和部署新的修订版本以显示修订版本部署表单。
1. 如果需要，请提供要部署的新容器映像的网址。
2. 根据需要配置容器。
3. 根据需要设置结算。
4. 在“容量”下，指定内存上限和 CPU 上限。
5. 根据需要指定请求超时和并发。
6. 根据需要指定执行环境。
7. 在“自动扩缩”下，指定最小和最大实例数。
8. 根据需要，使用其他标签页选择性地配置：
如需将所有流量都发送到新修订版本，请选择立即支持此修订版本。如需逐步发布新的修订版本，请取消选中该复选框。这样在部署中，系统将不会向新修订版本发送任何流量。部署后，按照逐步发布的说明进行操作。
点击部署并等待部署完成。

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
要部署容器映像，请执行以下操作：
1. 运行以下命令：
```
gcloud run deploy SERVICE --image IMAGE_URL
```
  替换以下内容：
  - SERVICE：您要部署到的服务的名称。您可以完全省略此参数，但如果省略它，系统将提示您输入服务名称。
  - IMAGE_URL：对容器映像的引用，例如 us-docker.pkg.dev/cloudrun/container/hello:latest。如果您使用 Artifact Registry，则必须预先创建制品库 REPO_NAME。网址采用 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG 格式。
  系统会自动为新修订版本分配后缀。如果您要提供自己的修订版本后缀，请使用 gcloud CLI 参数 --revision-suffix。
2. 等待部署完成。成功完成后，系统将显示一条成功消息以及已部署服务的网址。

YAML

如果您需要下载或查看现有服务的配置，请使用以下命令将结果保存到 YAML 文件：

gcloud run services describe SERVICE --format export > service.yaml

在服务配置 YAML 文件中，根据需要修改任何 spec.template 子属性以更新修订版本设置，然后部署新修订版本：

gcloud run services replace service.yaml

Cloud Code

如需使用 Cloud Code 部署现有服务的新修订版本，请阅读 IntelliJ 和 Visual Studio Code 指南。

Terraform

确保您已按照部署新服务示例中的说明设置了 Terraform。

更改配置文件。
应用 Terraform 配置：
```
terraform apply
```
输入 yes，确认您要应用所述操作。

注意：除非需要更改配置，否则不会创建新修订版本。

写邮件

您可以将 Compose 规范存储在 YAML 文件中，然后使用单个 gcloud 命令将其部署为 Cloud Run 服务修订版本。

如需将 compose.yaml 文件部署为 Cloud Run 服务修订版本，请按照以下步骤操作：

在项目目录中，创建一个包含服务定义的 compose.yaml 文件。
```
services:
  web:
    image: IMAGE
    ports:
      - "8080:8080"
```
将 IMAGE 替换为容器映像的网址。

您还可以指定更多配置选项，例如环境变量、Secret 和卷装载。
如需部署服务，请运行 gcloud beta run compose up 命令：
```
gcloud beta run compose up compose.yaml
```
在系统提示时，通过响应 y 来响应任何提示，以安装所需组件或启用 API。
可选：如果您想允许对服务进行未经身份验证的访问，请将服务设为公开。

客户端库

如需通过代码部署新的修订版本，请使用以下客户端库：

REST API

如需部署新的修订版本，请向 Cloud Run Admin API service 端点发送 PATCH HTTP 请求。

例如，使用 curl：

curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X PATCH \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE

替换以下内容：

ACCESS_TOKEN：具有部署修订版本的 IAM 权限的账号的有效访问令牌。例如，如果您已登录 gcloud，则可以使用 gcloud auth print-access-token 检索访问令牌。在 Cloud Run 容器实例中，您可以使用容器实例元数据服务器检索访问令牌。
IMAGE_URL：对容器映像的引用，例如 us-docker.pkg.dev/cloudrun/container/hello:latest。如果您使用 Artifact Registry，则必须预先创建制品库 REPO_NAME。网址采用 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG 格式。
SERVICE：您要部署到的服务的名称。
REGION：服务的 Google Cloud 区域。
PROJECT-ID： Google Cloud 项目 ID。

Cloud Run 位置

Cloud Run 是区域级的，这意味着运行 Cloud Run 服务的基础架构位于特定区域，并且由 Google 代管，以便在该区域内的所有可用区以冗余方式提供。

Cloud Run 可在以下区域使用：

基于层级 1 价格

asia-east1（台湾）
asia-northeast1（东京）
asia-northeast2（大阪）
asia-south1（印度孟买）
europe-north1（芬兰）二氧化碳排放量低
europe-north2（斯德哥尔摩）二氧化碳排放量低
europe-southwest1（马德里）二氧化碳排放量低
europe-west1（比利时）二氧化碳排放量低
europe-west4（荷兰）二氧化碳排放量低
europe-west8（米兰）
europe-west9（巴黎）二氧化碳排放量低
me-west1（特拉维夫）
northamerica-south1（墨西哥）
us-central1（爱荷华）二氧化碳排放量低
us-east1（南卡罗来纳）
us-east4（北弗吉尼亚）
us-east5（哥伦布）
us-south1（达拉斯）二氧化碳排放量低
us-west1（俄勒冈）二氧化碳排放量低

基于层级 2 价格

africa-south1（约翰内斯堡）
asia-east2（香港）
asia-northeast3（韩国首尔）
asia-southeast1（新加坡）
asia-southeast2 （雅加达）
asia-south2（印度德里）
australia-southeast1（悉尼）
australia-southeast2（墨尔本）
europe-central2（波兰，华沙）
europe-west10（柏林）
europe-west12（都灵）
europe-west2（英国伦敦）二氧化碳排放量低
europe-west3（德国法兰克福）
europe-west6（瑞士苏黎世）二氧化碳排放量低
me-central1（多哈）
me-central2（达曼）
northamerica-northeast1（蒙特利尔）二氧化碳排放量低
northamerica-northeast2（多伦多）二氧化碳排放量低
southamerica-east1（巴西圣保罗）二氧化碳排放量低
southamerica-west1（智利圣地亚哥）二氧化碳排放量低
us-west2（洛杉矶）
us-west3（盐湖城）
us-west4（拉斯维加斯）

如果您已创建 Cloud Run 服务，可在Google Cloud 控制台的 Cloud Run 信息中心内查看区域。

从其他 Google Cloud 项目部署映像

如需从其他 Google Cloud 项目部署映像，您或您的管理员必须为部署者账号和 Cloud Run 服务代理授予所需的 IAM 角色。

如需了解部署者账号所需的角色，请参阅必需的角色。

如需为 Cloud Run 服务代理授予所需的角色，请参阅以下说明：

在 Google Cloud 控制台中，打开 Cloud Run 服务对应的项目。

转到 IAM 页面
选择包括 Google 提供的角色授权。
复制 Cloud Run 服务代理的电子邮件。该电子邮件的后缀为 @serverless-robot-prodiam.gserviceaccount.com。
打开您要使用的容器注册表所属的项目。

进入 IAM 页面
点击添加以添加新的主账号。
在新的主账号字段中，粘贴您之前复制的服务账号的电子邮件地址。
在选择角色菜单中，点击 Artifact Registry -> Artifact Registry Reader。
将容器映像部署到您的 Cloud Run 服务所属的项目。

注意：为了提高安全性，请授予对容器映像所在 Artifact Registry 存储库的访问权限。

从其他注册表中部署映像

如需部署未存储在 Artifact Registry 或 Docker Hub 中的公共或私有容器映像，请设置 Artifact Registry 远程仓库。

借助 Artifact Registry 远程仓库，您可以执行以下操作：

部署任何公共容器映像，例如 GitHub Container Registry (ghcr.io)。
从需要身份验证的私有仓库（例如 JFrog Artifactory 或 Nexus）部署容器映像。

或者，如果您无法使用 Artifact Registry 远程仓库，可以使用 docker push 暂时将容器映像拉取到 Artifact Registry，并将其推送到 Cloud Run。容器映像在部署时由 Cloud Run 导入，因此在部署后，您可以从 Artifact Registry 删除映像。

将多个容器部署到服务 (Sidecar)

在具有 Sidecar 的 Cloud Run 部署中，有一个入站流量容器来处理您指定的容器 PORT 中的所有传入 HTTPS 请求，并且还有一个或多个 Sidecar容器。Sidecar 无法监听入站流量容器端口中的传入 HTTP 请求，但可以使用 localhost 端口相互通信以及与入站流量容器通信。所用的 localhost 端口因您使用的容器而异。

在下图中，入站流量容器使用 localhost:5000 与边车通信。

Cloud Run 多容器

每个实例最多可以部署 10 个容器，包括 Ingress 容器。实例中的所有容器共用同一网络命名空间，并且可以使用内存中共享卷来共享文件，如图所示。

您可以在第一代或第二代执行环境中部署多个容器。

如果您使用基于请求的结算方式（Cloud Run 的默认结算方式），则仅在以下情况下才会为边车分配 CPU：

实例正在处理至少一个请求。
入站流量容器正在启动。

如果边车必须在请求处理之外使用 CPU（例如，用于指标收集），请将服务的结算设置配置为基于实例的结算方式。如需了解详情，请参阅结算设置（服务）。

如果您使用的是基于请求的结算方式，请配置启动探测器，以确保边车在启动时不会受到 CPU 限制。

您可以通过创建自定义组织政策，要求所有部署都使用特定的边车容器。

使用场景

Cloud Run 服务中 Sidecar 的应用场景包括：

应用监控、日志记录和跟踪记录
在应用容器前面使用 Nginx、Envoy 或 Apache2 作为代理
添加身份验证和授权过滤器（例如 Open Policy Agent）
运行出站连接代理，例如 Alloy DB Auth 代理

使用 Sidecar 容器部署服务

您可以使用Google Cloud 控制台、Google Cloud CLI、YAML 或 Terraform 将多个边车容器部署到 Cloud Run 作业。

点击相应标签页即可获取有关所选工具的使用说明。

控制台

在 Google Cloud 控制台中，前往 Cloud Run 服务页面：

转到 Cloud Run
- 如需部署到现有服务，请在服务列表中找到服务，点击以打开它，然后点击修改和部署新修订版本以显示修订版本部署表单。
- 如需部署新服务，请点击部署容器以显示创建服务表单。
对于新服务，
1. 提供服务名称和要部署的入站流量容器映像的网址。
2. 点击容器、卷、网络、安全性
在修改容器卡片中，根据需要配置 Ingress 容器。
点击添加容器，然后配置要添加的边车容器以及入站流量容器。如果边车依赖于服务中的其他容器，请在容器启动顺序菜单中指明。对您要部署的每个边车容器重复此步骤。
如需将所有流量都发送到新修订版本，请选择立即支持此修订版本。对于逐步发布，请取消选中该复选框。这样在部署中，系统将不会向新修订版本发送任何流量。部署后，按照逐步发布的说明进行操作。
点击创建（对于新服务）或部署（对于现有服务），然后等待部署完成。

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
如需将多个容器部署到服务，请运行以下命令：
```
gcloud run deploy SERVICE \
 --container INGRESS_CONTAINER_NAME \
 --image='INGRESS_IMAGE' \
 --port='CONTAINER_PORT' \
 --container SIDECAR_CONTAINER_NAME \
 --image='SIDECAR_IMAGE'
```
替换以下内容：
- SERVICE：您要部署到的服务的名称。您可以完全省略此参数，但如果省略它，系统将提示您输入服务名称。
- INGRESS_CONTAINER_NAME：接收请求的容器的名称，例如 app。
- INGRESS_IMAGE：对应接收请求的容器映像的引用，例如 us-docker.pkg.dev/cloudrun/container/hello:latest。
- CONTAINER_PORT：入站流量容器监听传入请求的端口。与单容器服务不同，对于包含 Sidecar 的服务，入站流量容器没有默认端口。您必须为入站流量容器明确配置容器端口，并且只有一个容器可以公开该端口。
- SIDECAR_CONTAINER_NAME：边车容器的名称，例如 sidecar。
- SIDECAR_IMAGE：对边车容器映像的引用
如果要在部署命令中配置每个容器，请在 container 参数后面提供每个容器的配置，例如：
```
gcloud run deploy SERVICE \
  --container CONTAINER_1_NAME \
  --image='INGRESS_IMAGE' \
  --set-env-vars=KEY=VALUE \
  --port='CONTAINER_PORT' \
  --container SIDECAR_CONTAINER_NAME \
  --image='SIDECAR_IMAGE' \
  --set-env-vars=KEY_N=VALUE_N
```
重要提示：使用 --container 标志时，您必须在容器级标志前面指定所有非容器级标志，否则部署命令将会失败，并显示错误消息来说明这一点。例如，在“gcloud run services deploy service --execution-environment=gen2 --container app --memory=1G”命令中，--execution-environment 标志必须在 --container 标志之前传递。
等待部署完成。成功完成后，系统将显示一条成功消息以及已部署服务的网址。

YAML

以下说明介绍了具有边车的 Cloud Run 服务的基本 YAML 文件。创建名为 service.yaml 的文件，并将以下内容添加到其中：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: INGRESS_IMAGE
        ports:
          - containerPort: CONTAINER_PORT
      - image: SIDECAR_IMAGE

替换以下内容：

SERVICE：Cloud Run 服务的名称。服务名称不得超过 49 个字符。
CONTAINER_PORT：入站流量容器监听传入请求的端口。与单容器服务不同，对于包含 Sidecar 的服务，入站流量容器没有默认端口。您必须为入站流量容器明确配置容器端口，并且只有一个容器可以公开该端口。
INGRESS_IMAGE：对应接收请求的容器映像的引用，例如 us-docker.pkg.dev/cloudrun/container/hello:latest。
SIDECAR_IMAGE：对边车容器映像的引用。您可以通过向 YAML 中的 containers 数组添加更多元素来指定多个 Sidecar。

更新 YAML 以添加入站流量容器和边车容器后，使用以下命令部署到 Cloud Run：

gcloud run services replace service.yaml

Terraform

如需了解如何应用或移除 Terraform 配置，请参阅基本 Terraform 命令。

将以下内容添加到 Terraform 配置中的 google_cloud_run_v2_service 资源：

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  location = "REGION"
  ingress = "INGRESS_TRAFFIC_ALL"
  template {
    containers {
      name = "INGRESS_CONTAINER_NAME"
      ports {
        container_port = CONTAINER_PORT
      }
      image = "INGRESS_IMAGE"
      depends_on = ["SIDECAR_CONTAINER_NAME"]
    }
    containers {
      name = "SIDECAR_CONTAINER_NAME"
      image = "SIDECAR_IMAGE"
      }
    }
  }

CONTAINER_PORT 表示入站流量容器监听传入请求的端口。与单容器服务不同，对于包含 Sidecar 的服务，入站流量容器没有默认端口。您必须为入站流量容器明确配置容器端口，并且只有一个容器可以公开该端口。

具有 Sidecar 的部署提供的显著功能

启动顺序

如果在具有容器的部署中您的依赖项要求某些容器在其他容器之前启动，则可以在该部署中指定容器启动顺序

如果您的容器依赖于其他容器，则必须在部署中使用健康检查。如果您使用健康检查，Cloud Run 会遵循容器启动顺序并检查每个容器的健康状况，从而确保每个容器在 Cloud Run 按顺序启动下一个容器之前成功通过健康检查。如果您不使用健康检查，则健康状况良好的容器将会启动，即使其所依赖的容器未在运行也是如此。

在边车之间交换文件数据

单个实例中的多个容器可以访问共享的内存中卷，每个容器都可以使用您创建的装载点访问该卷。这通常用于在容器之间共享文件，例如，遥测边车容器可以从应用容器收集日志。

在边车之间通信

同一实例的两个容器可以在本地网络上相互通信。

请考虑以下示例服务：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example
spec:
  template:
    spec:
      containers:
      - name: ingress
        image: ...
        ports:
          - containerPort: 8080
      - name: sidecar
        image: ...

此服务的每个实例都将运行两个容器：一个名为 ingress，另一个名为 sidecar。

到达服务的请求会发送到端口 8080 上的 ingress 容器。在具有多个容器的服务中，只能将一个容器配置为处理所有入站请求的入站流量容器，并且该容器必须是配置了 containerPort 的容器。

容器 ingress 和 sidecar 可以在 http://localhost 上相互通信。例如，如果容器 sidecar 在端口 5000 上监听请求，则容器 ingress 可以通过 http://localhost:5000 与其通信。

由于容器已命名，因此容器甚至可以使用容器的名称相互通信。例如，如果容器 sidecar 在端口 5000 上监听请求，则容器 ingress 可以使用 http://sidecar:5000 与 sidecar 通信。

调整容器以适应 Cloud Run

您构建或找到的大多数容器都与 Cloud Run 容器运行时合同兼容。不过，您可能需要更改一些为简化本地开发而构建的容器，或者需要完全的机器控制权，才能使这些容器与 Cloud Run 执行环境兼容。

将装载移至 Cloud Run 配置

容器的初始化脚本必须假定在调用容器之前，装载已完成。您必须将所有装载操作移至 Cloud Run 资源配置中。

尽可能切换到非根用户

首选不使用或依赖根用户的容器。这种做法可降低 Cloud Run 服务的漏洞风险，缩小容器的受攻击面，限制攻击者对文件系统的访问权限，并遵循最小权限原则。

在 Dockerfile 中使用 USER 指令切换到权限较低的身份，因为默认情况下是以 root 身份运行的。Cloud Run 使用 Dockerfile 中指定的用户来运行容器。

审核 `setuid` 二进制文件的使用情况

从 Cloud Run 中的容器运行时，setuid 二进制文件的执行将失败。

如果您在本地使用 Docker 或 Podman，请使用 --cap-drop=setuid 参数。或者，验证您所依赖的二进制文件是否未设置 setuid 位。

验证根容器是否与用户命名空间兼容

在用户命名空间下运行时（例如使用 Docker 的 userns-remap 功能、在无根 Podman 中运行容器，或使用 docker run 命令中的 --userns-remap=default 参数将这些更改部署到运行 Container-Optimized OS 的 Google 虚拟机），通过评估代码在本地或虚拟机中测试更改。

后续步骤

部署新服务后，您可以执行以下操作：

您可以使用 Cloud Build 触发器实现 Cloud Run 服务的自动构建和部署：

设置持续部署

您还可以使用 Cloud Deploy 设置持续交付流水线，以将 Cloud Run 服务部署到多个环境中：

使用 Cloud Deploy 将应用部署到 Cloud Run

将容器映像部署到 Cloud Run 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

前期准备

所需的角色

支持的容器存储库和映像

部署新的服务

控制台

gcloud

YAML

Terraform

写邮件

客户端库

REST API

Cloud Run 位置

基于层级 1 价格

基于层级 2 价格

部署现有服务的新修订版本

控制台

gcloud

YAML

Cloud Code

Terraform

写邮件

客户端库

REST API

Cloud Run 位置

基于层级 1 价格

基于层级 2 价格

从其他 Google Cloud 项目部署映像

从其他注册表中部署映像

将多个容器部署到服务 (Sidecar)

使用场景

使用 Sidecar 容器部署服务

控制台

gcloud

YAML

Terraform

具有 Sidecar 的部署提供的显著功能

启动顺序

在边车之间交换文件数据

在边车之间通信

调整容器以适应 Cloud Run

将装载移至 Cloud Run 配置

尽可能切换到非根用户

审核 setuid 二进制文件的使用情况

验证根容器是否与用户命名空间兼容

后续步骤

将容器映像部署到 Cloud Run

审核 `setuid` 二进制文件的使用情况