Governance der Azure DevTest Labs-Infrastruktur

Dieser Artikel behandelt die Ausrichtung und die Verwaltung von Ressourcen für DevTest Labs in Ihrer Organisation.

Ressourcen

Ausrichten von DevTest Labs-Ressourcen in einem Azure-Abonnement

Bevor eine Organisation damit beginnt, Azure für die allgemeine Anwendungsentwicklung einzusetzen, sollten die IT-Planer zunächst überprüfen, wie die Funktionalität im Rahmen des Gesamtportfolios an Diensten eingeführt werden soll. Die zu überprüfenden Bereiche sollten die folgenden Anliegen berücksichtigen:

• Wie werden die mit dem Lebenszyklus der Anwendungsentwicklung einhergehenden Kosten gemessen?
• Wie bringt die Organisation das vorgeschlagene Dienstangebot mit der Sicherheitsrichtlinie des Unternehmens in Einklang?
• Ist Segmentierung erforderlich, um Entwicklungs- und Produktionsumgebung zu trennen?
• Welche Steuerungsmechanismen werden für eine langfristig komfortable Verwaltung, für Stabilität und Wachstum eingeführt?

Als erste empfohlene Praxis sollte die Azure-Taxonomie von Organisationen überprüft werden, die einen Hinweis auf die Grenzen zwischen Produktions- und Entwicklungsabonnements gibt. Im folgenden Diagramm ermöglicht die vorgeschlagene Taxonomie eine logische Trennung von Entwicklungs-/Test- und Produktionsumgebung. Bei diesem Ansatz kann eine Organisation Abrechnungscodes einführen, um die für die einzelnen Umgebungen anfallenden Kosten separat nachzuverfolgen. Weitere Informationen finden Sie unter Prescriptive subscription governance (Präskriptive Abonnementgovernance). Darüber hinaus können Sie Azure-Tags verwenden, um Ressourcen zu Nachverfolgungs- und Abrechnungszwecken zu ordnen.

Als zweite empfohlene Praxis sollte das DevTest-Abonnement innerhalb des Azure Enterprise-Portals aktiviert werden. Dies ermöglicht einer Organisation das Ausführen von Clientbetriebssystemen, die normalerweise in einem Azure Enterprise-Abonnement nicht verfügbar sind. Verwenden Sie außerdem Unternehmenssoftware, bei der Sie nur Computeleistungen bezahlen und sich nicht um die Lizenzierung zu kümmern brauchen. Dadurch wird sichergestellt, dass die Abrechnung für vorgesehene Dienste, einschließlich Katalogimages in IaaS wie etwa Microsoft SQL Server, ausschließlich nutzungsbasiert erfolgt. Details zum Azure DevTest-Abonnement finden Sie hier für EA-Kunden (Enterprise Agreement) und hier für Kunden mit nutzungsbasierter Bezahlung.

Dieses Modell bietet einer Organisation die Flexibilität, Azure DevTest Labs bedarfsorientiert bereitzustellen. Eine Organisation kann Hunderte Labs für verschiedene Geschäftseinheiten mit 100 bis 1000 parallel ausgeführten virtuellen Computern unterstützen. Es befördert das Konzept einer konzernweit zentralen Lab-Lösung, bei der die stets gleichen Prinzipien von Konfigurationsmanagement und Sicherheitsmechanismen durchgesetzt werden können.

Dieses Modell stellt auch sicher, dass die Organisation die Ressourcengrenzwerte im Rahmen ihres Azure-Abonnements nicht ausschöpft. Details zu Grenzwerten für Abonnements und Dienste finden Sie unter Azure subscription and service limits, quotas, and constraints (Grenzwerte für Azure-Abonnements und -Dienste, Kontingente und Einschränkungen). Der DevTest Labs-Bereitstellungsprozess kann eine große Anzahl Ressourcengruppen in Anspruch nehmen. Über eine Supportanfrage beim Azure DevTest-Abonnement können Sie eine Heraufsetzung der Grenzwerte anfordern. Die Ressourcen innerhalb des Produktionsabonnements werden durch die zunehmende Nutzung des Entwicklungsabonnements nicht beeinträchtigt. Weitere Informationen zum Skalieren von DevTest Labs finden Sie unter Scale quotas and limits in DevTest Labs (Skalierungskontingente und -beschränkungen in DevTest Labs).

