Bearbeiten

Azure DevTest Labs-Architektur für Unternehmen

Azure DevTest Labs
Azure Artifacts
Azure Bastion

Dieser Artikel enthält einen Architekturansatz zur Vorbereitung von Azure DevTest Labs (DTL oder Lab) in einer Zielzone auf Unternehmensebene (Enterprise-Scale Landing Zone, ESLZ) mit Schwerpunkt auf den Entwurfsrichtlinien.

Aufbau

In der Architektur für DTL in einem Unternehmen wird die Grundlage der Plattform in der Regel durch den Plattformadministrator gemäß den in der ESLZ bereitgestellten Richtlinien für die Zentralisierung von Netzwerk, Identität und Governance eingerichtet. Informationen zur Einrichtung der ESLZ-Plattform finden Sie unter Implementieren von Cloud Adoption Framework-Zielzonen auf Unternehmensebene in Azure.

Das Anwendungsteam ist für die Bereitstellung der DTL-Kernressourcen in den DevTest-Abonnements zuständig, wie rechts unten im folgenden Diagramm dargestellt. Dadurch wird die bereits eingerichtete Grundlage verwendet. Die auf Verwaltungsgruppen angewendeten Richtlinien werden auch auf das DevTest-Abonnement und die Ressourcen angewendet.

DTL an sich verfügt zwar über keine integrierten Grenzwerte, andere Azure-Ressourcen, die im Lab verwendet werden, gehen jedoch möglicherweise über die Azure-Abonnementgrenzwerte hinaus. In diesen Fällen sind möglicherweise mehrere Azure-Abonnements erforderlich, um große DTL-Bereitstellungen abzudecken.

Diagram of the reference architecture for DevTest Labs in an enterprise.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

  • Der Netzwerkadministrator erstellt ein Spoke-VNet und andere Netzwerkressourcen wie NSG und UDR in der Netzwerkressourcengruppe, die mittels Peering mit dem Hub-VNet verknüpft ist. Das Peering wird durch Azure-Richtlinien erstellt, die der Unternehmensverwaltungsgruppe per ESLZ-Automatisierung zugewiesen werden. Dieses Peering ermöglicht Unternehmensbenutzern den Zugriff auf die virtuellen Labcomputer über VPN/ExpressRoute mit einer privaten IP-Adresse.
  • Der Lab-Besitzer konfiguriert integrierte Labrichtlinien gemäß den Projektanforderungen. Alle verfügbaren Richtlinien finden Sie unter Verwalten aller Richtlinien für ein Lab in Azure DevTest Labs. Im Anschluss finden Sie einige Richtlinien, die für diesen Artikel relevant sind:
    • Konfigurieren Sie die VNet-Einstellung so, dass alle Lab-VMs im Spoke-VNet erstellt werden.
    • Konfigurieren Sie die Labeinstellungen so, dass alle Lab-VMs in der angegebenen Labressourcengruppe erstellt werden. Auf diese Weise werden sie nicht auf mehrere Ressourcengruppen verteilt.
    • Aktivieren Sie die Browserverbindung, um den im Hub-VNet bereitgestellten Bastionhost zu verwenden und so den RDP-/SSH-Zugriff auf Lab-VMs über das Internet ohne öffentliche IP-Adresse zu schützen.
    • Konfigurieren Sie Lab-Benutzer, und weisen Sie geeignete Rollen nach dem Prinzip der geringsten Berechtigungen zu. DTL bietet drei integrierte Rollen: Besitzer, Mitwirkender und Benutzer.
    • Konfigurieren Sie das Artefakt für den Domänenbeitritt als obligatorisches Artefakt im Lab, wenn ein Domänenbeitritt des virtuellen Labcomputers erforderlich ist.
    • Konfigurieren Sie ein privates GitHub-/ADO-Repository im Lab für Artefakte und Umgebungsvorlagen. Das Repository kann auch zum Speichern der Anwendungscodebasis verwendet werden.
  • Das Anwendungsteam kann die Labressourcen (VMs und PaaS-Umgebungen) manuell starten oder Azure Pipelines für die Bereitstellung von Ressourcen mithilfe von DTL-Aufgaben einrichten.

