訂閱自動售貨實作指引

本文提供 訂閱自動販賣 自動化的實作指引。 訂用帳戶銷售會將要求、部署及控管訂用帳戶的程式標準化，讓應用程式小組可以更快速地部署其工作負載。

圖 1.範例 Azure 環境中的 訂閱自動販賣 實作。

我們已建立 訂閱自動販賣 Bicep 和 Terraform 模組，您應該用來作為起點。 您應該修改範本以符合您的實作需求。 如需 訂閱自動販賣 程式的詳細資訊，請參閱訂閱自動售貨概觀。

架構

您應該建構 訂閱自動販賣 自動化，以完成三個主要工作。 訂用帳戶自動銷售應該 （1） 收集訂用帳戶要求數據、（2） 起始平臺自動化，以及 （3） 使用基礎結構即程式代碼建立訂用帳戶。 有數種方法可用來實作 訂閱自動販賣 自動化，以完成這三項工作。 範例實作 （圖 2） 顯示一個使用 Gitflow 的方法。 Gitflow 設計符合許多平臺小組用來管理平臺的宣告式方法。

圖 2.訂閱自動販賣 自動化的範例實作。

在範例實作中（圖 2）， 數據收集工具 會收集訂用帳戶要求數據。 當訂閱要求收到核准時，它會起始平台自動化。 平臺 自動化 包含要求管線、原始檔控制和部署管線。 要求 管線 會使用數據收集工具中的數據，建立 JSON 或 YAML 訂用帳戶參數檔案。 要求管線也會建立新的分支、認可訂用帳戶參數檔案，並在原始檔控制中開啟提取要求。 新的分支會與原始檔控制中的main分支合併。 合併會 觸發部署管線 ，以使用基礎結構即程式代碼模組建立訂用帳戶。

部署應該根據治理需求將訂用帳戶放在正確的管理群組中（請參閱圖 1）。 部署會建立初步訂用帳戶預算作為成本管理的基礎。 根據工作負載的需求，部署可能會建立空的虛擬網路，並設定對等互連至區域中樞。 平臺小組應該在建立和設定之後，將訂用帳戶交給應用程式小組。 應用程式小組應更新訂用帳戶預算，並建立工作負載資源。

收集資料

收集數據的目標是要接收商務核准，並定義 JSON/YAML 訂用帳戶參數檔案的值。 當應用程式小組提交訂閱要求時，您應該使用資料收集工具來收集必要的數據。 數據收集工具應該與 訂閱自動販賣 工作流程中的其他系統介面，以起始平台自動化。

使用資料收集工具。 您可以使用 IT 服務管理 （ITSM） 工具來收集數據，或使用低程式碼或無程式碼工具來建置客戶入口網站，例如 Microsoft PowerApps。 數據收集工具應該提供商業規則來核准或拒絕訂用帳戶要求。

收集必要的數據。 您需要收集足夠的數據，以定義 JSON/YAML 訂用帳戶參數的值，以便您將部署自動化。 您收集的特定值取決於您的需求。 您應該擷取要求授權者、成本中心和網路需求（因特網或內部部署連線能力）。 詢問應用程式小組是否有預期的工作負載元件（應用程式平臺、數據需求）、數據敏感度，以及環境數目（開發、測試、生產前、生產環境）可能很有説明。

驗證數據。 您應該在資料收集程式期間驗證數據。 稍後在平臺自動化階段中更難解決問題。

建立可追蹤的要求。 數據收集工具應該為新的訂用帳戶建立記錄且可追蹤的要求（例如ITSM工具中的票證）。 要求應包含所有必要的數據，以符合該訂用帳戶的需求。 您應該將商業規則和授權追蹤系結至要求。

與其他內部系統的介面。 必要時，數據收集工具應該會與組織中的其他工具或系統互動。 目標是使用來自其他系統的數據來擴充要求。 您可能需要身分識別、財務、安全性和網路數據來執行自動化。 例如，自動化可以與IP位址管理 （IPAM） 工具進行介面，以保留正確的IP位址空間。

建立觸發程式。 當訂閱要求收到核准時，數據傳輸應該會觸發平臺自動化。 最好使用數據收集工具的必要數據來建立推播通知。 您可能需要中間件層，例如 Azure Functions 或 Azure Logic Apps 來起始程式。

起始平台自動化

數據收集工具的通知和數據應該觸發平臺自動化。 平臺自動化的目標是建立 JSON/YAML 訂用帳戶參數檔案、將檔案合併至主要分支，並使用基礎結構即程式代碼模組加以部署，以建立訂用帳戶。 平臺小組應該擁有和維護平臺自動化。 範例實作中的平臺自動化包含要求管線、原始檔控制和部署管線（請參閱圖 2）。