Ein gemeinsamer Grenzwert auf Abonnementebene, dem Rechnung zu tragen ist, besteht in der Zuweisung des Netzwerk-IP-Adressraums, damit sowohl das Produktions- als auch das Entwicklungsabonnement unterstützt werden. Diese Zuweisungen sollten Wachstum in Lauf der Zeit berücksichtigen (ausgehend von lokaler Konnektivität oder einer anderen Netzwerktopologie, die eine Verwaltung des Netzwerkstapels durch das Unternehmen erfordert, statt einfach die Implementierung in Azure zu nutzen). Die empfohlene Praxis besteht in der Verwendung einiger virtueller Netzwerke, denen ein großes IP-Adresspräfix zugewiesen ist und die in viele große Subnetze aufgeteilt sind, gegenüber einer Lösung mit vielen virtuellen Netzwerken mit kleinen Subnetzen. Beispielsweise können Sie mit 10 Abonnements 10 virtuelle Netzwerke definieren (eins für jedes Abonnement). Alle Labs, für die keine Isolierung erforderlich ist, können dasselbe Subnetz im virtuellen Netzwerk des Abonnements nutzen.

Anzahl der Benutzer pro Lab und Labs pro Organisation

Geschäftseinheiten und Entwicklungsgruppen, die dem gleichen Entwicklungsprojekt angehören, sollten dem gleichen Lab zugeordnet sein. Dadurch können für beide Gruppen die gleichen Arten von Richtlinien, Images und Richtlinien zum Herunterfahren angewendet werden.

Ggf. müssen auch geografische Grenzen berücksichtigt werden. Beispielsweise benutzen Entwickler im Nordosten der USA möglicherweise ein Lab, das in USA Osten 2 bereitgestellt ist. Demgegenüber sind Entwickler in Dallas, Texas, und Denver, Colorado, gehalten, eine Ressource in USA Süden-Mitte zu verwenden. Im Falle einer Zusammenarbeit mit einem externen Dritten könnten sie einem Lab zugewiesen werden, das nicht von internen Entwicklern genutzt wird.

Sie können auch ein Lab für ein bestimmtes Projekt in Azure DevOps Projects verwenden. Anschließend wenden Sie Sicherheit in Form einer angegebenen Microsoft Entra-Gruppe an, was den Zugriff auf beide Ressourcensätze ermöglicht. Das dem Lab zugewiesene virtuelle Netzwerk kann eine weitere Grenze zur Konsolidierung der Benutzer bilden.

Verhindern des Löschens von Ressourcen

Legen Sie Berechtigungen auf Lab-Ebene fest, damit nur autorisierte Benutzer Ressourcen löschen oder Lab-Richtlinien ändern können. Entwickler sollten innerhalb der Gruppe DevTest Labs-Benutzer platziert werden. Der Entwicklungsleiter oder der Infrastruktur-Lead sollte als DevTest Labs-Besitzer festgelegt werden. Wir empfehlen, nur zwei Lab-Besitzer festzulegen. Diese Richtlinie wird auf das Coderepository ausgeweitet, um Beschädigungen zu vermeiden. Lab-Benutzer verfügen über Rechte zur Nutzung von Ressourcen, sie können aber keine Lab-Richtlinien aktualisieren. Der folgende Artikel listet die Rollen und Rechte auf, über die jede integrierte Gruppe innerhalb eines Labs verfügt: Hinzufügen von Besitzern und Benutzern in Azure DevTest Labs.

Verwalten von Kosten und Besitz

Kosten und Besitz sind zentrale Überlegungen beim Aufbau Ihrer Entwicklungs- und Testumgebungen. In diesem Abschnitt finden Sie Informationen, die Ihnen beim Optimieren der Kosten und beim Festlegen des Besitzes in Ihrer gesamten Umgebung helfen.

Optimieren für Kosten

Mehrere integrierte Features von DevTest Labs helfen Ihnen bei der Kostenoptimierung. Informationen zum Beschränken der Benutzeraktivitäten finden Sie in den Artikeln zur Kostenverwaltung und zu Schwellenwerten und zu Richtlinien.

Wenn Sie DevTest Labs für Entwicklungs- und Testworkloads verwenden, sollten Sie den Enterprise Dev/Test-Abonnementvorteil im Rahmen Ihres Enterprise Agreements in Erwägung ziehen. Wenn Sie ein Kunde mit nutzungsbasierter Zahlung sind, sollten Sie stattdessen das Dev/Test-Angebot mit nutzungsbasierter Zahlung berücksichtigen.

