Agents Windows autohébergés

Azure DevOps Services

Pour générer et déployer Windows, Azure et d’autres solutions Visual Studio, vous avez besoin d’au moins un agent Windows. Les agents Windows peuvent également créer des applications Java et Android.

Cet article fournit des conseils sur l’utilisation du logiciel d’agent 3.x avec Azure DevOps Services et les versions actuelles d’Azure DevOps Server. Pour obtenir la liste des versions d’Azure DevOps Server qui prennent en charge l’agent 3.x, consultez Azure DevOps Server prend-il en charge l’agent 3.x.

Remarque

Cet article explique comment configurer un agent auto-hébergé. Si vous utilisez Azure DevOps Services et qu’un agent hébergé par Microsoft répond à vos besoins, vous pouvez ignorer la configuration d’un agent Windows auto-hébergé.

En savoir plus sur les agents

Si vous connaissez déjà ce qu’est un agent et comment il fonctionne, n’hésitez pas à passer directement aux sections suivantes. Toutefois, si vous souhaitez en savoir plus sur ce qu’ils font et leur fonctionnement, consultez les agents Azure Pipelines.

Vérifier les conditions préalables

Vérifiez que votre machine présente les conditions préalables suivantes :

• Version du système d'exploitation
  • Système d’exploitation client
    • Windows 7 SP1 ESU
    • Windows 8.1
    • Windows 10
    • Windows 11
  • Système d’exploitation du serveur
    • Windows Server 2012 ou version ultérieure
• Le logiciel de l’agent installe sa propre version de .NET afin qu’il n’existe aucun prérequis .NET.
• PowerShell 3.0 ou version ultérieure
• Subversion - Si vous créez à partir d’un dépôt Subversion, vous devez installer le client Subversion sur l’ordinateur.
• Recommandé - Outils de génération Visual Studio (2015 ou version ultérieure)

Vous devez exécuter manuellement le programme d’installation de l’agent la première fois. Une fois que vous avez une idée du fonctionnement des agents ou si vous souhaitez automatiser la configuration de nombreux agents, envisagez d’utiliser la configuration sans assistance.

Spécifications matérielles

Les spécifications matérielles de vos agents varient en fonction de vos besoins, de la taille de l’équipe, etc. Il n’est pas possible de faire une recommandation générale qui s’applique à tout le monde. À titre de référence, l’équipe Azure DevOps génère le code des agents hébergés à l’aide de pipelines qui utilisent des agents hébergés. En revanche, la majeure partie du code Azure DevOps est générée par des machines de classe de serveur 24 cœurs exécutant quatre agents auto-hébergés.

Préparer les autorisations

Sécurité des informations pour les agents auto-hébergés

L’utilisateur configurant l’agent a besoin d’autorisations d’administrateur de pool, mais l’utilisateur exécutant l’agent ne le fait pas.

Les dossiers contrôlés par l’agent doivent être limités à autant d’utilisateurs que possible, car ils contiennent des secrets qui peuvent être déchiffrés ou exfiltrés.

L’agent Azure Pipelines est un produit logiciel conçu pour exécuter le code qu’il télécharge à partir de sources externes. Il peut s’agir par nature d’une cible pour les attaques RCE (Remote Code Execution).

Par conséquent, il est important de prendre en compte le modèle de menace entourant chaque utilisation individuelle des agents de pipelines pour effectuer le travail, et de décider quelles sont les autorisations minimales qui peuvent être accordées à l’utilisateur exécutant l’agent, à l’ordinateur sur lequel l’agent s’exécute, aux utilisateurs qui ont accès en écriture à la définition de pipeline, les dépôts git où le yaml est stocké, ou le groupe d’utilisateurs qui contrôlent l’accès au pool pour les nouveaux pipelines.

L’identité qui exécute l’agent doit, dans la mesure du possible, être différente de l’identité possédant des autorisations pour connecter l’agent au pool. L’utilisateur qui génère les informations d’identification (et d’autres fichiers liés à l’agent) est différent de celui qui doit les lire. Par conséquent, il est plus sûr d’envisager soigneusement l’accès accordé à l’ordinateur de l’agent lui-même, ainsi que les dossiers de l’agent qui contiennent des fichiers sensibles, tels que les journaux et les artefacts.

