Configurare la rete di pool DevOps gestiti

2025-07-08

Gli agenti di Pool DevOps gestiti possono essere configurati per l'esecuzione in una rete virtuale isolata o in una rete virtuale esistente. Questo articolo descrive come configurare il pool devOps gestito per eseguire gli agenti nella rete virtuale.

Aggiunta di agenti alla propria rete virtuale

È possibile aggiungere agenti da pool DevOps gestiti alla propria rete virtuale per scenari come:

Gli agenti CI/CD devono accedere alle risorse disponibili solo nella rete aziendale tramite un servizio come ExpressRoute
Gli agenti CI/CD devono accedere alle risorse che sono isolate su endpoint privati.
Si vuole isolare l'infrastruttura CI/CD implementando la propria rete virtuale con regole del firewall specifiche della tua azienda
Qualsiasi altro caso d'uso univoco che non può essere ottenuto dalle funzionalità standard relative alla rete dei pool di DevOps gestiti.

È possibile aggiungere gli agenti del pool alla rete virtuale seguendo questa procedura.

Crea o porta la tua rete virtuale e la subnet virtuale
Assegna la delega della subnet a Microsoft.DevOpsInfrastructure/pools
Associare la subnet al pool DevOps gestito

I passaggi precedenti delegano la subnet per l'accesso esclusivo dal pool e la subnet non può essere usata da altri pool o risorse. Per connettere più pool alla stessa rete virtuale, è possibile usare più subnet, ognuna delegata e associata al proprio pool.

Creare o portare la rete virtuale e la subnet

La subnet deve avere spazio di indirizzi sufficiente per supportare le dimensioni massime del pool che si vuole associare (includere il 5 indirizzo IP riservato da Azure nella subnet). Se si usa ExpressRoute, è necessario eliminare o modificare il blocco di gestione nel gruppo di risorse per consentire le scritture.

Importante

Il pool DevOps gestito e la rete virtuale devono trovarsi nella stessa area oppure si riceverà un errore simile al seguente quando si tenta di creare il pool o aggiornare la configurazione di rete. Virtual network MDPVN is in region eastus, but pool mdpnonprodsub is in region australiaeast. These must be in the same region.

Concedere l'accesso come Lettore e Collaboratore di Rete all'entità principale del servizio DevOpsInfrastructure

Verificare che l'entità DevOpsInfrastructure abbia il seguente accesso alla rete virtuale.

Reader e Network Contributor
In alternativa, aggiungere l'autorizzazione seguente a un ruolo personalizzato:
- 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

Creare un ruolo personalizzato per l'accesso a Service Association Link. È possibile creare un ruolo di esempio a livello di gruppo di risorse o sottoscrizione nella scheda Controllo di accesso, come illustrato nell'esempio seguente.

Screenshot delle autorizzazioni personalizzate per i ruoli.

Controllare l'accesso del principale DevOpsInfrastructure

Scegliere Controllo di accesso (IAM) per la rete virtuale e scegliere Controlla accesso.
Cerca DevOpsInfrastructure e selezionalo.
Verificare l'accesso del lettore. Verificare che l'accesso a Microsoft.Network/virtualNetworks/subnets/join/action, Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action e Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write sia assegnato. Il ruolo personalizzato dovrebbe essere visualizzato qui.
Se DevOpsInfrastructure non dispone di tali autorizzazioni, aggiungerle scegliendo Controllo di accesso (IAM) per la rete virtuale e scegliere Concedi l'accesso a questa risorsa e aggiungerle.

Delegare la sottorete a Microsoft.DevOpsInfrastructure/pools

La subnet deve essere delegata all'oggetto Microsoft.DevOpsInfrastructure/pools da usare. Aprire le proprietà della subnet nel portale e selezionare Microsoft.DevOpsInfrastructure/pools nella sezione Delega subnet e scegliere Salva.

Screenshot della configurazione di delega della subnet.

Questo delega la subnet per l'accesso esclusivo per il pool e la subnet non può essere usata da altri pool o risorse. Per connettere più pool alla stessa rete virtuale, è necessario usare più subnet, ognuna delegata e associata al proprio pool. Altre informazioni sulla delega della subnet sono disponibili qui.