Ressourcentopologie

Innerhalb des DevTest-Abonnements lassen sich die Ressourcen durch Optimieren der Ressourcengruppenstruktur für Labs besser verwalten. In einem Unternehmen werden die netzwerkbezogenen Ressourcen üblicherweise von Netzwerkadministratoren gesteuert und sind durch die Verwendung separater Ressourcengruppen von den Anwendungsressourcen isoliert.

Labressourcen können im Rahmen des DevTest-Abonnements innerhalb von zwei Ressourcengruppen verteilt werden, wie im obigen Diagramm zu sehen:

  • Netzwerkressourcengruppe (rg-network-dtl), die das VNet, die NSG und Routen enthält. Die Netzwerkressourcen können von mehreren Labs innerhalb desselben Abonnements gemeinsam genutzt werden.
  • Labressourcengruppe (rg-team-lab1), die die Kernressourcen des Labs enthält. Standardmäßig wird von DTL für jeden neuen virtuellen Computer eine Ressourcengruppe erstellt, was gut ist, wenn Sie diese Isolation benötigen. Andernfalls können Sie diese Konfiguration ändern, um alle virtuellen Computer in der gleichen Ressourcengruppe bereitzustellen. Mehrere Teams können eine DTL-Instanz gemeinsam nutzen oder je nach Team- oder Projektanforderungen eine separate DTL-Instanz starten.

Beim Bereitstellen einer DTL-Instanz werden automatisch folgende Infrastrukturressourcen erstellt:

  • Key Vault-Instanz: DTL-Benutzer können Key Vault verwenden, um ein Kennwort für einen virtuellen Windows-Computer, einen öffentlichen SSH-Schlüssel für einen virtuellen Linux-Computer oder ein persönliches Zugriffstoken zum Klonen eines Git-Repositorys über ein Artefakt zu speichern.
  • Speicherkonto: Speicherkonten werden von DTL für Folgendes verwendet:
    • Speichern von Formulardokumenten, die zum Erstellen von virtuellen Computern verwendet werden können
    • Speichern von Artefaktergebnissen (einschließlich Bereitstellungs- und Erweiterungsprotokolle, die durch das Anwenden von Artefakten erstellt wurden)
    • Hochladen virtueller Festplatten (Virtual Hard Disks, VHDs) für die Erstellung benutzerdefinierter Images im Lab
    • Zwischenspeichern häufig verwendeter Artefakte und Azure Resource Manager-Vorlagen, um sie beim Erstellen von virtuellen Computern und Umgebungen schneller abrufen zu können
  • Virtuelles Netzwerk: DTL erstellt ein virtuelles Standardnetzwerk, falls kein vorhandenes virtuelles Netzwerk bereitgestellt wird. In dieser Architektur wird ein vorhandenes Spoke-VNet empfohlen, das mit dem Hub-VNet durch Peering verknüpft ist.

