共用方式為

Azure 上的 Red Hat Enterprise Linux 平臺自動化考慮

  • 發行項

本文說明如何在 Azure 上管理 Red Hat Enterprise Linux （RHEL） 的自動化。 其描述 Azure 生態系統中各種工具的設計考慮、設計建議和選項，可用來達成一致且穩定的環境。 本文提供與各種客戶案例、商務需求、營運實務和技術成熟度一致的指引。

概觀

當您將 Azure 登陸區域的 RHEL 自動化時，您會使用 Red Hat 基礎結構標準 （RH-IS） 和相關聯的 Red Hat 基礎結構標準採用模型 （RH-ISAM） 來配合 Azure 登陸區域生命週期管理。 將系統標準化，為解決方案提供可靠的基礎。 RH-IS 定義標準作業環境，其中包含一組預設的軟體元件和組態。 您可以透過 RH-ISAM、一組 DevOps 或 Git 作業原則、Azure Resource Manager 範本（ARM 範本）、Terraform、Azure CLI 和 Azure PowerShell，將這些元件和組態套用至系統。

您可以將各種作業自動化。 例如，您可以使用自動化來：

  • 布建元件。
  • 管理系統。
  • 執行平臺演進。
  • 納入基礎結構作業。
  • 設定應用程式和工作負載生命週期。

您可以透過基礎結構即程序代碼 （IaC） 實作這些作業，並以程式代碼的形式進行設定。 若要減少錯誤並增加可靠性，請定義及測試組態。 若要加速大規模移轉，請自動布建。 自動化設定可減少設定漂移，並確保系統正常運作。

設計考量

Red Hat Identity Management （IdM） 提供集中式且統一的平臺，可讓您用來管理 RHEL 系統的身分識別存放區、驗證原則和授權原則。 在混合式案例中，您可以跨虛擬專用網或 Azure ExpressRoute 擴充現有的 Red Hat IdM 基礎結構。 此設定會將內部部署環境與 Azure 內的 RHEL 登陸區域連線。 若要支援混合式雲端身分識別案例，請將內部部署環境延伸至 Azure，讓您可以將工作負載與 Microsoft Entra 整合。 如需詳細資訊，請參閱 Microsoft Entra 驗證。

作為替代身分識別管理解決方案，您可以加入 RHEL，以使用 Windows Server Active Directory 建立外部信任，或直接加入現有的 Windows Server Active Directory 樹系。 如需詳細資訊，請參閱 直接整合 RHEL 系統與 Windows Server Active Directory。

Red Hat Satellite 是傳遞至受控 RHEL 系統之內容的單一來源。 Satellite 包含 Red Hat 套件和修補程式，以及應用程式開發小組開發的非Microsoft套件和自定義套件。 衛星可作為 Red Hat Insights 的閘道，其提供設定的預測性分析，以辨識安全性或效能風險。 如果您部署預先設定的 RHEL 隨用隨付映像，您可以利用 適用於 Azure 的 Red Hat Update Infrastructure，這是內建於隨用隨付映像中的更新工具。

Red Hat Ansible Automation Platform 設計考慮

Red Hat Ansible Automation Platform （AAP） 可協助標準化技術工作流程和週期性工作。 您可以使用 AAP 來協調工作流程、為新系統布建程式，以及建立週期性作業工作。 若要降低複雜性，請使用一個常見的自動化平台和語言。 完全自動化的工作流程可加速應用程式創新，並簡化跨內部部署環境和雲端環境的大規模工作負載移轉。

RHEL 作為平台自動化策略的優點包括：

  • 新系統大規模完全自動化布建，可提升大規模移轉速度。

  • 在實體系統和虛擬系統之間，已測試系統的組態和應用程式安裝更加統一。

  • 持續更新，因為修補程式管理立即可供使用。

  • 標準化和簡化的平臺，可提供新的應用程式和工作負載。 員工有額外的時間來提供更高的創新。

您可以實作：

  • 透過內部部署基礎結構、雲端基礎結構或兩者進行自我管理的 AAP 實例。 您可以使用 RHEL 部署或 Red Hat OpenShift 容器平臺部署。

  • 公用雲端中的自我管理 AAP 實例。

  • 公用雲端中的受控 AAP 實例。

自我管理的 Red Hat AAP 內部部署或雲端

