Konfigurieren von Netzwerknetzwerken für verwaltete DevOps-Pools

Sie können verwaltete DevOps-Pools-Agents so konfigurieren, dass sie in einem isolierten virtuellen Netzwerk oder in einem vorhandenen virtuellen Netzwerk ausgeführt werden. In diesem Artikel wird beschrieben, wie Sie Ihren Pool so konfigurieren, dass Agents in Ihrem virtuellen Netzwerk ausgeführt werden.

Auswählen des Netzwerktyps

Verwaltete DevOps-Pools unterstützen zwei Arten von Netzwerkkonfigurationen:

• Isoliertes virtuelles Netzwerk: Jeder Pool erhält ein eigenes isoliertes virtuelles Netzwerk, das vom Verwalteten DevOps-Pools-Dienst erstellt und verwaltet wird.
• In bestehendes virtuelles Netzwerk eingebundene Agenten: Sie können Ihr eigenes virtuelles Netzwerk und Subnetz verwenden. Alle virtuellen Computer, die für den Pool erstellt wurden, verwenden dieses Subnetz, und keine anderen Ressourcen können das Subnetz verwenden. Sie können Agents aus verwalteten DevOps-Pools zu Ihrem eigenen virtuellen Netzwerk hinzufügen, z. B.:
  • Ihre kontinuierlichen Integrations- und Kontinuierlichen Übermittlungs-Agents (CI/CD) müssen über einen Dienst wie Azure ExpressRoute auf Ressourcen zugreifen, die nur in Ihrem Unternehmensnetzwerk verfügbar sind.
  • Ihre CI/CD-Agents müssen auf Ressourcen zugreifen, die nur über private Endpunkte zugänglich sind.
  • Sie möchten Ihre CI/CD-Infrastruktur netzwerkisolieren, indem Sie Ihr eigenes virtuelles Netzwerk mit unternehmensspezifischen Firewallregeln bereitstellen.
  • Alle anderen eindeutigen Anwendungsfälle, die nicht durch standardmäßige Network-Features von verwalteten DevOps-Pools erreicht werden können.

Isoliertes virtuelles Netzwerk

Standardmäßig verwenden alle Pools ein von Microsoft bereitgestelltes virtuelles Netzwerk, das den gesamten eingehenden Datenverkehr einschränkt und über die folgenden Konfigurationsoptionen für ausgehenden Datenverkehr verfügt.

1. Standardmäßige ausgehende Zugriffskonnektivität ist der aktuelle Standardwert, der den gesamten ausgehenden Datenverkehr über eine von Microsoft bereitgestellte IP-Adresse zulässt. Standardmäßiger ausgehender Zugriff für VMs in Azure soll eingestellt werden. Wenn der standardmäßige ausgehende Zugriff eingestellt wird, werden Pools standardmäßig mit einer statischen IP-Adresse konfiguriert.
2. Anstatt den standardmäßigen ausgehenden Zugriff zu verwenden, können Sie Ihren Pool so konfigurieren, dass er bis zu 16 statische ausgehende IP-Adressen verwendet. Verwaltete DevOps-Pools erstellen ein NAT-Gateway in derselben Region wie Ihr Pool, um die IP-Adressen bereitzustellen. Mit dieser Konfiguration können Sie bestimmte IP-Adressen für externe Dienste zulassen, auf die Ihre Pipelines zugreifen müssen.
   • Das NAT-Gateway verursacht zusätzliche Azure-Kosten. Sie können modellieren, wie viel sie kosten wird, indem Sie den Azure-Kostenrechner verwenden. Weitere Informationen finden Sie unter Azure NAT Gateway-Preise.

{
    "name": "MyManagedDevOpsPool",
    "type": "Microsoft.DevOpsInfrastructure/pools",
    "apiVersion": "2025-09-20",
    ...
    "properties": {
        ...
        "fabricProfile": {
            "networkProfile": {
              "staticIpAddressCount": 1
            }
        }
    }
}

