Condividi tramite

Configurare la rete di pool DevOps gestiti

È possibile configurare gli agenti di pool DevOps gestiti per l'esecuzione in una rete virtuale isolata o in una rete virtuale esistente. Questo articolo descrive come configurare il pool per eseguire gli agenti nella rete virtuale.

Scegliere il tipo di rete

I pool DevOps gestiti supportano due tipi di configurazioni di rete:

  • Rete virtuale isolata: ogni pool ottiene la propria rete virtuale isolata creata e gestita dal servizio Pool devOps gestiti.
  • Agenti inseriti nella rete virtuale esistente: è possibile usare la propria rete virtuale e la propria subnet. Tutte le macchine virtuali create per il pool useranno tale subnet e nessun'altra risorsa sarà in grado di usare la subnet. È possibile aggiungere agenti da pool DevOps gestiti alla propria rete virtuale per scenari come:
    • Gli agenti di integrazione continua e recapito continuo (CI/CD) devono accedere alle risorse disponibili solo nella rete aziendale tramite un servizio come Azure ExpressRoute.
    • Gli agenti di CI/CD devono accedere a risorse che sono isolate tramite endpoint privati.
    • Vuoi isolare la tua infrastruttura CI/CD portando la tua rete virtuale con regole del firewall specifiche per la tua azienda.
    • Qualsiasi altro caso d'uso univoco che non può essere ottenuto dalle funzionalità di rete dei pool devOps gestiti predefiniti.

Rete virtuale isolata

Per impostazione predefinita, tutti i pool usano una rete virtuale fornita da Microsoft, che limita tutto il traffico in ingresso e include le opzioni di configurazione del traffico in uscita seguenti.

  1. La connettività di accesso in uscita predefinita è l'impostazione predefinita corrente, che consente tutto il traffico in uscita usando un indirizzo IP fornito da Microsoft. L'accesso in uscita predefinito per le macchine virtuali in Azure è pianificato per essere ritirato. Quando l'accesso in uscita predefinito viene ritirato, i pool verranno configurati con un indirizzo IP statico per impostazione predefinita.
  2. Anziché usare l'accesso in uscita predefinito, è possibile configurare il pool in modo da usare fino a 16 indirizzi IP statici in uscita. I pool DevOps gestiti creeranno un gateway NAT nella stessa area del pool per fornire gli indirizzi IP. Questa configurazione consente di consentire indirizzi IP specifici nei servizi esterni a cui devono accedere le pipeline.
    • Il gateway NAT comporta costi aggiuntivi di Azure. È possibile modellare la quantità di costi usando il calcolatore dei costi di Azure. Per altre informazioni, vedere Prezzi del gateway NAT di Azure.

Importante

Se si modifica il numero di indirizzi IP statici dopo la creazione del pool, gli indirizzi IP sono soggetti a modifica e sarà necessario ottenere i nuovi indirizzi IP e aggiornare l'elenco di indirizzi consentiti nei servizi esterni al termine dell'operazione di aggiornamento.

Per configurare le impostazioni indirizzo IP durante la creazione di un pool, passare alla scheda Rete . Per aggiornare un pool esistente, passare a Impostazioni>rete.

Scegliere Nessuno per Instradamento attraverso indirizzi IP pubblici per utilizzare l'accesso in uscita predefinito.

Scegliere Indirizzi IP forniti da Microsoft per configurare indirizzi IP statici in uscita e specificare il numero di indirizzi IP statici che si desidera usare. I pool DevOps gestiti creano automaticamente un gateway NAT e gestiscono gli indirizzi IP.

Screenshot delle impostazioni dell'indirizzo IP.

Annotazioni

Si verifica un problema noto: se il pool è configurato con un'identità gestita, le chiamate API non restituiranno la ipAddresses proprietà a meno che all'entità servizio DevOpsInfrastructure non venga assegnato il ruolo Operatore identità gestita nell'identità gestita. Per i passaggi dettagliati, vedere Assegnare ruoli di Azure usando il portale di Azure.

La concessione di questo ruolo non è necessaria affinché gli indirizzi IP statici siano funzionali. Senza questa assegnazione di ruolo, è comunque possibile trovare gli indirizzi IP assegnati visualizzandoli nella pagina Rete nel portale di Azure.

Agenti inseriti nella rete virtuale esistente

È possibile configurare gli agenti del pool per l'uso della rete virtuale attenendosi alla procedura seguente:

  1. Creare o portare la rete virtuale e la subnet.
  2. Delegare la subnet a Microsoft.DevOpsInfrastructure/pools.
  3. Associare la subnet al proprio pool.

I passaggi precedenti delegano la subnet per l'accesso esclusivo da parte del pool. Altri pool o risorse non possono usare la subnet.

Un pool può usare più subnet per connettere più pool alla stessa rete virtuale. Ogni subnet viene 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 (inclusi i cinque indirizzi IP riservati da Azure nella subnet).

Se si usa ExpressRoute, è necessario consentire le scritture modificando o eliminando temporaneamente il blocco di gestione nel gruppo di risorse.