Komponenten

  • Zielzone auf Unternehmensebene (Enterprise-Scale Landing Zone, ESLZ): Ein Architekturansatz und eine Referenzimplementierung, die die effektive Erstellung und Operationalisierung von Zielzonen in Azure im großen Stil ermöglicht. Bei Azure-Zielzonen handelt es sich um die Ausgabe einer Azure-Umgebung mit mehreren Abonnements, in der Aspekte wie Skalierung, Sicherheit, Governance, Netzwerk und Identität berücksichtigt werden. DTL kann in der DevTest-Zielzone oder im Sandboxabonnement bereitgestellt werden, wie unter Verwaltungsgruppen- und Abonnementtopologie erläutert.
  • Azure DevTest Labs (DTL): Ein vollständig verwalteter Dienst, mit dem Entwickler und Tester schnell Entwicklungs- und Testumgebungen bereitstellen können. Mit DTL können Benutzer virtuelle Computer und PaaS-Ressourcen erstellen. Die VM-Erstellung wird nativ unterstützt. PaaS-Ressourcen können mithilfe von Umgebungsvorlagen erstellt werden.
  • DTL-Richtlinien: Mit diesen Richtlinien können Sie Kosten und die unnötige Beanspruchung von Ressourcen in Ihren Labs minimieren, indem Sie Richtlinien (Einstellungen) für jedes Lab verwalten. Durch eine DTL-Richtlinie können Sie die zulässigen VM-Größen in einem Lab angeben, um eine unnötige Beanspruchung von Ressourcen zu vermeiden. Wenn diese Richtlinie aktiviert ist, können zum Erstellen von virtuellen Computern nur VM-Größen aus der Liste verwendet werden.
  • Hub-and-Spoke-Konfigurationen: Diese Konfigurationen bieten Vorteile wie Kosteneinsparungen, Überwindung von Abonnementgrenzwerten und Workloadisolation. Das Hub-VNet fungiert als zentraler Verbindungspunkt für viele Spoke-VNets und für lokale Netzwerke. Die virtuellen Spoke-Netzwerke stellen eine Peeringverbindung mit dem Hub her und können zur Isolierung von Workloads verwendet werden. DTL kann im Spoke-Netzwerk platziert werden, sodass Unternehmen Sicherheitsfeatures zentral steuern können. Hierzu zählen beispielsweise eine Firewall im Hub als DMZ sowie ExpressRoute-/VPN-Konnektivität und die getrennte Verwaltung für die Workload. Die VNets (einschließlich des Spoke-VNet) werden üblicherweise durch den Plattformadministrator bereitgestellt. Das App-Team kann die DTL-Instanz im angegebenen Subnetz bereitstellen. Weitere Informationen finden Sie unter Netzwerktopologie.
  • Azure Bastion: Ein vollständig verwalteter Dienst, der sichereren und nahtloseren VM-Zugriff per RDP (Remotedesktopprotokoll) und SSH (Secure Shell-Protokoll) ohne jegliche Verfügbarkeit über öffentliche IP-Adressen bietet. DTL kann den Bastionhost verwenden, um eine sichere RDP-/SSH-Verbindung mit virtuellen Computern herzustellen, ohne sie direkt über das Internet verfügbar zu machen, wie unter Netzwerktopologie erläutert. Standardmäßig lässt DTL Konnektivität mit dem virtuellen Computer per öffentlicher IP-Adresse oder freigegebener öffentlicher IP-Adresse zu.
  • DTL-Artefakte ermöglichen die Angabe von Aktionen, die bei der Bereitstellung der VM ausgeführt werden. Hierzu zählen beispielsweise das Ausführen von Windows PowerShell-Skripts, das Ausführen von Bash-Befehlen und das Installieren von Software. Mithilfe von Artefaktparametern können Sie das Artefakt für Ihr Szenario anpassen. Das von DevTest Labs gepflegte öffentliche Artefaktrepository enthält zahlreiche gängige Tools für Windows und Linux. Ein Link zu diesem Repository wird Ihrem Lab automatisch hinzugefügt.
  • Bei einer Formel in Azure DevTest Labs handelt es sich um eine Liste von Standardeigenschaftswerten, die zum Erstellen eines virtuellen Computers verwendet werden.
  • DTL-Umgebungen: Mithilfe dieser Umgebungen können Benutzer komplexe Infrastrukturen im Rahmen des Labs problemlos konsistent bereitstellen. Sie können Azure Resource Manager Vorlagen verwenden, um Umgebungen mit Ressourcensätzen in DevTest Labs zu erstellen. Diese Umgebungen können alle Azure-Ressourcen enthalten, die von Resource Manager-Vorlagen erstellt werden können.

Alternativen