"networkProfile": {
   "ipAddresses": [
      "203.0.113.254"
    ],
    "staticIpAddressCount": 1
}

az mdp pool create \
   --fabric-profile fabric-profile.json
   # other parameters omitted for space

{
  "vmss": {
    "sku": {...},
    "images": [...],
    "osProfile": {...},
    "storageProfile": {...},
    "networkProfile": {
        "staticIpAddressCount": 1
    }
  }
}

resource managedDevOpsPools 'Microsoft.DevOpsInfrastructure/pools@2025-09-20' = {
  name: 'MyManagedDevOpsPool'
  ...
  properties: {
    ...
    fabricProfile: {
      networkProfile: {
        staticIpAddressCount: 1
      }
  }
}

In ein vorhandenes virtuelles Netzwerk eingefügte Agents

Sie können die Agents Ihres Pools so konfigurieren, dass sie Ihr virtuelles Netzwerk verwenden, indem Sie die folgenden Schritte ausführen:

1. Erstellen oder übertragen Sie Ihr virtuelles Netzwerk und Ihr Subnetz.
2. Delegieren Sie das Subnetz an Microsoft.DevOpsInfrastructure/pools.
3. Ordnen Sie das Subnetz Ihrem Pool zu.

Die vorstehenden Schritte delegieren das Subnetz für den exklusiven Zugriff durch den Pool. Andere Pools oder Ressourcen können das Subnetz nicht verwenden.

Ein Pool kann mehrere Subnetze verwenden, um mehrere Pools mit demselben virtuellen Netzwerk zu verbinden. Jedes Subnetz wird delegiert und einem eigenen Pool zugeordnet.

Erstellen oder Verwenden eines eigenen virtuelles Netzwerks und Subnetzes

Das Subnetz muss über genügend Adressraum verfügen, um die maximale Poolgröße des Pools aufzunehmen, den Sie zuordnen möchten (einschließlich der fünf IP-Adressen, die Azure im Subnetz reserviert).

Wenn Sie ExpressRoute verwenden, müssen Sie Schreibvorgänge zulassen, indem Sie die Verwaltungssperre für die Ressourcengruppe vorübergehend ablegen oder ändern.

Gewähren Sie Lesezugriff und Netzwerkmitwirkender-Zugriff auf den Dienstprinzipal DevOpsInfrastructure

Stellen Sie sicher, dass der DevOpsInfrastructure-Prinzipal Reader- und Network Contributor-Zugriff auf das virtuelle Netzwerk hat.

Statt integrierte Rollen zu verwenden, können Sie eine benutzerdefinierte Rolle erstellen, die über die folgenden Berechtigungen verfügt:

• Microsoft.Network/virtualNetworks/*/read
• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action
• Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write
• Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/delete

Erstellen Sie eine benutzerdefinierte Rolle für den Zugriff auf den Dienstverknüpfungslink. Sie können eine Beispielrolle auf ressourcengruppen- oder Abonnementebene auf der Registerkarte " Zugriffssteuerung " erstellen, wie im folgenden Beispiel gezeigt.

Überprüfen des Hauptzugriffs auf DevOpsInfrastructure

1. Wählen Sie access control (IAM) für das virtuelle Netzwerk aus, und wählen Sie dann "Zugriff überprüfen" aus.

   

2. Suchen Sie nach DevOpsInfrastructure, und wählen Sie sie aus.

   

3. Stellen Sie sicher, dass Sie zugriff auf Leseebene haben. Stellen Sie sicher, dass Microsoft.Network/virtualNetworks/subnets/join/action, Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/actionund Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write der Zugriff zugewiesen ist. Ihre benutzerdefinierte Rolle sollte hier angezeigt werden.

   

4. Wenn der DevOpsInfrastructure-Prinzipal nicht über diese Berechtigungen verfügt, fügen Sie sie hinzu. Wählen Sie access control (IAM) für das virtuelle Netzwerk aus, und wählen Sie dann "Zugriff auf diese Ressource gewähren" aus.

Delegieren des Subnetzes an Microsoft.DevOpsInfrastructure/pools

Öffnen Sie im Portal Subnetzeigenschaften, und wählen Sie unter Microsoft.DevOpsInfrastructure/pools aus. Wählen Sie Speichern aus.

Dieser Prozess delegiert das Subnetz für den exklusiven Zugriff für den Pool. Andere Pools oder Ressourcen können das Subnetz nicht verwenden. Um mehrere Pools mit demselben virtuellen Netzwerk zu verbinden, müssen Sie mehrere Subnetze verwenden. Jedes Subnetz muss delegiert und einem eigenen Pool zugeordnet werden. Weitere Informationen zur Subnetzdelegierung finden Sie in dieser Übersicht über die Subnetzdelegierung.

Nachdem Sie das Subnetz an Microsoft.DevOpsInfrastructure/pools delegiert haben, können Sie den Pool so aktualisieren, dass dieser das Subnetz verwendet.

Zuordnen des Subnetzes zu Ihrem Pool

{
    "name": "MyManagedDevOpsPool",
    "type": "Microsoft.DevOpsInfrastructure/pools",
    "apiVersion": "2025-09-20",
    "location": "eastus",
    "properties": {
        ...
        "fabricProfile": {
            "networkProfile": {
              "subnetId":"/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetwork/subnets/mySubnet",
            }
        }
    }
}

az mdp pool create \
   --fabric-profile fabric-profile.json
   # other parameters omitted for space

{
  "vmss": {
    "sku": {...},
    "images": [...],
    "osProfile": {...},
    "storageProfile": {...},
    "networkProfile": {
        "subnetId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetwork/subnets/mySubnet"
    }
  }
}

resource managedDevOpsPools 'Microsoft.DevOpsInfrastructure/pools@2025-09-20' = {
  name: 'MyManagedDevOpsPool'
  location: 'eastus'
  properties: {
    ...
    fabricProfile: {
      networkProfile: {
        subnetId: '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetwork/subnets/mySubnet'
      }
  }
}

Einschränken der ausgehenden Konnektivität

Wenn In Ihrem Netzwerk Systeme vorhanden sind (z. B. Netzwerksicherheitsgruppen oder Firewalls), die die ausgehende Konnektivität einschränken, müssen Sie einer Zulassungsliste bestimmte Endpunkte hinzufügen, um verwaltete DevOps-Pools vollständig zu unterstützen. Diese Endpunkte sind in global erforderliche Endpunkte (erforderlich auf jedem Computer mit verwalteten DevOps-Pools) und Endpunkten unterteilt, die Sie für bestimmte Szenarien benötigen. Alle Endpunkte sind HTTPS, sofern nicht anders angegeben.

Erforderliche Endpunkte zum Starten von verwalteten DevOps-Pools

Wenn Sie diese Endpunkte nicht zu einer Zulassungsliste hinzufügen, können Computer nicht als Teil des Diensts für verwaltete DevOps-Pools online sein, und Sie können keine Pipelines im Pool ausführen:

• *.prod.manageddevops.microsoft.com: Verwalteter DevOps Pools-Endpunkt, der für die Kommunikation mit dem Dienst "Managed DevOps Pools" verwendet wird.
• rmprodbuilds.azureedge.net: Wird zum Herunterladen der Binärdateien und Startskripts für verwaltete DevOps-Pools verwendet. Der Agentenanteil der Arbeitsbinärdateien wird von rm-agent.prod.manageddevops.microsoft.com heruntergeladen (früher heruntergeladen von agent.prod.manageddevops.microsoft.com), was durch den vorherigen erforderlichen Eintrag *.prod.manageddevops.microsoft.com abgedeckt wird.
• *.queue.core.windows.net: Arbeitswarteschlange für die Kommunikation mit dem Dienst für verwaltete DevOps-Pools.

Erforderliche Endpunkte für die Verbindung mit Azure DevOps

Wenn Sie diese Endpunkte nicht zu einer Zulassungsliste hinzufügen, kommen Computer möglicherweise online und wechseln möglicherweise sogar zu einem zugewiesenen Zustand, kommunizieren aber nicht mit Azure DevOps, da der Aufgaben-Agent von Azure DevOps Services entweder keine Verbindung herstellen kann oder nicht gestartet werden kann.

• download.agent.dev.azure.com: Der Speicherort des Content Delivery Network (CDN) des Azure DevOps-Agents, der zum Herunterladen des Azure DevOps-Agents verwendet wird (früher vstsagentpackage.azureedge.net; weitere Informationen finden Sie unter Edgio CDN für Azure DevOps wird eingestellt).
• dev.azure.com: Erforderlich für die Behandlung der Kommunikation mit Azure DevOps.

Erforderliche Endpunkte für Linux-Computer

Diese Endpunkte sind erforderlich, um Ubuntu-Computer zu starten, aber nicht notwendig, wenn nur Windows in einem Pool verwendet wird. Wenn Sie den Azure DevOps-Aufgaben-Agent einrichten, werden erforderliche Pakete hinzugefügt und ein apt-get Befehl ausgeführt. Dieser Vorgang schlägt fehl, wenn die folgenden Endpunkte nicht zu einer Positivliste hinzugefügt werden.

• azure.archive.ubuntu.com: Bereitstellen von Linux-Computern. Dieser Endpunkt ist HTTP (Port 80), nicht HTTPS (Port 443).
• www.microsoft.com: Bereitstellen von Linux-Computern.
• security.ubuntu.com: Bereitstellen von Linux-Computern.
• packages.microsoft.com: Bereitstellen von Linux-Computern.
• ppa.launchpad.net: Bereitstellen bestimmter Linux-Distributionen.
• dl.fedoraproject.org: Bereitstellen bestimmter Linux-Verteilungen.

Erforderliche Endpunkte für einige Azure DevOps-Features

Diese optionalen Endpunkte sind für bestimmte Azure DevOps-Features erforderlich, um an Ihren Pipelines zu arbeiten. Im folgenden Satz kann der Wildcard durch die spezifische Azure DevOps-Organisation ersetzt werden, die Ihre Pipeline hostet. Wenn Ihre Organisation beispielsweise contoso benannt ist, können Sie contoso.services.visualstudio.com anstelle von *.services.visualstudio.com verwenden.

• *.services.visualstudio.com
• *.vsblob.visualstudio.com: Wird sowohl für das Hochladen als auch für die Nutzung von Artefakten verwendet.
• *.vssps.visualstudio.com: Wird für die Authentifizierung mit Azure DevOps für bestimmte Features verwendet.
• *.visualstudio.com

Azure-bezogene Endpunkte

Virtuelle Azure-Computer (VMs) leiten möglicherweise Datenverkehr zu bestimmten Azure-Features über Ihr Subnetz weiter. Für diese Anforderungen können Sie Anforderungen direkt über Azure weiterleiten oder den Zugriff über Ihr Netzwerk aktivieren.

1. Konfigurieren von Azure-Datenverkehr für die Ausführung über Dienstendpunkte:

   Sie können den Datenverkehr direkt über Azure leiten, um die Belastung Ihrer Netzwerksicherheitsgruppen oder Firewalls durch zusätzlichen Durchsatz zu vermeiden. Sie müssen die in der folgenden Option aufgeführten Domänen nicht zu einer Zulassungsliste hinzufügen.

   Sie können z. B. die Datendatenträgerfunktion verwenden, um Netzwerkaufrufe an Azure Storage einzubeziehen. Wenn Sie den Microsoft.Storage-Dienstendpunkt in Ihrem Netzwerk aktivieren, leitet der Datenverkehr direkt über Azure weiter, wodurch Ihre Netzwerkregeln vermieden und die Last reduziert wird.

2. Um das Routing von Datenverkehr über Dienstendpunkte zu vermeiden, fügen Sie die md-*.blob.storage.azure.net Domäne zu Ihrer Zulassungsliste hinzu. Diese Domäne ist zum Konfigurieren eines Datenträgers erforderlich.

Akamai CDN-Übermittlungs-IPs

Am 1. Mai 2025 wechselten die Azure DevOps CDN-Ressourcen zu einer Lösung, die von Akamai und Azure Front Door bereitgestellt wurden. Stellen Sie sicher, dass Ihr Netzwerk über ausgehenden Zugriff auf Akamai-IP-Bereiche verfügt. Weitere Informationen finden Sie unter:

• Änderung der CDN-Domain-URL für Agents in Pipelines
• Häufig gestellte Fragen zur Deaktivierung von Azure CDN von Edgio
• Akamai TechDocs: Origin IP-Zugriffssteuerungsliste

Wenn Sie Ihre Azure DevOps-Pipeline für die Ausführung innerhalb eines Containers konfigurieren, müssen Sie auch die Quelle des Containerimages (Docker oder Azure Container Registry) zu einer Zulassungsliste hinzufügen.

Überprüfen der Endpunktkonnektivität

Vergewissern Sie sich, dass Sie ein Subnetz mit verwalteten DevOps-Pools verwenden können, indem Sie das folgende Skript für eine Ressource in diesem Subnetz ausführen. Dieser Schritt hilft Ihnen zu überprüfen, ob der Netzwerkfluss so konfiguriert ist, dass alle verfügbaren Endpunkte und die Verwaltete DevOps-Steuerungsebene erreicht werden.

Um das Skript mit PowerShell Core oder PowerShell 5 oder höher auszuführen, speichern Sie das folgende Skript unter ValidateMDPEndpoints.ps1. Führen Sie den folgenden PowerShell-Befehl aus: .\ValidateMDPEndpoints.ps1 -organization "<your-organization>".

# ValidateMDPEndpoints.ps1
param (
    [string]$organization
)
$azureDevOpsUris = @(
    "https://dev.azure.com",
    "https://vssps.dev.azure.com",
    "https://vsrm.dev.azure.com",
    "https://management.azure.com",
    "https://login.microsoftonline.com",
    "https://graph.microsoft.com",
    "https://aadcdn.msftauth.net",
    "https://${organization}.visualstudio.com",
    "https://${organization}.vsrm.visualstudio.com",
    "https://${organization}.vstmr.visualstudio.com",
    "https://${organization}.pkgs.visualstudio.com",
    "https://${organization}.vssps.visualstudio.com",
    "https://download.agent.dev.azure.com",
    "download.agent.dev.azure.com"
)
$managedDevOpsPoolsControlPlaneUris = @(
    # List of agent queue endpoints - maps to *.queue.core.windows.net
    "https://rmprodaedefaultcq.queue.core.windows.net",
    "https://rmprodbrsdefaultcq.queue.core.windows.net",
    "https://rmprodcncdefaultcq.queue.core.windows.net",
    "https://rmprodcusdefaultcq.queue.core.windows.net",
    "https://rmprodeus2defaultcq.queue.core.windows.net",
    "https://rmprodgwcdefaultcq.queue.core.windows.net",
    "https://rmprodincdefaultcq.queue.core.windows.net",
    "https://rmprodneudefaultcq.queue.core.windows.net",
    "https://rmprodseadefaultcq.queue.core.windows.net",
    "https://rmprodszndefaultcq.queue.core.windows.net",
    "https://rmproduksdefaultcq.queue.core.windows.net",
    "https://rmprodwus3defaultcq.queue.core.windows.net",
    # CDN for downloading the Managed DevOps Pools agent - maps to *.prod.managedevops.microsoft.com
    "rm-agent.prod.manageddevops.microsoft.com"
    # List of control plane endpoints - maps to *.manageddevops.microsoft.com
    "default.ae.prod.manageddevops.microsoft.com",
    "default.brs.prod.manageddevops.microsoft.com",
    "default.cnc.prod.manageddevops.microsoft.com",
    "default.cus.prod.manageddevops.microsoft.com",
    "default.eus2.prod.manageddevops.microsoft.com",
    "default.gwc.prod.manageddevops.microsoft.com",
    "default.inc.prod.manageddevops.microsoft.com",
    "default.neu.prod.manageddevops.microsoft.com",
    "default.sea.prod.manageddevops.microsoft.com",
    "default.szn.prod.manageddevops.microsoft.com",
    "default.uks.prod.manageddevops.microsoft.com",
    "default.wus3.prod.manageddevops.microsoft.com"
)
$unreachableUris = @()
foreach ($uri in $azureDevOpsUris) {
    try {
        $hostName = ($uri -replace "^https?://", "") -replace "/.*", ""
        $connection = Test-NetConnection -ComputerName $hostName -Port 443 -WarningAction SilentlyContinue
        if (-not $connection.TcpTestSucceeded) {
            $unreachableUris += $uri
        }
    } catch {
        $unreachableUris += $uri
    }
}
if ($unreachableUris.Count -eq 0) {
    Write-Output "All Azure DevOps endpoints are reachable."
} else {
    Write-Output "The following Azure DevOps endpoints could not be reached:"
    $unreachableUris | ForEach-Object { Write-Output $_ }
}
foreach ($uri in $managedDevOpsPoolsControlPlaneUris) {
    try {
        $hostName = ($uri -replace "^https?://", "") -replace "/.*", ""
        $connection = Test-NetConnection -ComputerName $hostName -Port 443 -WarningAction SilentlyContinue

        if (-not $connection.TcpTestSucceeded) {
            $unreachableUris += $uri
        }
    } catch {
        $unreachableUris += $uri
    }
}
if ($unreachableUris.Count -eq 0) {
    Write-Output "All Azure Managed DevOps Pools endpoints are reachable."
} else {
    Write-Output "The following Managed DevOps Pools endpoints could not be reached:"
    $unreachableUris | ForEach-Object { Write-Output $_ }
}

Konfigurieren des Azure DevOps-Agents für die Ausführung hinter einem Proxy

Wenn Sie einen Proxydienst für Ihr Image konfiguriert haben und möchten, dass die Workloads, die auf Ihrem Pool ausgeführt werden, hinter diesem Proxy ausgeführt werden sollen, müssen Sie die folgenden Umgebungsvariablen zu Ihrem Image hinzufügen:

• VSTS_AGENT_INPUT_PROXYURL: Die URL des konfigurierten Proxys, der im Hintergrund ausgeführt werden soll.
• VSTS_AGENT_INPUT_PROXYUSERNAME: Der Benutzername, der für die Verwendung des Proxys erforderlich ist.
• VSTS_AGENT_INPUT_PROXYPASSWORD: Das Kennwort für die Verwendung des Proxys.

Bei Windows sollten diese Umgebungsvariablen Systemumgebungsvariablen sein. Bei Linux sollten sich diese Variablen in der /etc/environment Datei befinden. Wenn Sie diese Systemvariablen falsch oder ohne einen konfigurierten Proxydienst auf dem Image festlegen, schlägt die Bereitstellung neuer Agents mit Netzwerkkonnektivitätsproblemen fehl.

Wenn Sie von Azure Virtual Machine Scale Sets Agents migrieren und bereits die Proxyumgebungsvariablen auf Ihrem Image verwenden, sollten Sie keine Änderungen vornehmen. Dieser Prozess wird in Azure Virtual Machine Scale Set Agents beschrieben: Anpassen der Konfiguration des Pipeline-Agents.

Verwandte Inhalte

• Konfigurieren von Pooleinstellungen
• Zulässige Azure DevOps-IP-Adressen und Domänen-URLs