部署 Cloud Run 服务或作业

本文档介绍了如何部署应用,包括 Cloud Run 服务和 Cloud Run 作业。

借助 Cloud Deploy,您可以将基于容器的工作负载部署到任何 Cloud Run 服务作业。所有 Cloud Deploy 功能 部署到 Cloud Run 目标时 Cloud Run 服务,但不支持 Canary 部署: Cloud Run 作业。

本文档介绍了您需要完成的三个主要配置,以便部署到 Cloud Run:

限制

  • 您只能为每个目标部署一项 Cloud Run 服务或作业。

  • 您无法针对 Cloud Run 作业运行 Canary 部署

    不过,Cloud Run 服务可以使用 Canary 部署。

准备工作

创建目标配置

目标可以在交付流水线 YAML 中配置,也可以在 一个单独的文件。此外,您还可以在同一文件中配置多个目标。

在目标定义中,创建一个 run 诗节,以标识将创建 Cloud Run 服务的位置。

在目标定义中指定 Cloud Run 服务或作业的语法如下所示:

run:
 location: projects/[project_name]/locations/[region_name]

此资源标识符使用以下元素:

  • [project_name] 是将用于创建 Cloud Run 服务或作业的 Google Cloud 项目的名称。

    您需要为每个目标执行此操作。建议为每个项目分别使用不同的项目 Cloud Run 服务或作业。如果您需要多项服务 在同一个项目中,您需要使用 Skaffold 配置文件 添加到 skaffold.yaml 配置文件中。

  • [region_name] 是将创建服务或作业的区域。您的服务或作业可以位于任何 Cloud Run 支持的区域

以下是目标配置示例,用于定义要创建的 Cloud Run 服务或作业:

      apiVersion: deploy.cloud.google.com/v1
      kind: Target
      metadata:
       name: dev
      description: development service
      run:
       location: projects/my-app/locations/us-central1

您可以在 Cloud Deploy 交付流水线中定义此目标 定义或单独进行定义无论采用哪种方式 注册目标 然后再创建版本以部署 Cloud Run 服务 或工作。

创建 Skaffold 配置

以下是 Cloud Run 部署skaffold.yaml 文件示例

apiVersion: skaffold/v4beta7
kind: Config
metadata: 
  name: cloud-run-application
manifests:
  rawYaml:
  - service.yaml
deploy:
  cloudrun: {}

在此 skaffold.yaml 文件中...

  • manifests.rawYaml 提供 Cloud Run 的名称, 服务定义。

    在此示例中,service.yaml 是用于定义 Skaffold 将部署的 Cloud Run 服务的文件。此文件名可以是任何名称,但按照惯例,服务的文件名为 service.yaml,作业的文件名为 job.yaml

  • deploy 诗节指定了您希望如何部署清单,具体包括项目和位置。“deploy”为必填字段。

    我们建议您将 {} 留空。Cloud Deploy 填充 根据项目和来自目标平台的位置,在渲染过程中 定义。

    不过,对于本地开发,您可以在此处提供值。不过, Cloud Deploy 始终使用目标中的项目和位置 定义,无论此处是否提供了值。

创建 Cloud Run 服务定义

如需创建 Cloud Run 服务定义,您可以创建 也可以从现有服务中复制一个文件本部分将介绍这两种方法。

选项 1:创建新的 Cloud Run service.yaml

service.yaml 用于定义 Cloud Run 服务。当您 创建版本后,Skaffold 会使用此定义来部署您的服务。

下面是一个简化示例:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
 name: [SERVICE_NAME]
spec:
 template:
  spec:
   containers:
   - image: [IMAGE_PATH]

其中:

  • [SERVICE_NAME] 是此 Cloud Run 服务的名称。

  • [IMAGE_PATH] 指向您用于部署的一个或多个容器映像 。

方法 2:使用 Google Cloud 控制台从现有服务中复制 service.yaml

您可以使用 Google Cloud 控制台创建服务,也可以使用现有服务。 然后从该文件夹中复制 service.yaml

如需使用 Google Cloud CLI 获取 service.yaml,请执行以下操作:

gcloud run services describe [service_name] --format=export

如需从 Google Cloud 控制台获取 service.yaml,请执行以下操作:

  1. 在 Google Cloud 控制台中,前往 Cloud Run 服务 页面。

  2. 选择您要使用的现有服务的定义。

或者,您也可以新建一个,然后选择该维度。时间 选择服务后,系统会显示“Service Details”(服务详情)页面:

Google Cloud 控制台中的服务详情页面,其中显示了“YAML”标签页

  1. 选择 YAML 标签页。

  2. 点击修改,然后将 YAML 的内容复制到文件系统中名为 service.yaml 的新文件中,以便 Skaffold 在您创建版本时使用它。

创建 Cloud Run 作业定义

如需部署 Cloud Run 作业定义,您可以创建 也可以从现有作业中复制一个本部分将介绍这两种方法。

请注意,作业不一定会在通过 Cloud Deploy 部署后运行。这与服务不同,服务是指在部署后运行的应用。作业的调用方式取决于作业 本身。

选项 1:创建新的 Cloud Run job.yaml

job.yaml 用于定义 Cloud Run 作业。创建版本时,Skaffold 会使用此定义来部署作业。

下面是一个简化示例:

apiVersion: run.googleapis.com/v1
kind: Job
metadata:
 name: [JOB_NAME]
spec:
  template:
  spec:
   containers:
   - image: [IMAGE_PATH]

其中:

  • [JOB_NAME] 是此 Cloud Run 作业的名称。

  • [IMAGE_PATH] 指向您要为此作业部署的容器映像。

方法 2:使用 Google Cloud 控制台从现有作业中复制 job.yaml

您可以使用 Google Cloud 控制台创建作业,也可以使用现有作业,然后从中复制 job.yaml

如需使用 Google Cloud CLI 获取 job.yaml,请执行以下操作:

gcloud run jobs describe [job_name] --format=export

如需从 Google Cloud 控制台获取 job.yaml,请执行以下操作:

  1. 在 Google Cloud 控制台中,前往 Cloud Run 作业 页面。

  2. 选择您要使用的现有作业的定义。

或者,您也可以新建一个,然后选择该转化操作。选择作业后,系统会显示“作业详情”页面:

Google Cloud 控制台上的作业详情页面,其中显示了 YAML 标签页

  1. 选择 YAML 标签页。

  2. 点击 Edit,然后将 YAML 的内容复制到名为 job.yaml,这样当您调用时,Skaffold 可以使用它。 创建版本

综合应用

现在,您已经有了 Cloud Run 服务或作业定义, skaffold.yaml 配置,以及您的 Cloud Deploy 目标 定义, 注册了您的目标 作为 Cloud Deploy 资源,您现在可以 调用交付流水线 创建一个版本,并按照定义的目标逐步推进发布流程 流水线中。

快速入门 使用 Cloud Deploy 将应用部署到 Cloud Run 实际操作次数。

服务跨修订版本的行为

重新部署服务时,新修订版本 已部署“service.yaml”。除非新部署的 YAML 中与先前修订版本相同,否则系统不会保留先前修订版本的任何内容。例如,如果 先前修订版本中有些配置设置或标签 但在新 YAML 中,这些设置或标签不会出现在新版本中。

触发 Cloud Run 作业

部署作业后,您可以按照 Cloud Run 文档中的说明触发作业。

在多个项目中部署 Cloud Run 服务和作业

如果您需要部署不同项目中的服务或作业, 执行服务账号的需求 访问定义了这些服务或作业的项目的权限。

请参阅 Cloud Deploy 执行服务账号 以及 Identity and Access Management 角色和权限

后续步骤