Condividi tramite

Agenti di Azure Pipelines

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

È necessario almeno un agente per compilare il codice o distribuire il software usando Azure Pipelines. Man mano che la codebase e il team aumentano, sono necessari più agenti.

Quando la pipeline viene eseguita, il sistema avvia uno o più processi. L'infrastruttura di elaborazione è un agente con software agente installato che esegue un compito alla volta.

Azure Pipelines offre diversi tipi di agenti.

Tipo di agente Descrizione Disponibilità
Agenti ospitati da Microsoft Agenti ospitati e gestiti da Microsoft. Servizi di Azure DevOps
Agenti auto-ospitati Agenti configurati e gestiti ospitati nelle macchine virtuali. Servizi Azure DevOps, Server Azure DevOps
Agenti gestiti dei pool DevOps I pool DevOps gestiti sono un servizio completamente gestito. Macchine virtuali o contenitori che alimentano gli agenti risiedono in una sottoscrizione di Microsoft Azure e non nella propria sottoscrizione di Azure. Servizi di Azure DevOps
Agenti dei set di scalabilità delle macchine virtuali Azure Una forma di agenti self-hosted che usa set di scalabilità di macchine virtuali di Azure e può essere ridimensionata automaticamente per soddisfare le esigenze.

Se si sta valutando l'uso di pool di agenti autocalabili e self-hosted, è consigliabile prendere in considerazione i pool DevOps gestiti. Per altre informazioni, vedere Confrontare i pool di DevOps gestiti con gli agenti dei set di scalabilità di macchine virtuali di Azure e la panoramica dei pool di DevOps gestiti.		 Servizi di Azure DevOps

È possibile eseguire processi direttamente nel computer host dell'agente o in un contenitore.

Agenti ospitati da Microsoft

Se le pipeline si trovano in Azure Pipelines, è possibile eseguire facilmente i processi usando un agente ospitato da Microsoft. Con gli agenti ospitati da Microsoft, la manutenzione e gli aggiornamenti vengono eseguiti automaticamente.

È sempre disponibile la versione più recente dell'immagine della macchina virtuale 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 scartata dopo un'operazione. Qualsiasi modifica apportata da un processo al file system della macchina virtuale, ad esempio il controllo del codice, non è disponibile nel 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 processo è il modo più semplice per eseguire le attività. È possibile provare prima di tutto per verificare se funziona per la compilazione o la distribuzione. In caso contrario, è possibile usare gli agenti dei set di scalabilità di macchine virtuali o un agente ospitato autonomamente.

Suggerimento

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

Altre informazioni sugli agenti ospitati da Microsoft.

Agenti autogestiti

Un agente ospitato internamente è un agente che configuri per eseguire i lavori e gestire autonomamente. È possibile usare agenti self-hosted in Azure Pipelines o Azure DevOps Server. Gli agenti autogestiti offrono un maggiore controllo per installare il software dipendente necessario per le compilazioni e le distribuzioni. Inoltre, le cache a livello macchina e la configurazione vengono mantenute tra le esecuzioni, il che può aumentare la velocità.

Anche se è possibile installare più agenti per computer, è consigliabile installare un solo agente per computer. Quando si installano due o più agenti, potrebbe influire negativamente sulle prestazioni e sul risultato delle pipeline.

Suggerimento

Prima di installare un agente autogestito, puoi verificare se un pool di agenti ospitato da Microsoft fa al caso tuo. In molti casi, un pool di agenti ospitati da Microsoft è il modo più semplice per iniziare. Prova.

È possibile installare l'agente in computer Linux, macOS e Windows. È anche possibile installare l'agente in un contenitore Docker. Per ulteriori informazioni sull'installazione di un agente autogestito, consultare:

Su macOS, è necessario rimuovere l'attributo speciale nell'archivio di download per impedire la visualizzazione della protezione Gatekeeper di macOS per ogni assembly nel file TAR quando viene eseguito ./config.sh. Il comando seguente cancella l'attributo esteso nel file:

xattr -c vsts-agent-osx-x64-V.v.v.tar.gz  ## replace V.v.v with the version in the filename downloaded.
 
# then unpack the gzip tar file normally:

tar xvfz vsts-agent-osx-x64-V.v.v.tar.gz

Dopo aver installato l'agente su un computer, è possibile installare qualsiasi altro software su quel computer che i processi richiedono.

Nota

Gli agenti sono ampiamente compatibili con le versioni precedenti. Qualsiasi versione dell'agente deve essere compatibile con qualsiasi versione di Azure DevOps, purché Azure DevOps non richieda una versione successiva dell'agente.

È supportata solo la versione più recente dell'agente, perché questa è l'unica versione garantita per avere tutte le patch e le correzioni di bug up-to-date.

versioni del runner di Node.js

L'agente viene fornito con diverse versioni di librerie di Node.js per supportare le attività di destinazione che usano gestori di Node.js diversi.

