相應增加您的 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 訂用帳戶。 如果工作負載只是開發和測試，建議您選取 Enterprise DevTest 供應專案以取得其他可用的映像，並在 Windows 虛擬機上降低速率。
  • 內部部署存取：如有必要，已設定內部部署存取。 內部部署存取可透過站對站 VPN 連線或透過 Express Route 來完成。 透過 Express Route 的 連線 性通常可能需要數周的時間才能建立，建議您在啟動專案之前先設定 Express Route。
  • 試驗 Teams：已識別使用 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 Directory Services）或內部部署網域。 針對內部部署，判斷虛擬機加入的 Active Directory 內哪個組織單位 （OU）。 此外，請確認使用者有權加入（或建立服務帳戶，且能夠在網域中建立計算機記錄）

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

一旦網路拓撲就緒，可以採取下列步驟來建立第一個/試驗實驗室：

  1. 建立初始DevTest Labs環境。
  2. 判斷允許的 VM 映像和大小，以搭配實驗室使用。 決定是否可以將自定義映像上傳至 Azure 以搭配 DevTest Labs 使用。
  3. 為實驗室建立初始 Azure 角色型訪問控制 （Azure RBAC） 來保護實驗室的存取權（實驗室擁有者和實驗室使用者）。 建議您使用已同步處理的 Active Directory 帳戶與 Microsoft Entra ID 搭配 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 基礎結構的治理