在 Microsoft內部部署、雲端或混合式基礎結構中，以自我管理模式在 Azure 上部署 Red Hat AAP，以取得下列優點：

  • 架構和規模：決定支援自動化平臺的理想架構。 您可以根據 RHEL 基礎結構或 OpenShift 操作員部署來建置架構。 根據您的車隊大小和需求，選擇控制器、執行節點和私人自動化中樞實例的數目和實例大小。 如需架構、設計、設定和調整的詳細資訊，請參閱 Red Hat AAP 規劃指南。

  • Azure 組態：優化組織的 Azure 設計和設定的自動化架構。

  • 自動化網格支援：使用 AAP 自動化網狀結構功能，將自動化工作負載分散到使用現有網路建立對等連線的混合式雲端節點。 根據安全性設計準則和網路拓撲，將躍點節點放在位置。

  • 自動化中樞架構：優化自動化中樞架構，以調整和放置私人自動化中樞實例。 優化組態，以增強安全自動化內容傳遞，以及存取與自動化執行資源相近的執行環境來源。 您可以選擇哪些 Ansible 內容集合和自動化取用者可以存取的版本。

Azure 上的受控或自我管理 Red Hat AAP

Microsoft Azure 上的 Red Hat AAP 可透過受控應用程式或自我管理應用程式取得，其提供下列優點：

  • 由於使用方便，投資快速回報（ROI：您可以直接從 Azure Marketplace 在 Azure 上部署 AAP。 此受控解決方案會在部署后立即處於作用中狀態，而且您可以在幾分鐘內開始自動管理 Azure 資源。 Red Hat 會管理基礎結構，因此您可以自由考慮對企業至關重要的其他系統。

  • 簡化整合：Azure 上的 AAP 與 Azure 服務整合。 Microsoft和 Red Hat 開發安全性，並測試了適用於 Azure 的 Ansible 集合，因此您需要最少的設定，並且獲得最大支援。 使用 Azure 上的 AAP 作為混合式雲端自動化策略的一部分，以整合混合式雲端、物聯網和邊緣部署之間的管理和自動化。

  • 現有的已認可 Azure 支出：您可以使用現有的認可支出搭配Microsoft在 Azure 上購買 Red Hat AAP。 使用認可的費用，讓整個組織的小組可以順暢地部署、設定及自動化元件。 整合式計費表示您可以取得一筆帳單，並完整查看成本。

  • 雲端以外的自動化：在 Azure 上使用 AAP，您可以在 azure 雲端Microsoft部署應用程式，然後跨基礎結構加以擴充。 跨 Azure 和混合式雲端環境部署、執行及調整應用程式。

  • 支援：Red Hat 和 Microsoft合作在 Azure 上建置 AAP，以確保一致且以安全性為主的作業。 Red Hat 會管理、服務及支援應用程式，讓您的 IT 小組能夠專注於提供自動化策略。

受控模式的其他考慮

您可以在 Azure 上以受控模式安裝 AAP，讓它成為受控應用程式。 Red Hat 會同時管理基礎 Azure 資源和其上執行的軟體。 該基礎結構會在您的 Azure 租用戶中執行。

受控應用程式資源群組與租使用者中的其他資源群組不同。 Red Hat 只能存取受控應用程式資源群組，無法查看其他租用戶資源。

如需詳細資訊，請參閱 Azure 受控應用程式概觀。

受控模式中的 Azure 上的 AAP 會使用下列資源群組：

  • 租使用者中的新或現有資源群組。 此資源群組包含單一資源，該資源是指 Azure 受控應用程式部署上的 AAP。 Red Hat 可以存取受控應用程式，以執行支援、維護和升級。 但 Red Hat 不會管理資源群組。

  • 多租使用者受控資源群組 （MRG） ，其中包含在 Azure 上操作 AAP 所需的大部分基礎結構。 Red Hat 租使用者和您的租用戶會共用此多租用戶資源群組。 Red Hat 具有完整的系統管理控制權。 您有資源群組的唯讀存取權。

  • Azure Kubernetes Service （AKS） 節點集區資源群組 （NPRG） 。 Microsoft需要 AKS 部署的 NPRG。 NPRG 包含 AKS 用來運作的資源。 此資源群組會在部署時建立。 Red Hat 不會管理此資源群組。 如需詳細資訊，請參閱 Microsoft AKS 檔。