使用 JSON 或 YAML 檔案。 您應該使用結構化資料檔 （JSON 或 YAML） 來儲存資料以建立訂用帳戶。 您應該記錄檔案的結構，並使它可擴充以支持未來的需求。 例如，下列 JSON 代碼段會定義 GitHub 中其中一個 Bicep 模組的訂用帳戶參數值。

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "subscriptionDisplayName": {
      "value": "sub-bicep-lz-vending-example-001"
    },
    "subscriptionAliasName": {
      "value": "sub-bicep-lz-vending-example-001"
    },
    "subscriptionBillingScope": {
      "value": "providers/Microsoft.Billing/billingAccounts/1234567/enrollmentAccounts/123456"
    },
    // Insert more parameters here
  }
}

請參閱整個檔案。 如需更多範例，請參閱 Bicep 範例 和 Terraform 範例

每個訂用帳戶要求使用一個檔案。 訂用帳戶是 訂閱自動販賣 程式中的部署單位，因此每個訂用帳戶要求都應該有一個專用的訂用帳戶參數檔案。

使用提取要求系統。 建立訂用帳戶參數檔案的 Gitflow 程式應該自動化下列步驟：

1. 為每個訂用帳戶要求建立新的分支。
2. 使用收集的數據，為分支中的新訂用帳戶建立單一 YAML/JSON 訂用帳戶參數檔案。
3. 從您的分支建立提取要求到 main。
4. 使用狀態變更和此提取要求的參考來更新數據收集工具。

範例 實作中的要求管線 會執行這些步驟（請參閱圖 2）。 如果工作流程很複雜，您也可以使用裝載在 Azure 中的程式代碼型解決方案。

驗證訂用帳戶參數檔案。 提取要求應該觸發linting程式來驗證要求數據。 目標是確保部署成功。 它應該驗證 YAML/JSON 訂用帳戶參數檔案。 它也可以確認IP位址範圍仍然可用。 您也可以使用人為介入來新增手動檢閱閘道。 他們可以執行最終檢閱，並變更訂用帳戶參數檔案。 輸出應該是 JSON/YAML 訂用帳戶參數檔案，其中包含要建立訂用帳戶的所有數據。

觸發部署管線。 當提取要求合併至 main 分支時，合併應該會觸發部署管線。

建立訂用帳戶

訂閱自動販賣 自動化的最後一項工作是建立和設定新的訂用帳戶。 此範例實作會 使用部署管線 ，使用 JSON/YAML 訂用帳戶參數檔案來部署基礎結構即程式代碼模組（請參閱圖 2）。

使用基礎結構即程序代碼。 您的部署應該使用基礎結構即程式代碼來建立訂用帳戶。 平臺小組應建立和維護這些範本，以確保適當的控管。 您應該使用 訂閱自動販賣 Bicep 和 Terraform 模組，並加以修改以符合您的實作需求。

使用部署管線。 部署管線會協調新訂用帳戶的建立和設定。 管線應該執行下列工作：

您需要商業合約，才能以程序設計方式建立訂用帳戶。 如果您沒有商業合約，則需要引進手動程式來建立訂用帳戶，但仍可將訂用帳戶設定的所有其他層面自動化。

建立工作負載身分識別。 部署管線需要許可權，才能使用它介面的所有系統來執行這些作業。 您應該使用受控識別或 OpenID Connect （OIDC） 向 Azure 進行驗證。

部署後

訂閱自動販賣 自動化會以訂用帳戶建立和設定結束。 平臺小組應該在建立之後，將新的訂用帳戶交給應用程式小組。 應用程式小組應更新訂用帳戶預算、建立工作負載資源，以及部署工作負載。 平臺小組會控制訂用帳戶的控管，並隨著時間管理訂用帳戶治理的變更。

強制執行成本管理。 訂用帳戶預算會提供對成本管理至關重要的通知。 部署應該根據訂用帳戶要求數據建立初步訂用帳戶預算。 應用程式小組會收到訂用帳戶。 他們應該更新預算，以符合工作負載的需求。 如需詳細資訊，請參閱

• 建立及管理預算
• 使用 Azure 預算來管理成本
• 成本配置
• 追蹤跨業務部門、環境或專案的成本

管理訂用帳戶治理。 您應該在工作負載的治理需求變更時更新訂用帳戶。 例如，您可能需要將訂用帳戶移至不同的管理群組。 您應該為其中一些例行作業建置自動化。 如需詳細資訊，請參閱

• 移動管理群組和訂用帳戶
• 讓原則和原則計劃保持在最新狀態
• 資源標記
• 量身打造 Azure 登陸區域架構以符合需求

下一步

訂用帳戶自動販賣可簡化和標準化訂閱建立程式，並將其置於組織的治理之下。 您應該實作 訂閱自動販賣 自動化，以協助應用程式小組更快存取應用程式登陸區域，並更快速地將工作負載上線。 如需詳細資訊，請參閱

• Bicep 模組
• Terraform 模組
• 訂閱自動售貨概觀
• 建立常見的 訂閱自動販賣產品線
• Azure 登陸區域概觀