SaaS 运行时概览

借助 SaaS 运行时，您可以在 Google Cloud上存储、托管、管理和监控软件即服务 (SaaS) 应用。SaaS 运行时可管理大规模的 Terraform 部署，让您可以同时管理 SaaS 应用和它在运行时所处的基础设施。

SaaS 运行时可供 SaaS 管道中的各种利益相关者以多种方式使用。如果您的工作与以下任何角色相关，您可能会对使用 SaaS 运行时感兴趣：

  • 平台管理员
  • 应用开发者
  • 架构师
  • 合规管理员
  • 平台工程师
  • 财务运营

SaaS 运行时具有以下优势：

  • 通过在 SaaS 租户中自动执行服务管理任务（例如部署、发布和功能标志管理），大规模简化服务管理。
  • 通过在可配置的单元中微调更新和发布，扩大可观测性和控制范围，从而大规模精确管理 SaaS 产品。
  • 通过管理各种 Google Cloud 产品（包括 Google Cloud、Google Distributed Cloud、结算、可观测性和 Resource Manager）中的服务，在整个 Google Cloud 生态系统中实现一致性。
  • 使用灵活且可模板化的架构，以促进基于单元的组更新和部署，从而提高效率和可重用性。

SaaS 运行时如何运作？

SaaS 运行时会部署用于定义 SaaS 产品的制品。这些制品必须具有 Terraform 配置。部署分为不同的单元，这些单元可以通过包含产品更改的发布版本，以可配置的发布流程进行更新。

如需详细了解 SaaS 运行时命名惯例，请参阅术语表。

为 SaaS 运行时准备工作负载

在部署 SaaS 产品之前，建议您先确定 SaaS 产品在 SaaS 运行时生态系统中的理想安排。

将应一起更新或修改的 SaaS 产品部分整理到不同的 Terraform 配置中。在规划 SaaS 产品时，请为 SaaS 产品的每个分组使用单元种类。

确定 SaaS 运行时上工作负载的理想结构后，您可以创建 SaaS 产品、单元种类，然后使用发布来部署单元。

如需查看 SaaS 运行时设置示例，请参阅快速入门。

SaaS 运行时服务账号

SaaS 运行时会同时使用 Google 管理的服务账号和用户代管式服务账号：

  • SaaS 运行时服务账号（由 Google 管理）：此账号会在创建第一个 SaaS 产品资源后自动创建。由 Google 管理。它会代表您执行操作，例如在单元配置期间与其他 Google Cloud 服务互动。

  • 启动服务账号（用户管理）：此服务账号由您创建和管理。在预配或更新单元时，SaaS 运行时（通过 Infrastructure Manager）会使用此账号来执行您的 Terraform 配置。此账号充当创建和管理 Terraform 中定义的资源的身份。执行服务账号权限直接与 Terraform 配置所管理的资源相关联。

    您可以拥有多个启动服务账号。我们建议您为每个租户设置一个促动服务账号。

  • 可选：制品创建服务账号（用户管理）：此服务账号用于构建 Terraform 并将其打包成 OCI 制品，然后上传。这通常是 Cloud Build 服务账号，但也可以是具有适用于您的 SaaS 产品/服务的相应权限的任何服务账号。

SaaS 运行时服务账号（由 Google 管理）

SaaS 运行时服务账号是由 Google 管理的服务代理，SaaS 运行时会使用该服务代理在您的项目中执行操作。

当您创建第一个 SaaS Runtime 资源时，系统会自动预配此服务账号。SaaS 运行时服务账号创建格式如下：

  service-PROJECT_NUMBER@gcp-sa-saasservicemgmt.iam.gserviceaccount.com

将

  • PROJECT_NUMBER：您的项目编号。

执行启动操作的服务账号（用户管理）

启动服务账号是您必须创建的用户代管式服务账号。SaaS 运行时（通过 Infra Manager）使用此服务账号执行 Terraform 配置。它是创建、修改和删除 Terraform 中定义的资源的身份。

您负责在项目或租户项目内创建此服务账号。

执行启动操作的服务账号输入变量

创建单元时，您必须为 Terraform 配置提供一个键值对输入变量作为促动服务账号：

  • 名称：actuation_sa
  • 变量类型：String

  • 变量值：启动服务账号电子邮件地址：

    my-actuation-sa@my-identifier.iam.gserviceaccount.com

所需权限

