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