借助 App Lifecycle Manager（以前称为 SaaS 运行时），您可以在 Google Cloud上存储、托管、管理和监控软件即服务 (SaaS) 应用。App Lifecycle Manager 可管理大规模的 Terraform 部署，让您可以同时管理 SaaS 应用和它在运行时所处的基础设施。
SaaS 流水线中的各种利益相关方可以通过多种方式使用 App Lifecycle Manager。如果您的工作属于以下任一角色，您可能会对使用 App Lifecycle Manager 感兴趣：
- 平台管理员
- 应用开发者
- 架构师
- 合规管理员
- 平台工程师
- 财务运营
App Lifecycle Manager 具有以下优势：
- 通过在 SaaS 租户中自动执行服务管理任务（例如部署、发布和功能标志管理），大规模简化服务管理。
- 通过在可配置单元中微调更新和发布，扩大您的可观测性和控制范围，从而大规模精确管理您的应用产品。
- 通过管理各种 Google Cloud 产品（包括 Google Cloud、Google Distributed Cloud、结算、可观测性和 Resource Manager）中的服务，在整个 Google Cloud 生态系统中实现一致性。
- 使用灵活且可模板化的架构，促进基于单元的群组更新和部署，从而提高效率和可重用性。
App Lifecycle Manager 的运作方式是什么？
App Lifecycle Manager 会部署用于定义应用产品的制品。这些制品必须具有 Terraform 配置。部署分为不同的单元，这些单元可以通过发布版本进行更新，发布版本包含通过可配置发布对产品进行的更改。
如需详细了解 App Lifecycle Manager 命名法，请参阅术语表。
为 App Lifecycle Manager 准备工作负载
在部署应用产品之前，我们建议您确定应用产品在 App Lifecycle Manager 生态系统中的理想排列方式。
将应用产品中应一起更新或修改的部分整理到不同的 Terraform 配置中。在规划应用产品时，请为应用产品的每个分组使用单元类型。
在 App Lifecycle Manager 上为工作负载确定理想的结构后，您可以创建应用产品、单元种类，然后使用发布来部署单元。
如需查看 App Lifecycle Manager 的设置示例，请参阅快速入门。
将复合模板与 App Lifecycle Manager 搭配使用
您可以通过 Application Design Center 使用复合模板来定义 App Lifecycle Manager 应用产品的基础设施。
将复合模板附加到应用产品后，App Lifecycle Manager 将填充模板中定义的单元种类。这样，您就可以根据复合模板中定义的结构和资源来部署单元。
您可以在应用设计中心内修改复合模板，并在 App Lifecycle Manager 应用产品中查看所做的更改。
如需详细了解复合模板，请参阅设计复合模板文档。如需详细了解如何将复合模板附加到 App Lifecycle Manager 产品，请参阅模型和软件包部署单元。
App Lifecycle Manager 服务账号
App Lifecycle Manager 结合使用 Google 管理的服务账号和用户管理的服务账号：
App Lifecycle Manager 服务账号（由 Google 管理）：此账号会在创建第一个应用产品资源后自动创建。它由 Google 管理。它会代表您执行操作，例如在单元预配期间与其他 Google Cloud 服务进行交互。
执行服务账号（用户管理）：您创建和管理此服务账号。App Lifecycle Manager（通过 Infrastructure Manager）在预配或更新单元时，会使用此账号来执行您的 Terraform 配置。此账号充当创建和管理 Terraform 中定义的资源的身份。执行服务账号权限与 Terraform 配置管理的资源直接相关。
您可以拥有多个执行服务账号。我们建议您为每个租户创建一个执行服务账号。
可选：制品创建服务账号（用户管理）：此服务账号用于构建和上传打包到 OCI 制品中的 Terraform。这通常是 Cloud Build 服务账号，但也可以是具有应用产品适当权限的任何服务账号。
App Lifecycle Manager 服务账号（由 Google 管理）
App Lifecycle Manager 服务账号是 Google 管理的服务代理，由 App Lifecycle Manager 用于在您的项目中执行操作。
此服务账号会在您创建第一个 App Lifecycle Manager 资源时自动预配。App Lifecycle Manager 服务账号是使用以下格式创建的：
service-PROJECT_NUMBER@gcp-sa-saasservicemgmt.
将
- PROJECT_NUMBER：您的项目编号。
执行启动操作的服务账号（用户管理）
执行服务账号是您必须创建的用户代管式服务账号。App Lifecycle Manager（通过 Infra Manager）使用此服务账号执行您的 Terraform 配置。它是创建、修改和删除 Terraform 中定义的资源的身份。
您负责在项目或租户项目中创建此服务账号。
执行启动操作的服务账号输入变量
创建单元时，您必须提供执行服务账号作为 Terraform 配置的键值对输入变量：
- 名称：
actuation_sa - 变量类型：
String 变量值：执行服务账号电子邮件地址：
my-actuation-sa@my-identifier.
所需权限
执行服务账号需要足够的权限来管理 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。
此服务账号独立于 App Lifecycle Manager 和执行启动操作的服务账号，用于构建 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：用于执行构建。 - 构建流程所需的任何其他权限（例如，对源代码库的访问权限）。
发布策略
App Lifecycle Manager 采用多种发布策略来管理应用产品中单元的更新方式。这些发布策略遵循 Google Cloud的变更方法，在整个应用产品中采用一致的方法来部署变更。
使用发布策略，尽量减少对客户的不利影响，并将问题隔离到各个逻辑和物理故障域。通过创建发布种类来定义发布策略，并指定以下发布策略之一：
一次一个位置（简单）：一次更新一个位置，位置之间无需等待。系统会在一个位置内任意选择单元，在给定时间最多更新该位置 5% 的单元。
建议在开发环境和紧急场景中使用此策略。
一次全部（简单）：所有位置同时开始更新。
建议在开发环境和紧急情况下使用此策略。
渐进式（逐步）：在每个位置，单元会按基于百分比的静态批次（例如 1%、10%、20%、30%、~40%）进行更新，批次之间有过渡时间。在不同位置，推出会以指数级增加并发位置数量（例如，一个位置，然后是两个，然后是四个），并在各波次之间设置过渡时间（例如 18 小时）。系统会随机选择某个位置内的单元。
此策略旨在跨多个位置实现安全且可预测的发布。它首先从小范围开始，然后随着信心的增强而逐步扩大范围。建议在多个位置的生产环境中使用此策略。
渐进式（单个位置）：单元按基于百分比的静态批次（例如 1%、10%、20%、30%、~40%）进行更新，批次之间的过渡时间较长（例如 18 小时），以便有充足的时间检测问题并限制发布更改的不利影响。
此策略专为在单个位置运营的应用产品量身定制，优先考虑安全性和谨慎性。我们建议在具有一个位置的生产环境中使用此策略。
如需详细了解如何创建发布种类，请参阅创建发布种类。
App Lifecycle Manager 区域化
应用产品资源定义了 App Lifecycle Manager 单元可以驻留的位置以及发布版本的管理方式。创建应用优惠时，您选择的区域将作为应用优惠支持的国家/区域的单一事实来源。您选择的区域是您为应用产品定义的可用区域。
通过 Google Cloud 控制台使用 App Lifecycle Manager 时，App Lifecycle Manager 会自动在各个区域中复制您在应用产品中定义的资源。这可确保 App Lifecycle Manager 资源在您在应用产品中定义的所有可用区域中的一致性和可用性。
App Lifecycle Manager 会复制以下资源：
- 应用产品 (
Saas) - 单位种类 (
UnitKind) - 版本 (
Release)
使用 global 作为区域
通常不建议将 global 作为应用产品中的区域纳入部署目标。App Lifecycle Manager 使用 global 区域来传播区域级发布。区域级发布无法在 global 区域中运行。
发布地区化
支持发布的地点由应用产品/服务可用区域中定义的顶级区域决定。
发布作业会从关联的应用产品中读取可用区域列表。
资源复制
App Lifecycle Manager 会处理应用产品的所有可用区域中的资源创建和更新。
当您更新应用产品/服务的可用区域时，App Lifecycle Manager 会处理复制：
- 添加的位置：资源会复制到新添加的位置。
- 包含旧副本的位置：内容会更新。
Artifact Registry 和 Developer Connect 位置
Artifact Registry 代码库和 Developer Connect 实例的位置有特定要求：
Artifact Registry 代码库和 Developer Connect 实例的区域可以是任何有效的 Google Cloud 区域。这些地区无需包含在应用产品的可用区域中。
Artifact Registry 代码库的区域必须与 Developer Connect 实例的区域一致。
这就要求在应用产品中定义的所有区域中都存在应用产品、发布和单元类型资源，即使 Artifact Registry 和 Developer Connect 位于单个（可能不同）区域中也是如此。
只能在应用产品中指定的区域内创建单元。
App Lifecycle Manager 区域配置示例
我们提供了此示例，以演示在使用 App Lifecycle Manager 和代管式资源复制时，区域化如何运作。
例如，如果您想在us-central1和europe-west4部署应用产品，同时在us-east1托管 Artifact Registry 代码库和 Developer Connect 实例，则 App Lifecycle Manager 区域基础设施将如下所示：
- 应用提供情况 - 适用区域：
['us-central1', 'europe-west4'] - Artifact Registry 代码库区域：
us-east1 - Developer Connect 实例区域：
us-east1 - 单元种类和版本资源：App Lifecycle Manager 负责管理
global、us-central1和europe-west4区域中这些资源的创建和更新 - 单位：可以在
us-central1或europe-west4中创建单位
通过此配置，您可以管理跨两个区域的部署，同时通过自动资源复制，将制品管理集中在第三个不同的区域。在选择区域时，您应仔细考虑延迟时间、合规性和数据驻留要求。