Dieser Ansatz bietet mehrere Vorteile:

• Niedrigere Dev/Test-Tarife für virtuelle Windows-Computer, Clouddienste, HDInsight, App Service und Logic Apps
• Großartige Enterprise Agreement-Tarife (EA) für andere Azure-Dienste
• Zugriff auf exklusive Dev/Test-Images im Katalog, einschließlich Windows 8.1 und Windows 10

Nur aktive Visual Studio-Abonnenten (Standardabonnements oder Jahres- und Monatscloudabonnements) können die im Rahmen eines Enterprise Dev/Test-Abonnements ausgeführten Azure-Dienste nutzen. Endbenutzer können jedoch auch auf die Anwendung zugreifen, um Feedback zu geben oder Akzeptanztests durchzuführen. Sie können Ressourcen in diesem Abonnement nur zum Entwickeln und Testen von Anwendungen verwenden. Es gibt keine Verfügbarkeitsgarantie.

Wenn Sie das DevTest-Angebot nutzen möchten, verwenden Sie diesen Vorteil ausschließlich für das Entwickeln und Testen Ihrer Anwendungen. Die Nutzung im Rahmen des Abonnements unterliegt keiner Vereinbarung zum Servicelevel (SLA) mit finanzieller Absicherung, mit Ausnahme der Nutzung von Azure DevOps und HockeyApp.

Definieren von rollenbasiertem Zugriff in Ihrer gesamten Organisation

Die zentrale IT-Abteilung sollte nur das Nötigste verwalten und den Projekt- und Anwendungsteams das erforderliche Maß an Kontrolle ermöglichen. In der Regel bedeutet dies, dass die IT-Zentrale der Besitzer des Abonnements ist und die wichtigsten IT-Funktionen übernimmt, z.B. Netzwerkkonfigurationen. Die Gruppe von Besitzern eines Abonnement sollte klein sein. Diese Besitzer können weitere Besitzer vorschlagen, wenn dies erforderlich ist, oder Richtlinien auf Abonnementebene anwenden, z. B. „Keine öffentliche IP-Adresse“.

Möglicherweise gibt es eine Teilmenge von Benutzern, die Zugriff auf ein Abonnement benötigen, z.B. der Support auf Ebene 1 oder Ebene 2. In diesem Fall wird empfohlen, diesen Benutzern Zugriff auf der Ebene Mitwirkender zu gewähren, sodass sie die Ressourcen verwalten können, aber keinen Benutzerzugriff erhalten oder Richtlinien anpassen können.

DevTest Labs-Ressourcenbesitzer sollten sich in der Nähe des Projekts oder Anwendungsteams befinden. Diese Besitzer verstehen die Computer- und Softwareanforderungen. In den meisten Organisationen ist der Besitzer dieser DevTest Labs-Ressource der Projekt- oder Entwicklungsleiter. Dieser Besitzer kann Benutzer und Richtlinien in der Lab-Umgebung und alle VMs in der DevTest Labs-Umgebung verwalten.

Fügen Sie der Rolle „DevTest Labs-Benutzer“ Mitglieder des Projekt- und Anwendungsteams hinzu. Diese Benutzer können VMs erstellen (entsprechend den Richtlinien auf Lab- und Abonnementebene). Benutzer können auch ihre eigenen VMs verwalten, aber keine VMs, die anderen Benutzern gehören.

Weitere Informationen finden Sie unter Azure-Unternehmensgerüst – präskriptive Abonnementgovernance.

Unternehmensrichtlinie und Compliance

Dieser Abschnitt bietet Anleitungen zur Governance der Unternehmensrichtlinie und der Compliance für die Azure DevTest Labs-Infrastruktur.

Vergleich: Öffentliches vs. privates Artefaktrepository

Das öffentliche Artefaktrepository stellt einen Anfangssatz von Softwarepaketen bereit, die am häufigsten verwendet werden. Dies hilft bei der schnellen Bereitstellung – ohne Zeitaufwand zum Reproduzieren gängiger Entwicklertools und Add-Ins. Sie können auch Ihr eigenes privates Repository bereitstellen. Sie haben die Möglichkeit, ein öffentliches und ein privates Repository parallel zu nutzen. Das öffentliche Repository lässt sich auch deaktivieren. Beachten Sie die folgenden Fragen und Überlegungen, bevor Sie ein privates Repository bereitstellen:

• Muss die Organisation im Rahmen ihres DevTest Labs-Angebots lizenzierte Unternehmenssoftware verwenden? Falls ja, sollte ein privates Repository erstellt werden.
• Entwickelt die Organisation benutzerdefinierte Software, die einen bestimmten Vorgang bereitstellt, der im Rahmen des gesamten Bereitstellungsprozesses erforderlich ist? Falls ja, sollte ein privates Repository bereitgestellt werden.
• Wenn die Governancerichtlinie der Organisation eine Isolierung erfordert und externe Repositorys nicht direkt der Konfigurationsverwaltung durch die Organisation unterliegen, sollte ein privates Artefaktrepository bereitgestellt werden. Im Rahmen dieses Prozesses kann eine Erstkopie des öffentlichen Repositorys kopiert und in das private Repository integriert werden. Dann kann das öffentliche Repository deaktiviert werden, sodass niemand mehr innerhalb der Organisation darauf zugreifen kann. Dieser Ansatz bewirkt, dass alle Benutzer innerhalb der Organisation nur über ein einziges Repository verfügen, das von der Organisation genehmigt wird, und Konfigurationsabweichungen minimiert werden.

Vergleich: Einzelnes Repository vs. mehrere Repositorys

Im Rahmen der allgemeinen Governance- und Konfigurationsverwaltungsstrategie Ihrer Organisation wird empfohlen, ein zentrales Repository zu verwenden. Wenn Sie mehrere Repositorys verwenden, können diese im Laufe der Zeit zu Silos nicht verwalteter Software werden. Mit einem zentralen Repository können mehrere Teams Artefakte aus diesem Repository für ihre Projekte verwenden. Es bewirkt Standardisierung, Sicherheit sowie einfache Verwaltung und vermeidet doppelten Aufwand. Im Rahmen der Zentralisierung werden die folgenden Aktionen zur langfristigen Verwaltung und Nachhaltigkeit empfohlen:

• Ordnen Sie die Azure Repos demselben Microsoft Entra-Mandanten zu, den das Azure-Abonnement zur Authentifizierung und Autorisierung verwendet.
• Erstellen Sie in Microsoft Entra eine Gruppe mit dem Namen Alle DevTest Labs-Entwickler, die zentral verwaltet wird. Jeder Entwickler, der zur Entwicklung von Artefakten beiträgt, sollte in diese Gruppe aufgenommen werden.
• Die gleiche Microsoft Entra-Gruppe kann verwendet werden, um Zugriff auf das Azure Repos-Repository und -Lab zu ermöglichen.
• In den Azure Repos sollten Verzweigungen oder Gabelungen verwendet werden, um ein Entwicklungsrepository vom primären Produktionsrepository zu trennen. Inhalte werden dem Mainbranch erst nach einem ordnungsgemäßen Code Review mit einem Pull Request hinzugefügt. Sobald der Codereviewer die Änderung genehmigt hat, führt ein leitender Entwickler, der für die Wartung des Mainbranchs verantwortlich ist, den aktualisierten Code zusammen.

Unternehmenssicherheitsrichtlinien

Ein Organisation kann Unternehmenssicherheitsrichtlinien wie folgt anwenden:

• Entwickeln und Veröffentlichen einer umfassenden Sicherheitsrichtlinie. Die Richtlinie definiert die Regeln der zulässigen Nutzung von Software und Cloudressourcen. Sie regelt auch, was eindeutig gegen die Richtlinie verstößt.
• Entwickeln eines benutzerdefinierten Images, benutzerdefinierter Artefakte und eines Bereitstellungsprozesses, der die Orchestrierung innerhalb des Sicherheitsbereichs ermöglicht, der mit Active Directory definiert ist. Dieser Ansatz setzt die Unternehmensgrenze durch und legt einen gemeinsamen Steuerelementsatz für die Umgebung fest. Entwickler können diese Umgebungssteuerelemente beim Entwickeln berücksichtigen und im Rahmen ihres Gesamtprozesses einen sicheren Entwicklungslebenszyklus verfolgen. Ziel ist es auch, eine Umgebung zu schaffen, die nicht zu restriktiv ist (was die Entwicklung behindern würde), sondern einen angemessenen Satz von Steuerelementen. Die Gruppenrichtlinien der Organisationseinheit (OE), die Lab-VMs enthält, können eine Teilmenge der gesamten Gruppenrichtlinien sein, die sich in der Produktion befinden. Sie können aber auch ein anderer Satz sein, um alle identifizierten Risiken angemessen zu mindern.

