Cloud Deploy 服务架构

本文档介绍了 Cloud Deploy 与其配合(以便部署应用)的外部系统之间的关系。这些系统是其他 Google Cloud 服务和第三方工具。

概要视图

下图显示了 Cloud Deploy 与其依赖的独立系统之间的关系。

Cloud Deploy 组件之间的关系

如图所示,Cloud Deploy 与以下系统交互:

  • 您的 CI 系统

    Cloud Deploy 支持大多数 CI 工具,前提是 CI 流程的一个输出可以调用 Cloud Deploy APICLI创建版本

  • Cloud Build

    Cloud Deploy 调用 Cloud Build 以呈现清单并部署到目标运行时。

  • Skaffold

    Cloud Deploy 通过 Cloud Build 使用 Skaffold 呈现和部署应用,从而部署应用。

  • Cloud Storage

    Cloud Deploy 将渲染来源和渲染清单存储在 Cloud Storage 存储桶中。

  • Google Cloud 可观测性Cloud Audit Logs

    Google Cloud Observability 会收集并提供 Cloud Deploy 的日志记录数据。

    另请参阅审核日志记录

  • Pub/Sub

    Cloud Deploy 会将消息发布到多个 Pub/Sub 主题。您可以使用此服务来与外部工作流、测试和其他相关系统集成。

    如需了解详情,请参阅订阅 Cloud Deploy 通知

  • 目标运行时

    Cloud Deploy 通过 Cloud Build 使用 skaffold apply 将应用部署到目标运行时(GKE 或 GKE Enterprise)。

Cloud Deploy 资源

下图显示了 Cloud Deploy 用于交付应用的资源以及这些资源之间的关系:

Cloud Deploy 资源之间的关系

如图所示,各资源之间的关系如下:

  • 交付流水线可以生成零个或多个版本,并且可以引用一个或多个目标,包括多目标及其关联的子目标

  • 交付流水线还可以引用一个或多个自动化操作,这些自动化操作可自动对 Cloud Deploy 资源执行操作。

  • 每个版本都包含流水线实例,即创建版本时交付流水线和目标的“快照”。

  • 每个版本可以生成零个或多个“发布”,并且可以引用零个或多个工件。

    每个发布至少包含一个阶段,表示发布中逻辑上组合在一起的操作(作业)集合,例如部署或部署和验证。

    每个阶段都包含一个或多个作业,表示要在发布时完成的操作,即部署或验证。每个作业可以包含一个或多个作业运行,这些作业运行是作业的实例,例如,尝试部署。作业运行是发布的子资源。

    用于并行部署多目标可创建控制器发布,此类发布会创建与子目标对应的子发布。

  • 每次发布都与一个目标相关联。

    对于并行部署,每个子目标都与一个子发布相关联。

  • 每个目标都与应用的一个 GKE、Anthos 集群或其他运行时目标相关联。

  • 目标可以与一个或多个交付流水线相关联。

  • 工件是指在发布过程中部署到目标运行时的任何 CI 流程输出(例如容器映像)。

此外,发布包含一个或多个阶段,而阶段包含一个或多个作业以及一个或多个作业运行。

发布资源

如图所示,发布包含以下内容:

  • 阶段

    一个阶段包含一个或多个作业(例如部署,或者部署和验证)。每个发布都有一个或多个阶段。阶段是发布中的子消息。

  • 作业

    要在发布时执行的特定操作,例如部署或验证。作业是发布中的子消息。

  • JobRuns

    作业实例,例如尝试验证。每个作业可以有零个或多个 JobRun。JobRun 是发布的子资源。

自动化操作包含自动化规则,这些规则可以由零个或多个 AutomationRun 资源引用。AutomationRun 是已执行的自动化规则的实例,例如从一个目标自动提升到另一个目标。Automation 和 AutomationRun 资源是交付流水线下的对等子资源。

Automation 有关的资源

它们如何整合在一起以交付版本