Importante

Il pool e la rete virtuale devono trovarsi nella stessa area. In caso contrario, viene visualizzato un errore simile al seguente quando si tenta di creare il pool o aggiornare la configurazione di rete: "La rete virtuale MDPVN si trova nell'area eastus, ma il pool mdpnonprodsub si trova nell'area australiaeast. Devono trovarsi nella stessa area".

Concedere l'accesso lettore e contributore di rete al principale del servizio DevOpsInfrastructure

Assicurarsi che l'entità DevOpsInfrastructure abbia accesso Reader e Network Contributor alla rete virtuale.

Anziché usare ruoli predefiniti, è possibile creare un ruolo personalizzato con le autorizzazioni seguenti:

  • 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 che mostra le autorizzazioni personalizzate per i ruoli.

Controllare l'accesso principale per DevOpsInfrastructure

  1. Selezionare Controllo di accesso (IAM) per la rete virtuale e quindi selezionare Controlla accesso.

    Screenshot che mostra le autorizzazioni di rete virtuale per la delega della subnet.

  2. Cercare e selezionare DevOpsInfrastructure.

    Screenshot che mostra come selezionare il principale AzureDevOpsInfrastructure.

  3. Verificare di avere l'accesso a livello di Reader. 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.

    Screenshot che mostra le autorizzazioni di rete virtuale.

  4. Se l'entità DevOpsInfrastructure non dispone delle autorizzazioni necessarie, aggiungile. Selezionare Controllo di accesso (IAM) per la rete virtuale e quindi selezionare Concedi accesso a questa risorsa.

Delegare la sottorete a Microsoft.DevOpsInfrastructure/pools

Nel portale aprire Proprietà subnet e selezionare Microsoft.DevOpsInfrastructure/pools in Delega subnet. Seleziona Salva.

Screenshot che illustra come configurare la delegazione della subnet.

Questo processo delega la subnet all'accesso esclusivo del pool. Altri pool o risorse non possono usare la subnet. Per connettere più pool alla stessa rete virtuale, è necessario usare più subnet. Ogni subnet deve essere delegata e associata al proprio pool. Altre informazioni sulla delega della subnet sono disponibili in questa panoramica della delega della subnet.

Dopo aver delegato la subnet a Microsoft.DevOpsInfrastructure/pools, è possibile aggiornare il pool per usare la subnet.

Associare la subnet al pool

  1. Per creare un nuovo pool, passare alla scheda Rete. Per aggiornare un pool esistente, passare a Impostazioni>rete e quindi selezionare Agenti inseriti nella rete> virtuale esistenteConfigura.

    Screenshot che mostra l'opzione di configurazione.

  2. Selezionare i valori Sottoscrizione, Rete virtuale e Subnet delegati a Microsoft.DevOpsInfrastructure/poolse quindi selezionare OK.

    Screenshot che mostra come associare la subnet al pool.

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

Importante

Non inserire un blocco Di eliminazione nella rete virtuale quando si aggiornano i pool. Durante un'operazione di aggiornamento del pool, i pool di DevOps gestiti creano un collegamento di associazione del servizio nella subnet. Se un aggiornamento non riesce, i pool di DevOps gestiti tentano di pulire il collegamento di associazione del servizio, ma se è presente un blocco di eliminazione , viene visualizzato un InUseSubnetCannotBeDeleted errore. I pool DevOps gestiti non sono in grado di eliminare il collegamento di associazione del servizio, che lascia la subnet in uno stato bloccato (non è possibile eliminarli). Per risolvere il problema, rimuovere il blocco Elimina e ripetere l'operazione di aggiornamento.

Per altre informazioni, vedere Aspetti da considerare prima di applicare blocchi alle risorse di Azure.

Limitare la connettività in uscita

Se nella rete sono presenti sistemi (ad esempio, gruppi di sicurezza di rete o firewall) che limitano la connettività in uscita, è necessario aggiungere determinati endpoint a un elenco di elementi consentiti per supportare completamente i pool devOps gestiti. Questi endpoint sono suddivisi in endpoint necessari a livello globale (necessari in qualsiasi computer che usa pool DevOps gestiti) ed endpoint necessari per determinati scenari. Tutti gli endpoint sono HTTPS, se non diversamente specificato.

Endpoint necessari per l'avvio di pool DevOps gestiti

Se non si aggiungono questi endpoint a un elenco elementi consentiti, i computer non vengono online come parte del servizio Pool di DevOps gestiti e non è possibile eseguire pipeline nel pool:

  • *.prod.manageddevops.microsoft.com: endpoint dei pool DevOps gestiti usato per comunicare con il servizio 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 sezione agente dei file binari dei lavoratori viene scaricata da rm-agent.prod.manageddevops.microsoft.com (in precedenza da agent.prod.manageddevops.microsoft.com), ed è coperta dalla voce *.prod.manageddevops.microsoft.com richiesta precedentemente.
  • *.queue.core.windows.net: Coda di lavoro per la comunicazione con il servizio di pool DevOps gestiti.

Endpoint necessari per la connessione ad Azure DevOps

