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 运行时部署的安全性和正常运行至关重要。您应始终遵循最小权限原则，仅向每个服务账号授予必要的权限。

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

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

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

  [e-mail]

将

• PROJECT_NUMBER：您的项目编号。

注意： 您可以在 Google Cloud 控制台的信息中心页面上找到您的项目编号。

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

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

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

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

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

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

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

  [e-mail]
  

所需权限

执行服务账号需要具备足够的权限来管理 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 产品量身定制，优先考虑安全性并确保稳妥。我们建议在一个营业地点的生产环境中使用此策略。

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

SaaS 运行时区域化

SaaS 产品资源定义了 SaaS 运行时单元的驻留位置，以及如何管理发布作业。创建 SaaS 产品时，您选择的区域将作为 SaaS 产品支持的区域的单一可信来源。您选择的区域是为 SaaS 产品定义的可用区域。

当您通过 Google Cloud 控制台使用 SaaS 运行时时，SaaS 运行时会自动将您在 SaaS 产品中定义的资源复制到各个区域。这可确保您的 SaaS 运行时资源在 SaaS 产品中定义的所有可用区域中保持一致性和可用性。

注意： 如果您使用 Google Cloud CLI 创建或更新 SaaS Runtime，资源复制不会自动进行。如果您想跨区域同步创建或更新操作，请使用 Google Cloud 控制台。

SaaS 运行时会复制以下资源：

• SaaS 产品 (Saas)
• 单元种类 (UnitKind)
• 版本 (Release)

使用 global 作为区域

对于部署目标，一般不建议将 global 作为 SaaS 产品/服务中的区域。SaaS 运行时使用 global 区域来传播区域发布作业。区域性发布无法在 global 区域中运行。

发布区域化

分阶段发布支持的位置由 SaaS 产品的可用区域中定义的顶级区域决定。

发布会从关联的 SaaS 产品中读取可用区域的列表。

资源复制

SaaS 运行时会处理资源创建和更新，以确保您的 SaaS 产品在所有可用区域中保持最新状态。

更新 SaaS 产品的可用区域时，SaaS 运行时会处理复制：

• 添加的地理位置：资源会复制到新添加的地理位置。
• 有旧副本的营业地点：内容已更新。

Artifact Registry 和 Developer Connect 位置

Artifact Registry 代码库和 Developer Connect 实例的位置有特定要求：

• Artifact Registry 代码库和 Developer Connect 实例的区域可以是任何有效的 Google Cloud 区域。它们无需包含在 SaaS 产品的可用区域中。

• Artifact Registry 代码库的区域必须与 Developer Connect 实例的区域一致。

  这要求在 SaaS 产品中定义的所有区域中都存在 SaaS 产品、版本和单元类型资源，即使 Artifact Registry 和 Developer Connect 位于单个（可能不同的）区域中也是如此。

• 只能在 SaaS 产品中指定的区域内创建单元。

  注意： 单元不会传播到 global 区域。

SaaS 运行时区域配置示例

我们提供了此示例，以演示在使用 SaaS 运行时和受管资源复制时，区域化功能如何运作。

例如，如果您想在 us-central1 和 europe-west4 中部署 SaaS 产品，同时在 us-east1 中托管 Artifact Registry 代码库和 Developer Connect 实例，那么您的 SaaS 运行时区域基础架构将如下所示：

• SaaS 产品可用的区域： ['us-central1', 'europe-west4']
• Artifact Registry 制品库区域：us-east1
• Developer Connect 实例区域：us-east1
• 单元种类和发布资源：SaaS 运行时管理这些资源在 global、us-central1 和 europe-west4 区域中的创建和更新
• 单元：可以在 us-central1 或 europe-west4 中创建单元

此配置可让您跨两个区域管理部署，同时将制品管理集中在第三个不同的区域中，并实现自动化资源复制。选择区域时，您应仔细考虑延迟时间、合规性和数据驻留要求。

后续步骤

• 不妨尝试快速入门，了解如何使用 SaaS 运行时部署虚拟机。
• 如需开始使用 SaaS 运行时，请先创建 SaaS 产品。