針對受控模式中的 Azure 上的 AAP，也請考慮下列因素：

  • 當您在 Azure 上安裝 AAP 時，您可以選擇部署是公用還是私人，這會影響使用者存取 AAP 使用者介面的方式。

  • 無論您選擇公用或私人部署，都必須設定網路對等互連，以將來自 AAP 的輸出通訊設定為包含您想要自動化之資源的專用網。 您可以將網路對等互連從 Azure 上的 AAP 設定為私人 Azure 虛擬網路，以及使用 Azure 進行傳輸路由的內部部署網路或多雲端網路。

自我管理模式的其他考慮

自我管理模式中的 Azure 上的 AAP 提供許多與受控 AAP 相同的優點。 但是，在AKS叢集內執行受控模式時，自我管理模式自動化平台資源是以虛擬機 （VM） 為基礎。

針對以自我管理模式在 Azure 上的 AAP，請考慮下列因素：

  • Event-Driven Ansible 包含在 Azure 上的自我管理供應專案中。 事件驅動自動化可協助您減少手動工作，並提供專注於創新的有效IT環境。 Event-Driven Ansible 會處理事件、判斷適當的回應，然後執行自動化動作來補救事件。

  • 訂用帳戶以100個作用中的受控節點增量提供。 它們可在公開供應專案或私人供應專案中取得。

  • 以自我管理模式支撐 Azure 上 AAP 的 VM 資源，可以完全由 Azure Marketplace 映射或混合的 Azure Marketplace 映像和客戶管理的映射所組成。

設計建議

當您為 Azure 登陸區域操作 RHEL 平臺時，請使用 Red Hat 認證的內容和來自 Red Hat 自動化中樞的已驗證內容集合。 下列集合在自動化架構中具有突出的角色：

  • redhat.rhel_idm

    • 設定IdM主要VM。
    • 設定IdM複本。
    • 整合及設定 RHEL 用戶端與 IdM。

  • redhat.satellite、 redhat.satellite_operations 和 redhat.rhel_system_roles

    • 部署衛星和膠囊。
    • 建立及設定 Satellite 對象和設定。
    • 布建及設定 RHEL 系統。

  • ansible.*、 ansible.controller 和 infra.controller_configuration

    • 設定 AAP。
    • 建立及設定 AAP 作業範本和設定。

適用於 Azure 的 Ansible 集合包含超過 250 個模組，可用來詢問、管理及自動化 Azure 資源類型，例如：

  • AKS。
  • 應用程式安全性群組。
  • Azure Container Registry。
  • Azure 資料庫服務。
  • Azure Key Vault。
  • Azure SQL Database。
  • Azure 虛擬機器。
  • Microsoft Entra ID.
  • 網路功能。
  • 儲存空間。

核心平臺基礎結構部署

建立概念和程式，以有效地部署核心平臺基礎結構，並支援 Azure 登陸區域模型的 RHEL 平臺。

如需詳細資訊，請參閱

  • 適用於平臺自動化考慮的 Azure 登陸區域設計指引。

  • 開發生命週期。 探索使用自動化來建立登陸區域的重要設計考慮和建議。 本指南討論存放庫、分支、自動化組建、部署和復原策略。

  • IaC. 探索透過 IaC 實作 Azure 登陸區域的優點。 瞭解程式代碼結構、工具和技術的相關考慮。

  • 環境。 瞭解如何使用多個環境，以更高的速度和頻率建置、測試和發行程序代碼。 這種方法可讓部署盡可能簡單。

  • 測試驅動開發。 瞭解如何使用單元測試來改善新功能的品質，並改善 Azure 登陸區域程式代碼基底。

