Share via

治理 Azure DevTest Labs 基礎結構

  • 發行項

此文章將說明如何在組織內調整與管理適用於 DevTest Labs 的資源。

資源

在 Azure 訂用帳戶內對齊 DevTest Labs 資源

在組織開始使用 Azure 進行一般應用程式開發之前，IT 規劃人員應該先檢閱如何引進功能以作為其整體服務組合的一部分。 檢閱的領域應該能夠消除下列顧慮：

  • 如何測量與應用程式開發生命週期相關聯的成本？
  • 組織如何使用公司安全性原則來調整所提議的服務供應項目？
  • 是否需要進行分割以便將開發與生產環境分隔開來？
  • 需要基於長期簡化管理、穩定性和成長因素來引進哪些控制項？

第一個建議的做法是檢閱組織的 Azure 分類法，其概述如何在生產與開發訂用帳戶之間進行劃分。 在下圖中，建議的分類法允許進行開發/測試和生產環境的邏輯分隔。 使用此方法，組織就能導入計費代碼，個別追蹤與每個環境相關聯的成本。 如需詳細資訊，請參閱 規定的訂用帳戶治理。 此外，您可以基於追蹤與計費目的，使用 Azure 標記來組織資源。

第二個建議的做法是在 Azure 企業版入口網站內啟用 DevTest 訂用帳戶。 它讓組織能夠執行通常不會在 Azure 企業版訂用帳戶中提供的用戶端作業系統。 然後，使用企業軟體，您只需支付計算費用，而不需擔心授權。 它可確保對於指定服務 (包括像是 Microsoft SQL Server 之 IaaS 中的資源庫映像) 的計費只會以使用量為基礎。 有關 Azure DevTest 訂用帳戶的詳細資料，可在此處找到適用於 Enterprise 合約 (EA) 客戶的資料，並在這裡找到適用於隨用隨付客戶的資料。

Diagram showing how resources alignment with subscriptions.

此模型可為組織提供彈性，以大規模部署 Azure DevTest Labs。 組織可以使用 100 到 1000 部以平行方式執行的虛擬機器，來支援各個業務單位的數百個實驗室。 它會推動集中式企業實驗室解決方案的概念，其可共用組態管理和安全性控制項的相同準則。

此模型也可確保組織不會耗盡與其 Azure 訂用帳戶相關聯的資源限制。 如需訂用帳戶與服務限制的詳細資料，請參閱 Azure 訂用帳戶和服務限制、配額及條件約束。 DevTest Labs 佈建程序可能會取用大量資源群組。 您可以透過 Azure DevTest 訂用帳戶中的支援要求來要求提高限制。 生產環境訂用帳戶內的資源不會因為使用中的開發訂用帳戶增加而受到影響。 如需調整 DevTest Labs 的詳細資訊，請參閱在 DevTest Labs 中調整配額和限制。

需要考量的常見訂用帳戶層級限制是如何配置網路 IP 範圍指派，以同時支援生產環境和開發訂用帳戶。 這些指派應考量一段時間內的成長 (假設內部部署連線能力，或需要企業管理其網路堆疊而不是預設為 Azure 實作的另一個網路拓撲)。 建議的做法是具備少數虛擬網路，其中已指派大型 IP 位址前置詞，並已使用許多大型子網路來劃分，而不是具備多個含有小型子網路的虛擬網路。 例如，使用 10 個訂用帳戶，您可以定義 10 個虛擬網路 (針對每個訂用帳戶定義一個)。 所有不需隔離的實驗室均可在該訂用帳戶的虛擬網路上共用相同的子網路。

每個實驗室的使用者數目及每個組織的實驗室數目

與相同開發專案相關聯的業務單位和開發群組應該與相同的實驗室相關聯。 這樣就能將相同類型的原則、映像及關機原則套用到這兩個群組。

