App Lifecycle Manager (原稱 SaaS Runtime) 可讓您在 Google Cloud儲存、託管、管理及監控軟體即服務 (SaaS) 應用程式。App Lifecycle Manager 可大規模管理 Terraform 部署作業，讓您同時管理 SaaS 應用程式和執行該應用程式的基礎架構。
SaaS 管道中的各種利害關係人，可以透過多種方式使用 App Lifecycle Manager。如果您的工作與下列任何角色相關，或許會想使用 App Lifecycle Manager：
- 平台管理員
- 應用程式開發人員
- 架構師
- 法規遵循管理員
- 平台工程師
- 財務營運
App Lifecycle Manager 具備下列優點：
- 自動執行 SaaS 租戶的服務管理工作 (例如部署、推出和功能旗標管理)，大規模簡化服務管理作業。
- 微調可設定單元的更新和發布作業，擴大觀測能力和控管範圍，精準管理大規模應用程式。
- 管理 Google Cloud、Google Distributed Cloud、Billing、Observability 和 Resource Manager 等各種 Google Cloud 產品的服務，在 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
您可以透過 App Design Center 使用複合式範本，定義 App Lifecycle Manager 應用程式產品的基礎架構。
將複合式範本附加至應用程式產品後，App Lifecycle Manager 會填入範本中定義的單元 kind。這樣一來，您就能根據複合範本中定義的結構和資源部署單位。
您可以在應用程式設計中心編輯複合範本，並在 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.iam.gserviceaccount.com
更改項目：
- PROJECT_NUMBER：您的專案編號。
啟動用服務帳戶 (使用者自行管理)
啟動服務帳戶是您必須建立的使用者自行管理的服務帳戶。App Lifecycle Manager (透過 Infra Manager) 會使用這個服務帳戶執行 Terraform 設定。這個身分會建立、修改及刪除 Terraform 中定義的資源。
您必須在專案或租戶專案中建立這個服務帳戶。
啟動用服務帳戶輸入變數
建立單元時，您必須提供啟動服務帳戶，做為 Terraform 設定的鍵/值組合輸入變數：
- Name (名稱)：
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 資源說明文件，瞭解必要權限。授予應用程式運作所需的最小權限。
Artifact 建立服務帳戶 (使用者自行管理)
構件建立服務帳戶是您建立的使用者自管服務帳戶，用於透過建構系統 (例如 Cloud Build) 封裝 Terraform 構件，並上傳至 Artifact Registry。
這個服務帳戶與 App Lifecycle Manager 和啟動用服務帳戶不同，會建構 Terraform 程式碼，並將產生的構件推送至 Artifact Registry。通常是 Cloud Build 服務帳戶。
手動建立構件
如果您手動建構及上傳 Terraform 構件 (例如直接使用 Docker 建構和 Docker 推送)，則不需要另外的構件建立服務帳戶。
建議您改用自己的憑證或具有必要 Artifact Registry 權限的服務帳戶進行驗證。
所需權限
如果您使用 Cloud Build，Cloud Build 服務帳戶通常需要下列角色：
roles/artifactregistry.writer：將構件推送至 Artifact Registry。roles/artifactregistry.repoAdmin：管理 Artifact Registry 存放區。roles/storage.admin：管理 Cloud Storage bucket。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的變更方法，對應用程式產品的變更部署作業採用一致的方法。
使用推出策略，盡可能減少對客戶的負面影響，並將問題隔離至個別邏輯和實體故障域。建立推出作業 kind，並指定下列其中一種推出作業策略，定義推出作業策略：
一次一個位置 (簡易)：一次推出至一個位置，位置之間無需等待。系統會任意選取某個位置中的單位，並在指定時間更新該位置最多 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中
透過這項設定，您可以在兩個區域管理部署作業，同時將構件管理作業集中在第三個不同的區域，並自動複製資源。選取區域時，請務必仔細考量延遲時間、法規遵循和資料落地需求。