當您具備必要的原始程式碼管理工具，以及從前幾節建立的原始程式碼管理程式時，您可以實作自動化。 使用隨附的 IaC 或設定程式代碼來開發 Ansible 自動化程式代碼，以部署核心基礎結構並支援適用於 Azure 登陸區域模型的 RHEL 平臺。 針對綠地部署，您可以自動化下列工作以進行完整的環境實作。 針對棕色地帶部署，您只能將使用案例所需的工作自動化。

  • 建立 Azure 資源群組。
  • 建立虛擬網路。
  • 建立子網。
  • 建立網路安全性群組。
  • 透過自動化的 Red Hat 映射產生器，為 Azure 建立 RHEL 8.x 和 9.x 黃金映射。
  • 建立IdM主要 VM（附屬布建前）。 透過設定作為程式代碼設定IdM主要VM。
  • 建立附屬 VM（附屬布建前）。 將 Satellite 設定為程式代碼。
  • 建立膠囊 VM（衛星布建）。 透過組態將 Capsule 設定為程式代碼。
  • 建立IdM複本 VM（附屬布建）。 透過設定作為程式代碼設定IdM複本。
  • 建立 AAP 基礎結構 （衛星布建），包括：
    • 自動化控制器 VM。
    • 執行節點 VM。
    • 躍點節點 VM （選擇性）。
    • 自動化中樞 VM。
    • 事件驅動 Ansible VM（如果已啟用）。
    • 適用於 PostgreSQL 的 Azure 資料庫 伺服器和控制器、中樞和事件驅動 Ansible 元件的必要資料庫。 高可用性或災害復原 適用於 PostgreSQL 的 Azure 資料庫 設定需要透過複寫傳送、記錄傳送或 Crunchy Postgres 的額外自動化。
  • 建立負載平衡器（應用程式閘道）。
    • Capsule VM 的前端
    • AAP 控制器 VM 的前端
    • 自動化中樞 VM 的前端
  • 建立應用程式安全組。
    • IdM 基礎結構
    • AAP 基礎結構
    • 衛星或膠囊基礎結構

RHEL 系統生命週期管理

核心平臺基礎結構就緒之後，您可以實作 RHEL 應用程式和工作負載生命週期的自動化。 下列工作流程說明開發生命週期管線的自動化實作範例：

  1. 更新 errata 篩選結束日期，並在 Satellite 中發布內容。

  2. 將內容檢視 （CV） 和複合內容檢視 （CCV） 提升為開發。

  3. 從衛星主機群組部署 RHEL 開發測試系統。 RHEL 8.x 和 9.x 黃金映射可透過自動化的 Red Hat 映射產生器，在 Satellite 中定義為 Azure 計算資源。

  4. 根據應用程式通訊路徑更新或建立 Azure 網路安全組。

  5. 更新或建立 Azure 應用程式安全組，為多層式應用程式堆疊提供額外的分層安全性。

  6. 更新 RHEL 開發系統，並從衛星開發 CV 或 CCV 部署和設定所需的應用程式。

    • 部署至簡單應用程式堆疊的單一 RHEL 實例。
    • 部署到多層式應用程式堆疊的數個 RHEL 實例。
    • 設定應用程式堆疊。

  7. 執行應用程式測試架構。

    • 如果測試失敗，請通知 OnCall 自動化管理以協助進行疑難解答和分析。 結束自動化工作流程。 RHEL 測試系統仍會部署以進行驗屍失敗分析。
    • 如果測試成功，請繼續進行步驟。

  8. 將 CSV 和 CCV 提升到質量保證（QA）。

  9. 終結 RHEL 開發測試系統。

生命週期管線中的後續階段與開發生命週期階段稍有不同。 只有開發階段會使用初始內容發佈和初始 CV 和 CCV 升級進行開發。 下列範例說明非開發生命週期管線的自動化工作流程，例如QA、生產前和生產管線。

  1. 從附屬主機群組部署 RHEL QA 測試系統。 RHEL 8.x 和 9.x 黃金映射可透過自動化的 Red Hat 映射產生器，在 Satellite 中定義為 Azure 計算資源。

  2. 根據應用程式通訊路徑更新或建立 Azure 網路安全組。

  3. 更新或建立 Azure 應用程式安全組，為多層式應用程式堆疊提供額外的分層安全性。

  4. 更新 RHEL QA 系統，並從衛星 QA 中的 CV 或 CCV 部署和設定所需的應用程式。

    • 部署至簡單應用程式堆疊的單一 RHEL 實例。
    • 部署到多層式應用程式堆疊的數個 RHEL 實例。
    • 設定應用程式堆疊。

  5. 執行應用程式測試架構。

    • 如果測試失敗，請通知 OnCall 自動化管理以協助進行疑難解答和分析。 結束自動化工作流程。 RHEL 測試系統仍會部署以進行驗屍失敗分析。
    • 如果測試成功，請繼續進行步驟。

  6. 將 CSV 和 CCV 升階至生產環境。

  7. 終結 RHEL QA 測試系統。

Azure 原生工具的其他設計考慮