您可能也需要考慮地理界限。 例如，位於美國東部 (US) 的開發人員可能會使用佈建於美國東部 2 的實驗室。 此外，可能會將位於德克薩斯州達拉斯和科羅拉多州丹佛的開發人員重新導向來使用位於美國中南部的資源。 如果要與外部協力廠商共同合作，則可能會將他們指派到不是由內部開發人員所使用的實驗室。

您還可以將實驗室用於 Azure DevOps 專案內的特定專案。 然後，透過指定的 Microsoft Entra 群組套用安全性，以允許您存取這兩組資源。 指派到實驗室的虛擬網路可以是另一個要合併使用者的界限。

防止刪除資源

在實驗室層級設定權限，讓只有授權的使用者才能刪除資源或變更實驗室原則。 開發人員應該放置於 DevTest Labs 使用者群組內。 首席開發人員或基礎結構負責人都應該是 DevTest Labs 擁有者。 我們建議您只有兩位實驗室擁有者。 此原則會擴充到程式碼存放庫以避免損毀。 實驗室使用者有權使用資源，但無法更新實驗室原則。 請參閱下列文章，其中列出每個內建群組在實驗室中所擁有的角色和權限：在 Azure DevTest Labs 中新增擁有者和使用者。

管理成本與所有權

當您考慮建置開發和測試環境時，成本和擁有權是主要考量。 在此節中，您會發現可協助您進行成本最佳化，並在環境中配置擁有權的資訊。

進行成本最佳化

數個 DevTest Labs 內建功能皆可協助您進行成本最佳化。 請參閱成本管理、閾值及原則文章，以限制使用者的活動。

如果您針對開發和測試工作負載運用 DevTest Labs，請考慮使用 Enterprise 開發/測試訂閱權益作為 Enterprise 合約的一部分。 或者，如果您是隨用隨付的客戶，請考慮隨用隨付開發/測試供應項目。

這個方法提供多項優點：

  • 享有 Windows 虛擬機器、雲端服務、HDInsight、App Service 及 Logic Apps 的更優惠開發/測試費率
  • 在其他 Azure 服務上享有絕佳的 Enterprise 合約 (EA) 費率
  • 可以存取資源庫中的專屬開發/測試映像，包括 Windows 8.1 和 Windows 10

僅有效的 Visual Studio 訂閱者 (標準訂用帳戶、年度雲端訂用帳戶及每月雲端訂用帳戶) 能夠使用在 Enterprise 開發/測試訂用帳戶內執行的 Azure 資源。 不過，終端使用者可以存取應用程式來提供意見反應或執行驗收測試。 此訂閱內的資源只可用於開發和測試應用程式。 沒有執行時間保證。

如果您決定使用 DevTest 供應項目，請將此項權益專門用於應用程式的開發與測試。 訂閱內的使用量不包含財務支援的 SLA，除了使用 Azure DevOps 及 HockeyApp 之外。

定義您整個組織內的角色型存取

中央 IT 應該只擁有必要項目，並讓專案和應用程式小組能夠擁有所需的控制層級。 一般而言，這表示中央 IT 擁有訂用帳戶並會處理核心 IT 函式，例如網路設定。 這組適用於訂用帳戶的擁有者應該很小。 這些擁有者可以在需要時提名其他擁有者，或套用訂閱層級的原則，例如「沒有公用 IP」。

可能有使用者子集需要跨訂用帳戶進行存取，例如第 1 層或第 2 層支援。 在此情況下，我們建議您為這些使用者授與參與者存取權，讓他們可以管理資源，但不提供使用者存取權或調整原則。

DevTest Labs 資源擁有者應該與專案或應用程式小組密切合作。 這些擁有者了解機器和軟體需求。 在大多數組織中，DevTest Labs 資源的擁有者即為專案或開發負責人。 此擁有者可以管理實驗室環境內的使用者和原則，以及 DevTest Labs 環境內的所有虛擬機器。