Kunden können eine DevTest Labs-ähnliche Lösung erstellen, indem sie mehrere Dienste mit nativen Azure-Features wie Richtlinien, RBAC-Gruppen, VM-Erweiterungen und Automatisierung miteinander kombinieren.

Der Hauptvorteil von DevTest Labs sind die sofort einsatzbereiten integrierten Features sowie die intuitive Benutzeroberfläche, die neuen Benutzern (Administratoren und Entwicklern) ohne umfassende Azure-Kenntnisse den Einstieg erleichtert. Somit beschleunigt und vereinfacht DTL die Implementierung und Wartung.

Szenariodetails

DTL ermöglicht es Entwicklern in Teams, virtuelle Computer und PaaS-Ressourcen effizient selbst zu verwalten, ohne auf Genehmigungen warten zu müssen, was für eine sorgenfreie Self-Service-Umgebung sorgt. Dies ist äußerst hilfreich in Schlüsselszenarien wie Entwicklerdesktops, Testumgebungen, Schulungen und Sandboxuntersuchungen – insbesondere, wenn Sie gerade erst mit der Verwendung von Azure beginnen. Durch die integrierten Labrichtlinien und Schwellenwerte lassen sich mühelos Kosten senken. Weitere Informationen zu den Kernkonzepten von DTL finden Sie unter DevTest Labs-Konzepte.

Dieser Artikel enthält übergreifende Empfehlungen für Verwaltungsgruppen- und Abonnementtopologie, Netzwerk, Identität, Enterprise Agreement-Angebote, Anwendungsautomatisierung und Sicherheit für DevTest-Workloads im Kontext von DTL.

Unternehmen, die DevTest-Workloads in großem Umfang migrieren, können von der Einrichtung dieser Architektur auf Unternehmensebene profitieren und Folgendes erreichen:

  • Geringerer operativer Mehraufwand für Anwendungsteams, da sie sich auf Anwendungsentwicklung/Tests mit DTL konzentrieren und alle Aufgaben im Zusammenhang mit Plattformverwaltung, Netzwerk, Sicherheit und Identitätseinrichtung einem zentralen IT-Team überlassen können
  • Zentralisierte übergreifende Erzwingung der Organisationscompliance für DevTest-Workloads

Mögliche Anwendungsfälle

Diese Architektur ist für Organisationen hilfreich, die Folgendes benötigen:

  • Von Anfang an eine vollständig integrierte Betriebssteuerungsebene für DevTest-Workloads
  • Eine klare Trennung der Zuständigkeiten zwischen Plattform- und Anwendungsworkloads

Diese Architektur wird üblicherweise als Grundlage für umfangreiche, abonnementübergreifende Bereitstellungen von DevTest-Workloads verwendet.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Diese Sicherheitsbaseline wendet Empfehlungen der Version 2.0 des Azure-Sicherheitsvergleichstests auf DTL an.

Governance und Einhaltung

Unter den folgenden Links finden Sie Informationen zu Governance und Compliance für DTL:

Identitäts- und Zugriffsverwaltung