本部分介绍 Cloud Deploy 如何与本文档中列出的组件进行交互,以自动将应用作为版本交付。

  1. 您的 CI 系统会调用 Cloud Deploy 交付流水线。

    您的 CI 流程使用 CLIAPI 调用 Cloud Deploy,以创建新的版本,并将构建工件或对映像的引用传递。

    如需详细了解如何集成 CI 系统,请参阅将 Cloud Deploy 与其他系统集成

  2. 创建新版本后,Cloud Deploy 会执行以下操作:

    1. 将交付流水线的实例存储为版本的一部分。

      即使交付流水线配置已更改,此版本的此流水线实例也保持不变。如需了解详情,请参阅每个版本的流水线实例

      此外,Skaffold 版本也会存储在该版本中。在大多数情况下,这将是默认的 Skaffold 版本,但由于您可以指定其他版本,系统会存储该信息。

    2. 调用 Cloud Build,以从 Cloud Storage 获取 Skaffold 渲染来源。

      Cloud Deploy 将渲染来源存储在默认或备用 Cloud Storage 存储桶中。

    3. 调用 skaffold diagnose(使用创建版本时存储的 Skaffold 版本)生成单个有效的清单。

    4. 调用 render 操作。

      如果您使用的是内置目标,Cloud Deploy 会调用 skaffold render 以使用提供的映像或构建工件来呈现清单。Cloud Deploy 会将 spec.templates.spec.containers.image 中的映像名称替换为 gcloud deploy releases create 命令或该命令引用的构建工件文件中提供的完整映像路径(包括摘要或标记)。

      如果您使用的是自定义目标,Cloud Deploy 会调用为其自定义目标类型定义的 render 操作

      Cloud Deploy 将渲染的清单存储在默认或备用 Cloud Storage 存储桶中。

      Cloud Deploy 使用默认或备用执行环境执行这些操作。

  3. 创建发布(版本创建后自动或之后按需创建)时,Cloud Deploy 会执行以下操作:

    1. 调用部署前钩子(如果已指定)。

      如果您使用的是 Canary 部署策略,则系统会在第一阶段开始时调用部署前钩子。

    2. 调用 deploy 操作。

      如果您使用的是内置目标,Cloud Deploy 会通过调用 skaffold apply 自动创建发布并将其部署到第一个目标。如果您使用的是内置目标,则在创建版本时会自动创建第一次发布。

      如果您使用的是自定义目标,Cloud Deploy 会自动创建发布到第一个目标的发布,并调用为其自定义目标类型定义的 deploy 操作

      对于内置目标和自定义目标,只有在使用命令行创建版本时,系统才会自动发布到第一个目标。

      部署到第一个目标的过程与提升相同,如下一步所述。

    3. 如果交付流水线配置中的目标的 verifytrue,并且在 Skaffold 配置中指定了验证,则调用 skaffold verify

    4. 如果指定了 verify,则在 verify 之后调用部署后钩子(如果已指定)。否则,系统会在 deploy 之后调用部署后钩子。

      如果您使用的是 Canary 部署策略,则部署后钩子将作为最终发布阶段的最后一个作业执行。

  4. 当需要将版本提升到下一个目标时,Cloud Build 会从 Cloud Storage 中检索特定于目标的清单。然后,Cloud Build 调用 skaffold apply 以将已渲染清单应用于指定的目标运行时。

    如果目标需要批准,您可以通过 CLI 或使用控制台批准或拒绝。

    此外,Cloud Deploy 还会生成一条 Pub/Sub 消息,您可订阅该消息以自动启动审批工作流

    Cloud Deploy 使用与此版本关联的 Skaffold 版本和流水线实例,并在默认或自定义执行环境中执行此步骤。

    此过程不仅适用于提升,也适用于回滚和重新部署。

  5. 在整个 Cloud Deploy 操作过程中,该服务会向多个 Pub/Sub 主题发布通知(例如,当发布需要批准时)。

    将 Cloud Deploy 与外部系统集成中介绍了此集成和其他集成。

  6. 您可以指定一项自动化操作,以自动执行交付流水线中的各种operations。这些可在指定时间执行。automationRun 表示执行自动化规则。

  7. 在整个 Cloud Deploy 操作过程中,该服务会将平台日志和审核日志写入 Google Cloud Observability 和 Cloud Audit Logs。

在所有这些步骤中,都可以使用 Identity and Access Management 来限制流控制和资源访问权限。

后续步骤