App Lifecycle Manager 總覽

預覽

這項產品或功能適用《服務專屬條款》中「一般服務條款」一節的《正式發布前產品條款》。正式發布前的產品和功能是按照「原樣」提供，支援範圍可能有限。 詳情請參閱推出階段說明。

您可以使用 App Lifecycle Manager，在 Google Cloud儲存、託管、管理及監控軟體即服務 (SaaS) 應用程式。App Lifecycle Manager 可大規模管理 Terraform 部署作業，讓您同時管理 SaaS 應用程式和執行該應用程式的基礎架構。

SaaS 管道中的各種利害關係人，都能以多種方式使用 App Lifecycle Manager。如果您的工作與下列任何角色相關，或許可以考慮使用 App Lifecycle Manager：

• 平台管理員
• 應用程式開發人員
• 架構師
• 法規遵循管理員
• 平台工程師
• 財務營運

App Lifecycle Manager 提供下列優點：

• 自動化處理 SaaS 租戶的服務管理工作 (例如部署、推出和功能旗標管理)，簡化大規模服務管理作業。
• 您可以針對可設定的單元微調更新和發布內容，精確管理大規模的 SaaS 產品，進一步擴展觀測能力和控制範圍。
• 管理各種 Google Cloud 產品 (包括 Google CloudGoogle Distributed Cloud、帳單、可觀測性和 Resource Manager) 的服務，在整個 Google Cloud 生態系統中建立一致性。
• 使用彈性且可套用範本的架構，以單元為基礎更新及部署群組，提高效率和重複使用性。

App Lifecycle Manager 的運作方式

App Lifecycle Manager 會部署定義 SaaS 產品的構件。這些構件必須具有 Terraform 設定。部署作業會劃分為不同的單元，您可以透過可設定的推出作業程序，使用包含產品變更的發布版本更新這些單元。

如要進一步瞭解 App Lifecycle Manager 命名慣例，請參閱詞彙表。

準備工作負載以使用 App Lifecycle Manager

部署 SaaS 產品前，建議您先決定在 App Lifecycle Manager 生態系統中，SaaS 產品的最佳配置方式。

將應一併更新或修改的 SaaS 產品部分，整理成不同的 Terraform 設定。規劃 SaaS 服務時，請為每個 SaaS 服務群組使用單元 kind。

在 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 設定管理的資源直接相關。

  您可以擁有多個啟動用服務帳戶。建議您為每個租戶設定一個啟動服務帳戶。

• 選用：構件建立服務帳戶 (使用者自行管理)：這個服務帳戶用於建構 Terraform，並將其上傳至 OCI 構件。這通常是 Cloud Build 服務帳戶，但也可以是任何具備 SaaS 產品適當權限的服務帳戶。

注意： 請務必謹慎管理這些服務帳戶，確保 App Lifecycle Manager 部署作業的安全性和正常運作。您應一律遵循最小權限原則，只授予各個服務帳戶必要的權限。

App Lifecycle Manager 服務帳戶 (Google 代管)

App Lifecycle Manager 服務帳戶是 Google 管理的服務代理程式，App Lifecycle Manager 會使用這個帳戶在專案中執行作業。

建立第一個 App Lifecycle Manager 資源時，系統會自動佈建這個服務帳戶。App Lifecycle Manager 服務帳戶是使用以下格式建立：

  [e-mail]

更改項目：

• PROJECT_NUMBER：您的專案編號。

注意： 您可以在 Google Cloud 控制台的資訊主頁找到專案編號。

啟動用服務帳戶 (使用者自行管理)

啟動服務帳戶是使用者自行管理的服務帳戶，您必須建立這個帳戶。App Lifecycle Manager (透過 Infra Manager) 會使用這個服務帳戶執行 Terraform 設定。這個身分會建立、修改及刪除 Terraform 中定義的資源。

您必須在專案或租戶專案中建立這個服務帳戶。

啟動用服務帳戶輸入變數

建立單元時，您必須提供啟動服務帳戶，做為 Terraform 設定的鍵值配對輸入變數：

• Name (名稱)：actuation_sa
• 「Variable type」(變數類型)：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。

這個服務帳戶與 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 採用多種推出策略，管理 SaaS 產品中的單元更新方式。這些推出策略遵循 Google Cloud的變更方法，在整個 SaaS 產品中，以一致的方式部署變更。

使用推出策略，盡量減少對客戶的負面影響，並將問題隔離到個別邏輯和實體故障網域。建立推出作業 kind，並指定下列其中一種推出作業策略，即可定義推出作業策略：

• 一次推出至一個位置 (簡易)：一次推出至一個位置，位置之間沒有等待時間。系統會隨機選取位置內的裝置，且一次最多更新 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 產品中定義的資源複製到各個地區。這可確保您在 SaaS 產品中定義的所有可用區域，都能保持 App Lifecycle Manager 資源的一致性和可用性。

注意： 如果您使用 Google Cloud CLI 建立或更新 App Lifecycle Manager，資源複製作業不會自動執行。如要跨區域同步建立或更新作業，請使用 Google Cloud 控制台。

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 執行個體的區域相符。

  因此，即使 Artifact Registry 和 Developer Connect 位於單一 (可能不同的) 區域，您也必須在 SaaS 服務中定義的所有區域，提供 SaaS 服務、版本和單元 kind 資源。

• 單元只能在 SaaS 產品中指定的區域建立。

  注意： 單元不會傳播至 global 區域。

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 中建立

透過這項設定，您可以在兩個區域管理部署作業，同時將構件管理作業集中在第三個不同的區域，並自動複製資源。選擇區域時，請仔細考量延遲時間、法規遵循和資料落地要求。

後續步驟

• 請參閱快速入門導覽課程，瞭解如何使用 App Lifecycle Manager 部署 VM。
• 如要開始使用 App Lifecycle Manager，請先建立 SaaS 產品。