Dopo che la subnet è delegata a Microsoft.DevOpsInfrastructure/pools, il pool può essere aggiornato per utilizzare la subnet.

Associare la subnet al pool DevOps gestito

Se si sta creando un nuovo pool, passare alla scheda Rete. Per aggiornare un pool esistente, passare a Impostazioni>rete e scegliere Agenti inseriti nella rete virtuale esistente, Configura.
Scegliere la Sottoscrizione, la Rete virtuale e la Subnet che hai delegato a Microsoft.DevOpsInfrastructure/pools, e scegliere OK.

Al termine dell'aggiornamento di rete, la risorsa appena creata nel pool userà la subnet delegata.

Se si utilizzano modelli ARM, aggiungere una proprietà networkProfile nella sezione fabricProfile , quindi aggiungere una proprietà subnetId sotto networkProfile con l'ID della risorsa della subnet.

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

La rete viene configurata usando la proprietà networkProfile nella sezione fabricProfile durante la creazione o l'aggiornamento di un pool. Per una rete isolata, omettere la proprietà networkProfile durante la creazione di un pool.

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

Nell'esempio seguente viene illustrata la networkProfile sezione del file 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"
    }
  }
}

Limitazione della connettività in uscita

Se nella rete sono presenti sistemi (NSG, Firewall e così via) che limitano la connettività in uscita, alcuni endpoint devono essere consentiti per supportare completamente i pool DevOps gestiti. Questi endpoint sono suddivisi in endpoint necessari a livello globale (necessari in qualsiasi computer di pool DevOps gestiti) ed endpoint necessari per determinati scenari. Tutti gli endpoint sono HTTPS, se non diversamente specificato.

Endpoint necessari per l'avvio del pool devOps gestito: senza consentire l'inserimento di questi endpoint, i computer non verranno online come parte del servizio e non sarà possibile eseguire pipeline nel pool devOps gestito
- *.prod.manageddevops.microsoft.com - Endpoint dei pool DevOps gestiti, utilizzato per comunicare con il servizio di pool DevOps gestiti.
- rmprodbuilds.azureedge.net - Usato per scaricare i file binari di lavoro dei pool di DevOps gestiti e gli script di avvio. La parte agente dei file binari del lavoratore viene scaricata da rm-agent.prod.manageddevops.microsoft.com, (precedentemente scaricata da agent.prod.manageddevops.microsoft.com), ed è coperta dalla precedente voce obbligatoria *.prod.manageddevops.microsoft.com.
- *.queue.core.windows.net - Coda dei lavoratori per la comunicazione con il servizio di Pool gestiti DevOps.
Endpoint necessari per la connessione ad Azure DevOps: senza inserire questi endpoint in whitelist, le macchine possono essere online e persino passare a uno stato "allocato", ma potrebbero non riuscire a comunicare con Azure DevOps perché l'agente del processo di lavoro VSTS non può connettersi o non può avviarsi.
- download.agent.dev.azure.com - Posizione della rete CDN dell'agente Azure DevOps, usata per scaricare l'agente Azure DevOps (in precedenza vstsagentpackage.azureedge.net . Per altre informazioni, vedere La rete CDN Edgio per Azure DevOps è in fase di ritiro).
- dev.azure.com - Obbligatorio per gestire la comunicazione con Azure DevOps
- Preparazione dei computer Linux: questi endpoint sono necessari per avviare computer Ubuntu, ma non sono necessari se un pool usa solo Windows. Nell'ambito della configurazione dell'agente di attività di Azure DevOps vengono aggiunti alcuni pacchetti necessari e viene eseguita un'operazione apt-get, che avrà esito negativo senza che questi siano consentiti.
  - azure.archive.ubuntu.com - Provisioning di macchine Linux - ecco HTTP (porta 80), non HTTPS (porta 443)
  - www.microsoft.com - Provisioning di macchine Linux
  - security.ubuntu.com - Provisioning di macchine Linux
  - packages.microsoft.com - Provisioning di macchine Linux
  - ppa.launchpad.net - Implementazione di distribuzioni Linux specifiche
  - dl.fedoraproject.org - Configurazione di determinate distribuzioni Linux