Datenintegrität

Eine Organisation kann die Datenintegrität gewährleisten, um sicherzustellen, dass von Remote arbeitende Entwickler weder Code entfernen noch Malware oder nicht genehmigte Software integrieren können. Es gibt mehrere Kontrollebenen, um die Bedrohung durch externe Berater, Auftragnehmer und Mitarbeiter zu minimieren, die in DevTest Labs remote zusammenarbeiten.

Wie bereits erwähnt, muss im ersten Schritt eine Acceptable Use Policy ausgearbeitet und definiert werden, die die Folgen eines Verstoßes gegen die Richtlinie klar umreißt.

Die erste Kontrollebene für den Remotezugriff besteht darin, eine Remotezugriffsrichtlinie über eine VPN-Verbindung anzuwenden, die nicht direkt mit dem Lab verbunden ist.

Im Rahmen der zweiten Kontrollebene wird ein Satz von Gruppenrichtlinienobjekten angewendet, die das Kopieren und Einfügen über Remotedesktop verhindern. Sie können auch eine Netzwerkrichtlinie implementieren, um keine aus der Umgebung ausgehenden Dienste wie FTP- und RDP-Dienste zuzulassen. Benutzerdefiniertes Routing kann erzwingen, dass der gesamte Azure-Datenverkehr zurück an lokale Umgebungen übermittelt wird. Allerdings kann das Routing nicht alle URLs erfassen, die das Hochladen von Daten ermöglichen, es sei denn, die Steuerung erfolgt über einen Proxy zum Überprüfen von Inhalten und Sitzungen. Öffentliche IP-Adressen können im virtuellen Netzwerk eingeschränkt werden, das DevTest Labs unterstützt, um den Transfer einer externen Netzwerkressource zu untersagen.

Letztendlich muss für die gesamte Organisation der gleiche Einschränkungstyp gelten, der auch alle Methoden von Wechselmedien oder externen URLs berücksichtigen, die einen Beitrag von Inhalten akzeptieren können. Wenden Sie sich an Ihren Sicherheitsexperten, um eine Sicherheitsrichtlinie zu überprüfen und zu implementieren. Weitere Empfehlungen finden Sie unter Microsoft-Cybersicherheit.

Anwendungsmigration und -integration

Nach der Einrichtung Ihrer Entwicklungs-/Test Lab-Umgebung müssen Sie sich die folgenden Fragen stellen:

• Wie verwenden Sie die Umgebung innerhalb Ihres Projektteams?
• Wie stellen Sie sicher, dass alle erforderlichen Organisationsrichtlinien befolgt werden und zugleich die Agilität erhalten bleibt, um Mehrwert für Ihre Anwendung zu generieren?

Azure Marketplace-Images im Vergleich mit benutzerdefinierten Images

Azure Marketplace sollte standardmäßig verwendet werden, sofern keine bestimmten Anliegen oder die Organisation betreffenden Anforderungen bestehen. Dies sind einige häufige Beispiele:

• Eine komplexe Softwareeinrichtung, bei der eine Anwendung als Teil des Basisimages enthalten sein muss.
• Installation und Einrichtung einer Anwendung können viele Stunden dauern, und dieses Hinzufügen zu einem Azure Marketplace-Image stellt keine effiziente Nutzung der Computezeit dar.
• Entwickler und Tester benötigen schnell Zugriff auf einen virtuellen Computer und möchten die erforderliche Zeit für die Einrichtung eines neuen virtuellen Computers minimieren.
• Compliance- oder behördliche Bestimmungen (z.B. Sicherheitsrichtlinien), die für alle Computer umgesetzt werden müssen.

Erwägen Sie die Verwendung benutzerdefinierter Images sorgfältig. Benutzerdefinierte Images führen zu zusätzlicher Komplexität, da Sie sich nun um die Verwaltung der VHD-Dateien für die zugrundeliegenden Basisimages kümmern müssen. Außerdem müssen Sie die Basisimages regelmäßig mit Softwareupdates patchen. Zu diesen Updates gehören neue Betriebssystemupdates und alle Updates oder Konfigurationsänderungen, die am Softwarepaket selbst erforderlich werden.