Tutte le attività ufficiali di Azure DevOps usano Node.js libreria 20 come gestore universale. Tuttavia, i clienti potrebbero comunque usare attività personalizzate che usano le versioni di Node.js non più supportate. Gli autori di attività di estensione/personalizzati devono aggiornare/testare le attività con le versioni Node.js correnti.

Per ulteriori informazioni sul ciclo di vita del runner Node.js in Azure Pipelines, vedere runner Node.js nell'agente di Azure Pipelines.

Agenti dei set di scalabilità di macchine virtuali di Azure

Gli agenti dei set di scalabilità di macchine virtuali di Azure sono una forma di agenti self-hosted che possono essere ridimensionati automaticamente per soddisfare le esigenze. Questa elasticità riduce la necessità di utilizzare costantemente agenti dedicati. A differenza degli agenti ospitati da Microsoft, si ha flessibilità rispetto alle dimensioni e all'immagine dei computer in cui vengono eseguiti gli agenti.

Azure Pipelines gestisce automaticamente il ridimensionamento degli agenti. Specificare i fattori seguenti:

  • Un set di scalabilità di macchine virtuali
  • Numero di agenti da mantenere in standby
  • Numero massimo di macchine virtuali nel set di scalabilità

Per altre informazioni, vedere Agenti dei set di scalabilità di macchine virtuali di Azure.

Agenti di pool DevOps gestiti

I pool di DevOps gestiti consentono ai team di sviluppo di avviare rapidamente e facilmente pool di agenti di Azure DevOps personalizzati in base alle esigenze specifiche di un team.

Gestione dei pool DevOps

  • Implementa le procedure consigliate per la sicurezza.
  • Fornisce modi per bilanciare i costi e le prestazioni.
  • Fornisce percorsi per gli scenari più comuni.
  • Riduce significativamente il tempo necessario per creare e gestire pool personalizzati.

I pool devOps gestiti sono un'evoluzione dei pool di agenti dei set di scalabilità di macchine virtuali di Azure. Semplifica ulteriormente la creazione di pool personalizzati migliorando la scalabilità e l'affidabilità dei pool personalizzati. I pool DevOps gestiti sono un servizio completamente gestito. Le macchine virtuali o i contenitori che eseguono gli agenti operano all'interno di una sottoscrizione di Microsoft Azure e non nella tua sottoscrizione di Azure, analogamente ai pool di agenti dei set di scalabilità di macchine virtuali di Azure. Per altre informazioni, si veda Documentazione dei pool gestiti DevOps.

Lavori in parallelo

Il concetto di processi paralleli rappresenta il numero di processi che è possibile eseguire contemporaneamente nell'organizzazione. Se l'organizzazione ha un singolo processo parallelo, è possibile eseguire un singolo processo alla volta nell'organizzazione. Tutti gli altri lavori simultanei vengono messi in coda fino al completamento del primo lavoro. Per eseguire due processi contemporaneamente, sono necessari due processi in parallelo. In Azure Pipelines è possibile eseguire processi in parallelo nell'infrastruttura ospitata da Microsoft o nell'infrastruttura (self-hosted) personalizzata.

Microsoft offre un livello gratuito di servizio per impostazione predefinita in ogni organizzazione che include almeno un processo in parallelo. A seconda del numero di pipeline simultanee da eseguire, potrebbero essere necessari più processi paralleli per usare più agenti ospitati da Microsoft o self-hosted contemporaneamente. Per altre informazioni sui processi paralleli e sui diversi livelli gratuiti del servizio, vedere Processi paralleli in Azure Pipelines.

Potrebbero essere necessari più processi paralleli per usare più agenti contemporaneamente:

Importante

A partire da Azure DevOps Server 2019, non si paga per i processi simultanei self-hosted nelle versioni. Sei limitato solo dal numero di agenti che hai.

Funzionalità

Ogni agente autogestito ha un set di funzionalità che definiscono cosa può fare. Le funzionalità sono coppie nome/valore che sono:

  • Funzionalità rilevate dal software agente, denominate funzionalità di sistema.
  • Funzionalità definite dall'utente, denominate funzionalità utente.

Il software agente determina automaticamente varie funzionalità di sistema. Queste funzionalità includono il nome del computer, il tipo di sistema operativo e le versioni di determinati software installati nel computer. Inoltre, le variabili di ambiente definite nel computer vengono visualizzate automaticamente nell'elenco delle funzionalità di sistema.

Quando si archiviano le variabili di ambiente come funzionalità, i valori delle funzionalità archiviate vengono usati per impostare le variabili di ambiente quando viene eseguito un agente. Inoltre, quando si apportano modifiche alle variabili di ambiente mentre l'agente è in esecuzione, non vengono prelevate e usate da alcuna attività. Se non si vuole che le variabili di ambiente sensibili che cambiano da archiviare come funzionalità, è possibile indirizzare l'agente a ignorarle. Impostare la VSO_AGENT_IGNORE variabile di ambiente con un elenco delimitato da virgole di variabili da ignorare. Ad esempio, PATH è una variabile critica che può essere utile ignorare se si installa il software.