將專案和應用程式小組成員新增至 DevTest Labs 使用者角色。 這些使用者可以根據實驗室和訂閱層級原則來建立虛擬機器。 使用者也可以管理自己的虛擬機器，但無法管理屬於其他使用者的虛擬機器。

如需詳細資訊，請參閱 Azure 企業 Scaffold - 規定的訂閱治理。

公司原則和合規性

本節提供治理適用於 Azure DevTest Labs 基礎結構之公司原則和合規性的相關指導方針。

公用與私人成品存放庫

公用成品存放庫 \(英文\) 提供一組最常用的初始軟體套件。 它有助於進行快速部署，而不需花時間重新產生常用的開發人員工具和增益集。您可以選擇部署他們自己的私人存放庫。 您可以平行方式各使用一個公用和私人存放庫。 您也可以選擇停用公用存放庫。 部署私人存放庫的準則應透過下列問題和考量來衍生：

  • 組織是否需要使公司授權的軟體成為其 DevTest Labs 供應項目的一部分？ 如果答案是肯定的，則應該建立私人存放庫。
  • 組織是否要開發自訂軟體來提供特定作業，且需將其當作整體佈建程序的一部分？ 如果答案是肯定的，則應該部署私人存放庫。
  • 如果組織的治理原則需要隔離，而且組織不會對外部存放庫進行直接組態管理，就應該部署私人成品存放庫。 在此程序的過程中，可複製公用存放庫的初始複本，並與私人存放庫整合在一起。 接著，可以停用公用存放庫，如此一來，組織內的所有人都不能再存取該存放庫。 此方法強制組織內的所有使用者只能具有組織所核准的單一存放庫，並將設定漂移降到最低。

單一存放庫或多個存放庫

作為貴組織整體治理和組態管理策略的一部分，我們建議您使用集中式存放庫。 當您使用多個存放庫時，它們可能會在經過一段時間之後成為非受控軟體的定址接收器。 使用中央存放庫，多個小組就能針對他們的專案，從此存放庫中取用成品。 它會強制執行標準化、安全性、簡化管理，並排除重複的工作。 在集中化過程中，下列動作為適用於長期管理和持續性的建議做法：

  • 將 Azure Repos 與 Azure 訂用帳戶用來進行驗證和授權的相同 Microsoft Entra 租用戶產生關聯。
  • 在集中管理的 Microsoft Entra ID 中，建立名為所有 DevTest Labs 開發人員的群組。 任何有助於成品開發的開發人員都應該放置於此群組中。
  • 相同的 Microsoft Entra 群組可用來提供存取 Azure Repos 存放庫及實驗室。
  • 在 Azure Repos 中，應該使用分支或派生，將開發中的存放庫與主要生產環境存放庫分隔開來。 只有在進行適當的程式碼檢閱之後，才會使用提取要求將內容新增至主分支。 當程式碼檢閱者核准變更之後，負責維護主分支的首席開發人員就會合併更新的程式碼。

公司安全性原則

組織可以透過下列方式套用公司安全性原則：

  • 開發和發佈完善的安全性原則。 該原則會闡述與使用軟體、雲端資產相關聯的可接受使用規則。 它也會定義哪些明顯違反了該原則。
  • 開發自訂映像、自訂成品及部署程序，允許在使用 Active Directory 定義的安全性領域內進行協調流程。 此方法會強制執行公司界限，並設定一組常用的環境控制項。 這些控制項會以開發人員在開發期間可考量的環境為依據，並遵循安全開發生命週期作為其整體程序的一部分。 此外，目標在於提供未過度限制的環境，其可能會妨礙開發，但卻是一組合理的控制項。 位於包含實驗室虛擬機器之組織單位 (OU) 的群組原則，可能是在生產環境中找到的總計群組原則子集。 或者，它們可以是另一組集合，以適當減輕任何已識別的風險。

資料完整性