Formel- im Vergleich mit benutzerdefinierten Images

In der Regel sind die entscheidenden Faktoren Kosten und Wiederverwendbarkeit.

Sie können unter den folgenden Umständen die Kosten senken, indem Sie ein benutzerdefiniertes Image erstellen:

• Viele Benutzer oder Labs benötigen das Image.
• Das erforderliche Image verfügt über umfangreiche Software über dem Basisimage.

Diese Lösung bedeutet, dass Sie das Image ein Mal erstellen. Ein benutzerdefiniertes Image reduziert die Einrichtungszeit der VM. Bei der Ausführung der VM während des Setups fallen keine Kosten an.

Ein weiterer Faktor ist die Häufigkeit von Änderungen an Ihrem Softwarepaket. Wenn Sie täglich Builds ausführen und es erforderlich ist, dass Software auf den VMs Ihrer Benutzer vorhanden ist, ziehen Sie die Verwendung einer Formel anstelle eines benutzerdefinierten Images in Betracht.

Muster zum Einrichten der Netzwerkkonfiguration

Wenn Sie sicherstellen, dass Entwicklungs- und Test-VMs das öffentliche Internet nicht erreichen können, müssen zwei Aspekte berücksichtigt werden – eingehender und ausgehender Datenverkehr.

Eingehender Datenverkehr: Wenn die VM über keine öffentliche IP-Adresse verfügt, kann sie aus dem Internet nicht erreicht werden. Ein gängiger Ansatz besteht darin, eine Richtlinie auf Abonnementebene festzulegen, die sicherstellt, dass kein Benutzer eine öffentliche IP-Adresse erstellen kann.

Ausgehender Datenverkehr: Wenn Sie verhindern möchten, dass VMs direkte Verbindungen mit dem öffentlichen Internet herstellen und Datenverkehr durch eine Unternehmensfirewall senden können, können Sie den Datenverkehr lokal mithilfe von Azure ExpressRoute oder VPN routen, indem Sie erzwungenes Routing einsetzen.

Hinweis

Wenn Sie über einen Proxyserver verfügen, der ohne Proxyeinstellungen Datenverkehr blockiert, vergessen Sie nicht, Ausnahmen für das Speicherkonto des Labs für Artefakte hinzuzufügen.

Sie können außerdem Netzwerksicherheitsgruppen für virtuelle Computer oder Subnetze verwenden. Dieser Schritt fügt eine weitere Schutzschicht zum Zulassen/Blockieren von Datenverkehr hinzu.

Neues im Vergleich mit vorhandenem virtuellem Netzwerk

Wenn Ihre VMs mit vorhandener Infrastruktur interagieren müssen, sollten Sie die Verwendung eines vorhandenen virtuellen Netzwerks innerhalb Ihrer DevTest Labs-Umgebung in Erwägung ziehen. Wenn Sie ExpressRoute verwenden, minimieren Sie die Anzahl virtueller Netzwerke und Subnetze, sodass Sie den IP-Adressraum, der Ihren Abonnements zugewiesen ist, nicht fragmentieren. Sie sollten auch die Verwendung des Peeringmusters für virtuelle Netzwerke (Hub-Spoke-Modell) in Erwägung ziehen. Dieser Ansatz ermöglicht die abonnementübergreifende Kommunikation zwischen virtuellen Netzwerken und Subnetzen innerhalb einer bestimmten Region.

Jede DevTest Labs-Umgebung kann über ein eigenes virtuelles Netzwerk verfügen, aber es gibt Grenzwerte für die Anzahl virtueller Netzwerke pro Abonnement. Standardmäßig sind 50 möglich, dieser Grenzwert kann jedoch auf 100 heraufgesetzt werden.

Freigegebene, öffentliche oder private IP

Wenn Sie ein Standort-zu-Standort-VPN oder Express Route verwenden, ziehen Sie die Verwendung privater IPs in Erwägung, so dass auf Ihre Computer über Ihr internes Netzwerk zugegriffen werden kann, nicht aber aus dem öffentlichen Internet.

Hinweis

