Configurer la mise en réseau des pools DevOps managés

Vous pouvez configurer des agents de pools DevOps gérés pour qu’ils s’exécutent dans un réseau virtuel isolé ou dans un réseau virtuel existant. Cet article explique comment configurer votre pool pour exécuter des agents dans votre réseau virtuel.

Choisir votre type de réseau

Les pools DevOps managés prennent en charge deux types de configurations réseau :

• Réseau virtuel isolé : chaque pool obtient son propre réseau virtuel isolé créé et géré par le service Pools DevOps gérés.
• Agents injectés dans un réseau virtuel existant : vous pouvez apporter votre propre réseau virtuel et sous-réseau. Toutes les machines virtuelles créées pour le pool utiliseront ce sous-réseau et aucune autre ressource ne pourra utiliser le sous-réseau. Vous pouvez ajouter des agents à partir de pools DevOps managés à votre propre réseau virtuel pour des scénarios tels que :
  • Vos agents d’intégration continue et de livraison continue (CI/CD) doivent accéder aux ressources disponibles uniquement dans votre réseau d’entreprise via un service tel qu’Azure ExpressRoute.
  • Vos agents CI/CD doivent accéder à des ressources qui sont isolées sur des points de terminaison privés.
  • Vous souhaitez isoler votre infrastructure CI/CD en apportant votre propre réseau virtuel avec des règles de pare-feu spécifiques à l’entreprise.
  • Tous les autres cas d’usage uniques qui ne peuvent pas être réalisés avec les fonctionnalités de mise en réseau standard des pools DevOps managés.

Réseau virtuel isolé

Par défaut, tous les pools utilisent un réseau virtuel fourni par Microsoft, qui restreint tout le trafic entrant et dispose des options de configuration de trafic sortant suivantes.

1. La connectivité d’accès sortant par défaut est la valeur par défaut actuelle, qui autorise tout le trafic sortant à l’aide d’une adresse IP fournie par Microsoft. L’accès sortant par défaut pour les machines virtuelles dans Azure est planifié pour être mis hors service. Lorsque l’accès sortant par défaut est supprimé, les pools sont configurés avec une adresse IP statique par défaut.
2. Au lieu d’utiliser l’accès sortant par défaut, vous pouvez configurer votre pool pour qu’il utilise jusqu’à 16 adresses IP sortantes statiques. Les pools DevOps gérés créent une passerelle NAT dans la même région que votre pool pour fournir les adresses IP. Cette configuration vous permet d’autoriser la liste d’adresses IP spécifiques sur les services externes auxquels vos pipelines doivent accéder.
   • La passerelle NAT entraîne des coûts Azure supplémentaires. Vous pouvez modéliser le coût de l’opération à l’aide de la calculatrice de coûts Azure. Pour plus d’informations, consultez la tarification de la passerelle NAT Azure.

{
    "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
      }
  }
}

Agents injectés dans un réseau virtuel existant

Vous pouvez configurer les agents de votre pool pour utiliser votre réseau virtuel en procédant comme suit :

1. Créez ou apportez votre réseau virtuel et votre sous-réseau.
2. Déléguer le sous-réseau à Microsoft.DevOpsInfrastructure/pools.
3. Associez le sous-réseau à votre pool.

Les étapes précédentes délèguent le sous-réseau pour un accès exclusif par le pool. D’autres pools ou ressources ne peuvent pas utiliser le sous-réseau.

Un pool peut utiliser plusieurs sous-réseaux pour connecter plusieurs pools au même réseau virtuel. Chaque sous-réseau est délégué et associé à son propre pool.

Créer ou apporter votre réseau virtuel et votre sous-réseau

Le sous-réseau doit avoir suffisamment d’espace d’adressage pour prendre en charge la taille maximale du pool que vous souhaitez associer (y compris les cinq adresses IP qu’Azure réserve dans le sous-réseau).

Si vous utilisez ExpressRoute, vous devez autoriser les écritures en supprimant ou en modifiant temporairement le verrou de gestion sur le groupe de ressources.

Accorder les accès Lecteur et Contributeur réseau au service principal DevOpsInfrastructure

Vérifiez que le DevOpsInfrastructure principal a Reader et Network Contributor accès au réseau virtuel.

Au lieu d’utiliser des rôles intégrés, vous pouvez créer un rôle personnalisé disposant des autorisations suivantes :

• 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

Définissez un rôle personnalisé pour l'accès au lien d'association de services. Vous pouvez créer un exemple de rôle au niveau du groupe de ressources ou de l’abonnement sous l’onglet Contrôle d’accès , comme illustré dans l’exemple suivant.

Vérifier l’accès principal pour DevOpsInfrastructure

1. Sélectionnez Contrôle d’accès (IAM) pour le réseau virtuel, puis cochez l’accès.

   