Azure 自動化

若要將頻繁、耗時且容易出錯的管理工作自動化，您可以使用 Azure 自動化 中的程式自動化功能。 此功能可協助您專注於增加商業價值的工作。 程式自動化可減少錯誤並提升效率，這有助於降低營運成本。 如需詳細資訊，請參閱 自動化概觀。

程式自動化支援整合 Azure 服務和其他合作夥伴系統，例如 Red Hat，您需要部署、設定和管理端對端程式。 您也可以使用這項功能來撰寫圖形化 PowerShell 和 Python Runbook。

您可以針對各種自動化工作使用 Runbook，例如管理資源、啟動和停止 VM，以及處理 Azure 內外的維護工作。 如需詳細資訊，請參閱 Azure 自動化 中的 Azure 自動化 帳戶驗證概觀和 Runbook。

下表描述支援的 Runbook 類型。

Runbook 類型 描述
PowerShell 以 Windows PowerShell 腳本為基礎的文字 Runbook。 支援的版本包括 PowerShell 7.2 （GA） 和 PowerShell 5.1 （GA）。 PowerShell 父產品不再支援 PowerShell 7.1。 建議您在長期支援的 PowerShell 7.2 版中建立 Runbook。
PowerShell 工作流程 以 Windows PowerShell 工作流程腳本為基礎的文字 Runbook。
Python 以 Python 腳本為基礎的文字 Runbook。 支援的版本是 Python 3.8 （GA） 和 Python 3.10 （預覽版）。 Python 父產品不再支援 Python 2.7。 建議您在長期支援的版本中建立 Runbook。
圖形化 以 Windows PowerShell 為基礎的圖形化 Runbook，並在 Azure 入口網站 的圖形化編輯器中完全建立和編輯。
圖形化 PowerShell 工作流程 以 Windows PowerShell 工作流程為基礎的圖形化 Runbook，並在 Azure 入口網站 的圖形化編輯器中完全建立和編輯。

使用 Webhook 來完成要求，並透過 Azure Logic Apps、Azure Functions、IT 服務管理服務、DevOps 或監視系統觸發自動化，以確保持續傳遞和作業。

Azure Arc 代表雲端運算的顯著進步，並提供整合的管理平臺，將 Azure 功能延伸至內部部署、多重雲端和邊緣環境。 Azure Arc 透過 VM 擴充功能架構與 Azure 自動化 服務整合，以部署混合式 Runbook 背景工作角色，並簡化更新管理、變更追蹤和清查功能的上線。

顯示 Azure Arc 生態系統的圖表。

如需詳細資訊，請參閱 將現有的Linux伺服器連線到 Azure Arc。

ARM 範本

透過 ARM 範本的 IaC 提供一致的宣告式方法來部署和管理 Azure 資源。 使用 ARM 範本，以 JSON 格式定義應用程式所需的基礎結構。 ARM 範本具有等冪性，這表示您可以多次部署相同的範本，並取得相同狀態中的相同資源類型。

如需詳細資訊，請參閱 ARM樣本檔。

JSON 範例

{ 

  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", 
  "contentVersion": "1.0.0.0", 
  "parameters": { 
    "location": { 
      "type": "string", 
      "defaultValue": "[resourceGroup().location]" 
    }, 
    "storageAccountName": { 
      "type": "string", 
      "defaultValue": "[format('toylaunch{0}', uniqueString(resourceGroup().id))]" 
    } 
  }, 
  "resources": [ 
    { 
      "type": "Microsoft.Storage/storageAccounts", 
      "apiVersion": "2021-06-01", 
      "name": "[parameters('storageAccountName')]", 
      "location": "[parameters('location')]", 
      "sku": { 
        "name": "Standard_LRS" 
      }, 
      "kind": "StorageV2", 
      "properties": { 
        "accessTier": "Hot" 
      } 
    } 
  ] 
}

您可以使用 Bicep 網域特定語言來減少 JSON 語法的複雜性，並將新加入 Azure 的人員學習曲線降到最低。 Bicep 與使用 JSON 的 ARM 範本相比，Bicep 是透明的抽象概念，而 Bicep 會保留 JSON 範本功能。 在部署期間，Bicep 命令行介面會將 Bicep 檔案轉換成使用 JSON 的 ARM 範本。