Labbesitzer können diese Subnetzrichtlinie ändern, um sicherzustellen, dass niemand versehentlich öffentliche IP-Adressen für seine VMs erstellt. Der Abonnementbesitzer sollte eine Abonnementrichtlinie einrichten, die das Erstellen öffentlicher IPs verhindert.

Bei der Verwendung gemeinsamer öffentlicher IPs teilen die virtuellen Computer in einem Lab eine öffentliche IP-Adresse. Dieser Ansatz kann nützlich sein, wenn Sie das Überschreiten des Grenzwerts für öffentliche IP-Adressen für ein bestimmtes Abonnement vermeiden müssen.

Labgrenzwerte

Es gibt mehrere Lab-Grenzwerte, die Sie beachten sollten. Diese Grenzwerte werden in den folgenden Abschnitten beschrieben.

Grenzwerte für Labs pro Abonnement

Es gibt keine bestimmte Beschränkung für die Anzahl von Labs, die pro Abonnement erstellt werden können. Allerdings ist die Menge der pro Abonnement nutzbaren Ressourcen begrenzt. Weitere Informationen finden Sie bei Bedarf in den Artikeln zu den Einschränkungen für Azure-Abonnements und Kontingente und zum Erhöhen dieser Limits.

Grenzwerte für VMs pro Lab

Es gibt keinen bestimmten Grenzwert für die Anzahl von VMs, die pro Lab erstellt werden können. Die Menge an Ressourcen pro Abonnement (VM-Kerne, öffentliche IP-Adressen usw.) ist jedoch begrenzt. Weitere Informationen finden Sie bei Bedarf in den Artikeln zu den Einschränkungen für Azure-Abonnements und Kontingente und zum Erhöhen dieser Limits.

Grenzen der Anzahl virtueller Computer pro Benutzer oder Lab

Beim Betrachten der Anzahl von VMs pro Benutzer oder Lab gibt es drei Hauptprobleme:

• Die Gesamtkosten, die das Team für Ressourcen im Lab aufwenden kann. Es ist natürlich kein Problem, viele Computer laufen zu lassen. Ein Mechanismus zur Kostenkontrolle besteht darin, die Anzahl der VMs pro Benutzer oder Lab zu beschränken.
• Die Gesamtzahl der virtuellen Computer in einem Lab wird durch die verfügbaren Kontingente auf Abonnementebene beeinflusst. Eine der Obergrenzen liegt bei 800 Ressourcengruppen pro Abonnement. DevTest Labs erstellt derzeit eine neue Ressourcengruppe für jeden virtuellen Computer (sofern keine gemeinsamen öffentlichen IP-Adressen verwendet werden). Wenn Sie 10 Labs in einem Abonnement betreiben, könnten pro Lab ungefähr 79 virtuelle Computer eingesetzt werden (Obergrenze von 800 – 10 Ressourcengruppen für die 10 Labs selbst) = 79 virtuelle Computer pro Lab.
• Wenn das Lab mithilfe von ExpressRoute (beispielsweise) mit dem lokalen Netzwerk verbunden ist, sind für das VNet/Subnetz definierte IP-Adressräume verfügbar. Um sicherzustellen, dass keine Fehler beim Erstellen von VMs im Lab auftreten (Fehler: IP-Adresse kann nicht abgerufen werden), können sich Lab-Besitzer beim Festlegen der maximalen Anzahl von VMs pro Lab am zur Verfügung stehenden IP-Adressraum orientieren.

Verwenden von Resource Manager-Vorlagen

Stellen Sie Ihre Resource Manager-Vorlagen bereit, indem Sie die Schritte unter Verwenden von Azure DevTest Labs für Testumgebungen ausführen. Im Wesentlichen checken Sie Ihre Resource Manager-Vorlagen in ein Azure Repos- oder GitHub Git-Repository ein und fügen dem Lab ein privates Repository für Ihre Vorlagen hinzu.

Dieses Szenario ist möglicherweise nicht sinnvoll, wenn Sie DevTest Labs zum Hosten von Entwicklungscomputern verwenden. Verwenden Sie dieses Szenario, um eine Stagingumgebung zu erstellen, die für die Produktion repräsentativ ist.

Die Option für die Anzahl von VMs pro Lab oder Benutzer schränkt nur die Anzahl der nativ im Lab selbst erstellten Computer ein. Diese Option schränkt nicht die Erstellung durch Umgebungen mit Resource Manager Vorlagen ein.