2. Recherchez et sélectionnez DevOpsInfrastructure.

   

3. Vérifiez que vous disposez d’un accès au niveau Lecteur. Vérifiez que les accès Microsoft.Network/virtualNetworks/subnets/join/action, Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action, et Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write sont attribués. Votre rôle personnalisé doit apparaître ici.

   

4. Si le principal DevOpsInfrastructure n’a pas ces autorisations, ajoutez-les. Sélectionnez Contrôle d’accès (IAM) pour le réseau virtuel, puis accorder l’accès à cette ressource.

Déléguer le sous-réseau à Microsoft.DevOpsInfrastructure/pools

Dans le portail, ouvrez les propriétés du sous-réseau et sélectionnez Microsoft.DevOpsInfrastructure/pools sous Délégation de sous-réseau. Cliquez sur Enregistrer.

Ce processus délègue le sous-réseau pour un accès exclusif au pool. D’autres pools ou ressources ne peuvent pas utiliser le sous-réseau. Pour connecter plusieurs pools au même réseau virtuel, vous devez utiliser plusieurs sous-réseaux. Chaque sous-réseau doit être délégué et associé à son propre pool. Vous trouverez plus d’informations sur la délégation de sous-réseau dans cette vue d’ensemble de la délégation de sous-réseau.

Après avoir délégué le sous-réseau à Microsoft.DevOpsInfrastructure/pools, vous pouvez mettre à jour le pool pour utiliser le sous-réseau.

Associer le sous-réseau à votre 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'
      }
  }
}

Restreindre la connectivité sortante

Si vous avez des systèmes en place sur votre réseau (par exemple, des groupes de sécurité réseau ou des pare-feu) qui limitent la connectivité sortante, vous devez ajouter certains points de terminaison à une liste verte pour prendre entièrement en charge les pools DevOps gérés. Ces points de terminaison sont divisés en points de terminaison globalement requis (nécessaires sur n’importe quel ordinateur utilisant des pools DevOps managés) et des points de terminaison dont vous avez besoin pour certains scénarios. Tous les points de terminaison sont HTTPS, sauf indication contraire.

Points de terminaison requis pour démarrer des pools DevOps managés

Si vous n’ajoutez pas ces points de terminaison à une liste d'autorisation, les machines ne parviennent pas à se connecter dans le cadre du service de pools DevOps gérés, et vous ne pouvez pas exécuter de pipelines sur le pool.

• *.prod.manageddevops.microsoft.com: point de terminaison des pools DevOps managés utilisé pour communiquer avec le service des pools DevOps managés.
• rmprodbuilds.azureedge.net: utilisé pour télécharger les fichiers binaires worker des pools DevOps managés et les scripts de démarrage. La partie agent des fichiers binaires worker est téléchargée à partir rm-agent.prod.manageddevops.microsoft.com (anciennement téléchargée à partir de agent.prod.manageddevops.microsoft.com), qui est couverte par l’entrée obligatoire *.prod.manageddevops.microsoft.com précédente.
• *.queue.core.windows.net: file d’attente de tâches pour communiquer avec le service Pools DevOps gérés.

Points de terminaison requis pour la connexion à Azure DevOps

Si vous n’ajoutez pas ces points de terminaison à une liste d'autorisation, les machines peuvent être en ligne et peuvent même passer à un état alloué, mais ne pas communiquer avec Azure DevOps, car l’agent de tâche Azure DevOps Services ne peut ni se connecter ni démarrer.

• download.agent.dev.azure.com: Emplacement du réseau de distribution de contenu (CDN) de l’agent Azure DevOps, utilisé pour télécharger l’agent Azure DevOps (anciennement vstsagentpackage.azureedge.net; pour plus d’informations, consultez Edgio CDN pour Azure DevOps en cours de mise hors service).
• dev.azure.com: Requis pour gérer la communication avec Azure DevOps.

Points de terminaison requis pour les machines Linux

Ces points de terminaison sont nécessaires pour faire tourner des machines Ubuntu, mais ne sont pas nécessaires si un pool utilise uniquement Windows. Lorsque vous configurez l’agent de tâche Azure DevOps, les packages requis sont ajoutés et une apt-get commande est exécutée. Ce processus échoue si les points de terminaison suivants ne sont pas ajoutés à une liste verte.

• azure.archive.ubuntu.com: approvisionnement de machines Linux. Ce point de terminaison est HTTP (port 80), et non HTTPS (port 443).
• www.microsoft.com: approvisionnement de machines Linux.
• security.ubuntu.com: approvisionnement de machines Linux.
• packages.microsoft.com: approvisionnement de machines Linux.
• ppa.launchpad.net: approvisionnement de certaines distributions Linux spécifiques.
• dl.fedoraproject.org: approvisionnement de certaines distributions Linux.