本節中的範例顯示 Bicep 檔案與對等 JSON 範本之間的差異。 這兩個範例都會部署儲存體帳戶。

Bicep 範例

param location string = resourceGroup().location 
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}' 
 

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = { 
  name: storageAccountName 
  location: location 
  sku: { 
    name: 'Standard_LRS' 
  } 
  kind: 'StorageV2' 
  properties: { 
    accessTier: 'Hot' 
  } 
}

Azure DevOps

Azure DevOps 是一組完整的開發工具，可為雲端和內部部署環境提供專案管理、持續整合和持續傳遞 （CI/CD） 服務和原始程式碼存放庫。 您可以將這些功能與 Azure Test Plans、Azure Artifacts、Logic Apps 和 Azure Functions 結合，以利現代化軟體項目的順暢共同作業、開發和傳遞。

Azure Boards

Azure Boards 支援適用於雲端軟體開發和專案管理的敏捷式方法。 如需詳細資訊，請參閱 Azure Boards 文件和設定和自定義 Azure Boards。

若要充分利用 Azure Boards，請瞭解您的小組如何使用其工具和功能，例如 Scrum、Kanban 和 Scrumban，以及他們對組態和自定義的相依性。

下表摘要說明您在建構專案時應考慮的主要專案。

專案層級 小組層級
您想要定義的小組數目 如何使用產品待辦項目來規劃和排定工作優先順序
如何建構區域路徑以支援公事包管理檢視 無論您是追蹤 Bug 作為需求、追蹤 Bug 做為工作，或完全不使用 Bug
欄位自定義 您是否使用工作來追蹤時間和容量
自訂工作項目類型 如何使用組合待辦專案層級
組合待辦專案自定義專案 如何使用組合待辦專案層級
工作流程自定義 如何通知上層管理進度、狀態和風險

Azure Pipelines

Azure Pipelines 提供快速、簡單且安全的方式，以一致且高品質的程式代碼自動執行您的專案建置。

Azure Pipelines：

  • 使用任何語言或平臺。
  • 同時部署到不同類型的目標。
  • 與 Azure 部署整合。
  • 建置在 Windows、Linux 或 Mac 計算機上。
  • 與 GitHub 整合。
  • 使用開放原始碼專案。

如需詳細資訊，請參閱 Azure Pipelines 文件。

根據您的組織需求，您可以選擇 Azure Pipelines 的四個核心架構之一：

Azure Repos

Azure Repos 提供兩種類型的版本控制： Git 版本控制 和 集中式版本控制。

若要存取您的程式代碼，請將開發環境連線至 Azure Repos。 透過下列方式共用您的程式代碼：

如需詳細資訊，請參閱 Azure Repos Git 檔和 Team Foundation 版本控制 檔。

使用發行管線和 Azure Artifacts 來源

開發人員可以使用 Azure Artifacts 從摘要和公用登錄發佈及取用不同類型的套件，例如 PyPI、Maven Central 和 NuGet.org。您可以使用 Azure Artifacts 搭配 Azure Pipelines 來發佈組建和管線成品、部署套件，或跨管線的各個階段整合檔案，以建置、測試或部署應用程式。

如需詳細資訊，請參閱

整合 Azure 原則 與 Azure DevOps

Azure 原則 直接套用至 Azure 環境內的資源，但其原則和治理可能會間接影響 Azure DevOps 做法。 例如，Azure 原則 可能會影響：

  • CI/CD 管線中的合規性：您可以將合規性檢查整合到管線中。 例如，請確定您透過 Azure DevOps 部署的任何基礎結構都符合您在 Azure 原則 中定義的原則。

  • 環境一致性：使用 Azure 原則 來強制執行特定組態或資源類型，以確保您透過 Azure DevOps 部署的環境一致且符合規範。

  • 安全性和治理：原則可以在 Azure DevOps Projects 管理的資源上強制執行安全性標準和治理做法。 此法規可確保開發生命週期包含符合組織和法規標準的規範。

若要有效地整合 Azure 原則 與 Azure DevOps，您可以使用 Azure 原則 合規性數據和稽核功能來通知 DevOps 實務。 調整管線或 IaC 定義，以配合您透過 Azure 原則 強制執行的組織原則。

此整合可確保您透過 Azure DevOps 部署和管理的資源一律符合貴公司的治理標準。 使用此方法可增強 Azure 環境的安全性、一致性和成本管理。

下一步