Condividi tramite


Agenti Windows autogestiti

Servizi di Azure DevOps

Per compilare e distribuire Windows, Azure e altre soluzioni di Visual Studio, è necessario almeno un agente Windows. Gli agenti Windows possono anche creare app Java e Android.

Questo articolo fornisce indicazioni per l'uso del software agente 3.x con Azure DevOps Services e le versioni correnti di Azure DevOps Server. Per un elenco delle versioni di Azure DevOps Server che supportano l'agente 3.x, vedere Does Azure DevOps Server support the 3.x agent.

Nota

Questo articolo descrive come configurare un agente autogestito . Se si usa Azure DevOps Services e un agente ospitato da Microsoft soddisfa le proprie esigenze, è possibile ignorare la configurazione di un agente Windows self-hosted.

Informazioni sugli agenti

Se si conosce già cos'è un agente e come funziona, è possibile passare direttamente alle sezioni seguenti. Tuttavia, per un'ulteriore comprensione su cosa fanno e come operano, consulta Gli agenti di Azure Pipelines.

Verificare i prerequisiti

Assicurarsi che il computer disponga dei prerequisiti seguenti:

  • Versione del sistema operativo
    • Sistema operativo client
      • Windows 7 SP1 ESU
      • Windows 8.1
      • Windows 10
      • Windows 11
    • Sistema operativo server
      • Windows Server 2012 o versione successiva
  • Il software dell'agente installa la propria versione di .NET, quindi non esiste alcun prerequisito .NET.
  • PowerShell 3.0 o versione successiva
  • Subversion: se si esegue la compilazione da un repository Subversion, è necessario installare il client Subversion nel computer.
  • Consigliato- Strumenti di compilazione di Visual Studio (2015 o versione successiva)

È consigliabile eseguire manualmente l'installazione dell'agente la prima volta. Dopo aver compreso come funzionano gli agenti, o se si desidera automatizzare la configurazione di molti agenti, considera l'uso della configurazione non presidiata.

Specifiche hardware

Le specifiche hardware per gli agenti variano in base alle esigenze, alle dimensioni del team e così via. Non è possibile fare una raccomandazione generale che verrà applicata a tutti. Come punto di riferimento, il team di Azure DevOps compila il codice degli agenti ospitati usando pipeline che usano agenti ospitati. D'altra parte, la maggior parte del codice di Azure DevOps è sviluppata da macchine server di classe con 24 core che eseguono ciascuno quattro agenti self-hosted.

Preparare le autorizzazioni

Sicurezza delle informazioni per gli agenti ospitati internamente

L'utente che configura l'agente ha bisogno delle autorizzazioni di amministratore del pool, ma l'utente che esegue l'agente non ne ha bisogno.

Le cartelle controllate dall'agente devono essere limitate al minor numero possibile di utenti perché contengono segreti che potrebbero essere decrittografati o esfiltrati.

L'agente di Azure Pipelines è un prodotto software progettato per eseguire il codice scaricato da origini esterne. È potenzialmente un obiettivo per attacchi di esecuzione di codice in remoto (RCE).

È quindi importante considerare il modello di minaccia che circonda ogni singolo utilizzo degli agenti pipeline per eseguire il lavoro e decidere quali sono le autorizzazioni minime che possono essere concesse all'utente che esegue l'agente, al computer in cui viene eseguito l'agente, agli utenti che dispongono dell'accesso in scrittura alla definizione della pipeline, ai repository Git in cui è archiviato il yaml, o il gruppo di utenti che controllano l'accesso al pool per le nuove pipeline.

È una buona pratica che l'identità che esegue l'agente sia diversa dall'identità che possiede le autorizzazioni per connettere l'agente al pool. L'utente che genera le credenziali (e altri file correlati all'agente) è diverso dall'utente che deve leggerli. Pertanto, è più sicuro valutare attentamente l'accesso concesso al computer agente stesso e alle cartelle dell'agente che contengono file sensibili, come log e artefatti.

È opportuno concedere l'accesso alla cartella dell'agente solo agli amministratori DevOps e all'identità utente che esegue il processo dell'agente. Gli amministratori potrebbero dover esaminare il file system per comprendere gli errori di compilazione o ottenere i file di log per poter segnalare gli errori di Azure DevOps.

Decidi quale utente utilizzerai