Points de terminaison requis pour certaines fonctionnalités Azure DevOps

Ces points de terminaison facultatifs sont requis pour que des fonctionnalités Azure DevOps spécifiques fonctionnent sur vos pipelines. Dans le groupe ci-dessous, le joker peut être remplacé par l'organisation Azure DevOps spécifique qui héberge votre pipeline. Par exemple, si votre organisation est nommée contoso, vous pouvez utiliser contoso.services.visualstudio.com au lieu de *.services.visualstudio.com.

• *.services.visualstudio.com
• *.vsblob.visualstudio.com: utilisé pour charger et consommer des artefacts.
• *.vssps.visualstudio.com: utilisé pour l’authentification auprès d’Azure DevOps pour certaines fonctionnalités.
• *.visualstudio.com

Points de terminaison liés à Azure

Les machines virtuelles Azure peuvent acheminer le trafic vers certaines fonctionnalités Azure via votre sous-réseau. Pour ces demandes, vous pouvez router les demandes directement via Azure ou activer l’accès via votre réseau.

1. Configurez le trafic Azure pour qu’il s’exécute via des points de terminaison de service :

   Vous pouvez router le trafic directement via Azure pour éviter d’ajouter du débit à vos groupes de sécurité réseau ou pare-feu. Vous n’avez pas besoin d’ajouter les domaines répertoriés dans l’option suivante à une liste d'autorisation.

   Par exemple, vous pouvez utiliser la fonctionnalité de disque de données pour impliquer des appels réseau vers stockage Azure. Lorsque vous activez le point de terminaison de service Microsoft.Storage sur votre réseau, le trafic est acheminé directement via Azure, ce qui évite vos règles réseau et réduit la charge.

2. Pour éviter le routage du trafic via des points de terminaison de service, ajoutez le domaine md-*.blob.storage.azure.net à votre liste d'autorisation. Ce domaine est requis pour la configuration d’un disque de données.

Adresses IP de distribution CDN Akamai

Le 1er mai 2025, les ressources CDN Azure DevOps ont été transférées vers une solution fournie par Akamai et Azure Front Door. Vérifiez que votre réseau dispose d’un accès sortant aux plages d’adresses IP Akamai. Pour plus d’informations, consultez :

• Modification de l’URL de domaine CDN pour les agents dans les pipelines
• FAQ sur le retrait d'Azure CDN d'Edgio
• Akamai TechDocs : Liste de contrôle d’accès IP d’origine

Si vous configurez votre pipeline Azure DevOps pour être exécuté à l'intérieur d'un conteneur, vous devez également ajouter la source de l'image de conteneur (Docker ou Azure Container Registry) à une liste d'autorisations.

Valider la connectivité des points de terminaison

Vérifiez que vous pouvez utiliser un sous-réseau avec des pools DevOps managés en exécutant le script suivant sur une ressource sur ce sous-réseau. Cette étape vous aidera à vérifier que le flux réseau est configuré pour atteindre tous ces points de terminaison disponibles et le plan de contrôle DevOps managé.

Pour exécuter le script avec PowerShell Core ou PowerShell 5 ou version ultérieure, enregistrez le script ValidateMDPEndpoints.ps1suivant sous . Exécutez la commande PowerShell suivante : .\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 $_ }
}

Configurer l’agent Azure DevOps pour qu’il s’exécute derrière un proxy

Si vous avez configuré un service proxy sur votre image et souhaitez que les charges de travail qui s’exécutent sur votre pool s’exécutent derrière ce proxy, vous devez ajouter les variables d’environnement suivantes sur votre image :

• VSTS_AGENT_INPUT_PROXYURL: L’URL du proxy configuré pour fonctionner derrière.
• VSTS_AGENT_INPUT_PROXYUSERNAME: nom d’utilisateur nécessaire pour utiliser le proxy.
• VSTS_AGENT_INPUT_PROXYPASSWORD: mot de passe à utiliser le proxy.

Pour Windows, ces variables d’environnement doivent être des variables d’environnement système. Pour Linux, ces variables doivent se trouver dans le /etc/environment fichier. Si vous définissez ces variables système de manière incorrecte ou sans service proxy configuré sur l’image, l’approvisionnement de nouveaux agents échoue avec des problèmes de connectivité réseau.

Si vous effectuez une migration à partir d’agents Azure Virtual Machine Scale Sets et que vous utilisez déjà les variables d’environnement proxy sur votre image, vous n’avez pas besoin d’apporter de modifications. Ce processus est décrit dans Personnaliser la configuration de l’agent de pipeline pour les agents d'ensemble de machines virtuelles à échelle Azure.

Contenu connexe

• Configurer les paramètres du pool
• Adresses IP et URL de domaine autorisées pour Azure DevOps