訂閱自動售貨實作指引

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

圖 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 連線 （OIDC） 向 Azure 進行驗證。

部署後

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

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

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

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

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

下一步

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

• Bicep 模組
• Terraform 模組
• 訂閱自動售貨概觀
• Azure 登陸區域概觀