Il est judicieux d’accorder l’accès au dossier de l’agent uniquement pour les administrateurs DevOps et l’identité utilisateur exécutant le processus de l’agent. Les administrateurs peuvent avoir besoin d’examiner le système de fichiers pour comprendre les échecs de build ou obtenir des fichiers journaux pour pouvoir signaler des échecs Azure DevOps.

Déterminer l’utilisateur que vous allez utiliser

À titre d’étape unique, vous devez inscrire l’agent. Une personne disposant de l’autorisation d’administrer la file d’attente de l’agent doit effectuer ces étapes. L'agent n'utilisera pas les informations d'identification de cette personne dans les opérations de tous les jours, mais ils sont nécessaires pour terminer l'enregistrement. En savoir plus sur la façon dont les agents communiquent.

Confirmer que l’utilisateur dispose d’une autorisation

Vérifiez que le compte d’utilisateur que vous allez utiliser est autorisé à inscrire l’agent.

L’utilisateur est-il propriétaire de l’organisation Azure DevOps ou TFS ou administrateur du serveur Azure DevOps ? Arrêtez-vous ici, vous avez l’autorisation.

Autrement :

1. Ouvrez un navigateur et accédez à l’onglet Pools d’agents pour votre organisation Azure Pipelines ou votre serveur Azure DevOps Server ou TFS :

   1. Connectez-vous à votre organisation (https://dev.azure.com/{yourorganization}).

   2. Choisissez Azure DevOps, Paramètres de l’organisation.

      

   3. Choisissez Pools d’agents.

      

2. Sélectionnez le pool sur le côté droit de la page, puis cliquez sur Sécurité.

3. Si le compte d’utilisateur que vous allez utiliser n’est pas affiché, obtenez un administrateur pour l’ajouter. L’administrateur peut être un administrateur de pool d’agents, un propriétaire d’organisation Azure DevOps ou un administrateur TFS ou Azure DevOps Server.

   S’il s’agit d’un agent de groupe de déploiement , l’administrateur peut être un administrateur de groupe de déploiement, un propriétaire d’organisation Azure DevOpsou un administrateur TFS ou Azure DevOps Server.

   Vous pouvez ajouter un utilisateur au rôle d’administrateur de groupe de déploiement dans l’onglet Sécurité de la page Groupes de déploiement dans Azure Pipelines.

Remarque

Si vous voyez un message comme suit : Désolé, nous n’avons pas pu ajouter l’identité. Essayez une autre identité. Vous avez probablement suivi les étapes ci-dessus pour un propriétaire de l’organisation ou un administrateur de serveur TFS ou Azure DevOps. Vous n’avez rien à faire ; vous disposez déjà de l’autorisation d’administrer le pool d’agents.

Télécharger et configurer l’agent

Azure Pipelines

1. Connectez-vous à l’ordinateur à l’aide du compte pour lequel vous avez préparé des autorisations, comme expliqué ci-dessus.

2. Dans votre navigateur web, connectez-vous à Azure Pipelines et accédez à l’onglet Pools d’agents :

   1. Connectez-vous à votre organisation (https://dev.azure.com/{yourorganization}).

   2. Choisissez Azure DevOps, Paramètres de l’organisation.

      

   3. Choisissez Pools d’agents.

      

3. Sélectionnez le pool par défaut , sélectionnez l’onglet Agents , puis choisissez Nouvel agent.

4. Dans la boîte de dialogue Obtenir l’agent , choisissez Windows.

5. Dans le volet gauche, sélectionnez l’architecture du processeur de la version du système d’exploitation Windows installée sur votre ordinateur. La version de l’agent x64 est destinée à Windows 64 bits, tandis que la version x86 est destinée à Windows 32 bits. Si vous ne savez pas quelle version de Windows est installée, suivez ces instructions pour en savoir plus.

6. Dans le volet droit, cliquez sur le bouton Télécharger .

7. Suivez les instructions de la page pour télécharger l’agent.

8. Décompressez l’agent dans le répertoire de votre choix. Assurez-vous que le chemin d’accès au répertoire ne contient aucun espace, car les outils et les scripts n’échappent pas toujours correctement aux espaces. Un dossier recommandé est C:\agents. L’extraction dans le dossier de téléchargement ou d’autres dossiers utilisateur peut entraîner des problèmes d’autorisation.

Importante

Nous vous recommandons vivement de configurer l’agent à partir d’une fenêtre PowerShell avec élévation de privilèges. Si vous souhaitez configurer en tant que service, cela est nécessaire.

Vous ne devez pas utiliser Windows PowerShell ISE pour configurer l’agent.

Importante

Pour des raisons de sécurité, nous vous recommandons vivement de vérifier que le dossier des agents (C:\agents) n’est modifiable que par les administrateurs.

Remarque

Évitez d’utiliser des interpréteurs de commandes mintty, tels que git-bash, pour la configuration de l’agent. Mintty n’est pas entièrement compatible avec l’API Windows d’entrée/sortie native (voici quelques informations sur celle-ci) et nous ne pouvons pas garantir que le script d’installation fonctionne correctement dans ce cas.

Installer l’agent

1. Ouvrez une fenêtre PowerShell avec des privilèges élevés et définissez l’emplacement où vous avez décompressé l'agent.

   cd C:\agents 
   
   

2. Exécutez config.cmd. Cela vous posera une série de questions pour configurer l’agent.

   .\config.cmd
   
   

URL du serveur

Lorsque le programme d’installation demande l’URL de votre serveur, pour Azure DevOps Services, répondez https://dev.azure.com/{your-organization}.

Type d'authentification de configuration de l'agent

Lorsque vous inscrivez un agent, choisissez parmi les types d’authentification suivants, et le programme d’installation vous invite à entrer les informations supplémentaires spécifiques requises pour chaque type d’authentification. Pour plus d'informations, consultez Options d'authentification de l'agent auto-hébergé.

• Jeton d’accès personnel
• Flux de code de périphérique
• Principal du service

La méthode d'authentification utilisée pour enregistrer l'agent est utilisée uniquement lors de l'enregistrement de l'agent. Pour en savoir plus sur la façon dont les agents communiquent avec Azure Pipelines après l’inscription, consultez Communication avec Azure Pipelines ou TFS.

Choisir le mode interactif ou de service

Pour obtenir des conseils sur l’exécution de l’agent en mode interactif ou en tant que service, consultez Agents : Interactif et service.

Si vous choisissez de l’exécuter en tant que service (recommandé), le nom d’utilisateur doit comporter 20 caractères maximum.

Exécuter l’agent

Exécuter de manière interactive

Si vous avez configuré l’agent de manière interactive, exécutez la commande suivante pour démarrer l’agent.

.\run.cmd

Pour redémarrer l’agent, appuyez sur Ctrl+C pour arrêter l’agent, puis exécutez-le run.cmd pour le redémarrer.

Remarque

Si vous exécutez l’agent à partir de PowerShell Core pour exécuter des tâches Windows PowerShell, votre pipeline peut échouer avec une erreur telle que Error in TypeData "System.Security.AccessControl.ObjectSecurity": The member is already present. Cela est dû au fait que Windows PowerShell hérite de la PSModulePath variable d’environnement, qui inclut des emplacements de module PowerShell Core, à partir de son processus parent.

Pour contourner cela, vous pouvez définir le paramètre AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL de l’agent à true dans le pipeline. Cela permet à l’agent de réinitialiser PSModulePath avant d’exécuter des tâches.

variables:
 AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL: "true"

Si cette solution de contournement ne résout pas votre problème ou si vous devez utiliser des emplacements de module personnalisés, vous pouvez définir la $Env:PSModulePath variable en fonction des besoins dans votre fenêtre PowerShell Core avant d’exécuter l’agent.

Exécuter une seule fois

Vous pouvez également choisir d’accepter un seul travail et de quitter l’agent. Pour exécuter cette configuration, utilisez la commande suivante.

.\run.cmd --once

Les agents dans ce mode n’acceptent qu’un seul travail, puis s’exécutent correctement (utile pour l’exécution dans Docker sur un service tel qu’Azure Container Instances).

Exécuter en tant que service

Si vous avez configuré l’agent pour qu’il s’exécute en tant que service, il démarre automatiquement. Vous pouvez voir et contrôler l’état d’exécution de l’agent dans le composant logiciel enfichable de services. Exécutez services.msc et recherchez l’un des suivants :

• « Agent Azure Pipelines (nom de votre agent) »
• « Agent VSTS (nom de votre agent) »
• "vstsagent. (nom de l’organisation). (nom de votre agent)"

Remarque

Pour permettre une plus grande flexibilité avec le contrôle d’accès d’un agent s’exécutant en tant que service, il est possible de configurer le type SID du service agent en tant que [SERVICE_SID_TYPE_UNRESTRICTED] via un indicateur ou une invite pendant le flux de configuration interactif. Par défaut, le service d’agent est configuré avec SERVICE_SID_TYPE_NONE.

Pour plus d’informations sur les types SID , consultez cette documentation.

Pour redémarrer l’agent, cliquez avec le bouton droit sur l’entrée, puis choisissez Redémarrer.

Remarque

Si vous devez modifier le compte d’ouverture de session de l’agent, ne le faites pas avec le composant logiciel enfichable de services. Au lieu de cela, consultez les informations ci-dessous pour reconfigurer l’agent.

Pour utiliser votre agent, exécutez une tâche grâce au pool de l’agent. Si vous n’avez pas choisi un autre pool, votre agent se trouve dans le pool par défaut .

Remplacer un agent

Pour remplacer un agent, suivez à nouveau les étapes de téléchargement et de configuration de l’agent .

Lorsque vous configurez un agent avec le même nom qu’un agent qui existe déjà, vous êtes invité à remplacer l’agent existant. Si vous répondez Y, veillez à supprimer l’agent (voir ci-dessous) que vous remplacez. Sinon, après quelques minutes de conflits, l’un des agents s’arrêtera.

Supprimer et reconfigurer un agent

Pour supprimer l’agent :

.\config remove

Une fois que vous avez supprimé l’agent, vous pouvez le configurer à nouveau.

Configuration sans assistance

L’agent peut être configuré à partir d’un script sans intervention humaine. Vous devez transférer --unattended et les réponses à toutes les questions.

Pour configurer un agent, il doit connaître l’URL de votre organisation ou de votre collection et les informations de connexion d’une personne autorisée à configurer des agents. Toutes les autres réponses sont facultatives. Tout paramètre de ligne de commande peut être spécifié à l’aide d’une variable d’environnement à la place : placez son nom en majuscules et ajoutez-le devant VSTS_AGENT_INPUT_. Par exemple, VSTS_AGENT_INPUT_PASSWORD au lieu de spécifier --password.

Options requises

• --unattended - La configuration de l’agent ne demande pas d’informations, et tous les paramètres doivent être fournis sur la ligne de commande
• --url <url> - URL du serveur. Par exemple : https://dev.azure.com/myorganization ou http://my-azure-devops-server:8080/tfs
• --auth <type> - Type d’authentification. Les valeurs valides sont les suivantes :
  • pat (Jeton d’accès personnel)
  • SP(Service Principal) (Requiert la version 3.227.1 de l'agent ou une version plus récente)
  • negotiate (Kerberos ou NTLM)
  • alt (Authentification de base)
  • integrated (Informations d’identification windows par défaut)

Options d’authentification

• Si vous avez choisi --auth pat:
  • --token <token> - spécifie votre jeton d’accès personnel
  • Vous pouvez également passer un jeton OAuth 2.0 en tant que --token paramètre.
• Si vous avez choisi --auth negotiate ou --auth alt:
  • --userName <userName> - spécifie un nom d’utilisateur Windows au format domain\userName ou userName@domain.com
  • --password <password> - spécifie un mot de passe
• Si vous avez choisi --auth SP:
  • --clientID <clientID> - spécifie l’ID client du principal de service ayant accès pour inscrire des agents
  • --tenantId <tenantID> - spécifie l’ID de locataire dans lequel le principal de service est inscrit
  • --clientSecret <clientSecret> - spécifie la clé secrète client du principal de service
  • Pour plus d’informations, consultez Inscrire un agent à l’aide d’un principal de service

Noms de pool et d’agent

• --pool <pool> : Nom du pool que l’agent doit joindre
• --agent <agent> - Nom de l’agent
• --replace - remplacer l'agent dans un pool. Si un autre agent écoute sous le même nom, il commence à échouer avec un conflit

Configuration de l’agent

• --work <workDirectory> - répertoire de travail où les données de travail sont stockées. Le répertoire par défaut est _work à la racine du répertoire de l’agent. Le répertoire de travail appartient à un agent donné et ne doit pas être partagé entre plusieurs agents.
• --acceptTeeEula - acceptez le Contrat de licence utilisateur final Team Explorer partout (macOS et Linux uniquement)
• --disableloguploads - n'envoyez pas ou ne diffusez pas la sortie des logs de la console au serveur. Au lieu de cela, vous pouvez les récupérer du système de fichiers de l’hôte de l’agent une fois le travail terminé.

Démarrage Windows uniquement

• --runAsService - configurer l’agent pour qu’il s’exécute en tant que service Windows (nécessite une autorisation d’administrateur)
• --runAsAutoLogon - configurer l’ouverture de session automatique et exécuter l’agent au démarrage (nécessite une autorisation d’administrateur)
• --windowsLogonAccount <account> - utilisé avec --runAsService ou --runAsAutoLogon pour spécifier le nom d’utilisateur Windows au format domain\userName ou userName@domain.com
• --windowsLogonPassword <password> - utilisé avec --runAsService ou --runAsAutoLogon pour spécifier le mot de passe d’ouverture de session Windows (non requis pour les comptes de service géré de groupe et les comptes Windows intégrés tels que « NT AUTHORITY\NETWORK SERVICE »)
• --enableservicesidtypeunrestricted - utilisé avec --runAsService pour configurer l’agent avec le type SID de service comme SERVICE_SID_TYPE_UNRESTRICTED (nécessite l’autorisation administrateur)
• --overwriteAutoLogon - utilisé avec --runAsAutoLogon pour remplacer l’ouverture de session automatique existante sur la machine
• --noRestart - utilisé avec --runAsAutoLogon pour empêcher l’hôte de redémarrer une fois la configuration de l’agent terminée

Résolution des problèmes de configuration de l’agent avec l’option runAsAutoLogon

La configuration de l’agent avec l’option runAsAutoLogon exécute l’agent chaque fois après le redémarrage de l’ordinateur. Effectuez les étapes suivantes si l’agent ne s’exécute pas suite au redémarrage de l’ordinateur.

Si l’agent a déjà été configuré sur l’ordinateur

Avant de reconfigurer l’agent, il est nécessaire de supprimer l’ancienne configuration de l’agent. Essayez donc d’exécuter cette commande dans le dossier de l’agent :

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

Vérifiez si l’agent a été supprimé de votre pool d’agents après l’exécution de la commande :

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

Supprimez l’agent de votre pool d’agents manuellement s’il n’a pas été supprimé en exécutant la commande.

Essayez ensuite de reconfigurer l’agent en exécutant cette commande à partir du dossier de l’agent :

.\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>'

Spécifiez le nom de l’agent (n’importe quel nom unique spécifique) et vérifiez si cet agent apparaît dans votre pool d’agents après la reconfiguration.

Il sera beaucoup mieux de décompresser une archive d’agent (qui peut être téléchargée ici) et d’exécuter cette commande à partir du nouveau dossier de l’agent décompressé.

Vérifiez si la clé de Registre Windows est enregistrée et enregistrée correctement

Exécutez la whoami /user commande pour obtenir le <sid>. Ouvrez Registry Editor et suivez le chemin d’accès :

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

Vérifiez s’il existe la VSTSAgent clé. Supprimez cette clé s’il existe, fermez Registry Editor et configurez l’agent en exécutant la .\config.cmd commande (sans arguments) dans le dossier de l’agent. Avant de répondre à la question Enter Restart the machine at a later time?, ouvrez Registry Editor à nouveau et vérifiez si la VSTSAgent clé est apparue. Appuyez Enter pour répondre à la question et vérifiez si la VSTSAgent clé reste à sa place après le redémarrage de l’ordinateur.

Vérifiez si les clés de Registre Windows fonctionnent correctement sur votre ordinateur

Créez un autorun.cmd fichier qui contient la ligne suivante : echo "Hello from AutoRun!". Ouvrez Registry Editor et créez dans le chemin d’accès ci-dessus une nouvelle paire clé-valeur avec la clé AutoRun et la valeur

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

Redémarrez votre machine. Vous rencontrez un problème avec les clés de Registre Windows si vous ne voyez pas de fenêtre de console avec le Hello from AutoRun! message.

Groupe de déploiement uniquement

• --deploymentGroup - configurer l’agent en tant qu’agent de groupe de déploiement
• --deploymentGroupName <name> - utilisé avec --deploymentGroup pour spécifier le groupe de déploiement de l’agent à joindre
• --projectName <name> - utilisé avec --deploymentGroup pour définir le nom du projet
• --addDeploymentGroupTags - utilisé avec --deploymentGroup pour indiquer que les balises de groupe de déploiement doivent être ajoutées
• --deploymentGroupTags <tags> - utilisé avec --addDeploymentGroupTags pour spécifier la liste séparée par des virgules de l’agent de groupe de déploiement - par exemple « web, db »

Environnements uniquement

• --addvirtualmachineresourcetags - utilisé pour indiquer que les balises de ressource d’environnement doivent être ajoutées
• --virtualmachineresourcetags <tags> - utilisé avec --addvirtualmachineresourcetags pour spécifier la liste séparée par des virgules des balises pour l’agent de ressource d’environnement - par exemple « web, db »

.\config --help répertorie toujours les réponses obligatoires et facultatives les plus récentes.

Diagnostiques

Si vous rencontrez des problèmes avec votre agent auto-hébergé, vous pouvez essayer d’exécuter des diagnostics. Après avoir configuré l’agent :

.\run --diagnostics

Cette opération s’exécute via une suite de diagnostics qui peut vous aider à résoudre le problème. La fonctionnalité de diagnostic est disponible à partir de la version 2.165.0 de l’agent.

Diagnostics réseau pour les agents hébergés localement

Définissez la valeur de Agent.Diagnostic à true pour collecter des journaux supplémentaires qui peuvent être utilisés pour résoudre les problèmes réseau pour les agents auto-hébergés. Pour plus d’informations, consultez Diagnostics réseau pour les agents auto-hébergés

Aide sur d’autres options

Pour en savoir plus sur d’autres options :

.\config --help

L’aide fournit des informations sur les alternatives d’authentification et la configuration sans assistance.

Capacités

Les capacités de votre agent sont cataloguées et publiées dans le pool pour que seules les builds et les mises en production qu’il peut gérer lui soient attribuées. Consultez les fonctionnalités de build et de mise en production de l’agent.

Dans de nombreux cas, après avoir déployé un agent, vous devez installer des logiciels ou des utilitaires. En règle générale, vous devez installer sur vos agents les logiciels et outils que vous utilisez sur votre ordinateur de développement.

Par exemple, si votre build inclut la tâche npm, la build ne s’exécute pas, sauf s’il existe un agent de build dans le pool sur lequel npm est installé.

Importante

Les fonctionnalités incluent toutes les variables d’environnement et les valeurs définies lors de l’exécution de l’agent. Si l’une de ces valeurs change pendant l’exécution de l’agent, celui-ci doit être redémarré pour récupérer les nouvelles valeurs. Après avoir installé un nouveau logiciel sur un agent, vous devez redémarrer l’agent pour que la nouvelle fonctionnalité s’affiche dans le pool, afin que la build puisse s’exécuter.

Si vous souhaitez exclure des variables d’environnement en tant que fonctionnalités, vous pouvez les désigner en définissant une variable VSO_AGENT_IGNORE d’environnement avec une liste délimitée par des virgules de variables à ignorer.

Questions fréquentes (FAQ)

Quelle version de Git est exécutée par mon agent ?

Par défaut, l’agent Windows utilise la version de Git fournie avec le logiciel de l’agent. Microsoft recommande d'utiliser la version de Git incluse avec l'agent, mais vous avez plusieurs options pour ignorer ce comportement par défaut et utiliser la version de Git que l'ordinateur de l'agent a installée dans le chemin.

• Définissez une variable de pipeline nommée System.PreferGitFromPath sur true dans vos pipelines.
• Sur les agents autohébergés, vous pouvez créer un fichier nommé .env dans le répertoire racine de l’agent et ajouter une ligne System.PreferGitFromPath=true au fichier. Pour plus d’informations, consultez Comment définir des variables d’environnement différentes pour chaque agent ?.

Pour voir la version de Git utilisée par un pipeline, vous pouvez examiner les journaux d’activité d’une étape checkout dans votre pipeline, comme illustré dans l’exemple suivant.

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

Comment vérifier que je dispose de la dernière version de l’agent ?

1. Accédez à l’onglet Pools d’agents :

   1. Connectez-vous à votre organisation (https://dev.azure.com/{yourorganization}).

   2. Choisissez Azure DevOps, Paramètres de l’organisation.

      

   3. Choisissez Pools d’agents.

      

2. Cliquez sur le pool qui contient l’agent.

3. Vérifiez que l’agent est activé.

4. Accédez à l’onglet Capacités :

   1. Sous l’onglet Pools d’agents, sélectionnez le pool d’agents souhaité.

      

   2. Sélectionnez Agents et choisissez l’agent souhaité.

      

   3. Choisissez l’onglet Fonctionnalités.

      

      Remarque

      Les agents hébergés par Microsoft n’affichent pas de fonctionnalités système. Pour obtenir la liste des logiciels installés sur des agents hébergés par Microsoft, consultez Utiliser un agent hébergé par Microsoft.

5. Recherchez la capacité Agent.Version. Vous pouvez vérifier cette valeur en la comparant à la dernière version publiée de l’agent. Consultez Agent Azure Pipelines et recherchez le numéro de version le plus élevé dans la page.

6. Chaque agent est mis à jour automatiquement quand il exécute une tâche nécessitant une version plus récente de l’agent. Si vous souhaitez mettre à jour manuellement certains agents, cliquez avec le bouton droit sur le pool, puis sélectionnez Mettre à jour tous les agents.

J’exécute un pare-feu et mon code se trouve dans Azure Repos. Avec quelles URL l’agent doit-il communiquer ?

Si vous exécutez un agent dans un réseau sécurisé derrière un pare-feu, assurez-vous que l’agent peut lancer la communication avec les URL et adresses IP suivantes.

URL de domaine	Description
https://{organization_name}.pkgs.visualstudio.com	API d’empaquetage Azure DevOps pour les organisations utilisant le {organization_name}.visualstudio.com domaine
https://{organization_name}.visualstudio.com	Pour les organisations utilisant le {organization_name}.visualstudio.com domaine
https://{organization_name}.vsblob.visualstudio.com	Télémétrie Azure DevOps pour les organisations utilisant le {organization_name}.visualstudio.com domaine
https://{organization_name}.vsrm.visualstudio.com	Release Management Services pour les organisations utilisant le {organization_name}.visualstudio.com domaine
https://{organization_name}.vssps.visualstudio.com	Azure DevOps Platform Services pour les organisations utilisant le {organization_name}.visualstudio.com domaine
https://{organization_name}.vstmr.visualstudio.com	Azure DevOps Test Management Services pour les organisations utilisant le {organization_name}.visualstudio.com domaine
https://*.blob.core.windows.net	Artifacts d'Azure
https://*.dev.azure.com	Pour les organisations utilisant le dev.azure.com domaine
https://*.vsassets.io	Azure Artifacts avec CDN
https://*.vsblob.visualstudio.com	Télémétrie Azure DevOps pour les organisations utilisant le dev.azure.com domaine
https://*.vssps.visualstudio.com	Azure DevOps Platform Services pour les organisations utilisant le dev.azure.com domaine
https://*.vstmr.visualstudio.com	Azure DevOps Test Management Services pour les organisations utilisant le dev.azure.com domaine
https://app.vssps.visualstudio.com	Pour les organisations utilisant le {organization_name}.visualstudio.com domaine
https://dev.azure.com	Pour les organisations utilisant le dev.azure.com domaine
https://login.microsoftonline.com	Connexion Microsoft Entra
https://management.core.windows.net	API de gestion Azure
https://vstsagentpackage.azureedge.net https://download.agent.dev.azure.com	Package d’agent

Importante

Edgio CDN pour Azure DevOps est mis hors service, ce qui nécessite qu’une nouvelle URL de domaine soit autorisée dans les règles de pare-feu pour le téléchargement logiciel de l’agent. Le nouveau domaine de la liste des autorisations pour le téléchargement de l’agent est https://*.dev.azure.com. Si vos règles de pare-feu n’autorisent pas les caractères génériques, utilisez https://download.agent.dev.azure.com.

L’équipe Azure DevOps recommande d’apporter cette modification à la date suivante :

• 1er mai 2025 pour Azure DevOps Services
• 15 mai 2025 pour Azure DevOps Server

Pour plus d’informations, consultez la modification de l’URL de domaine CDN pour les agents dans les pipelines.

Pour garantir que votre organisation fonctionne avec toutes les restrictions de pare-feu ou d’adresse IP existantes, assurez-vous que dev.azure.com et *dev.azure.com sont ouverts, et mettez à jour vos adresses IP autorisées pour inclure les adresses IP suivantes, en fonction de votre version IP. Si les adresses IP 13.107.6.183 et 13.107.9.183 sont déjà sur votre liste verte, conservez-les, car vous n’avez pas besoin de les supprimer.

Plages IP V4

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

Plages IP V6

2620:1ec:4::/48
2620:1ec:a92::/48
2620:1ec:21::/48
2620:1ec:22::/48
2620:1ec:50::/48 
2620:1ec:51::/48 
2603:1061:10::/48

Remarque

Pour plus d’informations sur les adresses autorisées, consultez listes d’adresses autorisées et connexions réseau.

Comment exécuter l’agent avec un certificat auto-signé ?

Remarque

L’exécution de l’agent avec un certificat auto-signé s’applique uniquement à Azure DevOps Server.

Exécuter l’agent avec un certificat auto-signé

Comment exécuter l’agent derrière un proxy web ?

Exécuter l’agent derrière un proxy web

Comment redémarrer l’agent ?

Si vous exécutez l’agent de manière interactive, consultez les instructions de redémarrage de l’exécution interactive. Si vous exécutez l’agent en tant que service, redémarrez l’agent en suivant les étapes décrites dans Exécuter en tant que service.

Comment définir des variables d’environnement différentes pour chaque agent individuel ?

Créez un .env fichier sous le répertoire racine de l’agent et placez les variables d’environnement que vous souhaitez définir dans le fichier au format suivant, puis redémarrez l’agent.

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

Comment configurer l’agent pour contourner un proxy web et me connecter à Azure Pipelines ?

Si vous souhaitez que l’agent contourne votre proxy et se connecte directement à Azure Pipelines, vous devez configurer votre proxy web pour permettre à l’agent d’accéder aux URL suivantes.

Pour les organisations qui utilisent le *.visualstudio.com domaine :

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

Pour les organisations qui utilisent le dev.azure.com domaine :

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

Pour vous assurer que votre organisation fonctionne avec toutes les restrictions de pare-feu ou d’adresse IP existantes, assurez-vous que dev.azure.com et *dev.azure.com sont ouverts et actualisez vos adresses IP autorisées pour inclure les adresses IP suivantes, en fonction de votre version d'adresse IP. Si vous ajoutez actuellement à la liste autorisée les adresses IP 13.107.6.183 et 13.107.9.183, laissez-les en place, car vous n'avez pas besoin de les retirer.

Plages IP V4

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

Plages IP V6

2620:1ec:4::/48
2620:1ec:a92::/48
2620:1ec:21::/48
2620:1ec:22::/48
2620:1ec:50::/48 
2620:1ec:51::/48 
2603:1061:10::/48

Remarque

Cette procédure permet à l’agent de contourner un proxy web. Votre pipeline de build et vos scripts doivent toujours gérer le contournement de votre proxy web pour chaque tâche et outil que vous exécutez dans votre build.

Par exemple, si vous utilisez une tâche NuGet, vous devez configurer votre proxy web pour prendre en charge le contournement de l’URL du serveur qui héberge le flux NuGet que vous utilisez.

J’utilise TFS et les URL dans les sections ci-dessus ne fonctionnent pas pour moi. Où puis-je obtenir de l’aide ?

Paramètres et sécurité du site web

Qu’est-ce que l’invite « enable SERVICE_SID_TYPE_UNRESTRICTED for agent service » ?

Lorsque vous configurez le logiciel de l’agent sur Windows Server, vous pouvez spécifier l’identificateur de sécurité du service à partir de l’invite suivante.

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

Les versions précédentes du logiciel agent définissaient le type d’identificateur de sécurité de service sur SERVICE_SID_TYPE_NONE (valeur par défaut pour les versions actuelles de l’agent). Pour configurer le type d’identificateur de service de sécurité sur SERVICE_SID_TYPE_UNRESTRICTED, appuyez sur Y.

Pour plus d’informations, consultez SERVICE_SID_INFO structure et identificateurs de sécurité.