Google Cloud Deploy 服务架构

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

概要视图

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

Cloud Deploy 组件之间的关系

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

  • 您的 CI 系统

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

  • Cloud Build

    Google Cloud Deploy 调用 Cloud Build 来渲染清单以及部署到目标运行时。

  • Skaffold

    Google Cloud Deploy 通过 Cloud Build 使用 Skaffold 来渲染和部署清单,从而部署应用。

  • Cloud Storage

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

  • Google Cloud 的运维套件Cloud Audit Logs

    Google Cloud 的运维套件会收集并提供 Google Cloud Deploy 的日志记录数据。

    另请参阅审核日志记录

  • Pub/Sub

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

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

  • 目标运行时

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

Google Cloud Deploy 资源

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

Cloud Deploy 资源之间的关系

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

  • 交付流水线可以生成零个或多个版本,并且可以引用一个或多个目标

  • 每个版本都包含流水线实例 - 交付流水线和目标在发布版本创建时配置的“快照”。

  • 每个版本可以生成零个或零个以上的发布作业,并且可以引用零个或零个以上的工件。

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

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

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

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

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

  • 工件是指 CI 进程(例如容器映像)中作为部署的一部分部署到目标运行时的任何输出。

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

发布资源

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

  • 阶段

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

  • 作业

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

  • 作业运行

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

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

本部分介绍 Google Cloud Deploy 如何与本文档中列出的组件交互,来以版本的形式自动交付应用。

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

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

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

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

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

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

      此外,Skaffold 版本会作为版本的一部分进行存储。在大多数情况下,这将是默认的 Skaffold 版本,但由于您可以指定其他版本,因此将存储该信息。

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

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

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

    4. 调用 skaffold render 以使用提供的映像或构建工件渲染清单。

      Google Cloud Deployment 会将 spec.templates.spec.containers.image 中的映像名称替换为在 gcloud deploy releases create 命令上或由该命令引用的构建工件文件中提供的完整映像路径(包括摘要和标记)。

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

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

    5. 通过调用 skaffold apply 自动创建发布并将其部署到第一个目标。

      只有在从 CLI 调用 Google Cloud Deploy 来创建版本时,才会出现这种情况。

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

    6. 如果 verify 在交付流水线配置中为目标 true,并且在 Skaffold 配置中指定,则调用 skaffold verify

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

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

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

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

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

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

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

  5. 在整个 Google Cloud Deploy 操作中,该服务会将平台日志和审核日志写入 Google Cloud 的运维套件和 Cloud Audit Logs。

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

后续步骤