Unternehmen arbeiten beim betrieblichen Zugriff in der Regel nach dem Prinzip der geringsten Berechtigungen, das über Microsoft Entra ID, die rollenbasierte Zugriffssteuerung (RBAC) in Azure und benutzerdefinierte Rollendefinitionen umgesetzt wird. Die RBAC-Rollen ermöglichen die Verwaltung von DTL-Ressourcen wie etwa das Erstellen von virtuellen Computern, das Erstellen von Umgebungen und das Starten, Beenden, Neustarten, Löschen und Anwenden von Artefakten.

  • Der Zugriff auf Labs kann so konfiguriert werden, dass Aufgaben in Ihrem Team auf verschiedene Rollen aufgeteilt werden. Drei dieser RBAC-Rollen sind Besitzer, DevTest Labs-Benutzer und Mitwirkender. Die DTL-Ressource muss sich im Besitz von Personen befinden, die mit den Projekt- und Teamanforderungen in puncto Budget, Computer und erforderliche Software vertraut sind. Ein gängiges Modell ist, dass der Projektleiter oder der App-Administrator als Lab-Besitzer und die Teammitglieder als Lab-Benutzer fungieren. Die Rolle „Mitwirkender“ kann App-Infrastrukturmitgliedern zugewiesen werden, die Berechtigungen zum Verwalten von Labressourcen benötigen. Der Lab-Besitzer ist für das Konfigurieren der Richtlinien und für das Hinzufügen der erforderlichen Benutzer zum Lab zuständig.
  • Für Unternehmen, bei denen Benutzer eine Verbindung mit domänenbasierten Identitäten herstellen müssen, kann für den Domänenbeitritt virtueller DTL-Computer ein dem Plattformabonnement hinzugefügter Domänencontroller verwendet werden. DTL-Artefakte ermöglichen einen automatischen Domänenbeitritt virtueller Computer. Standardmäßig verwenden virtuelle DTL-Computer ein lokales Administratorkonto.
  • DTL unterstützt verwaltete Identitäten für die zugehörigen Azure-Ressourcen. Verwenden Sie verwaltete Identitäten mit DTL für den Zugriff auf Key Vault und Speicher sowie für die Bereitstellung von virtuellen Computern und PaaS-Ressourcen. Weisen Sie benutzerseitig zugewiesene verwaltete Identitäten auf Ihren virtuellen Labcomputern in DTL zu, damit Benutzer von virtuellen Labcomputern auf Azure-Ressourcen zugreifen können.

Netzwerktopologie

Organisationen arbeiten häufig mit einer regionalen Hub-Spoke-Netzwerktopologie, bei der der Hub und die Spokes in separaten virtuellen Netzwerken bereitgestellt werden und Abonnements mittels Peering verknüpft sind.

Wie im obigen Architekturdiagramm zu sehen, verwenden DTL-Ressourcen die vorhandenen Spoke-VNets, die mittels Peering mit dem Hub-VNet verknüpft sind. Das Hub-VNet ist Teil des Plattformabonnements und ermöglicht sichere Konnektivität durch RDP-/SSH-Zugriff auf Folgendes:

  • Virtuelle DTL-Computer, die eine private IP-Adresse für interne Benutzer über VPN/ER verwenden. Konnektivität mit lokalen Umgebungen ist auch in Hybridanwendungsszenarien erforderlich, bei denen sich einige der erforderlichen Komponenten (etwa Datenbank und Active Directory-Domäne) weiterhin in der lokalen Umgebung befinden.
  • Virtuelle DTL-Computer, die eine private IP-Adresse für externe Benutzer per Bastionhost über das Internet verwenden. Organisationen können auch das Remotedesktopgateway in DTL konfigurieren, anstatt eine herkömmliche RDP-Verbindung über das Internet zu verwenden, wenn sie keine Browserverbindung über Bastion nutzen möchten.

Der Hub-Spoke-Entwurf trägt dazu bei, die direkte Verfügbarkeit von DTL-Ressourcen im öffentlichen Internet zu minimieren, bietet Workloadisolation und macht die Architektur erweiterbar. Bestimmte Ressourcen wie etwa eine Firewall und DNS können über mehrere Spoke-Netzwerke hinweg gemeinsam genutzt werden.

DTL bietet auch die Möglichkeit, per öffentlicher IP-Adresse oder freigegebener IP-Adresse eine direkte Verbindung mit virtuellen Computern herzustellen, sofern die Compliance der Organisation dies zulässt.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Enterprise Agreement für DevTest

Enterprise Agreement-Kunden können ihre Entwicklungs- und Testworkloads hervorragend in Azure ausführen, indem sie sich für niedrigere Preise für Dev/Test-Workloads registrieren, wie unter Enterprise Dev/Test beschrieben. Das Aktivieren des DevTest-Abonnements im Azure Enterprise-Portal ermöglicht einer Organisation Folgendes:

  • Ausführen von Clientbetriebssystemen, die üblicherweise nicht in einem Azure-Unternehmensabonnement verfügbar sind
  • Verwenden von Unternehmenssoftware, in der sie nur für die Computeressourcen bezahlen
  • Vertrauen auf die Lizenzierung

