管理 Azure 登陸區域中的應用程式開發環境
本文說明雲端平臺小組如何實作護欄來管理 Azure 登陸區域中的應用程式環境。 它也會說明如何讓各種應用程式開發環境與其架構保持一致。 建立適當環境的關鍵層面是將訂用帳戶放在適當的管理群組中。
設定基礎
開發小組需要能夠快速反覆運算，而雲端治理和平臺小組需要大規模管理組織風險、合規性和安全性。 您可以專注於兩個主要 的 Azure 登陸區域設計原則，以正確管理應用程式環境：原則驅動治理和訂用帳戶民主化。 這些原則提供基本防護措施，並描述如何將控件委派給應用程式小組。 應用程式小組會使用 Azure 架構完善的架構指引 來設計其工作負載。 他們會部署和管理自己的登陸區域資源，而平臺小組會藉由指派 Azure 原則控制資源。
請務必提供 半控管 資源的沙箱資源，讓應用程式小組可以試驗技術和功能。
當應用程式擁有者使用 訂閱自動販賣 或其他訂用帳戶建立程式時，他們必須知道如何要求多個開發環境的訂用帳戶。
本文說明 Azure 登陸區域，包括管理群組、原則和共用平台架構，以及工作負載或應用程式登陸區域。
注意
本文中的指引僅適用於工作負載或應用程式登陸區域。 如需 Azure 登陸區域平臺本身的測試和環境隔離，請參閱 Azure 登陸區域的測試方法，其中說明 Canary 方法。
在實務上，您可以使用任何數目和類型的階段式環境。 本文參考下列階段式環境。
| Environment | 描述 | 管理群組 |
|---|---|---|
| 沙箱 | 用於快速創新原型但不是生產系結組態的環境 | 沙箱管理群組 |
| 開發 | 用來建置潛在發行候選項目的環境 | 原型管理群組，例如 公司 或 在線 |
| Test | 用來執行測試的環境，包括單元測試、使用者驗收測試和品質保證測試 | 原型管理群組，例如 公司 或 在線 |
| 生產 | 用來為客戶提供價值的環境 | 原型管理群組，例如 公司 或 在線 |
如需詳細資訊，請參閱 處理應用程式工作負載 的開發、測試和生產環境影片，以及 應該在 Azure 中使用多少訂用帳戶？
環境、訂用帳戶和管理群組
如需本節的必要條件，請參閱 資源組織設計區域。
當您採用 Azure 登陸區域做法時，您必須正確組織訂用帳戶。 在理想情況下，每個應用程式環境都應該有自己的訂用帳戶。 這個方法提供安全性和原則控制，讓環境保持隔離。 它包含一個環境的潛在問題。
不同的訂用帳戶在原型層級上具有相同的原則。 如有需要，應用程式擁有者可以指派訂用帳戶特定原則，以強制執行應用程式和環境特定行為。
某些應用程式架構需要服務在環境之間共用。 如果是這種情況，您可以針對多個環境使用單一訂用帳戶。 我們建議工作負載擁有者與雲端平臺小組合作，以判斷是否需要多個環境的單一訂用帳戶。
如果下列狀況，請使用多個應用程式環境的單一訂用帳戶：
環境無法在自己的訂用帳戶中隔離。
環境具有指派給功能角色的相同小組，例如網路操作員。
環境可以使用相同的原則。
如果應用程式或服務工作負載必須位於單一訂用帳戶中，而且您需要變更套用至每個環境的原則，您可以：
在登陸區域管理群組底下建立新的 原型對齊 管理群組。 如需詳細資訊，請參閱 本文中的管理群組階層 。
使用沙箱訂用帳戶進行開發活動。 沙箱具有較不嚴格的原則集。
使用在訂用帳戶層級套用的原則，而不是管理群組層級。 您可以在原則定義中新增標籤，以協助篩選原則，並將原則套用至正確的環境。 您也可以將原則指派給特定資源群組，或將其排除在特定的資源群組中。
您可以在訂用帳戶建立程序期間指派原則，作為 訂閱自動販賣 的一部分。
針對您實作以協助控制成本的原則，請視需要在訂用帳戶層級套用原則定義。 或者，您可以讓登陸區域擁有者負責成本，以提供真正的自主性。 如需詳細資訊，請參閱 平臺自動化和DevOps。
警告
不同於管理群組層級的原則和控件，訂用帳戶型原則和標籤可由具有訂用帳戶更高許可權的個人變更。 具有適當角色的 管理員 istrators 可以排除原則、修改原則或變更資源上的標籤來略過這些控制件。
因此，您不應該在以安全性為主的原則定義中套用標籤。 此外，請勿針對下列動作一律指派許可權：
Microsoft.Authorization/policyAssignments/*Microsoft.Authorization/policyDefinitions/*Microsoft.Authorization/policyExemptions/*Microsoft.Authorization/policySetDefinitions/*
您可以使用 Privileged Identity Management （PIM） 來控制這些動作。
管理群組階層
避免複雜的管理群組階層。 它們可能需要頻繁的修訂、無效率地調整，以及缺乏價值。 為了避免這些潛在的問題，Azure 登陸區域管理群組會與工作負載原型保持一致。 如需詳細資訊，請參閱 管理群組和訂用帳戶組織。
原型對齊 表示只會針對特定工作負載原型建立管理群組。 例如，在概念架構中， 登陸區域 管理群組具有 公司 與 在線 子管理群組。 這些子管理群組會與所保存工作負載的不同原型模式一致。 子管理群組著重於混合式連線（VPN/Azure ExpressRoute）需求，例如僅限內部與公開的應用程式和服務。
除了沙箱環境之外，各種應用程式環境應該使用相同的原型進行部署。 即使環境分成數個訂用帳戶，它們仍會根據管理群組原型和需求，保留在相同的單一管理群組 （corp 或 online） 內。
您可以使用 沙箱訂 用帳戶進行非結構化開發，例如個人實驗室或沒有原型的工作負載。 應用程式或服務工作負載小組會使用沙箱管理群組來測試各種 Azure 服務，以判斷最適合其需求的專案。 在他們決定服務之後，他們可以為小組布建登陸區域（在正確的工作負載原型對齊管理群組中 ，為小組布建登陸區域 管理群組階層中。
沙箱環境可用於特定應用程式，或工作負載小組可以使用它們進行實驗。
如需詳細資訊，請參閱
環境型管理群組挑戰
原型內環境的管理群組可以增加管理額外負荷，並提供最少的價值。
登 陸區域 管理群組應具有通用原則，可針對 公司 與 在線 子管理群組強制執行護欄。 公司 與 在線 有獨特的原則，可強制執行與公開和私人面向工作負載相關的公司指導方針。
許多組織會為工作負載軟體開發生命週期 （SDLC） 環境建立個別的管理群組，以指派環境原則和控制。 在實務上，此方法會為工作負載小組建立比解決更多的挑戰。 SDLC 環境不應該有不同的原則，因此不建議個別的管理群組。
應用程式擁有者可以變更工作負載的拓撲或資源設定，以符合其透過升級的多個SDLC環境中的原則。 此方法會增加風險。 每個環境專屬的規則可能會導致開發人員和品質保證小組的開發體驗不佳。 如果應用程式有一組可在一個環境中運作的護欄原則，而且應用程式會在升級週期稍後公開至一組不同的原則，也會發生問題。 如果控件變更，您可能需要調整應用程式。
若要避免這項額外工作，請在 SDLC 環境中建立一致的程式代碼升級原則。 您不應該為每個環境建立原則，而是為所有開發環境提供一致的集合，但不包括沙盒環境。
例如，假設組織會定義原則，要求使用特定防火牆規則來設定記憶體帳戶，以防止輸入公用網路。 相反地，記憶體帳戶會使用 Azure 登陸區域網路內的私人端點進行通訊。 如果開發環境沒有這類原則，測試工作負載找不到允許公用存取的記憶體帳戶設定錯誤。 測試部署會在開發環境中運作，並反覆執行。 當解決方案升級至具有記憶體帳戶原則的另一個環境時，部署會因為強制執行的原則而失敗。
因此，應用程式開發小組必須在投入大量精力之後，重新作業其部署和架構。 此範例示範各種環境中的不同原則如何建立問題。
注意
下列方程式示範為何每個環境或工作負載的個別管理群組無法妥善調整： N 個工作負載 x Z 管理群組 = 總管理群組。
如果組織有 30 個工作負載，每個工作負載都需要管理群組和子管理群組來進行開發、測試和生產環境，則組織會保留：
N = 工作負載/應用程式數目 = 30
Z = 工作負載和環境的管理群組數目 （1 代表工作負載 + 3 用於環境） = 4
N （30） x Z （4） = 120 個總管理群組
應用程式擁有者可能需要將原則以不同的方式套用至多個環境。 例如，應用程式擁有者可能需要生產環境的備份設定，但不適用於其他環境。
某些原則可以啟用為管理群組層級的審核策略。 應用程式小組會決定如何實作 控件。 此方法不會防止部署，但它會建立感知，並讓應用程式小組管理其獨特的需求。 然後，他們可以建立子層級原則，或將這些需求併入其基礎結構即程序代碼 （IaC） 部署模組中。
在此共同責任模型中，平臺小組稽核做法，以及應用程式小組會管理實作。 此模型可以改善部署的靈活度。
平臺操作員必須與每個應用程式或服務工作負載小組（登陸區域擁有者）合作，以瞭解其需求。 平臺操作員可以根據應用程式需求和方案提供訂用帳戶。 平臺操作員也可以決定為各種類型的工作負載指定 產品線 ，以便根據應用程式或服務工作負載小組的一般需求來建置訂用帳戶建立流程和工具。
案例：虛擬機 （VM） 型工作負載
Azure 登陸區域中的早期工作負載通常是由 Azure VM 所組成。 您可以在 Azure 中部署這些工作負載，或從現有的數據中心移轉這些工作負載。
除了將 VM 部署到單一訂用帳戶中的多個環境，您也可以：
為每個應用程式環境建立訂用帳戶，並將其全部放在相同的原型管理群組中。
在適當的訂用帳戶中，為每個應用程式環境部署虛擬網路。 您可以根據應用程式環境的大小來判斷虛擬網路大小。
將 VM 部署至其適當的訂用帳戶。 如果適用，VM 可以針對每個環境使用不同的 SKU 和不同的可用性設定。
各種應用程式環境資源受到不同訪問控制的保護。 因此，當應用程式開發人員設定部署管線時，每個管線的身分識別可以受限於環境。 此設定有助於保護環境免於意外部署。
案例：Azure App 服務
使用 App Service 的環境訂用帳戶工作負載可能會產生挑戰。 對於應用程式開發人員， App Service 最佳做法 是使用 部署位置 來協助管理 Web 應用程式的變更和更新。
不過，此功能只能與 App Service 方案上的應用程式搭配使用，而 App Service 方案只能存在於單一訂用帳戶內。 如果平臺操作員要求應用程式擁有者針對開發、測試和生產環境使用不同的訂用帳戶，則應用程式部署生命週期可能會比較難以管理。
在此範例中，最佳選項是應用程式或服務工作負載的單一訂用帳戶。 應用程式擁有者可以使用 Azure 角色型存取控制 （RBAC） 與 資源群組層級的 PIM ，以提高安全性。