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

Article
11/13/2024

Les agents de pools DevOps managés peuvent être configurés pour s’exécuter dans un réseau virtuel isolé ou dans un réseau virtuel existant. Cet article explique comment configurer votre pool DevOps managé pour exécuter des agents dans votre réseau virtuel.

Ajout d’agents à votre propre réseau virtuel

Vous pouvez ajouter des agents à partir de pools DevOps managés à votre propre réseau virtuel pour des scénarios tels que :

Vos agents CI/CD doivent accéder aux ressources disponibles uniquement dans votre réseau d’entreprise via un service tel qu’Express Route
Vos agents CI/CD doivent accéder aux ressources isolées aux 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 atteints par des fonctionnalités de mise en réseau de pools DevOps managés prêtes à l’emploi

Vous pouvez ajouter les agents de votre pool à votre réseau virtuel en procédant comme suit.

Créer ou apporter votre réseau virtuel et votre sous-réseau
Déléguer le sous-réseau à Microsoft.DevOpsInfrastructure/pools
Associer le sous-réseau à votre pool DevOps managé

Les étapes précédentes délèguent le sous-réseau pour un accès exclusif par le pool et le sous-réseau ne peut pas être utilisé par d’autres pools ou ressources. Pour connecter plusieurs pools au même réseau virtuel, plusieurs sous-réseaux peuvent être utilisés, chaque 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 (incluez les 5 réserves Azure d’adresse IP dans le sous-réseau). Si vous utilisez Express Route, vous devez supprimer ou modifier temporairement le verrou de gestion sur le groupe de ressources pour autoriser les écritures.

Important

Le pool DevOps managé et le réseau virtuel doivent se trouver dans la même région, ou vous obtiendrez une erreur similaire à ce qui suit lorsque vous essayez de créer le pool ou de mettre à jour la configuration réseau. Virtual network MDPVN is in region eastus, but pool mdpnonprodsub is in region australiaeast. These must be in the same region.

Accorder l’accès Lecteur et Contributeur réseau au principal du service DevOpsInfrastructure

Vérifiez que le principal DevOpsInfrastructure dispose de l’accès suivant sur le réseau virtuel :

Reader et Network Contributor
Vous pouvez également ajouter l’autorisation suivante à un rôle personnalisé :
- 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. Un exemple de rôle peut être créé au niveau du groupe de ressources ou de l’abonnement dans l’onglet Contrôle d’accès, comme illustré dans l’exemple suivant.

Capture d’écran des autorisations de rôle personnalisées.

Pour vérifier l’accès au principal DevOpsInfrastructure

Choisissez Contrôle d’accès (IAM) pour le réseau virtuel, puis sélectionnez Vérifier l’accès.
Recherchez DevOpsInfrastructure et sélectionnez-le.
Vérifiez l’accès lecteur . Vérifiez que l’accès Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action et Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write l’accès Microsoft.Network/virtualNetworks/subnets/join/actionsont attribués. Votre rôle personnalisé doit apparaître ici.
Si DevOpsInfrastructure ne dispose pas de ces autorisations, ajoutez-les en choisissant Contrôle d’accès (IAM) pour le réseau virtuel, puis choisissez Accorder l’accès à cette ressource et ajoutez-les.

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

Le sous-réseau doit être délégué au sous-réseau Microsoft.DevOpsInfrastructure/pools à utiliser. Ouvrez les propriétés du sous-réseau dans le portail, puis sélectionnez Microsoft.DevOpsInfrastructure/pools sous la section Délégation de sous-réseau, puis choisissez Enregistrer.

Capture d’écran de la configuration de la délégation de sous-réseau.

Cela délègue le sous-réseau pour l’accès exclusif pour le pool et le sous-réseau ne peut pas être utilisé par d’autres pools ou ressources. Pour connecter plusieurs pools au même réseau virtuel, plusieurs sous-réseaux doivent être utilisés, chacun délégué et associé à son propre pool. Vous trouverez plus d’informations sur la délégation de sous-réseau ici.

Une fois le sous-réseau délégué, Microsoft.DevOpsInfrastructure/poolsle pool peut être mis à jour pour utiliser le sous-réseau.