Erstklassige Betriebsprozesse

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

Anwendungsautomatisierung und DevOps

Im Kontext von DTL umfasst die Automatisierung Folgendes:

  • Bereitstellen der DTL-Instanz: Konsistente und wiederholbare Bereitstellung von DTL mit Richtlinien unter Verwendung von gespeicherten ARM-/Bicep-Vorlagen aus einem Git-Repository. Die Automatisierung kann über ein beliebiges CI/CD-Framework erreicht werden.
  • Bereitstellen von Ressourcen innerhalb von DTL mithilfe von Azure DevOps: Automatisierung mit der Azure Pipelines-Erweiterung Azure DevTest Labs Tasks aus dem Marketplace, um Lab-VMs, benutzerdefinierte Images und Umgebungen zu erstellen und zu löschen.
  • Bereitstellung von Artefakten und PaaS-Umgebungen mit integrierter DTL-Automatisierung: Konfigurieren Sie ein privates benutzerdefiniertes Repository (ADO oder GitHub) im Lab, oder verwenden Sie Azure Lab Services Community-Repository-Inhalt, der zum Speichern und Automatisieren der Bereitstellung von Artefakten und Umgebungsvorlagen zur Verfügung steht.

Es gibt noch zahlreiche weitere Möglichkeiten für die Automatisierung von Azure und DevTest Labs. Hierzu zählen unter anderem REST-APIs, PowerShell, Azure CLI und Azure SDK.

Die DTL-Integration für Azure DevOps zu Entwicklungszwecken und für den Betrieb wird unter Integration von Azure DevTest Labs und Azure DevOps beschrieben. Im Azure Architecture Center steht außerdem der Artikel DevTest und DevOps für IaaS-Lösungen zur Verfügung.

Verwaltungsgruppen- und Abonnementtopologie

Eine durchdachte Topologie für Verwaltungsgruppen und Abonnements gewährleistet zusammen mit organisationsbezogenen Struktur- und Complianceanforderungen eine ordnungsgemäße Isolation sowie maximale Flexibilität für zukünftiges Wachstum. Die Einrichtung der Verwaltungsgruppe und des Abonnements ist Aufgabe des Plattformbesitzers, der dem Anwendungsadministrator oder Lab-Besitzer den erforderlichen Zugriff für die Bereitstellung des Labs gewährt.

Wie im obigen Architekturdiagramm zu sehen, können Anwendungsteams DTL in einem Abonnement unter einer Zielzonen- oder Sandbox-Verwaltungsgruppe bereitstellen. Die Entscheidung basiert auf den folgenden Aspekten:

  • Wenn die globale Organisationscompliance, die in der Zielzonenverwaltungsgruppe definiert ist, für DevTest-Workloads gültig ist, kann die DTL-Instanz in einem produktionsfremden Zielzonenabonnement unter einer Unternehmens- oder Onlineverwaltungsgruppe basierend auf der Anforderung von Konnektivität mit einer lokalen Umgebung bereitgestellt werden. In diesem Fall werden alle Azure-Richtlinien, die aus Compliancegründen auf die Zielzonenverwaltungsgruppen angewendet werden, von allen darin enthaltenen Abonnements geerbt. Dies schließt DTL-Ressourcen sowie die vom Administrator konfigurierten Richtlinien ein.
  • DTL kann auch in einer Sandboxumgebung für Untersuchungen, Schulungen und Untersuchungen konfiguriert werden. In diesem Fall kann die DTL-Instanz in einem Abonnement unter einer Sandboxverwaltungsgruppe bereitgestellt werden, die über minimale Einschränkungen verfügt und Benutzern Freiheit bei der Erkundung bietet.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte