Share via

擴大 Azure DevTest Labs 基礎結構

  • 發行項

在企業範圍內協調 DevTest Labs 的實作成功需要考慮關鍵決策點，並規劃一種快速部署和實作 Azure DevTest Labs 的方法。

本文說明規劃實作時您應考慮的關鍵決策點，並提供建議的部署方法。

關鍵決策點

以企業級規模實作 DevTest Labs 之前，有數個重要決策點。 了解這些高層的決策點可協助組織未來設計決策。 不過，這些決策點應該不會妨礙組織開始概念證明。

初始相應增加計劃的前三個領域如下：

  • 網路和安全性
  • 訂用帳戶拓撲
  • 角色和責任

網路和安全性

網路和安全性是所有組織的基石。 雖然整個企業的部署需要更深入的分析，但是成功完成概念證明的需求會減少。 一些主要領域包括：

  • Azure 訂用帳戶 – 若要部署 DevTest Labs，您必須使用適當的權限存取 Azure 訂用帳戶，才能建立資源。 有數種方式可以取得 Azure 訂用帳戶的存取權，包括 Enterprise 合約和隨用隨付方案。 如需有關取得 Azure 訂用帳戶存取權的詳細資訊，請參閱 Azure 企業授權。
  • 內部部署資源的存取權 – 部分組織需要其在 DevTest Labs 中的資源能夠存取內部部署資源。 您需要從內部部署環境到 Azure 的安全連線。 開始之前，請務必先設定 VPN 或 Azure ExpressRoute 連線。 如需詳細資訊，請參閱虛擬網路概觀。
  • 其他安全性需求 – 其他安全性需求，例如電腦原則、公用 IP 位址存取權，連線到網際網路都是必須要審核過後再實作概念證明的案例。

訂用帳戶拓撲

訂用帳戶拓撲是在將 DevTest Labs 部署至企業時的重要設計考量。 不過，不需要完成概念證明，就可以鞏固所有決策。 評估企業實作所需的訂用帳戶數目時，有兩個極端的方法：

  • 整個組織使用一個訂用帳戶
  • 每位使用者使用一個訂用帳戶

接下來，我們強調每一種方法的優勢。

一個訂用帳戶

一個訂用帳戶的方法通常在大型企業中不容易管理。 不過，限制訂用帳戶的數目有下列優點：

  • 預測企業的成本。 單一訂用帳戶的預算變得更容易，因為所有資源都在單一集區中。 此方法更容易決定在計費期間的任何指定時間執行成本控制措施。
  • VM、成品、公式、網路設定、權限、原則的管理更容易，因為所有更新只需要在一個訂用帳戶進行，而不需要對許多訂用帳戶進行更新。
  • 對於需要內部部署連線的企業，單一訂用帳戶的網路工作較為簡化。 額外的訂用帳戶需要跨訂用帳戶連接虛擬網路 (中樞-支點模型)，而這需要更多的設定、管理、IP 位址空間。
  • 小組共同作業在每個人於相同訂用帳戶中工作時較為輕鬆。 例如，將 VM 重新指派給同事或共用小組資源會比較輕鬆。

每位使用者使用一個訂用帳戶

每位使用者使用一個訂用帳戶可為替代範圍提供相等的機會。 擁有許多訂用帳戶的優點包括：

  • Azure 縮放配額將不會妨礙採用。 例如，撰寫本文時，Azure 允許每個訂用帳戶有 200 個儲存體帳戶。 在 Azure 中，多數服務都有操作配額 (許多可自訂，某些則不行)。 如果是每位使用者使用一個訂用帳戶這個模型，就不太可能達到大部分的配額。 如需有關目前 Azure 調整配額的詳細資訊，請參閱 Azure 訂用帳戶和服務限制、配額與限制。
  • 退款給群組或個別開發人員變得更容易，因為組織能夠使用其目前的模型來計算成本。
  • DevTest Labs 環境的擁有權和權限很簡單。 您為開發人員提供訂用帳戶層級的存取權，他們會完全負責所有事情，包括網路設定、實驗室原則和 VM 管理。

在企業中，對範圍的極端情況可能會有足夠的限制。 因此，您可能需要使用適中的方式設定訂用帳戶。 作為最佳做法，組織的目標應為盡可能使用最少量的訂用帳戶。 請記住，強制函式會增加訂用帳戶的總數。 再次提醒您，訂用帳戶拓撲對於 DevTest Labs 的企業部署至關重要，但不應該延遲概念證明。 在控管一文中包含如何決定組織中的訂用帳戶和實驗室細微度的更多詳細資料。

角色和責任