Facoltativo, ma necessario per funzionalità specifiche di Azure DevOps per lavorare sulle pipeline. Nel set seguente, il carattere jolly può essere sostituito con l'organizzazione specifica di Azure DevOps che ospita la pipeline. Ad esempio, se l'organizzazione è denominata contoso, è possibile usare contoso.services.visualstudio.com anziché *.services.visualstudio.com.
- *.services.visualstudio.com
- *.vsblob.visualstudio.com - Usato per gli artefatti, sia per il caricamento che per il consumo
- *.vssps.visualstudio.com - Usato per l'autenticazione con Azure DevOps per determinate funzionalità
- *.visualstudio.com
  
  Annotazioni
  
  Le voci precedenti sono i domini minimi necessari. In caso di problemi, vedere Indirizzi IP e URL di dominio consentiti di Azure DevOps per l'elenco completo dei domini necessari.
Endpoint correlati ad Azure: le macchine virtuali di Azure possono instradare il traffico verso delle specifiche funzionalità di Azure attraverso la sottorete. Per queste richieste, è possibile instradare direttamente le richieste tramite Azure o abilitare l'accesso tramite la rete.
1. Configurazione del traffico di Azure per far passare tramite Endpoint di Servizio
  
  Il routing del traffico tramite Azure evita direttamente l'aumento della larghezza di banda nei gruppi di sicurezza di rete o nei firewall e non richiede di consentire l'accesso ai domini menzionati nell'opzione seguente.
  
  Ad esempio, l'uso della funzionalità disco dati comporta chiamate di rete ad Azure Storage. L'abilitazione di endpoint di servizio Microsoft.Storage nella rete instrada il traffico direttamente attraverso Azure, evitando le regole di rete e riducendo il carico.
2. Se si vuole evitare di instradare il traffico tramite endpoint di servizio, questi sono i domini da consentire per funzionalità specifiche.
  - md-*.blob.storage.azure.net : necessario per configurare un disco dati
INDIRIZZI IP per la distribuzione della rete CDN Akamai: a partire dal 1° maggio 2025, gli asset della rete CDN di Azure DevOps stanno passando a una soluzione servita da Akamai e da Frontdoor di Azure. Verificare che la rete abbia accesso in uscita agli intervalli IP Akamai. Per altre informazioni, vedere:

Se si configura la pipeline di Azure DevOps per l'esecuzione all'interno di un contenitore, è necessario anche inserire nella lista consentita la sorgente dell'immagine del contenitore (Docker o Azure Container Registry, ACR).

Configurare l'agente Azure DevOps per l'esecuzione dietro un proxy

Se è stato configurato un servizio proxy nell'immagine e si vuole che i carichi di lavoro in esecuzione nel pool DevOps gestito vengano eseguiti dietro questo proxy, è necessario aggiungere le variabili di ambiente seguenti nell'immagine.

VSTS_AGENT_INPUT_PROXYURL - URL del proxy configurato per esecuzione retrostante.
VSTS_AGENT_INPUT_PROXYUSERNAME - Nome utente necessario per usare il proxy
VSTS_AGENT_INPUT_PROXYPASSWORD - Password per l'uso del proxy.

Per Windows, queste variabili di ambiente devono essere variabili di ambiente di sistema e per Linux queste variabili devono trovarsi nel file /etc/environment . L'impostazione errata di queste variabili di sistema o l'assenza di un servizio proxy configurato sull'immagine causa il fallimento del provisioning di nuovi agenti per problemi di connessione alla rete.

Se si esegue la migrazione dagli agenti del set di scalabilità di Azure Virtual Machines e si usano già le variabili di ambiente proxy nell'immagine, come descritto in Agenti del set di scalabilità di Azure Virtual Machines - Personalizzazione della configurazione dell'agente della pipeline, non è necessario apportare modifiche.