Quando si crea una pipeline, si specificano determinate richieste dell'agente. Il sistema invia il processo solo agli agenti con funzionalità che corrispondono alle richieste specificate nella pipeline. Di conseguenza, le funzionalità dell'agente consentono di indirizzare i processi a agenti specifici.

Le richieste e le capacità sono progettate per l'uso con agenti self-hosted affinché i lavori possano essere abbinati a un agente che soddisfa i requisiti del lavoro. Quando si usano agenti ospitati da Microsoft, si seleziona un'immagine per l'agente che soddisfa i requisiti del processo. Anche se è possibile aggiungere funzionalità a un agente ospitato da Microsoft, non è necessario usare le funzionalità con gli agenti ospitati da Microsoft.

Configurare le richieste

Per aggiungere una condizione alla pipeline di compilazione YAML, aggiungere la riga demands: nella sezione pool.

pool:
  name: Default
  demands: SpecialSoftware # exists check for SpecialSoftware

È possibile verificare l'esistenza di una funzionalità o eseguire un confronto con il valore di una funzionalità. Per altre informazioni, vedere Schema YAML - Richieste.

Configurare le funzionalità dell'agente

È possibile visualizzare i dettagli dell'agente, incluse le funzionalità di versione e di sistema e gestire le funzionalità utente. Passare a Pool di agenti e selezionare la scheda Funzionalità per l'agente desiderato.

  1. Nel browser web, passare a Pool di agenti:

    1. Accedi all'organizzazione (https://dev.azure.com/{yourorganization}).

    2. SelezionareImpostazioni dell'organizzazione>.

      Screenshot che mostra come selezionare le impostazioni dell'organizzazione.

    3. Selezionare Pool di agenti.

      Screenshot che mostra come selezionare la scheda Pool di agenti.

    1. Accedere alla raccolta di progetti (http://your-server/DefaultCollection).

    2. Selezionare Azure DevOps>Impostazioni della raccolta.

      Screenshot che mostra come selezionare Impostazioni raccolta.

    3. Selezionare Pool di agenti.

      Seleziona pool di agenti.

    Screenshot che mostra come accedere a e selezionare Pool di agenti.

  2. Passare alla scheda Funzionalità :

    1. Nella scheda Pool di agenti selezionare il pool di agenti desiderato.

      In Pool di agenti selezionare il pool di agenti desiderato.

    2. Selezionare Agenti e scegliere l'agente desiderato.

      Selezionare Agenti e scegliere l'agente.

    3. Scegliere la scheda Funzionalità .

      Scegliere la scheda Funzionalità.

      Nota

      Gli agenti ospitati da Microsoft non visualizzano le funzionalità di sistema. Per un elenco del software installato in agenti ospitati da Microsoft, vedere Usare un agente ospitato da Microsoft.

    1. Nella scheda Pool di agenti selezionare il pool desiderato.

      Selezionare il pool desiderato.

    2. Selezionare Agenti e scegliere l'agente desiderato.

      Selezionare Agenti e scegliere l'agente desiderato.

    3. Scegliere la scheda Funzionalità .

      Scheda Capacità Agente.

  3. Per registrare una nuova funzionalità con l'agente, selezionare Aggiungi una nuova funzionalità.

Suggerimento

Dopo aver installato il nuovo software in un agente self-hosted, è necessario riavviare l'agente per visualizzare la nuova funzionalità. Per altre informazioni, vedere Riavviare l'agente Windows, Riavviare l'agente Linux e Riavviare l'agente Mac.

Comunicazione

Comunicazione con Azure Pipelines

Comunicazione con Azure DevOps Server

L'agente comunica con Azure Pipelines o Azure DevOps Server. Determina il processo da eseguire e segnala i log e lo stato del processo. L'agente avvia sempre questa comunicazione.

Tutti i messaggi dall'agente ad Azure Pipelines o Azure DevOps Server vengono inviati tramite HTTP o HTTPS, a seconda della modalità di configurazione dell'agente. Questo modello pull consente di configurare l'agente in topologie diverse, come illustrato negli esempi seguenti.

Immagine che mostra le topologie degli agenti nelle installazioni locali.

Immagine che mostra le topologie degli agenti in Azure DevOps Services.

Ecco un modello di comunicazione comune tra l'agente e Azure Pipelines o Azure DevOps Server:

  1. L'utente registra un agente con Azure Pipelines o Azure DevOps Server aggiungendolo a un pool di agenti. Per registrare un agente nel pool di agenti, è necessario avere il ruolo di amministratore del pool di agenti . Il ruolo di amministratore del pool di agenti è necessario solo al momento della registrazione e non è persistente nell'agente. Non viene usato in altre comunicazioni tra l'agente e Azure Pipelines o Azure DevOps Server.

    Al termine della registrazione, l'agente scarica un file listener OAuth token e lo usa per ascoltare la coda di lavoro.

  2. L'agente è in ascolto per vedere se è pubblicata una nuova richiesta di attività nella coda delle attività in Azure Pipelines o in Azure DevOps Server, utilizzando un polling HTTP lungo. Quando un task è disponibile, l'agente scarica il task e un elemento job-specific OAuth token. Azure Pipelines o Azure DevOps Server genera un token di breve durata per l'identità con ambito specificata nella pipeline.

    L'agente usa il token per accedere o modificare le risorse in Azure Pipelines o nel server Azure DevOps all'interno di tale processo. Ad esempio, usa il token per accedere al codice sorgente o caricare i risultati dei test.

  3. L'agente rimuove il token specifico OAuth del processo dopo il completamento del processo e quindi verifica se è presente una nuova richiesta di processo usando il token OAuth del listener.

Il payload dei messaggi scambiati tra l'agente e Azure Pipelines o Azure DevOps Server vengono protetti usando la crittografia asimmetrica.

Ogni agente dispone di una coppia di chiavi pubblica e privata e la chiave pubblica viene scambiata con il server durante la registrazione. Il server usa la chiave pubblica per crittografare il payload del processo prima di inviarlo all'agente. L'agente decrittografa il contenuto del processo usando la relativa chiave privata.

Questo metodo protegge i segreti archiviati in pipeline o gruppi di variabili quando vengono scambiati con l'agente.

Nota

L'agente fornisce il supporto per l'output di codifica client UTF-8. Tuttavia, se il sistema non usa la codifica UTF-8, potrebbero verificarsi alcuni problemi con l'output del log. Ad esempio, i log potrebbero contenere caratteri non riconosciuti dalla codifica del sistema, in modo che sembrino essere incomprensibili o mancanti.

Comunicazione per la distribuzione nei server di destinazione

Quando si utilizza l'agente per distribuire gli artefatti a un insieme di server, è necessario disporre di una connessione diretta con tali server. Per impostazione predefinita, i pool di agenti ospitati da Microsoft hanno connettività a siti Web e server di Azure eseguiti in Azure.

Se le risorse di Azure vengono eseguite in una rete virtuale di Azure, è possibile ottenere gli intervalli IP dell'agente in cui vengono distribuiti gli agenti ospitati da Microsoft. È quindi possibile configurare le regole del firewall per la rete virtuale di Azure per consentire l'accesso dall'agente.

Se gli ambienti locali non hanno connettività a un pool di agenti ospitati da Microsoft, in genere a causa di firewall intermedi, è necessario configurare manualmente gli agenti self-hosted nei computer locali. Gli agenti devono avere connettività agli ambienti locali di destinazione e accedere a Internet per connettersi ad Azure Pipelines o azure DevOps Server. Questo processo è dimostrato nello schema seguente:

Immagine che mostra la connettività dell'agente per gli ambienti locali.

Autenticazione

Per registrare un agente, è necessario essere un membro del ruolo di amministratore nel pool di agenti. L'identità dell'amministratore del pool di agenti è necessaria solo al momento della registrazione e non viene memorizzata sull'agente. Non viene usato in alcuna comunicazione successiva tra l'agente e Azure Pipelines o Azure DevOps Server. Per configurare l'agente, è necessario anche essere un amministratore locale nel server.

Quando si registra un agente, selezionare tra i tipi di autenticazione seguenti. Il processo di installazione dell'agente richiede le informazioni aggiuntive specifiche necessarie per ogni tipo di autenticazione. Per ulteriori informazioni, vedere Opzioni di autenticazione dell'agente autogestito.

Inoltre, gli agenti Windows hanno le due opzioni di autenticazione seguenti in Azure DevOps Server.

  • Negoziazione: connettersi ad Azure DevOps Server come utente diverso dall'utente connesso tramite uno schema di autenticazione di Windows( ad esempio, New Technology LAN Manager (NTLM) o Kerberos. Dopo aver selezionato Negozia, vengono richieste le credenziali.
  • Integrato: (impostazione predefinita) Connettere un agente Windows ad Azure DevOps Server usando le credenziali dell'utente connesso tramite uno schema di autenticazione di Windows( ad esempio NTLM o Kerberos). Non verranno richieste le credenziali dopo aver selezionato questo metodo.

Importante

È necessario configurare il server per supportare il metodo di autenticazione per l'uso dell'autenticazione alternativa, negotiate o integrata.

Il metodo di autenticazione usato per registrare l'agente viene usato solo durante la registrazione dell'agente. Per altre informazioni su come gli agenti comunicano con Azure Pipelines dopo la registrazione, vedere Comunicazione con Azure Pipelines o Azure DevOps Server.

Interattivo vs. servizio

È possibile eseguire un agente ospitato autonomamente come servizio o come processo interattivo.

Dopo aver configurato l'agente, è consigliabile provarlo prima in modalità interattiva per assicurarsi che funzioni. Quindi, per l'uso in produzione, è consigliabile eseguire l'agente in una delle modalità seguenti in modo che rimanga in modo affidabile in uno stato di esecuzione. Queste modalità assicurano anche che l'agente venga avviato automaticamente in caso di riavvio del computer.

  • Come servizio: è possibile usare il gestore dei servizi del sistema operativo per gestire il ciclo di vita dell'agente. L'esperienza di aggiornamento automatico dell'agente è migliore quando si esegue l'agente come servizio.

  • Come processo interattivo con l'accesso automatico abilitato: in alcuni casi potrebbe essere necessario eseguire l'agente in modo interattivo per l'uso in produzione, ad esempio per eseguire test dell'interfaccia utente. Quando si configura un agente per l'esecuzione in questa modalità, lo screen saver è disabilitato. Alcuni criteri di dominio potrebbero impedire l'abilitazione dell'accesso automatico o la disabilitazione dello screen saver. In questi casi, potrebbe essere necessario richiedere un'esenzione dai criteri di dominio o eseguire l'agente in un computer del gruppo di lavoro in cui i criteri di dominio non si applicano.

    Nota

    Esistono rischi per la sicurezza quando si abilita l'accesso automatico o si disabilita lo screen saver. Altri utenti potrebbero essere in grado di accedere al computer e usare l'account che esegue automaticamente l'accesso. Se si configura l'agente per l'esecuzione in questo modo, è necessario assicurarsi che il computer sia fisicamente protetto, ad esempio che si trovi in una struttura sicura.

    Se si usa un desktop remoto per accedere a un computer in cui un agente è in esecuzione con accesso automatico, la chiusura del desktop remoto determina il blocco del computer. Eventuali test dell'interfaccia utente eseguiti su questo agente potrebbero non riuscire. Per evitare questo problema, usare il tscon comando per disconnettersi dal desktop remoto. Ad esempio:

    %windir%\System32\tscon.exe 1 /dest:console

Account agente

Che si esegua un agente come servizio o in modo interattivo, è possibile scegliere l'account del computer usato per eseguire l'agente. La scelta dell'account agente dipende esclusivamente dalle esigenze delle attività eseguite nei processi di compilazione e distribuzione.

Ad esempio, per eseguire le attività utilizzando l'autenticazione di Windows per accedere a un servizio esterno, l'agente deve operare con un account che abbia accesso a tale servizio. Tuttavia, se si eseguono test dell'interfaccia utente come Selenium o test codificati dell'interfaccia utente che richiedono un browser, il browser viene aperto nel contesto dell'account agente.

In Windows è consigliabile usare un account del servizio, ad esempio Servizio di rete o Servizio locale. Queste autorizzazioni per gli account sono limitate e le relative password non scadono, quindi l'agente richiede meno gestione nel tempo.

Queste credenziali sono diverse dalle credenziali usate quando si registra l'agente con Azure Pipelines o Azure DevOps Server.

Versione e aggiornamenti dell'agente

Il software agente viene aggiornato ogni poche settimane in Azure Pipelines. Indichiamo la versione dell'agente nel formato {major}.{minor}. Ad esempio, se la versione dell'agente è 2.1, la versione principale è 2 e la versione secondaria è 1.

Microsoft mantiene aggiornati gli agenti ospitati da Microsoft. Se la versione più recente dell'agente è diversa solo nella versione minor, Azure Pipelines può aggiornare automaticamente gli agenti ospitati autonomamente. L'impostazione predefinita è abilitata. È possibile configurare questa impostazione nei pool di agenti selezionando l'agente e quindi selezionando Impostazioni. Viene richiesto un aggiornamento quando una funzionalità della piattaforma o una delle attività nella pipeline richiede una versione più recente dell'agente.

Se si esegue un agente self-hosted in modo interattivo o se è disponibile una versione major più recente dell'agente, potrebbe essere necessario aggiornare manualmente gli agenti. È possibile aggiornare gli agenti dalla scheda Pool di agenti nell'organizzazione. Le pipeline non possono essere eseguite senza un agente compatibile.

Per aggiornare gli agenti auto-ospitati

  1. Passare a Impostazioni progetto>Pool di agenti.

    Screenshot che mostra come trovare e selezionare Pool di agenti.

  2. Selezionare il pool di agenti e quindi selezionare Aggiorna tutti gli agenti.

    Screenshot che mostra come selezionare Aggiorna tutti gli agenti.

    È anche possibile aggiornare gli agenti singolarmente selezionando Aggiorna agente dal menu ... .

    Screenshot che mostra come selezionare l'agente di aggiornamento.

  3. Selezionare Aggiorna per confermare.

    Screenshot che mostra come selezionare Aggiorna per confermare.

  4. Una richiesta di aggiornamento viene accodata per ogni agente nel pool e viene eseguita quando termina uno dei processi attualmente in esecuzione. Un aggiornamento richiede in genere solo alcuni istanti. Questo periodo di tempo è sufficiente per scaricare la versione più recente del software agente (circa 200 MB), decomprimerlo e riavviare l'agente con la nuova versione. È possibile monitorare lo stato degli agenti nella scheda Agenti .

Il software agente viene aggiornato con ogni aggiornamento di Azure DevOps Server. Indichiamo la versione dell'agente nel formato {major}.{minor}. Ad esempio, se la versione dell'agente è 2.1, la versione principale è 2 e la versione secondaria è 1.

Quando Azure DevOps Server ha una versione più recente dell'agente e tale agente più recente è diverso solo nella versione secondaria , in genere può essere aggiornato automaticamente. Viene richiesto un aggiornamento quando una funzionalità della piattaforma o una delle attività usate nella pipeline richiede una versione più recente dell'agente. A partire da Azure DevOps Server 2019, non è necessario attendere una nuova versione del server. È possibile caricare una nuova versione dell'agente nel livello dell'applicazione e tale versione viene offerta come aggiornamento.

Se si esegue l'agente in modo interattivo o se è disponibile una versione principale più recente dell'agente, potrebbe essere necessario aggiornare manualmente gli agenti. È possibile aggiornare facilmente l'agente dalla scheda Pool di agenti nella raccolta di progetti. Le pipeline non possono essere eseguite senza un agente compatibile.

È possibile visualizzare la versione di un agente. Passare a Pool di agenti e selezionare la scheda Funzionalità per l'agente desiderato, come descritto in Configurare le funzionalità dell'agente.

Per attivare l'aggiornamento dell'agente a livello di codice, è possibile usare l'API di aggiornamento dell'agente come descritto nella sezione Come attivare gli aggiornamenti dell'agente a livello di codice per un pool di agenti specifico?

Per i server senza accesso a Internet, copiare manualmente il file ZIP dell'agente nella cartella seguente da usare come file locale. Creare la cartella Agents se non è presente:

  • Finestre: %ProgramData%\Microsoft\Azure DevOps\Agents
  • Linux: usr/share/Microsoft/Azure DevOps/Agents
  • Macos: usr/share/Microsoft/Azure DevOps/Agents

Struttura della directory dell'agente

Quando i processi della pipeline vengono eseguiti sugli agenti, viene creata una struttura di directory per archiviare il codice sorgente, i file binari e gli artefatti.

La directory principale dell'agente è la directory in cui è installato l'agente. La directory si trova in genere:

  • Agenti ospitati da Microsoft: C:\agents\<agent version> in Windows, /Users/runner/runners/<agent version> in macOS e /home/vsts/agents/<agent version> in Linux.
  • Agenti self-hosted: C:\agent su Windows, Users/<username>/agent (~/agent) su macOS e /home/vsts/agent su Linux.

La directory di lavoro dell'agente contiene l'area di lavoro in cui sono archiviati il codice sorgente e l'output dei job. La directory di lavoro si trova in genere:

  • Agente ospitato da Microsoft: C:\a in Windows, /Users/runner/work in macOS e/home/vsts/work in Linux.
  • Agente autogestito: C:\agent\_work su Windows, ~/agent/work su macOS e /home/agent/_work su Linux.

La struttura della directory di lavoro è:


    - /work directory
        - /1 build directory/pipeline workspace
            - /s source/working directory
            - /b binaries directory
            - /a artifacts staging directory
            - /TestResults Test results directory
Directory Descrizione Esempi Variabili predefinite
Home directory dell'agente Posizione in cui è installato l'agente. Agente ospitato da Microsoft:
   Finestre: C:\agents\3.248.0
   Linux: /home/vsts/agents/3.248.0
   Macos: /Users/runner/runners/3.248.0
Agente autonomamente ospitato
   Finestre: C:\agent
   Linux: home/agent
   Macos: ~/agent		 Agent.HomeDirectory
Cartella di lavoro Dove l'agente archivia il codice sorgente, i file binari e gli artefatti. Agente ospitato da Microsoft:
   Finestre: C:\a
   Linux: /home/vsts/work
   Macos: /Users/runner/work
Agente autonomamente ospitato
   Finestre: C:\agent\_work
   Linux: /home/agent/_work
   Macos: ~/agent/work		 Agent.WorkFolder
Agent.RootDirectory
System.WorkFolder
Creare una directory o un'area di lavoro Posizione in cui viene eseguito il processo della pipeline. Agente ospitato da Microsoft:
   Finestre: C:\a\1
   Linux: /home/vsts/work/1
   Macos: /Users/runner/work/1
Agente autonomamente ospitato
   Finestre: C:\agent\_work\1
   Linux: /home/agent/_work/1
   Macos: ~/agent/work/1		 Agent.BuildDirectory
Pipeline.Workspace
s - Directory di origine o di lavoro Contiene il codice sorgente estratto dal repository. Se sono presenti più checkout passaggi nel processo, il codice sorgente viene estratto nelle directory denominate dopo i repository come sottocartella di s. Agente ospitato da Microsoft:
   Finestre: C:\a\1\s
   Linux: /home/vsts/work/1/s
   Macos: /Users/runner/work/1/s
Agente autonomamente ospitato
   Finestre: C:\agent\_work\1\s
   Linux: /home/agent/_work/1/s
   Macos: ~/agent/work/1/s		 Build.SourcesDirectory
Build.RepositoryLocalPath
System.DefaultWorkingDirectory
b - Directory dei binari Contiene gli output di compilazione. Agente ospitato da Microsoft:
   Finestre: C:\a\1\b
   Linux: /home/vsts/work/1/b
   Macos: /Users/runner/work/1/b
Agente autonomamente ospitato
   Finestre: C:\agent\_work\1\b
   Linux: /home/agent/_work/1/b
   Macos: ~/agent/work/1/b		 Build.BinariesDirectory
a - Directory di gestione temporanea artefatti Contiene gli artefatti di build. Viene pulito tra le esecuzioni sugli agenti ospitati autonomamente. Agente ospitato da Microsoft:
   Finestre: C:\a\1\a
   Linux: /home/vsts/work/1/a
   Macos: /Users/runner/work/1/a
Agente autonomamente ospitato
   Finestre: C:\agent\_work\1\a
   Linux: /home/agent/_work/1/a
   Macos: ~/agent/work/1/a		 Build.StagingDirectory
Build.ArtifactStagingDirectory
System.ArtifactsDirectory
TestResults Directory Contiene i risultati del test. Viene pulito tra le esecuzioni sugli agenti ospitati autonomamente. Agente ospitato da Microsoft:
   Finestre: C:\a\1\TestResults
   Linux: /home/vsts/work/1/TestResults
   Macos: /Users/runner/work/1/TestResults
Agente autonomamente ospitato
   Finestre: C:\agent\_work\1\TestResults
   Linux: /home/agent/_work/1/TestResults
   Macos: ~/agent/work/1/TestResults		 Common.TestResultsDirectory

Negli agenti ospitati da Microsoft viene usato un agente diverso in ogni esecuzione, quindi la directory di lavoro non viene mantenuta tra le esecuzioni. Negli agenti self-hosted, solo la directory di staging degli artefatti e la directory dei risultati dei test vengono pulite tra le esecuzioni per impostazione predefinita. Per altre informazioni sull'opzione di pulizia dell'area di lavoro, vedere Workspace.

Per altre informazioni sulle variabili predefinite, vedere Variabili predefinite.

Domande frequenti

Come posso assicurarmi di avere la versione più recente dell'agente?

  1. Passare alla scheda Pool di agenti :

    1. Accedi all'organizzazione (https://dev.azure.com/{yourorganization}).

    2. SelezionareImpostazioni dell'organizzazione>.

      Screenshot che mostra come selezionare le impostazioni dell'organizzazione.

    3. Selezionare Pool di agenti.

      Screenshot che mostra come selezionare la scheda Pool di agenti.

    1. Accedere alla raccolta di progetti (http://your-server/DefaultCollection).

    2. Selezionare Azure DevOps>Impostazioni della raccolta.

      Screenshot che mostra come selezionare Impostazioni raccolta.

    3. Selezionare Pool di agenti.

      Seleziona pool di agenti.

    Screenshot che mostra come accedere a e selezionare Pool di agenti.

  2. Selezionare il pool che contiene l'agente.

  3. Assicurarsi che l'agente sia abilitato.

  4. Passare alla scheda funzionalità:

    1. Nella scheda Pool di agenti selezionare il pool di agenti desiderato.

      In Pool di agenti selezionare il pool di agenti desiderato.

    2. Selezionare Agenti e scegliere l'agente desiderato.

      Selezionare Agenti e scegliere l'agente.

    3. Scegliere la scheda Funzionalità .

      Scegliere la scheda Funzionalità.

      Nota

      Gli agenti ospitati da Microsoft non visualizzano le funzionalità di sistema. Per un elenco del software installato in agenti ospitati da Microsoft, vedere Usare un agente ospitato da Microsoft.

    1. Nella scheda Pool di agenti selezionare il pool desiderato.

      Selezionare il pool desiderato.

    2. Selezionare Agenti e scegliere l'agente desiderato.

      Selezionare Agenti e scegliere l'agente desiderato.

    3. Scegliere la scheda Funzionalità .

      Scheda Capacità Agente.

  5. Cerca la Agent.Version funzionalità. È possibile confrontare questo valore con la versione più recente dell'agente pubblicato nella pagina Agente di Azure Pipelines .

  6. Ogni agente si aggiorna automaticamente quando esegue un'attività che richiede una versione più recente dell'agente. Per aggiornare manualmente alcuni agenti, fare clic con il pulsante destro del mouse sul pool e quindi scegliere Aggiorna tutti gli agenti.

È possibile aggiornare gli agenti che fanno parte di un pool di Azure DevOps Server?

Sì. A partire da Azure DevOps Server 2019, è possibile configurare il server per cercare i file del pacchetto dell'agente in un disco locale. Questa configurazione sostituisce la versione predefinita fornita con il server al momento del rilascio. Questo scenario si applica anche quando il server non ha accesso a Internet.

  1. Da un computer con accesso a Internet, scarica la versione più recente dei file del pacchetto dell'agente in formato .zip o .tar.gz dalla pagina delle release di Azure Pipelines Agent su GitHub.

  2. Trasferire i file di pacchetto scaricati in ogni livello applicazione di Azure DevOps Server usando un metodo di propria scelta, ad esempio unità USB, trasferimento di rete e così via. Posizionare i file dell'agente nella %ProgramData%\Microsoft\Azure DevOps\Agents cartella . Se non è presente alcuna cartella con etichetta Agents, crearne una.

  3. Tutto a posto! Il server Azure DevOps ora usa i file locali ogni volta che gli agenti vengono aggiornati. Ogni agente si aggiorna automaticamente quando esegue un'attività che richiede una versione più recente dell'agente. Tuttavia, se si desidera aggiornare manualmente alcuni agenti, fare clic con il pulsante destro del mouse sul pool e quindi scegliere Aggiorna tutti gli agenti.

Gli agenti self-hosted presentano vantaggi rispetto agli agenti ospitati da Microsoft in termini di prestazioni?

In molti casi, sì. Se si usa un agente self-hosted, è possibile eseguire compilazioni incrementali. Ad esempio, se si definisce una pipeline che non pulisce il repository e non esegue una compilazione pulita, le compilazioni vengono in genere eseguite più velocemente. Questi vantaggi non si ottengono con un agente ospitato da Microsoft, a meno che non si usino funzionalità come la memorizzazione nella cache, perché l'agente viene eliminato definitivamente dopo il completamento della pipeline.

Con un agente ospitato da Microsoft l'avvio della compilazione può richiedere più tempo. Anche se l'assegnazione del processo a un agente ospitato da Microsoft richiede spesso pochi secondi, può richiedere alcuni minuti per l'allocazione di un agente, a seconda del carico del sistema.

È possibile installare più agenti autogestiti sulla stessa macchina?

Sì. Questo approccio può essere utile per gli agenti che eseguono processi che non utilizzano molte risorse condivise. Ad esempio, potresti provarlo per agenti che eseguono rilasci che orchestrano principalmente le distribuzioni e non svolgono molte operazioni sull'agente stesso.

Si potrebbe notare che in altri casi non si ottiene molta efficienza eseguendo più agenti nello stesso computer. Ad esempio, potrebbe non essere utile per gli agenti che eseguono compilazioni che utilizzano molto spazio su disco e risorse di input/output.

È anche possibile riscontrare problemi se i processi di compilazione paralleli usano la stessa distribuzione dello strumento singleton (ad esempio, pacchetti npm). Una compilazione potrebbe aggiornare una dipendenza mentre un'altra compilazione la usa, che potrebbe causare risultati ed errori inaffidabili.

Cosa fanno gli agenti quando i lavori della pipeline vengono annullati?

Per gli agenti ospitati da Microsoft, l'agente viene eliminato e restituito al pool di Azure Pipelines.

Per gli agenti autogestiti:

  • Quando una pipeline viene annullata, l'agente invia una sequenza di comandi al processo che esegue il passaggio corrente.
  • Il primo comando viene inviato con un timeout di 7,5 secondi.
  • Se il processo non termina, viene inviato un secondo comando con un timeout di 2,5 secondi.
  • Se il processo non termina, l'agente lo comanda a terminarlo.
  • Se il processo ignora le due richieste di terminazione iniziali, viene terminato forzatamente.

Il tempo dalla richiesta iniziale alla terminazione è di circa 10 secondi.

I comandi inviati al processo per annullare la pipeline differiscono in base al sistema operativo dell'agente:

  • macOS e Linux: i comandi inviati sono SIGINT, seguiti da SIGTERM, seguiti da SIGKILL.
  • Windows: i comandi inviati al processo sono Ctrl+C, seguiti da Ctrl+Break, seguiti da Process.Kill.

Come è possibile attivare gli aggiornamenti dell'agente a livello di codice per un pool di agenti specifico?

È possibile attivare gli aggiornamenti dell'agente per il pool usando l'API seguente:

POST https://dev.azure.com/{organization}/_apis/distributedtask/pools/{poolId}/messages?agentId={agentId}&api-version=6.0

POST https://{server url}/tfs/{collection}/_apis/distributedtask/pools/{poolId}/messages?agentId={agentId}&api-version=6.0

Nota

Per altre informazioni, vedere Mapping delle versioni di API e Azure DevOps Server.

Parametri URI

Nome In Richiesto Tipo Descrizione
agentId query False string Agente da aggiornare. Se non è specificato, viene attivato un aggiornamento per tutti gli agenti.
organization percorso True string Nome dell'organizzazione di Azure DevOps.
poolId percorso True integer int32 Il pool di agenti da usare.
api-version query False string Versione dell'API da usare. Per usare questa versione dell'API, il valore deve essere impostato su 6.0.

Per attivare un aggiornamento dell'agente, il corpo della richiesta deve essere vuoto.

L'agente di Azure Pipelines è open source in GitHub.

Contenuti correlati

Per altre informazioni sugli agenti, vedere i moduli seguenti nel percorso di apprendimento Compilare applicazioni con Azure DevOps :

  • Last updated on