DevTest Labs 概念證明有三個主要角色及已定義的職責，分別是訂用帳戶擁有者、DevTest Labs 擁有者、DevTest Labs 使用者和 (選用的) 參與者。

  • 訂用帳戶擁有者 – 訂用帳戶擁有者擁有管理 Azure 訂用帳戶的權限，包括指派使用者、管理原則、建立與管理網路拓撲，以及要求增加配額等。 如需詳細資訊，請參閱這篇文章。
  • DevTest Labs 擁有者 – DevTest Labs 擁有者對實驗室有完整的系統管理存取權。 這位人員會負責新增/移除使用者、管理成本設定、一般實驗室設定，以及其他以 VM/成品為基礎的工作。 實驗室擁有者也具備 DevTest Labs 使用者的所有權限。
  • DevTest Labs 使用者 – DevTest Labs 使用者可以建立和使用實驗室中的虛擬機器。 這些人員對於所建立的 VM 有一些基本的系統管理功能 (啟動/停止/刪除/設定其 VM)。 這些使用者無法管理其他使用者的 VM。

協調 DevTest Labs 實作

本節提供快速部署和實作 Azure DevTest Labs 的建議方法。 下圖強調作為規範性指南的整體程序，同時觀察支援各種產業需求和案例的彈性。

Diagram showing steps for implementing Azure DevTest Labs.

假設

此文章假設您在實作 DevTest Labs 試驗之前，就已備妥下列項目：

  • Azure 訂用帳戶：試驗小組具備將資源部署到 Azure 訂用帳戶的存取權。 如果工作負載只有開發和測試，建議選取企業版 DevTest 供應項目，以用於 Windows 虛擬機器上其他可用的映像和較優惠的費率。
  • 內部部署存取：必要時，已經設定內部部署存取。 您可以透過站對站 VPN 連線或 Express Route 來完成內部部署存取。 透過 Express Route 的連線通常需要數週的時間來建立，建議在開始專案之前先備妥 Express Route。
  • 試驗小組：已識別出最初使用 DevTest Labs 的開發專案小組，以及適用於開發或測試活動，並針對那些小組建立需求/目標/目的。

里程碑 1：建立初始的網路拓撲和設計

部署 Azure DevTest Labs 解決方案時的第一個焦點領域是建立虛擬機器的計劃性連線。 下列步驟概述必要的程序：

  1. 定義在 Azure 中指派給 DevTest Labs 訂用帳戶的初始 IP 位址範圍。 此步驟需要預測所有 VM 的預期使用量，讓您可提供足夠大的區塊以供未來擴充使用。
  2. 將所需存取的方法識別到 DevTest Labs (例如，外部 / 內部存取)。 此步驟的重點是判斷虛擬機器是否具有公用 IP 位址 (也就是可從網際網路直接存取)。
  3. 針對 Azure 雲端環境的其餘部分和內部部署識別並建立連線的方法。 如果已啟用透過 Express Route 強制執行路由，虛擬機器很可能需要適當的 Proxy 設定以周遊企業防火牆。
  4. 如果 VM 已加入網域，請判斷它們是否要加入雲端式網域 (例如 Microsoft Entra 目錄服務) 或內部部署網域。 針對內部部署，判斷虛擬機器要加入 Active Directory 內的哪些組織單位 (OU)。 此外，確認使用者有權加入 (或建立能夠在網域中建立電腦記錄的服務帳戶)。

里程碑 2：部署試驗實驗室

當網路拓撲就緒之後，就能採用下列步驟來建立第一個/試驗實驗室：

  1. 建立初始 DevTest Labs 環境。
  2. 判斷允許的 VM 映像和大小，以便與實驗室搭配使用。 決定是否可將自訂映像上傳至 Azure，以便與 DevTest Labs 搭配使用。
  3. 藉由為實驗室 (實驗室擁有者和實驗室使用者) 建立初始 Azure 角色型存取控制 (Azure RBAC)，來保護對實驗室的存取。 我們建議搭配 Microsoft Entra ID 使用同步處理的 Active Directory 帳戶，以使用 DevTest Labs 進行身分識別。
  4. 設定 DevTest Labs 來使用原則，例如排程、成本管理、可認領 VM、自訂映像或公式。
  5. 建立 Azure Repos/Git 之類的線上存放庫。
  6. 決定使用公用或私人存放庫或兩者的組合。 組織 JSON 範本以用於部署和長期維持流程。
  7. 視需要建立自訂成品。 此步驟是選擇性的。

里程碑 3：文件、支援、了解及改善

最初的試驗小組可能需要深入支援以便快速入門。 使用他們的體驗來確保正確的文件及支援均已就緒，可繼續推出 Azure DevTest Labs。

  1. 將試驗小組介紹給其新的 DevTest Labs 資源 (示範、文件)
  2. 根據試驗小組的體驗，視需要規劃並提供文件
  3. 將用來使新小組上線的程序定形 (建立及設定實驗室、提供存取等)
  4. 根據最初的理解，確認 IP 位址空間的原始預測仍然合理且準確
  5. 確定已完成適當的合規性與安全性檢閱

下一步

請參閱本系列的下一篇文章：治理 Azure DevTest Labs 基礎結構