执行服务账号需要具备足够的权限来管理 Terraform 配置中定义的资源。至少需要：

  • roles/iam.serviceAccountTokenCreator：允许服务账号生成用于身份验证的令牌。
  • roles/config.admin：授予对 Infra Manager 资源的完全控制权。
  • roles/storage.admin：授予对 Cloud Storage 的完全控制权限。

促动服务账号还需要具备创建和管理应用所用特定 Google Cloud 资源的权限。

例如：

  • 如果您的 Terraform 会创建 Google Kubernetes Engine (GKE) 集群，则服务账号需要具有适当的 GKE 角色（例如 roles/container.admin）。
  • 如果您的 Terraform 会创建 Compute Engine 实例，则服务账号需要具备 roles/compute.admin 角色。
  • 如果您的 Terraform 创建 Cloud SQL 实例，则服务账号需要具有适当的 Cloud SQL 角色（例如 roles/cloudsql.admin）。

请参阅您在 Terraform 中使用的每个 Google Cloud 资源的相关文档，以确定所需的权限。授予应用正常运行所需的最低权限。

制品创建服务账号（用户管理）

制品创建服务账号是一种用户代管式服务账号，您可以通过创建该账号来使用构建系统（例如 Cloud Build）将 Terraform 制品打包并上传到 Artifact Registry。

此服务账号与 SaaS 运行时和服务账号分开，用于构建您的 Terraform 代码并将生成的制品推送到 Artifact Registry。通常，这是 Cloud Build 服务账号。

手动创建制品

如果您手动构建并上传 Terraform 制品（例如，直接使用 Docker build 和 Docker push），则无需单独的制品创建服务账号。

您应改用自己的凭据或具有必要 Artifact Registry 权限的服务账号进行身份验证。

所需权限

如果您使用的是 Cloud Build，Cloud Build 服务账号通常需要以下角色：

  • roles/artifactregistry.writer：将制品推送到 Artifact Registry。
  • roles/artifactregistry.repoAdmin：用于管理 Artifact Registry 代码库。
  • roles/storage.admin：管理 Cloud Storage 存储分区。
  • roles/developerconnect.admin：使用 Developer Connect 的权限。
  • roles/developerconnect.readTokenAccessor：获取 Developer Connect 读取令牌的权限。
  • roles/logging.logWriter：写入日志的权限。
  • 如果您使用 Developer Connect 部署 Terraform 配置，则需要以下权限： roles/cloudbuild.builds.builder：用于执行 build。
  • 构建流程所需的任何其他权限（例如，对源代码库的访问权限）。

发布策略

SaaS 运行时采用多种发布策略来管理 SaaS 产品中单元的更新方式。这些发布策略遵循 Google Cloud的变更方法，对 SaaS 产品/服务中的变更部署应用一致的方法。

使用发布策略可尽量减少对客户的不利影响，并将问题隔离到各个逻辑和物理故障网域。您可以通过创建指定以下发布策略之一的发布种类来定义发布策略：

  • 一次一个位置（简单）：一次推出一个位置，位置之间没有等待时间。系统会在某个位置内任意选择单元，但每次更新的单元数量最多不会超过该位置单元总数的 20%。

    建议在开发环境和紧急情况下使用此策略。

  • 一次全部（简单）：所有位置同时开始推出。

    建议在开发环境和紧急情况下使用此策略。

  • 渐进式（逐步）：在每个位置，以基于静态百分比的批次（例如 1%、10%、20%、30%、~40%）推出单元，批次之间有浸泡时间。在各个地理位置，发布作业会随着并发地理位置数量呈指数级增长（例如，一个地理位置，然后是两个，再然后是四个）而推进，并且在各波次之间会设置浸泡时间（例如 18 小时）。系统会随机选择某个位置内的单元。

    此策略旨在跨多个位置实现安全且可预测的发布。它首先从小范围开始，然后随着信心的增强而逐步扩大范围。建议在多个位置的生产环境中使用此策略。

  • 渐进式（单位置）：以静态的基于百分比的批次（例如 1%、10%、20%、30%、~40%）更新设备，批次之间有较长的浸泡时间（例如 18 小时），以便有充足的时间来检测问题并限制发布更改带来的不利影响。

    此策略专为在单个位置运行的 SaaS 产品量身定制，优先考虑安全性并确保稳妥。我们建议在一个营业地点的生产环境中使用此策略。

如需详细了解如何创建发布类型，请参阅创建发布类型。

后续步骤