Come passaggio una tantum, è necessario registrare l'agente. Un utente autorizzato ad amministrare la coda dell'agente deve completare questi passaggi. L'agente non userà le credenziali di questa persona nel funzionamento quotidiano, ma è necessario completare la registrazione. Altre informazioni sul modo in cui gli agenti comunicano.

Verificare che l'utente disponga dell'autorizzazione

Assicurarsi che l'account utente che si intende usare abbia l'autorizzazione per registrare l'agente.

L'utente è proprietario dell'organizzazione di Azure DevOps o TFS o amministratore di Azure DevOps Server? Fermati qui, sei autorizzato.

Altrimenti:

  1. Aprire un browser e passare alla scheda pool di agenti per l'organizzazione di Azure Pipelines o il server Azure DevOps Server o TFS:

    1. Accedi alla tua organizzazione (https://dev.azure.com/{yourorganization}).

    2. Scegliere Azure DevOps, Impostazioni organizzazione.

      Scegliere le impostazioni dell'organizzazione.

    3. Scegliere pool di agenti .

      Scegliere la scheda Pool di agenti.

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

    2. Scegliere Azure DevOps, Impostazioni della raccolta.

      Scegliere Impostazioni Raccolta.

    3. Scegliere pool di agenti .

      Scegliere pool di agenti.

  2. Selezionare il pool sul lato destro della pagina e quindi fare clic su Sicurezza.

  3. Se l'account utente che si intende usare non viene visualizzato, contatta un amministratore per farlo aggiungere. L'amministratore può essere un amministratore del pool di agenti, un proprietario dell'organizzazione di Azure DevOps o un amministratore di TFS o azure DevOps Server.

    Se si tratta di un agente del gruppo di distribuzione, l'amministratore può essere un amministratore del gruppo di distribuzione, un proprietario dell'organizzazione di Azure DevOps o un amministratore di TFS o Azure DevOps Server.

    È possibile aggiungere un utente al ruolo di amministratore del gruppo di distribuzione nella scheda Sicurezza della pagina Gruppi di distribuzione in Azure Pipelines.

Nota

Se viene visualizzato un messaggio simile al seguente: Spiacenti, non è stato possibile aggiungere l'identità. Provare un'identità diversa., è probabile che sia stata seguita la procedura precedente per un proprietario dell'organizzazione o un amministratore di TFS o di Azure DevOps Server. Non hai bisogno di fare niente; si dispone già dell'autorizzazione per amministrare il pool di agenti.

Scaricare e configurare l'agente

Azure Pipelines

  1. Accedere al computer usando l'account per cui sono state preparate le autorizzazioni, come illustrato in precedenza.

  2. Nel Web browser accedere ad Azure Pipelines e passare alla scheda Pool di agenti:

    1. Accedi alla tua organizzazione (https://dev.azure.com/{yourorganization}).

    2. Scegliere Azure DevOps, Impostazioni organizzazione.

      Scegliere le impostazioni dell'organizzazione.

    3. Scegliere pool di agenti .

      Scegliere la scheda Pool di agenti.

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

    2. Scegliere Azure DevOps, Impostazioni della raccolta.

      Scegliere Impostazioni Raccolta.

    3. Scegliere pool di agenti .

      Scegliere pool di agenti.

  3. Selezionare il pool predefinito, selezionare la scheda Agenti e scegliere Nuovo agente.

  4. Nella finestra di dialogo Recupera l'agente scegliere Windows.

  5. Nel riquadro sinistro selezionare l'architettura del processore della versione del sistema operativo Windows installata nel computer. La versione dell'agente x64 è destinata a Windows a 64 bit, mentre la versione x86 è destinata a Windows a 32 bit. Se non si è certi della versione di Windows installata, seguire queste istruzioni per scoprire.

  6. Nel riquadro destro fare clic sul pulsante Scarica .

  7. Seguire le istruzioni nella pagina per scaricare l'agente.

  8. Decomprimere l'agente nella directory di tua scelta. Assicurarsi che il percorso della directory non contenga spazi perché gli strumenti e gli script non sempre utilizzano spazi di escape appropriati. Una cartella consigliata è C:\agents. L'estrazione nella cartella di download o in altre cartelle utente può causare problemi di autorizzazione.

Importante

È consigliabile configurare l'agente da una finestra di PowerShell con privilegi elevati. Se si vuole configurare come servizio, è necessario.

Non è necessario usare Windows PowerShell ISE per configurare l'agente.

Importante

Per motivi di sicurezza, è consigliabile assicurarsi che la cartella agents (C:\agents) sia modificabile solo dagli amministratori.

Nota

Evitare di usare shell basate su mintty, ad esempio git-bash, per la configurazione dell'agente. Mintty non è completamente compatibile con l'API Windows input/output nativa (ecco alcune informazioni su di esso) e non possiamo garantire che lo script di installazione funzioni correttamente in questo caso.

Installare l'agente

  1. Avviare una finestra con privilegi elevati (PowerShell) e impostare il percorso in cui è stato decompresso l'agente.

    cd C:\agents 
    
    
  2. Esegui config.cmd. Ti verrà posta una serie di domande per configurare l'agente.

    .\config.cmd
    
    

URL del server

Quando l'installazione richiede l'URL del server, per Azure DevOps Services, rispondere https://dev.azure.com/{your-organization}.

Quando l'installazione richiede l'URL del server, per Azure DevOps Server, rispondere https://{my-server}/{my-collection}.

Tipo di autenticazione configurazione agente

Quando si registra un agente, scegliere tra i tipi di autenticazione seguenti e il programma di installazione richiederà le informazioni aggiuntive specifiche necessarie per ogni tipo di autenticazione. Per ulteriori informazioni, vedere Opzioni di autenticazione per agenti con hosting autonomo.

Gli agenti Windows hanno le due opzioni di autenticazione aggiuntive seguenti in Azure DevOps Server e TFS.

  • Negoziare Connettersi a TFS come utente diverso dall'utente connesso tramite uno schema di autenticazione di Windows, ad esempio NTLM o Kerberos. Dopo aver selezionato Negozia, verranno richieste le credenziali.
  • Integrato (impostazione predefinita) Connettere un agente Windows a TFS usando le credenziali dell'utente connesso tramite uno schema di autenticazione di Windows, ad esempio NTLM o Kerberos. Non verrà richiesto di immettere le credenziali dopo aver scelto questo metodo.

Importante

Il server deve essere configurato 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 TFS.

Scegliere la modalità interattiva o del servizio

Per indicazioni su se eseguire l'agente in modalità interattiva o come servizio, vedere Agents: Interactive vs. Service.

Se si sceglie di eseguire come servizio (cosa che consigliamo), il nome utente utilizzato deve essere composto da 20 caratteri o meno.

Eseguire l'agente

Eseguire in modo interattivo

Se l'agente è stato configurato per l'esecuzione interattiva, eseguire il comando seguente per avviare l'agente.

.\run.cmd

Per riavviare l'agente, premere CTRL+C per arrestare l'agente e quindi eseguire run.cmd per riavviarlo.

Nota

Se si esegue l'agente da PowerShell Core per eseguire attività di Windows PowerShell, la pipeline potrebbe non riuscire con, ad esempio, un errore Error in TypeData "System.Security.AccessControl.ObjectSecurity": The member is already present. Questo avviene perché Windows PowerShell eredita la PSModulePath variabile di ambiente, che include i percorsi dei moduli di PowerShell Core, dal processo padre.

Come soluzione alternativa, è possibile impostare la manopola AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL dell'agente su true nella pipeline. Ciò consentirà all'agente di reimpostare PSModulePath prima di eseguire le attività.

variables:
 AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL: "true"

Se questa soluzione alternativa non risolve il problema o se è necessario usare percorsi di modulo personalizzati, è possibile impostare la $Env:PSModulePath variabile in base alle esigenze nella finestra di PowerShell Core prima di eseguire l'agente.

Esegui una volta

È anche possibile scegliere di fare in modo che l'agente accetti un solo incarico e quindi esca. Per eseguire in questa configurazione, usare il comando seguente.

.\run.cmd --once

Gli agenti in questa modalità accetteranno un solo processo e quindi si chiuderanno gradualmente (utile per l'esecuzione in Docker su un servizio come Istanze di Azure Container).

Esegui come servizio

Se l'agente è stato configurato per l'esecuzione come servizio, viene avviato automaticamente. È possibile visualizzare e controllare lo stato di esecuzione dell'agente dal plugin dei servizi. Eseguire services.msc e cercare uno dei seguenti elementi:

  • "Agente di Azure Pipelines (nome dell'agente)"
  • "VSTS Agent (nome dell'agente)"
  • "vstsagent. (nome organizzazione). (nome dell'agente)"

Nota

Per consentire maggiore flessibilità con il controllo di accesso di un agente in esecuzione come servizio, è possibile configurare il tipo SID del servizio agente come [SERVICE_SID_TYPE_UNRESTRICTED] tramite flag o prompt durante il flusso di configurazione interattivo. Per impostazione predefinita, il servizio agente è configurato con SERVICE_SID_TYPE_NONE.

Per altre informazioni sui tipi SID , vedere questa documentazione.

Per riavviare l'agente, fare clic con il pulsante destro del mouse sulla voce e scegliere Riavvia.

Nota

Se è necessario modificare l'account di accesso dell'agente, non eseguire questa operazione dallo snap-in Servizi. Vedere invece le informazioni seguenti per riconfigurare l'agente.

Per usare l'agente, eseguire un processo usando il pool dell'agente. Se non è stato scelto un pool diverso, l'agente si troverà nel pool predefinito .

Sostituire un agente

Per sostituire un agente, seguire i passaggi Scaricare e configurare nuovamente l'agente.

Quando si configura un agente con lo stesso nome di un agente già esistente, viene chiesto se si vuole sostituire l'agente esistente. Se rispondi Y, assicurati di rimuovere l'agente (vedi sotto) che stai sostituendo. In caso contrario, dopo alcuni minuti di conflitti, uno degli agenti verrà disattivato.

Rimuovere e riconfigurare un agente

Per rimuovere l'agente:

.\config remove

Dopo aver rimosso l'agente, è possibile configurarlo di nuovo.

Configurazione senza intervento

L'agente può essere configurato da uno script senza alcun intervento umano. È necessario fornire --unattended insieme alle risposte a tutte le domande.

Per configurare un agente, deve conoscere l'URL dell'organizzazione o la raccolta e le credenziali di un utente autorizzato a configurare gli agenti. Tutte le altre risposte sono facoltative. È possibile specificare qualsiasi parametro della riga di comando usando invece una variabile di ambiente: inserire il nome in lettere maiuscole e anteporre VSTS_AGENT_INPUT_. Ad esempio, VSTS_AGENT_INPUT_PASSWORD anziché specificare --password.

Opzioni obbligatorie

  • --unattended - l'installazione dell'agente non richiederà informazioni e tutte le impostazioni devono essere specificate nella riga di comando
  • --url <url> : URL del server. Ad esempio: https://dev.azure.com/myorganization o http://my-azure-devops-server:8080/tfs
  • --auth <type> : tipo di autenticazione. I valori validi sono:
    • pat (Token di accesso personale)
    • SP (Service Principal) (Richiede la versione dell'agente 3.227.1 o successiva)
    • negotiate (Kerberos o NTLM)
    • alt (autenticazione di base)
    • integrated (Credenziali predefinite di Windows)

Opzioni di autenticazione

  • Se si sceglie --auth pat:
    • --token <token> : specifica il token di accesso personale
    • È anche possibile passare un token OAuth 2.0 come --token parametro.
  • Se si sceglie --auth negotiate o --auth alt:
    • --userName <userName> - specifica un nome utente di Windows nel formato domain\userName o [email protected]
    • --password <password> : specifica una password
  • Se si sceglie --auth SP:
    • --clientID <clientID> - specifica l'ID client del Principale del Servizio con accesso per registrare gli agenti
    • --tenantId <tenantID> - specifica l'ID tenant in cui è registrato il principale del servizio
    • --clientSecret <clientSecret> - specifica il segreto del client del principale del servizio
    • Per altre informazioni, vedere Registrare un agente usando un principale del servizio

Nomi di gruppi e agenti

  • --pool <pool> - nome del pool a cui l'agente deve unirsi
  • --agent <agent> - nome agente
  • --replace - sostituire un agente in un pool. Se un altro agente è in ascolto con lo stesso nome, inizierà a fallire a causa di un conflitto

Configurazione dell'agente

  • --work <workDirectory> : directory di lavoro in cui vengono archiviati i dati del lavoro. L'impostazione predefinita è impostata su _work nella radice della directory dell'agente. La directory di lavoro è di proprietà di un singolo agente e non deve essere condivisa tra più agenti.
  • --acceptTeeEula : accettare il Contratto di licenza per l'utente finale di Team Explorer Everywhere (solo macOS e Linux)
  • --disableloguploads - non trasmettere o inviare l'output del log della console al server. Al termine del lavoro, è invece possibile recuperarli dal file system dell'host dell'agente.

Startup solo per Windows

  • --runAsService : configurare l'agente per l'esecuzione come servizio Windows (richiede l'autorizzazione di amministratore)
  • --runAsAutoLogon - Configurare l'accesso automatico ed eseguire l'agente all'avvio (richiede l'autorizzazione di amministratore)
  • --windowsLogonAccount <account> - utilizzato con --runAsService o --runAsAutoLogon per specificare il nome utente di Windows nel formato domain\userName o [email protected]
  • --windowsLogonPassword <password> - usato con --runAsService o --runAsAutoLogon per specificare la password di accesso di Windows (non necessaria per gli account del servizio gestito del gruppo e gli account predefiniti di Windows, ad esempio 'NT AUTHORITY\NETWORK SERVICE')
  • --enableservicesidtypeunrestricted - usato con --runAsService per configurare l'agente con il tipo SID del servizio come SERVICE_SID_TYPE_UNRESTRICTED (richiede l'autorizzazione di amministratore)
  • --overwriteAutoLogon - usato con --runAsAutoLogon per sovrascrivere l'accesso automatico esistente nel computer
  • --noRestart - usato con --runAsAutoLogon per arrestare il riavvio dell'host al termine della configurazione dell'agente

Risoluzione dei problemi di configurazione dell'agente con l'opzione runAsAutoLogon

La configurazione dell'agente con l'opzione runAsAutoLogon avvia l'agente ogni volta che si riavvia il computer. Eseguire i seguenti passaggi se l'agente non si avvia dopo il riavvio del computer.

Se l'agente è già stato configurato nel computer

Prima di riconfigurare l'agente, è necessario rimuovere la configurazione dell'agente precedente, quindi provare a eseguire questo comando dalla cartella dell'agente:

.\config.cmd remove --auth 'PAT' --token '<token>'

Controllare se l'agente è stato rimosso dal pool di agenti dopo l'esecuzione del comando:

<Azure DevOps organization> / <Project> / Settings / Agent pools / <Agent Pool> / Agents

Rimuovere manualmente l'agente dal pool di agenti se non è stato rimosso eseguendo il comando .

Provare quindi a riconfigurare l'agente eseguendo questo comando dalla cartella dell'agente:

.\config.cmd --unattended --agent '<agent-name>' --pool '<agent-pool-name>' --url '<azure-dev-ops-organization-url>' --auth 'PAT' --token '<token>' --runAsAutoLogon --windowsLogonAccount '<domain\user-name>' --windowsLogonPassword '<windows-password>'

Specificare il nome dell'agente (qualsiasi nome univoco specifico) e verificare se questo agente è presente nel pool di agenti dopo la riconfigurazione.

Sarà molto meglio decomprimere un archivio agente (che può essere scaricato qui) ed eseguire questo comando dalla nuova cartella dell'agente decompresso.

Controllare se la chiave del Registro di sistema di Windows è registrata e salvata correttamente

Eseguire il comando whoami /user per ottenere <sid>. Aprire Registry Editor e seguire il percorso:

Computer\HKEY_USERS\<sid>\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Controllare se è presente la VSTSAgent chiave. Eliminare questa chiave, se esiste, quindi chiudere Registry Editor e configurare l'agente eseguendo il comando .\config.cmd dalla cartella dell'agente (senza arg). Prima di rispondere alla domanda Enter Restart the machine at a later time?, aprire Registry Editor di nuovo e verificare se la VSTSAgent chiave è apparsa. Premere Enter per rispondere alla domanda e verificare se il VSTSAgent tasto rimane sul posto dopo il riavvio del computer.

Controllare se le chiavi del Registro di sistema di Windows funzionano correttamente nel computer

Creare un autorun.cmd file contenente la riga seguente: echo "Hello from AutoRun!". Aprire Registry Editor e creare nel percorso precedente una nuova coppia chiave-valore con la chiave AutoRun e il valore

C:\windows\system32\cmd.exe /D /S /C start "AutoRun" "D:\path\to\autorun.cmd"

Riavviare il computer. Si verifica un problema con le chiavi del Registro di sistema di Windows se non viene visualizzata una finestra della console con il Hello from AutoRun! messaggio .

Solo gruppo di distribuzione

  • --deploymentGroup: configurare l'agente come agente del gruppo di distribuzione
  • --deploymentGroupName <name> - usato con --deploymentGroup per specificare il gruppo di distribuzione per l'agente da aggiungere
  • --projectName <name> : usato con --deploymentGroup per impostare il nome del progetto
  • --addDeploymentGroupTags - usato con --deploymentGroup per indicare che devono essere aggiunti i tag del gruppo di distribuzione
  • --deploymentGroupTags <tags> : usato con --addDeploymentGroupTags per specificare l'elenco delimitato da virgole di tag per l'agente del gruppo di distribuzione, ad esempio "Web, db"

Solo ambienti

  • --addvirtualmachineresourcetags - usato per indicare che i tag delle risorse dell'ambiente devono essere aggiunti
  • --virtualmachineresourcetags <tags> - usato con --addvirtualmachineresourcetags per specificare l'elenco di tag separati da virgole per l'agente risorse dell'ambiente, ad esempio "web, db"

.\config --help elenca sempre le risposte obbligatorie e facoltative più recenti.

Diagnostica

Se si verificano problemi con l'agente self-hosted, è possibile provare a eseguire la diagnostica. Dopo aver configurato l'agente:

.\run --diagnostics

Questa operazione verrà eseguita tramite una suite di diagnostica che può aiutare a risolvere il problema. La funzionalità di diagnostica è disponibile a partire dalla versione dell'agente 2.165.0.

Diagnostica di rete per gli agenti auto-ospitati

Configurare il valore di Agent.Diagnostic su true per raccogliere log aggiuntivi utilizzabili nella risoluzione di problemi di rete per gli agenti self-hosted. Per ulteriori informazioni, vedere Diagnostica di rete per gli agenti auto-ospitati

Guida su altre opzioni

Per altre informazioni sulle altre opzioni:

.\config --help

L'aiuto fornisce informazioni sulle alternative di autenticazione e sulla configurazione senza supervisione.

Capacità

Le funzionalità dell'agente vengono catalogate e pubblicizzate nel pool, in modo che gli vengano assegnate solo le compilazioni e versioni che è in grado di gestire. Vedere Funzionalità dell'agente di compilazione e rilascio.

In molti casi, dopo aver distribuito un agente, sarà necessario installare software o utilità. In genere è consigliabile installare sugli agenti qualsiasi software e strumenti usati nel computer di sviluppo.

Ad esempio, se la compilazione include l'attività npm, la compilazione non verrà eseguita a meno che non sia installato un agente di compilazione nel pool in cui è installato npm.

Importante

Le funzionalità includono tutte le variabili di ambiente e i valori impostati durante l'esecuzione dell'agente. Se uno di questi valori cambia durante l'esecuzione dell'agente, è necessario riavviare l'agente per acquisire i nuovi valori. Dopo aver installato il nuovo software in un agente, è necessario riavviare l'agente per visualizzare la nuova funzionalità nel pool, in modo che la compilazione possa essere eseguita.

Se si desidera escludere le variabili di ambiente come funzionalità, è possibile designarle impostando una variabile di ambiente VSO_AGENT_IGNORE con un elenco delimitato da virgole di variabili da ignorare.

Domande frequenti

Quale versione di Git viene eseguita dall'agente?

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.

  • Imposta una variabile di pipeline chiamata System.PreferGitFromPath su true nella pipeline.
  • Negli agenti self-hosted è possibile creare un file denominato .env nella directory radice dell'agente e aggiungere una riga System.PreferGitFromPath=true al file. Per ulteriori informazioni, consultare Come faccio a impostare variabili di ambiente diverse per ciascun agente?

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

Come faccio a essere sicuro di avere la versione più recente dell'agente?

  1. Passare alla scheda dei pool di agenti:

    1. Accedi alla tua organizzazione (https://dev.azure.com/{yourorganization}).

    2. Scegliere Azure DevOps, Impostazioni organizzazione.

      Scegliere le impostazioni dell'organizzazione.

    3. Scegliere pool di agenti .

      Scegliere la scheda Pool di agenti.

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

    2. Scegliere Azure DevOps, Impostazioni della raccolta.

      Scegliere Impostazioni Raccolta.

    3. Scegliere pool di agenti .

      Scegliere 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.

      Dai pool di agenti selezionare il pool di agenti desiderato.

    2. Selezionare Agenti e scegliere l'agente desiderato.

      Selezionare gli 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 gli agenti e scegliere l'agente desiderato.

    3. Scegliere la scheda Funzionalità .

      scheda funzionalità dell'agente.

  5. Cerca la funzionalità Agent.Version. È possibile controllare questo valore rispetto alla versione dell'agente più recente pubblicata. Consulta Azure Pipelines Agent e controlla la pagina per il numero di versione più alto elencato.

  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 selezionare 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 sostituirà la versione predefinita fornita con il server al momento del suo rilascio. Questo scenario si applica anche quando il server non ha accesso a Internet.

  1. Da un computer con accesso a Internet, è possibile scaricare la versione più recente dei file del pacchetto dell'agente (in formato .zip o .tar.gz) dalla pagina GitHub Releases di Azure Pipelines Agent.

  2. Trasferire i file del pacchetto scaricati in ogni livello applicazione del server Azure DevOps usando un metodo di propria scelta, ad esempio unità USB, trasferimento di rete e così via. Inserire i file dell'agente nella cartella seguente:

  • Windows: %ProgramData%\Microsoft\Azure DevOps\Agents
  • Linux: usr/share/Microsoft/Azure DevOps/Agents
  • macOS: usr/share/Microsoft/Azure DevOps/Agents

Creare la cartella Agenti se non è presente.

  1. Tutto pronto! Il server Azure DevOps userà ora 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.

Sto eseguendo un firewall e il mio codice si trova in Azure Repos. Con quali URL deve comunicare l'agente?

Se stai eseguendo un agente in una rete sicura dietro un firewall, controlla che l'agente possa avviare la comunicazione con gli URL e gli indirizzi IP seguenti.

URL del dominio Descrizione
https://{organization_name}.pkgs.visualstudio.com API di creazione pacchetti di Azure DevOps per le organizzazioni che usano il dominio di {organization_name}.visualstudio.com
https://{organization_name}.visualstudio.com Per le organizzazioni che usano il dominio {organization_name}.visualstudio.com
https://{organization_name}.vsblob.visualstudio.com Telemetria di Azure DevOps per le organizzazioni che usano il dominio {organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com Release Management Services per le organizzazioni che usano il dominio {organization_name}.visualstudio.com
https://{organization_name}.vssps.visualstudio.com Azure DevOps Platform Services per le organizzazioni che usano il dominio {organization_name}.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com Azure DevOps Test Management Services per le organizzazioni che usano il dominio {organization_name}.visualstudio.com
https://*.blob.core.windows.net Azure Artifacts
https://*.dev.azure.com Per le organizzazioni che usano il dominio dev.azure.com
https://*.vsassets.io Azure Artifacts tramite rete CDN
https://*.vsblob.visualstudio.com Telemetria di Azure DevOps per le organizzazioni che usano il dominio dev.azure.com
https://*.vssps.visualstudio.com Azure DevOps Platform Services per le organizzazioni che usano il dominio dev.azure.com
https://*.vstmr.visualstudio.com Azure DevOps Test Management Services per le organizzazioni che usano il dominio dev.azure.com
https://app.vssps.visualstudio.com Per le organizzazioni che usano il dominio {organization_name}.visualstudio.com
https://dev.azure.com Per le organizzazioni che usano il dominio dev.azure.com
https://login.microsoftonline.com Accesso a Microsoft Entra
https://management.core.windows.net API di gestione di Azure
https://vstsagentpackage.azureedge.net
https://download.agent.dev.azure.com
Pacchetto dell'agente

Importante

La rete CDN Edgio per Azure DevOps viene ritirata, il che richiede di inserire un nuovo URL di dominio nella lista consentita delle regole del firewall per il download del software agente. Il nuovo dominio da inserire nella lista dei consentiti per il download dell'agente è https://*.dev.azure.com. Se le regole del firewall non consentono caratteri jolly, usare https://download.agent.dev.azure.com.

Il team di Azure DevOps consiglia di apportare questa modifica entro la data seguente:

  • 1° maggio 2025 per Azure DevOps Services
  • 15 maggio 2025 per Azure DevOps Server

Per altre informazioni, vedere Modifica dell'URL di dominio della rete CDN per gli agenti nelle pipeline.

Per assicurarsi che l'organizzazione sia compatibile con qualsiasi firewall o restrizione IP esistente, assicurarsi che dev.azure.com e *dev.azure.com siano aperti e aggiornare gli indirizzi IP nella lista dei consentiti affinché includano gli indirizzi IP seguenti, in base alla versione IP. Se attualmente si consente di elencare gli indirizzi IP 13.107.6.183 e 13.107.9.183, lasciarli invariati, in quanto non è necessario rimuoverli.


13.107.6.0/24
13.107.9.0/24
13.107.42.0/24
13.107.43.0/24
150.171.22.0/24 
150.171.23.0/24 
150.171.73.0/24 
150.171.74.0/24 
150.171.75.0/24 
150.171.76.0/24

Nota

Per altre informazioni sugli indirizzi consentiti, vedere Elenchi di indirizzi consentiti e connessioni di rete.

Come avvio l'agente con un certificato autofirmato?

Nota

L'esecuzione dell'agente con un certificato autofirmato si applica solo ad Azure DevOps Server.

Eseguire l'agente con un certificato autofirmato

Come posso eseguire l'agente dietro un proxy web?

Eseguire l'agente dietro un proxy web

Come faccio a riavviare l'agente?

Se si esegue l'agente in modo interattivo, vedere le istruzioni di riavvio in Esegui in modo interattivo. Se esegui l'agente come servizio, riavvia l'agente seguendo la procedura descritta in Esegui come servizio.

Come si impostano variabili di ambiente diverse per ogni singolo agente?

Creare un .env file nella directory radice dell'agente e inserire le variabili di ambiente da impostare nel file nel formato seguente, quindi riavviare l'agente.

MyEnv0=MyEnvValue0
MyEnv1=MyEnvValue1
MyEnv2=MyEnvValue2
MyEnv3=MyEnvValue3
MyEnv4=MyEnvValue4

Come posso configurare l'agente per bypassare un proxy web e connettersi ad Azure Pipelines?

Se si vuole che l'agente ignori il proxy e si connetta direttamente ad Azure Pipelines, è necessario configurare il proxy Web per consentire all'agente di accedere agli URL seguenti.

Per le organizzazioni che usano il dominio *.visualstudio.com:

https://login.microsoftonline.com
https://app.vssps.visualstudio.com 
https://{organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com
https://{organization_name}.pkgs.visualstudio.com
https://{organization_name}.vssps.visualstudio.com

Per le organizzazioni che usano il dominio dev.azure.com:

https://dev.azure.com
https://*.dev.azure.com
https://login.microsoftonline.com
https://management.core.windows.net
https://vstsagentpackage.azureedge.net
https://download.agent.dev.azure.com
https://vssps.dev.azure.com

Per assicurarsi che l'organizzazione sia compatibile con qualsiasi firewall o restrizione IP esistente, assicurarsi che dev.azure.com e *dev.azure.com siano aperti e aggiornare gli indirizzi IP nella lista dei consentiti affinché includano gli indirizzi IP seguenti, in base alla versione IP. Se attualmente si consente di elencare gli indirizzi IP 13.107.6.183 e 13.107.9.183, lasciarli invariati, in quanto non è necessario rimuoverli.


13.107.6.0/24
13.107.9.0/24
13.107.42.0/24
13.107.43.0/24
150.171.22.0/24 
150.171.23.0/24 
150.171.73.0/24 
150.171.74.0/24 
150.171.75.0/24 
150.171.76.0/24

Nota

Questa procedura consente all'agente di ignorare un proxy Web. La pipeline di compilazione e gli script devono continuare a gestire il bypass del proxy web per ogni attività e strumento che esegui nella tua build.

Ad esempio, se si usa un'attività NuGet, è necessario configurare il proxy Web per supportare il bypass dell'URL per il server che ospita il feed NuGet in uso.

Sto utilizzando TFS e gli URL nelle sezioni precedenti non funzionano per me. Dove posso ottenere assistenza?

Impostazioni e sicurezza del sito Web

Io uso TFS in locale e non riesco a vedere alcune di queste funzionalità. Perché no?

Alcune di queste funzionalità sono disponibili solo in Azure Pipelines e non sono ancora disponibili in locale. Alcune funzionalità sono disponibili in locale se è stato eseguito l'aggiornamento alla versione più recente di TFS.

Che cos'è l'attivazione di SERVICE_SID_TYPE_UNRESTRICTED per il servizio agente?

Quando si configura il software agente in Windows Server, è possibile specificare l'identificatore di sicurezza del servizio dal prompt seguente.

Enter enable SERVICE_SID_TYPE_UNRESTRICTED for agent service (Y/N) (press enter for N)

Le versioni precedenti del software agente impostano il tipo di identificatore di sicurezza del servizio su SERVICE_SID_TYPE_NONE, ovvero il valore predefinito per le versioni correnti dell'agente. Per configurare il tipo di identificatore del servizio di sicurezza su SERVICE_SID_TYPE_UNRESTRICTED, premere Y.

Per altre informazioni, vedere SERVICE_SID_INFO struttura e Identificatori di sicurezza.