Se non aggiungi questi endpoint a un elenco di autorizzazioni, i computer potrebbero connettersi online e passare a uno stato allocato, ma non riuscire a comunicare con Azure DevOps, perché l'agente attività di Azure DevOps Services potrebbe non essere in grado di connettersi o avviarsi.

  • download.agent.dev.azure.com: posizione della rete di distribuzione di contenuti (CDN) dell'agente di Azure DevOps, utilizzata per scaricare l'agente di Azure DevOps (in precedenza vstsagentpackage.azureedge.net; per ulteriori informazioni, consultare La CDN di Edgio per Azure DevOps viene ritirata).
  • dev.azure.com: obbligatorio per gestire la comunicazione con Azure DevOps.

Endpoint necessari per le macchine Linux

Questi endpoint sono necessari per avviare computer Ubuntu, ma non sono necessari se un pool usa solo Windows. Quando si configura l'agente attività di Azure DevOps, vengono aggiunti i pacchetti necessari e viene eseguito un apt-get comando. Questo processo ha esito negativo se gli endpoint seguenti non vengono aggiunti a un elenco di elementi consentiti.

  • azure.archive.ubuntu.com: Preparazione di macchine Linux. Questo endpoint è HTTP (porta 80), non HTTPS (porta 443).
  • www.microsoft.com: Preparazione di macchine Linux.
  • security.ubuntu.com: Preparazione di macchine Linux.
  • packages.microsoft.com: Preparazione di macchine Linux.
  • ppa.launchpad.net: provisioning di alcune distribuzioni Linux specifiche.
  • dl.fedoraproject.org: configurazione di alcune distribuzioni Linux.

Endpoint necessari per alcune funzionalità di Azure DevOps

Questi endpoint facoltativi sono necessari per le funzionalità di Azure DevOps specifiche da usare nelle 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 sia per il caricamento che per l'utilizzo di artefatti.
  • *.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 l'elenco completo dei domini necessari in Azure DevOps indirizzi IP consentiti e URL di dominio.

Le macchine virtuali di Azure potrebbero instradare il traffico a determinati servizi di Azure tramite la subnet. Per queste richieste, è possibile instradare le richieste direttamente tramite Azure o abilitare l'accesso tramite la rete.

  1. Configurare il traffico di Azure per l'esecuzione tramite gli endpoint di servizio:

    È possibile instradare il traffico direttamente tramite Azure per evitare di aggiungere larghezza di banda ai gruppi di sicurezza di rete o ai firewall. Non è necessario aggiungere i domini elencati nell'opzione seguente a un elenco di elementi consentiti.

    Ad esempio, è possibile usare la funzionalità disco dati per effettuare chiamate di rete a Azure Storage. Quando si abilita l'endpoint del servizio Microsoft.Storage nella rete, il traffico viene instradato direttamente attraverso Azure, evitando così le regole di rete e riducendo il carico.

  2. Per evitare di instradare il traffico attraverso gli endpoint di servizio, aggiungi il dominio alla lista delle autorizzazioni md-*.blob.storage.azure.net. Questo dominio è necessario per configurare un disco dati.

Indirizzi IP per la distribuzione della rete CDN Akamai

Il 1° maggio 2025, gli asset della rete CDN di Azure DevOps sono passati a una soluzione servita da Akamai e Frontdoor di Azure. Assicurarsi 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 aggiungere anche l'origine dell'immagine del contenitore (Docker o Registro Azure Container) a un elenco di elementi consentiti.

Convalidare la connettività degli endpoint

Verificare che sia possibile usare una subnet con pool DevOps gestiti eseguendo lo script seguente in una risorsa in tale subnet. Questo passaggio consentirà di verificare che il flusso di rete sia configurato per raggiungere tutti questi endpoint disponibili e il piano di controllo DevOps gestito.

Importante

È necessario eseguire questo script in una risorsa nella subnet ,ad esempio una macchina virtuale o un contenitore, per verificare che il percorso di rete sia aperto da tale subnet agli endpoint necessari.

Per eseguire lo script con PowerShell Core o PowerShell 5 o versione successiva, salvare lo script seguente come ValidateMDPEndpoints.ps1. Eseguire il comando di PowerShell seguente: .\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 $_ }
}

Configurare l'agente di Azure DevOps per eseguire dietro un proxy

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

  • VSTS_AGENT_INPUT_PROXYURL: URL del proxy configurato da eseguire dietro.
  • 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. Per Linux, queste variabili devono trovarsi nel /etc/environment file . Se si impostano queste variabili di sistema in modo non corretto o senza un servizio proxy configurato nell'immagine, il provisioning di nuovi agenti non riesce con problemi di connettività di rete.

Se si esegue la migrazione dagli agenti dei set di scalabilità di macchine virtuali di Azure e si usano già le variabili di ambiente proxy nell'immagine, non è necessario apportare modifiche. Questo processo è descritto in Agenti del set di scalabilità di macchine virtuali di Azure: Personalizzare la configurazione dell'agente della pipeline.

Contenuti correlati

  • Last updated on