Associer le sous-réseau à votre pool DevOps managé

Si vous créez un pool, accédez à l’onglet Mise en réseau. Pour mettre à jour un pool existant, accédez à Paramètres>Réseau et choisissez Agents injectés dans un réseau virtuel existant, Configurez.
Choisissez l’abonnement, Réseau virtuel et le sous-réseau auquel Microsoft.DevOpsInfrastructure/poolsvous avez délégué, puis cliquez sur Ok.

Une fois la mise à jour réseau terminée, la ressource nouvellement créée dans le pool utilise le sous-réseau délégué.

Si vous utilisez des modèles ARM, ajoutez une networkProfile propriété si elle n’existe pas déjà, puis ajoutez une subnetId propriété sous networkProfile l’ID de ressource de votre sous-réseau.

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

La mise en réseau est configurée à l’aide de la networkProfile propriété dans la section lors de la création ou de la fabricProfile mise à jour d’un pool. Pour un réseau isolé, omettez la propriété lors de la networkProfile création d’un pool.

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

L’exemple suivant montre la networkProfile section du fichier fabric-profile.json .

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

Restriction de la connectivité sortante

Si vous avez des systèmes en place sur votre réseau (NSG, Pare-feu, etc.) qui limitent la connectivité sortante, vous devez vous assurer que les domaines suivants sont accessibles, sinon votre pool DevOps managé ne sera pas fonctionnel. Tous sont HTTPS, sauf indication contraire.

Points de terminaison hautement sécurisés dont dépend notre service :
- *.prod.manageddevops.microsoft.com - Point de terminaison de pools DevOps gérés
- rmprodbuilds.azureedge.net - Fichiers binaires de travail
- vstsagentpackage.azureedge.net - Emplacement CDN de l’agent Azure DevOps
- *.queue.core.windows.net - File d’attente worker pour la communication avec le service Pools DevOps managés
- server.pipe.aria.microsoft.com - Solution de télémétrie côté client commune (et utilisée par l’extension validation du pool d’agents entre autres)
- azure.archive.ubuntu.com - Approvisionnement de machines Linux : il s’agit de HTTP, et non HTTPS
- www.microsoft.com - Approvisionnement de machines Linux
Points de terminaison moins sécurisés et plus ouverts dont dépend notre service :
- Nécessaire par notre service :
  - packages.microsoft.com - Approvisionnement de machines Linux
  - ppa.launchpad.net - Approvisionnement de machines Ubuntu
  - dl.fedoraproject.org - Approvisionnement de certaines distributions Linux
- Requis par l’agent Azure DevOps :
  - dev.azure.com
  - *.services.visualstudio.com
  - *.vsblob.visualstudio.com
  - *.vssps.visualstudio.com
  - *.visualstudio.com Ces entrées sont les domaines minimaux requis. Si vous rencontrez des problèmes, consultez la liste verte Azure DevOps pour obtenir la liste complète des domaines requis.

Si vous configurez votre pipeline Azure DevOps pour qu’il s’exécute à l’intérieur d’un conteneur, vous devez également autoriser la liste de la source de l’image conteneur (Docker ou ACR).

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 vos charges de travail s’exécutent sur votre pool DevOps managé pour s’exécuter derrière ce proxy, vous devez ajouter les variables d’environnement suivantes sur votre image.

VSTS_AGENT_INPUT_PROXYURL - URL du proxy configuré à exécuter 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, et pour Linux, ces variables doivent se trouver dans le fichier /etc/environment . La définition incorrecte de ces variables système ou sans service proxy configuré sur l’image entraîne l’échec de l’approvisionnement de nouveaux agents avec des problèmes de connectivité réseau.

Si vous effectuez une migration à partir d’agents Azure Virtual Machine Scale Set et que vous utilisez déjà les variables d’environnement proxy sur votre image, comme décrit dans les agents Azure Virtual Machine Scale Set - Personnalisation de la configuration de l’agent de pipeline, aucune modification ne doit être nécessaire.

Voir aussi

Configurer les paramètres du pool

Partager via