組織可以確保資料完整性，以確保遠端開發人員無法移除程式碼或引入惡意程式碼或未經核准的軟體。 有數個控制層可以減輕來自外部顧問、承包商或遠端在 DevTest Labs 中共同作業的員工的威脅。

如先前所述，第一個步驟必須起草並定義一個可接受的使用原則，清晰地概述有人違反原則時的後果。

適用於遠端存取的第一個控制層是透過未直接連線至實驗室的 VPN 連線來套用遠端存取原則。

第二個控制層是套用一組群組原則物件，以避免透過遠端桌面進行複製與貼上。 您可以實作網路原則，不允許環境的輸出服務，例如離開該環境的 FTP 和 RDP 服務。 使用者定義的路由可以強制所有 Azure 網路流量回到內部部署，但除非透過 Proxy 來控制掃描內容與工作階段，否則路由無法負責可能允許上傳資料的所有 URL。 公用 IP 可能會在支援 DevTest Labs 的虛擬網路內受到限制，不允許對外部網路資源進行橋接。

最後，需要在整個組織中套用相同類型的限制，其也必須負責可能會接受內容貼文之抽取式媒體或外部 URL 的所有可能方法。 請洽詢您的安全性專業人員來檢閱並實作安全性原則。 如需其他建議，請參閱 Microsoft 網路安全性。

應用程式移轉與整合

一旦建立您的開發/測試實驗室環境之後，您需要思考下列問題：

  • 如何在專案小組中使用該環境？
  • 如何確保您會遵循任何必要的組織原則，並保有將值新增到應用程式的靈活度？

Azure Marketplace 映像與自訂映像

除非您具有特定考量或組織需求，否則預設應該使用 Azure Marketplace。 一些常見範例包括：

  • 複雜的軟體安裝，需要包含應用程式作為基礎映像的一部分。
  • 安裝和設定應用程式可能需要數個小時，如此就無法有效率地使用在 Azure Marketplace 映像上新增的計算時間。
  • 開發人員和測試人員需要快速存取虛擬機器，並且想要將安裝新虛擬機器的時間縮至最短。
  • 所有機器都必須具備的合規性或法規條件 (例如安全性原則)。

請謹慎考慮使用自訂映像。 自訂映像會引進額外的複雜性，因為您現在必須管理適用於那些基礎基本映像的 VHD 檔案。 您也需要使用軟體更新來定期修補那些基本映像。 這些更新包括新的作業系統 (OS) 更新，以及軟體套件本身所需的任何更新或設定變更。

公式與自訂映像

一般而言，此案例中的決定因素是成本與重複使用。

您可以建立自訂映像來降低成本，前提是：

  • 許多使用者或實驗室都需要映像。
  • 所需要的映像除了基礎映像，還需要很多軟體。

此解決方案可讓您只需要建立一次映像。 自訂映像可減少虛擬機器的設定時間。 在設定期間，不會產生執行虛擬機器的成本。

另一個因素是變更軟體套件的頻率。 如果您執行每日組建且要求軟體位於您使用者的虛擬機器上，請考慮使用公式，而非自訂映像。

設定網路設定的模式

當您確定開發和測試虛擬機器無法連線到公用網際網路時，有兩個方面需要考慮 – 輸入和輸出流量。

輸入流量：如果虛擬機器沒有公用 IP 位址，則網際網路無法連線到該虛擬機器。 常見的方法是設定訂用帳戶層級原則，沒有任何使用者可以建立公用 IP 位址。

輸出流量：如果您想要防止虛擬機器直接連至公用網際網路，並強制流量通過公司防火牆，則可以使用強制執行的路由，透過 Azure ExpressRoute 或 VPN 來路由傳送內部部署的流量。

注意

如果您的 Proxy 伺服器會封鎖不具 Proxy 設定的流量，請務必將例外狀況新增到實驗室的成品儲存體帳戶。

您也可以針對虛擬機器或子網路使用網路安全性群組。 這個步驟會新增另一層保護來允許或封鎖流量。

