Condividi tramite

Agenti ospitati da Microsoft

  • Articolo

Servizi di Azure DevOps

Gli agenti ospitati da Microsoft sono disponibili solo con Azure DevOps Services, ospitato nel cloud. Non è possibile usare agenti ospitati da Microsoft o il pool di agenti di Azure Pipelines con TFS locale o Azure DevOps Server. Con queste versioni locali, è necessario usare agenti self-hosted.

Importante

Selezionare una versione dal selettore Della versione del contenuto di Azure DevOps.

Selezionare la versione di questo articolo corrispondente alla piattaforma e alla versione. Il selettore di versione è sopra il sommario. Cercare la piattaforma e la versione di Azure DevOps.

Se le pipeline si trovano in Azure Pipelines, è possibile eseguire i processi usando un agente ospitato da Microsoft. Gli agenti ospitati da Microsoft si occupano anche della manutenzione e degli aggiornamenti. Si ottiene sempre l'ultima versione dell'immagine VM specificata nella pipeline. Ogni volta che si esegue una pipeline, si ottiene una nuova macchina virtuale per ogni processo nella pipeline. La macchina virtuale viene rimossa dopo un processo (ovvero qualsiasi modifica apportata da un processo al file system della macchina virtuale, ad esempio l'estrazione del codice, non sarà disponibile per il processo successivo). Gli agenti ospitati da Microsoft possono eseguire processi direttamente nella macchina virtuale o in un contenitore.

Azure Pipelines include un pool di agenti predefinito denominato Azure Pipelines con agenti ospitati da Microsoft.

Per molti team questo è il modo più semplice per eseguire i processi. È possibile provarlo per primo e verificare se funziona per la compilazione o la distribuzione. In caso contrario, è possibile usare agenti del set di scalabilità o un agente self-hosted.

Suggerimento

È possibile provare un agente ospitato da Microsoft senza alcun addebito.

Software

Il pool di agenti di Azure Pipelines offre diverse immagini di macchine virtuali tra cui scegliere, ognuna delle quali include un'ampia gamma di strumenti e software.

Immagine Specifica dell'agente dell'editor classico Etichetta dell'immagine della macchina virtuale YAML Software incluso
Windows Server 2022 con Visual Studio 2022 windows-2022 windows-latest O windows-2022 Collegamento
Windows Server 2019 con Visual Studio 2019 windows-2019 windows-2019 Collegamento
Ubuntu 24.04 ubuntu-24.04 ubuntu-24.04 Collegamento
Ubuntu 22.04 ubuntu-22.04 ubuntu-latest O ubuntu-22.04 Collegamento
Ubuntu 20.04 ubuntu-20.04 ubuntu-20.04 Collegamento
macOS 15 Sequia preview macOS-15 macOS-15 Collegamento
macOS 14 Sonoma macOS-14 macOS-latest O macOS-14 Collegamento
macOS 13 Ventura macOS-13 macOS-13 Collegamento
macOS 12 Monterey macOS-12 macOS-12 deprecated

L'immagine dell'agente predefinita per le pipeline di compilazione classiche è windows-2019 e l'immagine dell'agente predefinita per le pipeline di compilazione YAML è ubuntu-latest. Per altre informazioni, vedere Designare un pool nella pipeline.

È possibile visualizzare il software installato per ogni agente ospitato scegliendo il collegamento Software incluso nella tabella. Quando si usano immagini macOS, è possibile selezionare manualmente le versioni degli strumenti. Altre informazioni.

Aggiornamenti recenti

I clienti sono invitati a eseguire la migrazione a versioni più recenti o a un agente self-hosted.

Per altre informazioni e istruzioni su come aggiornare le pipeline che usano tali immagini, vedere Rimozione di immagini meno recenti nei pool ospitati di Azure Pipelines.

Nota

La capacità macOS è attualmente limitata. A differenza delle immagini Linux e Windows, in cui la capacità è vincolata da tutta la capacità di Azure, la capacità macOS è vincolata dalla quantità di hardware disponibile. Sebbene stiamo lavorando per rendere disponibile capacità aggiuntiva a Primavera 2024, alcuni processi potrebbero riscontrare un ritardo nell'esecuzione. Laddove possibile, ad esempio per i processi che non creano app dell'ecosistema Apple, i clienti dovrebbero scegliere immagini Linux o Windows.

Nota

Il pool ospitato di Azure Pipelines sostituisce i pool ospitati precedenti con nomi mappati alle immagini corrispondenti. Tutti i processi presenti nei pool ospitati precedenti vengono reindirizzati automaticamente all'immagine corretta nel nuovo pool ospitato di Azure Pipelines. In alcune circostanze, è comunque possibile visualizzare i nomi dei pool precedenti, ma in background i processi ospitati vengono eseguiti usando il pool di Azure Pipelines. Per altre informazioni su questo aggiornamento, vedere le note sulla versione del pool ospitato singolo delle note sulla versione del 1° luglio 2019 - Sprint 154.

Importante

Per richiedere l'installazione di software aggiuntivo sugli agenti ospitati da Microsoft, non creare una richiesta di feedback in questo documento o aprire un ticket di supporto. Aprire invece un problema nel repository, in cui vengono gestiti gli script per generare varie immagini.

Come identificare le pipeline usando un'immagine ospitata deprecata

Per identificare le pipeline che usano un'immagine deprecata, passare alla posizione seguente nell'organizzazione: https://dev.azure.com/{organization}/{project}/_settings/agentqueuese filtrare in base al nome dell'immagine da controllare. L'esempio seguente controlla l'immagine vs2017-win2016 .

Screenshot del filtro delle pipeline in base al nome dell'immagine.

È anche possibile eseguire query sulla cronologia dei processi per le immagini deprecate tra progetti usando lo script disponibile qui, come illustrato nell'esempio seguente.

./QueryJobHistoryForRetiredImages.ps1 -accountUrl https://dev.azure.com/{org} -pat {pat}

Usare un agente ospitato da Microsoft

Nelle pipeline YAML, se non si specifica un pool, per impostazione predefinita le pipeline sono il pool di agenti di Azure Pipelines. È sufficiente specificare l'immagine della macchina virtuale da usare.

jobs:
- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: echo hello from Linux
- job: macOS
  pool:
    vmImage: 'macOS-latest'
  steps:
  - script: echo hello from macOS
- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - script: echo hello from Windows

Nota

La specifica di un pool può essere eseguita a più livelli in un file YAML. Se si nota che la pipeline non è in esecuzione nell'immagine prevista, assicurarsi di verificare la specifica del pool a livello di pipeline, fase e processo.

Evitare riferimenti hardcoded

Quando si usa un agente ospitato da Microsoft, usare sempre le variabili per fare riferimento alle risorse dell'ambiente di compilazione e dell'agente. Ad esempio, non impostare come hardcoded la lettera o la cartella dell'unità che contiene il repository. Il layout preciso degli agenti ospitati è soggetto a modifiche senza avvisi.

Hardware

Gli agenti ospitati da Microsoft che eseguono immagini Windows e Linux vengono sottoposti a provisioning in macchine virtuali per utilizzo generico di Azure con una CPU da 2 core, 7 GB di RAM e 14 GB di spazio su disco SSD. Queste macchine virtuali si trovano nella stessa geografia dell'organizzazione di Azure DevOps.

Gli agenti che eseguono immagini macOS vengono sottoposti a provisioning nei Mac Pro con una CPU a 3 core, 14 GB di RAM e 14 GB di spazio su disco SSD. Questi agenti vengono sempre eseguiti negli Stati Uniti indipendentemente dalla posizione dell'organizzazione Azure DevOps. Se la sovranità dei dati è importante per l'utente e se l'organizzazione non si trova negli Stati Uniti, non è consigliabile usare immagini macOS. Altre informazioni.

Tutti questi computer hanno almeno 10 GB di spazio libero su disco disponibile per l'esecuzione delle pipeline. Questo spazio disponibile viene utilizzato quando la pipeline estrae il codice sorgente, scarica pacchetti, esegue il pull di immagini Docker o genera file intermedi.

Importante

Non è possibile rispettare le richieste di aumentare lo spazio su disco sugli agenti ospitati da Microsoft o di effettuare il provisioning di computer più potenti. Se le specifiche degli agenti ospitati da Microsoft non soddisfano le proprie esigenze, è consigliabile prendere in considerazione agenti self-hosted o agenti del set di scalabilità.

Rete

In alcune configurazioni potrebbe essere necessario conoscere l'intervallo di indirizzi IP in cui vengono distribuiti gli agenti. Ad esempio, se è necessario concedere agli agenti ospitati l'accesso tramite un firewall, è possibile limitare tale accesso in base all'indirizzo IP. Poiché Azure DevOps usa la rete globale di Azure, gli intervalli IP variano nel tempo. Microsoft pubblica un file JSON settimanale che elenca gli intervalli IP per i data center di Azure, suddivisi in base all'area. Questo file viene aggiornato settimanalmente con nuovi intervalli IP pianificati. Solo l’ultima versione della libreria è disponibile per il download. Se sono necessarie versioni precedenti, è necessario scaricarle e archiviarle ogni settimana man mano che diventano disponibili. I nuovi intervalli IP diventano effettivi la settimana seguente. È consigliabile eseguire il checkback frequentemente (almeno una volta alla settimana) per assicurarsi di mantenere un elenco aggiornato. Se i processi dell'agente iniziano ad avere esito negativo, un primo passaggio per la risoluzione dei problemi è assicurarsi che la configurazione corrisponda all'elenco più recente di indirizzi IP. Gli intervalli di indirizzi IP per gli agenti ospitati sono elencati nel file AzureCloud.<region>settimanale in , ad esempio AzureCloud.westus per l'area Stati Uniti occidentali.

Gli agenti ospitati vengono eseguiti nella stessa geografia di Azure dell'organizzazione. Ogni geografia contiene una o più aree geografiche. Anche se l'agente può essere eseguito nella stessa area dell'organizzazione, questa operazione non è garantita. Per ottenere l'elenco completo degli intervalli IP possibili per l'agente, è necessario usare gli intervalli IP di tutte le aree contenute nella geografia. Ad esempio, se l'organizzazione si trova nell'area geografica Stati Uniti, è necessario usare gli intervalli IP per tutte le aree in tale area geografica.

Per determinare l'area geografica, passare a https://dev.azure.com/<your_organization>/_settings/organizationOverview, ottenere l'area e trovare l'area geografica associata dalla tabella geography di Azure. Dopo aver identificato l'area geografica, usare gli intervalli IP del file settimanale per tutte le aree in tale area geografica.

Importante

Non è possibile usare connessioni private, ad esempio ExpressRoute o VPN, per connettere gli agenti ospitati da Microsoft alla rete aziendale. Il traffico tra gli agenti ospitati da Microsoft e i server sarà in rete pubblica.

Per identificare gli intervalli IP possibili per gli agenti ospitati da Microsoft

  1. Identificare l'area per l'organizzazione nelle impostazioni organizzazione.
  2. Identificare l'area geografica di Azure per l'area dell'organizzazione.
  3. Eseguire il mapping dei nomi delle aree nell'area geografica al formato usato nel file settimanale, seguendo il formato di AzureCloud.<region>, ad esempio AzureCloud.westus. È possibile eseguire il mapping dei nomi delle aree dall'elenco Geography di Azure al formato usato nel file settimanale esaminando i nomi delle aree passate al costruttore delle aree definite nel codice sorgente per la classe Region, dalle librerie di gestione di Azure per .NET.

    Nota

    Poiché non esiste alcuna API nelle librerie di gestione di Azure per .NET per elencare le aree per un'area geografica, è necessario elencarle manualmente come illustrato nell'esempio seguente.

  4. Recuperare gli indirizzi IP per tutte le aree geografiche dal file settimanale. Se l'area è Brasile meridionale o Europa occidentale, è necessario includere intervalli IP aggiuntivi in base all'area geografica di fallback, come descritto nella nota seguente.

Nota

A causa delle restrizioni di capacità, alcune organizzazioni nelle aree Brasile meridionale o Europa occidentale possono occasionalmente vedere gli agenti ospitati che si trovano al di fuori della geografia prevista. In questi casi, oltre ad includere gli intervalli IP per tutte le aree dell'area geografica, come descritto nella sezione precedente, è necessario includere intervalli IP aggiuntivi per le aree nell'area geografica di fallback della capacità.

Se l'organizzazione si trova nell'area brasile meridionale, l'area geografica di fallback della capacità è Stati Uniti.

Se l'organizzazione si trova nell'area Europa occidentale, l'area geografica di fallback della capacità è Francia.

Gli intervalli IP Mac non sono inclusi negli indirizzi IP di Azure precedenti, perché sono ospitati nel cloud macOS di GitHub. Gli intervalli IP possono essere recuperati usando l'API dei metadati GitHub seguendo le istruzioni fornite qui.

Esempio

Nell'esempio seguente, gli intervalli di indirizzi IP dell'agente ospitato per un'organizzazione nell'area Stati Uniti occidentali vengono recuperati dal file settimanale. Poiché l'area Stati Uniti occidentali si trova nell'area geografica Stati Uniti, sono inclusi gli indirizzi IP per tutte le aree dell'area geografica Stati Uniti. In questo esempio gli indirizzi IP vengono scritti nella console.

using Newtonsoft.Json.Linq;
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;

namespace WeeklyFileIPRanges
{
    class Program
    {
        // Path to the locally saved weekly file
        const string weeklyFilePath = @"C:\MyPath\ServiceTags_Public_20230904.json";

        static void Main(string[] args)
        {
            // United States geography has the following regions:
            // Central US, East US, East US 2, East US 3, North Central US, 
            // South Central US, West Central US, West US, West US 2, West US 3
            // This list is accurate as of 9/8/2023
            List<string> USGeographyRegions = new List<string>
            {
                "centralus",
                "eastus",
                "eastus2",
                "eastus3",
                "northcentralus",
                "southcentralus",
                "westcentralus",
                "westus",
                "westus2",
                "westus3"
            };

            // Load the weekly file
            JObject weeklyFile = JObject.Parse(File.ReadAllText(weeklyFilePath));
            JArray values = (JArray)weeklyFile["values"];

            foreach (string region in USGeographyRegions)
            {
                string tag = $"AzureCloud.{region}";
                Console.WriteLine(tag);

                var ipList =
                    from v in values
                    where tag.Equals((string)v["name"], StringComparison.OrdinalIgnoreCase)
                    select v["properties"]["addressPrefixes"];

                foreach (var ip in ipList.Children())
                {
                    Console.WriteLine(ip);
                }
            }
        }
    }
}

Tag di servizio

Gli agenti ospitati da Microsoft non possono essere elencati dai tag del servizio. Se si sta provando a concedere agli agenti ospitati l'accesso alle risorse, sarà necessario seguire il metodo di elenco elementi consentiti per l'intervallo IP.

Sicurezza

Gli agenti ospitati da Microsoft vengono eseguiti sulla piattaforma Azure sicura. Tuttavia, è necessario tenere presenti le considerazioni sulla sicurezza seguenti.

  • Anche se gli agenti ospitati da Microsoft vengono eseguiti nella rete pubblica di Azure, non vengono assegnati indirizzi IP pubblici. Pertanto, le entità esterne non possono essere destinate agli agenti ospitati da Microsoft.
  • Gli agenti ospitati da Microsoft vengono eseguiti in singole macchine virtuali, che vengono ricreate dopo ogni esecuzione. Ogni agente è dedicato a una singola organizzazione e ogni macchina virtuale ospita solo un singolo agente.
  • L'esecuzione della pipeline in agenti ospitati da Microsoft offre diversi vantaggi, dal punto di vista della sicurezza. Se si esegue codice non attendibile nella pipeline, ad esempio i contributi dei fork, è più sicuro eseguire la pipeline negli agenti ospitati da Microsoft rispetto agli agenti self-hosted che risiedono nella rete aziendale.
  • Quando una pipeline deve accedere alle risorse aziendali dietro un firewall, è necessario consentire l'intervallo di indirizzi IP per l'area geografica di Azure. Ciò può aumentare l'esposizione poiché l'intervallo di indirizzi IP è piuttosto grande e poiché anche i computer in questo intervallo possono appartenere ad altri clienti. Il modo migliore per evitare questo problema consiste nell'evitare la necessità di accedere alle risorse interne. Per informazioni sulla distribuzione di artefatti in un set di server, vedere Comunicazione per la distribuzione nei server di destinazione.
  • Le immagini ospitate non sono conformi ai benchmark di protezione avanzata CIS. Per usare immagini con protezione avanzata CIS, è necessario creare agenti self-hosted o agenti del set di scalabilità.

Funzionalità e limitazioni

Agenti ospitati da Microsoft:

  • Disporre del software precedente. È anche possibile aggiungere software durante la compilazione o il rilascio usando le attività del programma di installazione degli strumenti.
    • Si ottiene un agente appena immagineto per ogni processo nella pipeline.
  • Fornire 10 GB di spazio di archiviazione per l'origine e gli output di compilazione.
  • Fornire un livello gratuito:
    • Progetto pubblico: 10 processi paralleli ospitati da Microsoft gratuiti che possono essere eseguiti per un massimo di 360 minuti (6 ore) ogni volta, senza un limite di tempo complessivo al mese. Per ottenere i limiti del livello gratuito, contattare Microsoft .
    • Progetto privato: un processo parallelo gratuito che può essere eseguito per un massimo di 60 minuti ogni volta, fino a quando non sono stati usati 1.800 minuti (30 ore) al mese. È possibile pagare una capacità aggiuntiva per il processo in parallelo. I processi in parallelo a pagamento rimuovono il limite di tempo mensile e consentono di eseguire ogni processo per un massimo di 360 minuti (6 ore). Acquistare processi paralleli ospitati da Microsoft.
    • Quando si crea una nuova organizzazione di Azure DevOps, queste concessioni gratuite non vengono concesse per impostazione predefinita. Per richiedere la concessione gratuita per progetti pubblici o privati, inviare una richiesta.
  • Eseguire in macchine virtuali per utilizzo generico di Microsoft Azure Standard_DS2_v2.
  • Eseguire come amministratore in Windows e un utente sudo senza password in Linux.
  • (solo Linux) Eseguire i passaggi in un oggetto cgroup che offre 6 GB di memoria fisica e 13 GB di memoria totale.
  • Usare immagini di macchine virtuali aggiornate regolarmente (ogni 3 settimane).

Gli agenti ospitati da Microsoft non offrono:

  • Possibilità di connettersi in remoto.
  • Possibilità di eliminare elementi in una condivisione file UNC.
  • Possibilità di aggiungere computer direttamente alla rete aziendale.
  • Possibilità di ottenere computer di compilazione più grandi o più potenti.
  • Possibilità di pre-caricare software personalizzato. È possibile installare il software durante un'esecuzione della pipeline, ad esempio tramite attività del programma di installazione degli strumenti o in uno script.
  • Potenziali vantaggi in termini di prestazioni che è possibile ottenere usando agenti self-hosted che potrebbero avviare ed eseguire compilazioni più velocemente. Ulteriori informazioni
  • Possibilità di eseguire compilazioni XAML.
  • Possibilità di eseguire il rollback a una versione precedente dell'immagine della macchina virtuale. Si usa sempre la versione più recente.

Se gli agenti ospitati da Microsoft non soddisfano le proprie esigenze, è possibile distribuire agenti self-hosted, usare agenti del set di scalabilità o agenti di Pool DevOps gestiti.

Domande frequenti

Come posso vedere quale software è incluso in un'immagine?

È possibile visualizzare il software installato per ogni agente ospitato scegliendo il collegamento Software incluso nella tabella Software .

Nota

Per impostazione predefinita, l'agente di Windows usa la versione di Git in bundle con il software agente. Microsoft consiglia di usare la versione di Git in bundle con l'agente, ma sono disponibili diverse opzioni per eseguire l'override di questo comportamento predefinito e usare la versione di Git installata dal computer agente nel percorso.

Per visualizzare la versione di Git usata da una pipeline, è possibile esaminare i log per un checkout passaggio nella pipeline, come illustrato nell'esempio seguente.

Syncing repository: PathFilter (Git)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.26.2.windows.1

In che modo Microsoft sceglie il software e le versioni da inserire nell'immagine?

Altre informazioni sulle versioni del software incluse nelle immagini sono disponibili in Linee guida per gli elementi installati.

Quando vengono aggiornate le immagini?

Le immagini vengono in genere aggiornate settimanalmente. È possibile controllare i badge di stato nel formato 20200113.x in cui la prima parte indica la data di aggiornamento dell'immagine.

Cosa è possibile fare se è necessario rimuovere o sostituire il software con una versione più recente?

È possibile segnalare un problema di GitHub scegliendo i collegamenti Software inclusi nella tabella Usa un agente ospitato da Microsoft.

È anche possibile usare un agente self-hosted che include le versioni esatte del software necessarie. Per altre informazioni, vedere Agenti self-hosted.

Cosa accade se è necessaria una macchina più grande con maggiore potenza di elaborazione, memoria o spazio su disco?

Non è possibile aumentare la memoria, la potenza di elaborazione o lo spazio su disco per gli agenti ospitati da Microsoft, ma è possibile usare agenti self-hosted o agenti del set di scalabilità ospitati nei computer con le specifiche desiderate.

Non è possibile selezionare un agente ospitato da Microsoft e non è possibile accodamento della compilazione o della distribuzione. Cosa devo fare?

Gli agenti ospitati da Microsoft sono disponibili solo in Azure Pipelines e non in TFS o in Azure DevOps Server.

Per impostazione predefinita, tutti i collaboratori di progetto in un'organizzazione hanno accesso agli agenti ospitati da Microsoft. Tuttavia, l'amministratore dell'organizzazione può limitare l'accesso degli agenti ospitati da Microsoft per selezionare utenti o progetti. Chiedere al proprietario dell'organizzazione Azure DevOps di concedere all'utente l'autorizzazione per l'uso di un agente ospitato da Microsoft. Vedere Sicurezza del pool di agenti.

Il completamento delle pipeline in esecuzione negli agenti ospitati da Microsoft richiede più tempo. Come posso velocizzarle?

Se la pipeline è diventata più lenta di recente, esaminare la pagina di stato per cercare eventuali interruzioni. Potrebbero esserci dei problemi con il servizio. In alternativa, esaminare eventuali modifiche apportate nel codice o nella pipeline dell'applicazione. Le dimensioni del repository durante il check-out potrebbero essere aumentate oppure potrebbero essere in corso il caricamento di artefatti più grandi o l'esecuzione di altri test.

Se si configura una pipeline e si confrontano le prestazioni degli agenti ospitati da Microsoft con il computer locale o un agente self-hosted, prendere nota delle specifiche dell'hardware usato per eseguire i processi. Non siamo in grado di fornire computer più grandi o potenti. È possibile prendere in considerazione l'uso di agenti self-hosted o agenti del set di scalabilità se queste prestazioni non sono accettabili.

Ho bisogno di più agenti. Cosa posso fare?

Tutte le organizzazioni Di Azure DevOps vengono fornite con diversi processi paralleli gratuiti per i progetti open source e un processo parallelo gratuito e minuti limitati ogni mese per i progetti privati. Se sono necessari altri minuti o processi paralleli per il progetto open source, contattare il supporto tecnico. Se sono necessari altri minuti o processi paralleli per il progetto privato, è possibile acquistare di più.

La pipeline ha esito positivo nell'agente self-hosted, ma ha esito negativo sugli agenti ospitati da Microsoft. Cosa devo fare?

L'agente self-hosted include probabilmente tutte le dipendenze corrette installate, mentre le stesse dipendenze, strumenti e software non sono installate negli agenti ospitati da Microsoft. Prima di tutto, esaminare attentamente l'elenco di software installato negli agenti ospitati da Microsoft seguendo il collegamento a Software incluso nella tabella precedente. Confrontarlo con il software installato nell'agente self-hosted. In alcuni casi, gli agenti ospitati da Microsoft potrebbero avere gli strumenti necessari ,ad esempio Visual Studio, ma tutti i componenti facoltativi necessari potrebbero non essere stati installati. Se si riscontrano differenze, sono disponibili due opzioni:

  • È possibile creare un nuovo problema nel repository, in cui vengono monitorate le richieste di software aggiuntivo. Contattare il supporto tecnico non può aiutare a configurare il nuovo software sugli agenti ospitati da Microsoft.

  • È possibile usare agenti self-hosted o agenti del set di scalabilità. Con questi agenti, è possibile controllare completamente le immagini usate per eseguire le pipeline.

La compilazione ha esito positivo nel computer locale, ma ha esito negativo sugli agenti ospitati da Microsoft. Cosa devo fare?

Il computer locale include probabilmente tutte le dipendenze corrette installate, mentre le stesse dipendenze, strumenti e software non sono installate negli agenti ospitati da Microsoft. Prima di tutto, esaminare attentamente l'elenco di software installato negli agenti ospitati da Microsoft seguendo il collegamento a Software incluso nella tabella precedente. Confrontarlo con il software installato nel computer locale. In alcuni casi, gli agenti ospitati da Microsoft potrebbero avere gli strumenti necessari ,ad esempio Visual Studio, ma tutti i componenti facoltativi necessari potrebbero non essere stati installati. Se si riscontrano differenze, sono disponibili due opzioni:

  • È possibile creare un nuovo problema nel repository, in cui vengono monitorate le richieste di software aggiuntivo. Questa è la scelta migliore per ottenere un nuovo software installato. Il supporto tecnico non consente di configurare il nuovo software sugli agenti ospitati da Microsoft.

  • È possibile usare agenti self-hosted o agenti del set di scalabilità. Con questi agenti, è possibile controllare completamente le immagini usate per eseguire le pipeline.

La pipeline ha esito negativo e viene visualizzato l'errore "Nessuna spazio lasciato nel dispositivo".

Gli agenti ospitati da Microsoft hanno solo 10 GB di spazio su disco disponibile per l'esecuzione del processo. Questo spazio viene utilizzato quando si estrae il codice sorgente, quando si scaricano pacchetti, quando si scaricano immagini Docker o quando si producono file intermedi. Sfortunatamente, non è possibile aumentare lo spazio disponibile nelle immagini ospitate da Microsoft. È possibile ristrutturare la pipeline in modo che possa rientrare in questo spazio. In alternativa, è possibile prendere in considerazione l'uso di agenti self-hosted o agenti del set di scalabilità.

La pipeline in esecuzione su agenti ospitati da Microsoft richiede l'accesso ai server nella rete aziendale. Come si ottiene un elenco di indirizzi IP da consentire nel firewall?

Vedere la sezione Intervalli IP dell'agente

La pipeline in esecuzione su agenti ospitati da Microsoft non è in grado di risolvere il nome di un server nella rete aziendale. Come possiamo risolvere questo problema?

Se si fa riferimento al server in base al nome DNS, assicurarsi che il server sia accessibile pubblicamente su Internet tramite il nome DNS. Se si fa riferimento al server in base al relativo indirizzo IP, assicurarsi che l'indirizzo IP sia accessibile pubblicamente su Internet. In entrambi i casi, assicurarsi che qualsiasi firewall tra gli agenti e la rete aziendale disponga degli intervalli IP dell'agente consentiti.

Viene visualizzato un errore di autorizzazione IP di firma di accesso condiviso da un account Archiviazione di Azure

Se viene visualizzato un codice di errore di firma di accesso condiviso, è molto probabile che gli intervalli di indirizzi IP degli agenti ospitati da Microsoft non siano consentiti a causa delle regole di Archiviazione di Azure. Esistono alcune soluzioni alternative:

  1. Gestire le regole di rete IP per l'account Archiviazione di Azure e aggiungere gli intervalli di indirizzi IP per gli agenti ospitati.
  2. Nella pipeline usare l'interfaccia della riga di comando di Azure per aggiornare il set di regole di rete per l'account Archiviazione di Azure prima di accedere all'archiviazione e quindi ripristinare il set di regole precedente.
  3. Usare agenti self-hosted o agenti del set di scalabilità.

Come è possibile selezionare manualmente le versioni degli strumenti nell'agente macOS ospitato?

Xcode

Se si usa l'attività Xcode inclusa in Azure Pipelines e TFS, è possibile selezionare una versione di Xcode nelle proprietà dell'attività. In caso contrario, per impostare manualmente la versione Xcode da usare nel pool di agenti macOS ospitati, prima xcodebuild dell'attività di compilazione, eseguire questa riga di comando come parte della compilazione, sostituendo il numero di versione Xcode 13.2 in base alle esigenze:

/bin/bash -c "sudo xcode-select -s /Applications/Xcode_13.2.app/Contents/Developer"

Le versioni Xcode nel pool di agenti macOS ospitato sono disponibili qui per l'agente macos-12 .

Questo comando non funziona per le app Xamarin. Per selezionare manualmente una versione Xcode per la compilazione di app Xamarin, vedere le istruzioni precedenti.

Mono

Per selezionare manualmente una versione mono da usare nel pool di agenti macOS ospitato, eseguire questo script in ogni processo della compilazione prima dell'attività di compilazione Mono, specificando il collegamento simbolico con la versione mono richiesta:

SYMLINK=<symlink>
MONOPREFIX=/Library/Frameworks/Mono.framework/Versions/$SYMLINK
echo "##vso[task.setvariable variable=DYLD_FALLBACK_LIBRARY_PATH;]$MONOPREFIX/lib:/lib:/usr/lib:$DYLD_LIBRARY_FALLBACK_PATH"
echo "##vso[task.setvariable variable=PKG_CONFIG_PATH;]$MONOPREFIX/lib/pkgconfig:$MONOPREFIX/share/pkgconfig:$PKG_CONFIG_PATH"
echo "##vso[task.setvariable variable=PATH;]$MONOPREFIX/bin:$PATH"