新的與現有的虛擬網路

如果您的 VM 需要與現有的基礎結構互動，則應該考慮在 DevTest Labs 環境內使用現有的虛擬網路。 如果您使用 ExpressRoute，請將虛擬網路和子網路的數目降到最低，這樣就不會分散指派給訂用帳戶的 IP 位址空間。 另請考慮在此這裡使用虛擬網路對等互連模式 (中樞輪輻模型)。 此方法可在指定區域內的訂用帳戶之間啟用虛擬網路和子網路通訊。

每個 DevTest Labs 環境都可以有自己的虛擬網路，但每個訂用帳戶的虛擬網路數目有限制。 雖然可將此限制提升到 100，但預設數目是 50。

共用、公用或私人 IP

如果您使用站對站 VPN 或 Express Route，請考慮使用私人 IP，如此一來，您的機器就可透過透過內部網路存取，但無法透過公用網際網路存取。

注意

實驗室擁有者可以變更這個子網路原則，以確保沒有人會不小心為其 VM 建立公用 IP 位址。 訂用帳戶擁有者應該建立訂用帳戶原則，以防止建立公用 IP。

使用共用的公用 IP 時，實驗室中的虛擬機器會共用公用 IP 位址。 當您需要避免違反指定訂用帳戶的公用 IP 位址限制時，這個方法相當有幫助。

實驗室限制

您應該注意幾個實驗室限制。 下列各節說明這些限制。

每個訂用帳戶的實驗室限制

每個訂用帳戶可以建立的實驗室數目並無特定限制， 但每個訂用帳戶可使用的資源數量則有限制。 您可以閱讀 Azure 訂用帳戶的限制和配額和如何增加這些限制值。

每個實驗室的 VM 限制

每個實驗室可以建立的 VM 數目並無特定的限制。 不過，每個訂用帳戶可使用的資源 (VM 核心、公用 IP 位址等) 則有限制。 您可以閱讀 Azure 訂用帳戶的限制和配額和如何增加這些限制值。

每個使用者或實驗室的虛擬機器數目限制

當您考慮每位使用者或每個實驗室的虛擬機器數目時，有三個主要考量：

  • 小組可在實驗室中花費於資源上的整體成本。 很容易就能將許多機器向上微調。 若要控制成本，有一種機制是限制每位使用者或每個實驗室的 VM 數目
  • 實驗室中的虛擬機器總數會受到可用的訂用帳戶層級配額所影響。 其中一個上限是每個訂用帳戶 800 個資源群組。 DevTest Labs 目前會針對每部 VM 建立一個新的資源群組 (除非使用共用的公用 IP)。 如果訂用帳戶中有 10 個實驗室，實驗室大約能在每個實驗室中納入 79 部虛擬機器 (800 個上限 – 10 個實驗室本身的 10 個資源群組) = 每個實驗室 79 部虛擬機器。
  • 舉例來說，如果實驗室會透過 Express Route 連線到內部部署，則會針對 VNet/子網路定義可用的 IP 位址空間。 若要確保實驗室中的 VM 不會建立失敗 (錯誤：無法取得 IP 位址)，實驗室擁有者可以針對每個已配置可用 IP 位址空間的實驗室指定 VM 的最大數目。

使用資源管理員範本

使用針對測試環境使用 Azure DevTest Labs 中的步驟，部署您的 Resource Manager 範本。 基本上，您會將 Resource Manager 範本簽入到 Azure Repos 或 GitHub 存放庫，並將適用於範本的私人存放庫新增到實驗室。

如果您是使用 DevTest Labs 來裝載開發機器，則不適用此案例。 使用此案例來建置代表實際執行環境的預備環境。

每個實驗室或每位使用者的虛擬機器數目選項只會限制在實驗室本身原生建立的機器數目。 此選項不會限制任何環境使用 Resource Manager 範本的建立作業。