Agents Windows autohébergés

Azure DevOps Services

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

Important

Cet article donne des conseils sur l’utilisation de la version 3.x du logiciel de l’agent avec Azure DevOps Services. Si vous utilisez Azure DevOps Server ou TFS, consultez Agents Windows autohébergés (version 2.x de l’agent).

Notes

Cet article explique comment configurer un agent autohé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 autohébergé.

Présentation des agents

Si vous savez déjà ce qu’est un agent et connaissez son fonctionnement, n’hésitez pas à passer directement aux sections suivantes. Toutefois, si vous souhaitez en savoir plus sur leur rôle et leur fonctionnement, consultez Agents Azure Pipelines.

Vérifier les conditions préalables

Vérifiez que votre ordinateur respecte les prérequis suivants :

• 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 serveur
    • Windows Server 2012 ou version ultérieure
• Le logiciel de l’agent installe sa propre version de .NET afin d’éviter tout prérequis .NET.

• PowerShell 3.0 (ou version ultérieure)

• Subversion : si vous partez d’un référentiel Subversion, vous devez installer le client Subversion sur l’ordinateur.
• (Recommandé) Outils de build Visual Studio (2015 ou version ultérieure)

Il est recommandé d’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, vous pouvez 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 fournir des recommandations générales applicables à 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 ordinateurs de classe serveur 24 cœurs exécutant 4 agents autohébergés chacun.

Préparation des autorisations

Sécurité de l’information des agents autohébergés

L’utilisateur qui configure l’agent a besoin d’autorisations d’administrateur de pool, mais ce n’est pas le cas de l’utilisateur qui exécute l’agent.

Les dossiers contrôlés par l’agent doivent être limités à un nombre aussi restreint que possible d’utilisateurs. Ils contiennent des secrets qui pourraient ê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 par nature représenter 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 des agents Pipelines pour effectuer le travail. Il convient également de décider quelles sont les autorisations minimales pouvant être accordées à l’utilisateur qui exécute l’agent, à l’ordinateur sur lequel l’agent s’exécute, aux utilisateurs qui ont accès en écriture à la définition de pipeline, aux référentiels Git dans lesquels le YAML est stocké ou au groupe d’utilisateurs qui contrôle l’accès au pool des nouveaux pipelines.

Il est recommandé que l’identité qui exécute l’agent soit différente de celle qui possède l’autorisation de connecter l’agent au pool. L’utilisateur qui génère les informations d’identification (et d’autres fichiers liés à l’agent) n’est pas celui qui doit les lire. Par conséquent, il est plus sûr d’examiner soigneusement l’accès accordé à l’ordinateur de l’agent proprement dit, ainsi que les dossiers de l’agent qui contiennent des fichiers sensibles, par exemple des journaux et des artefacts.

Il est judicieux de n’accorder l’accès au dossier de l’agent qu’aux 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 les fichiers journaux leur permettant de signaler des défaillances Azure DevOps.

Choix de l’utilisateur à utiliser

Vous devez inscrire l’agent une seule fois. Ces étapes doivent être effectuées par une personne disposant de l’autorisation d’administration de la file d’attente d’agents. L’agent n’utilisera pas les informations d’identification de cette personne dans les opérations quotidiennes, mais elles sont nécessaires pour procéder à l’inscription. Découvrez comment les agents communiquent.

Authentification avec un jeton d’accès personnel (PAT)

1. Connectez-vous avec le compte d’utilisateur que vous envisagez d’utiliser dans votre organisation Azure DevOps (https://dev.azure.com/{your_organization}).

2. À partir de votre page d’hébergement, ouvrez vos paramètres utilisateur, puis sélectionnez Jetons d’accès personnels.

   

3. Créez un jeton d’accès personnel.

   

4. Pour l’étendue, sélectionnez Pools d’agents (lecture et gestion) et assurez-vous que toutes les autres cases sont décochées. S’il s’agit d’un agent de groupe de déploiement, choisissez comme étendue Groupe de déploiement (lecture et gestion) et décochez les autres cases.

   Sélectionnez Afficher toutes les étendues en bas de la fenêtre Créer une fenêtre de jeton d’accès personnel pour afficher la liste complète des étendues.

5. Copiez le jeton. Vous l’utiliserez lors de la configuration de l’agent.

Vérification de l’autorisation de l’utilisateur

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

Si l’utilisateur est propriétaire d’organisation Azure DevOps, ou administrateur TFS ou Azure DevOps Server, c’est bon. Vous disposez de l’autorisation nécessaire.

Sinon :

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

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

   2. Choisissez Azure DevOps, puis 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’apparaît pas, demandez à un administrateur de l’ajouter. Il peut s’agir d’un administrateur de pool d’agents, d’un propriétaire d’organisation Azure DevOps ou d’un administrateur TFS ou Azure DevOps Server.

   Dans le cas 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 DevOps ou 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.

Notes

Si vous voyez le message Impossible d’ajouter l’identité. Essayez-en une autre., cela signifie probablement que vous avez suivi la procédure ci-dessus pour un propriétaire d’organisation, ou un administrateur TFS ou Azure DevOps Server. Vous n’avez rien à faire : vous disposez déjà de l’autorisation d’administrer la file d’attente d’agents.

Téléchargement et configuration de l’agent

Azure Pipelines

1. Connectez-vous à l’ordinateur avec le compte pour lequel vous avez préparé des autorisations (cf. 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, puis 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 de 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, la version x86 à Windows 32 bits. Si vous ne savez pas quelle version de Windows est installée, suivez ces instructions pour la trouver.

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 du répertoire ne contient aucun espace, car les outils et les scripts n’échappe pas toujours correctement les espaces. Par exemple, le dossier C:\agents est recommandé. L’extraction dans le dossier de téléchargement ou dans d’autres dossiers utilisateur peut entraîner des problèmes d’autorisation. Exécutez ensuite config.cmd. L’utilitaire vous posera une série de questions pour configurer l’agent.

Important

Nous vous recommandons vivement de configurer l’agent dans une fenêtre PowerShell avec élévation de privilèges. C’est obligatoire si vous souhaitez le paramétrer en tant que service.

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

Important

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

Notes

Évitez d’utiliser des interpréteurs de commandes basés sur mintty (par exemple git-bash) pour la configuration de l’agent. Mintty n’est pas entièrement compatible avec l’API Windows d’entrée/sortie native (vous trouverez ici quelques informations à ce sujet). Le bon fonctionnement du script d’installation n’est dans ce cas pas garanti.

URL du serveur et authentification

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

Lorsque le programme d’installation demande votre type d’authentification, choisissez PAT. Collez ensuite le jeton PAT que vous avez créé dans la fenêtre d’invite de commandes.

Notes

Lorsque vous choisissez PAT comme méthode d’authentification, le jeton PAT n’est utilisé que pour la configuration initiale de l’agent. Si, par la suite, il expire ou doit être renouvelé, aucune autre modification de l’agent n’est nécessaire.

Choix entre le mode interactif et le mode de service

Pour obtenir de l’aide afin de choisir entre exécuter l’agent en mode interactif ou en tant que service, consultez Agents : mode interactif et mode de 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écution interactive

Si vous avez configuré l’agent de sorte qu’il s’exécute de manière interactive, procédez comme suit pour l’exécuter :

.\run.cmd

Pour redémarrer l’agent, appuyez sur Ctrl+C, puis exécutez run.cmd.

Exécution une seule fois

Pour que les agents configurés s’exécutent de manière interactive, vous pouvez faire en sorte qu’ils n’acceptent qu’un seul travail. Pour utiliser cette configuration, procédez comme suit :

.\run.cmd --once

Les agents qui fonctionnent dans ce mode n’acceptent qu’un seul travail, puis se mettent automatiquement en veille (utile pour l’exécution dans Docker sur un service comme Azure Container Instances).

Exécution en tant que service

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

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

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

Notes

Si vous devez modifier le compte d’ouverture de session de l’agent, n’utilisez pas pour cela le composant logiciel enfichable de services. Consultez plutôt les informations ci-dessous pour reconfigurer l’agent.

Pour utiliser votre agent, exécutez un travail à l’aide du pool de l’agent. Votre agent se trouve dans le pool Par défaut si vous n’en avez pas choisi d’autre.

Remplacement d’un agent

Pour remplacer un agent, suivez à nouveau la procédure Téléchargement et configuration de l’agent.

Lorsque vous configurez un agent sous le même nom qu’un agent déjà créé, il vous est demandé si vous souhaitez remplacer l’agent existant. Si vous répondez Y, veillez à supprimer l’agent (cf. ci-dessous) que vous remplacez. Sinon, après quelques minutes de conflits, l’un des agents s’arrête.

Suppression et reconfiguration d’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é avec un script sans intervention humaine. Vous devez passer --unattended et les réponses à toutes les questions.

Pour pouvoir configurer un agent, il doit connaître l’URL de votre organisation ou collection et les informations d’identification d’une personne autorisée à configurer les 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 : placez son nom en majuscules et ajoutez VSTS_AGENT_INPUT_ au début, par exemple VSTS_AGENT_INPUT_PASSWORD au lieu de --password.

Options obligatoires

• --unattended : le programme d’installation de l’agent ne demande pas d’informations, et tous les paramètres doivent être fournis en 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 autorisées sont :
  • pat (jeton d’accès personnel) : le seul schéma qui fonctionne avec Azure DevOps Services.
  • 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> : jeton d’accès personnel.
  • PAT est le seul schéma qui fonctionne avec Azure DevOps Services.
• Si vous avez choisi --auth negotiate ou --auth alt :
  • --userName <userName> : nom d’utilisateur Windows au format domain\userName ou userName@domain.com.
  • --password <password> : mot de passe.

Nom du pool et de l’agent

• --pool <pool> : nom du pool que l’agent doit rejoindre.
• --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.

Installation de l’agent

• --work <workDirectory> : répertoire de travail dans lequel les données de travail sont stockées. La valeur par défaut est _work sous 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 : accepter le Contrat de licence Utilisateur Final Team Explorer Everywhere (macOS et Linux uniquement).
• --disableloguploads : ne pas diffuser en continu ni envoyer la sortie du journal de console au serveur. Vous pouvez en revanche les récupérer auprès 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 (autorisation d’administrateur requise).
• --runAsAutoLogon : configurer l’ouverture de session automatique et exécuter l’agent au démarrage (autorisation d’administrateur requise).
• --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 ni les comptes Windows intégrés tels que « NT AUTHORITY\NETWORK SERVICE »).
• --overwriteAutoLogon : utilisé avec --runAsAutoLogon pour remplacer l’ouverture de session automatique existante sur l’ordinateur.
• --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

Lorsqu’il est configuré avec l’option runAsAutoLogon, l’agent s’exécute après chaque redémarrage de l’ordinateur. Procédez comme suit s’il n’est pas lancé une fois que vous avez redémarré 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 d’exécuter la commande suivante 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 manuellement l’agent de votre pool d’agents s’il n’a pas été supprimé par la commande.

Essayez ensuite de reconfigurer l’agent en exécutant la commande suivante dans le 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>'

Indiquez 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 est largement préférable de décompresser une archive d’agent (téléchargeable ici) et d’exécuter cette commande dans le nouveau dossier de l’agent décompressé.

Vérification de l’enregistrement de la clé de Registre Windows

Exécutez la commande whoami /user pour obtenir <sid>. Ouvrez Registry Editor et suivez le chemin suivant :

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

Vérifiez la présence de la clé VSTSAgent. Supprimez-la si elle existe, puis fermez Registry Editor et configurez l’agent en exécutant la commande .\config.cmd (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 clé VSTSAgent est apparue. Appuyez sur Enter pour répondre à la question et vérifiez si la clé VSTSAgent reste à sa place après le redémarrage de l’ordinateur.

Vérification du bon fonctionnement des clés de Registre Windows sur l’ordinateur

Créez un fichier autorun.cmd contenant la ligne echo "Hello from AutoRun!". Ouvrez Registry Editor et créez dans le chemin ci-dessus une paire clé-valeur avec la clé AutoRun et la valeur suivante :

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

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

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 que l’agent doit rejoindre.
• --projectName <name> : utilisé avec --deploymentGroup pour définir le nom du projet.
• --addDeploymentGroupTags : utilisé avec --deploymentGroup pour indiquer que des 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 des balises de l’agent de groupe de déploiement (par exemple « web, db »).

Environnement uniquement

• --addvirtualmachineresourcetags : utilisé pour indiquer que des 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 de l’agent de ressource d’environnement (par exemple « web, db »).

.\config --help donne toujours la liste des dernières réponses obligatoires et facultatives.

Diagnostics

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

.\run --diagnostics

Cela s’exécute au travers d’une suite de diagnostic 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 autohébergés

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 les autres options

Pour en savoir plus sur les autres options, exécutez la commande suivante :

.\config --help

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

Fonctionnalités

Les fonctionnalités de votre agent sont cataloguées et publiées dans le pool afin que seules les builds et les mises en production qu’il peut gérer lui soient affectées (cf. Fonctionnalités de l’agent de build et de mise en production).

Il est dans de nombreux cas nécessaire, après avoir déployé un agent, d’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, votre build ne s’exécute pas si elle inclut la tâche npm, à moins qu’il n’existe dans le pool un agent de build sur lequel npm est installé.

Important

Les fonctionnalités englobent toutes les variables d’environnement et les valeurs définies lors de l’exécution de l’agent. Si ces valeurs changent 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 de sorte que la nouvelle fonctionnalité s’affiche dans le pool et ainsi que la build puisse s’exécuter.

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

Questions fréquentes (FAQ)

Quelle version de Git mon agent exécute-t-il ?

Par défaut, l’agent Windows utilise la version de Git fournie avec le logiciel de l’agent. Il s’agit de la version recommandée par Microsoft. Néanmoins, vous disposez de plusieurs options pour remplacer ce comportement par défaut et choisir la version de Git que l’ordinateur de l’agent a installée dans le chemin.

• Définissez sur true une variable de pipeline nommée System.PreferGitFromPath 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 connaître la version de Git utilisée par un pipeline, vous pouvez examiner les journaux d’une étape checkout dans votre pipeline, comme 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, puis Paramètres de l’organisation.

      

   3. Choisissez Pools d’agents.

      

2. Cliquez sur le pool contenant l’agent.

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

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

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

      

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

      

   3. Sélectionnez l’onglet Fonctionnalités.

      

      Notes

      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 Utilisation d’un agent hébergé par Microsoft.

5. Recherchez la fonctionnalité Agent.Version. Vous pouvez confronter cette valeur à la dernière version de l’agent publié. Cherchez sur la page Agent Azure Pipelines le numéro de version le plus élevé qui y figure.

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

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, puis Paramètres de l’organisation.

      

   3. Choisissez Pools d’agents.

      

2. Cliquez sur le pool contenant l’agent.

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

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

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

      

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

      

   3. Sélectionnez l’onglet Fonctionnalités.

      

      Notes

      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 Utilisation d’un agent hébergé par Microsoft.

5. Recherchez la fonctionnalité Agent.Version. Vous pouvez confronter cette valeur à la dernière version de l’agent publié. Cherchez sur la page Agent Azure Pipelines le numéro de version le plus élevé qui y figure.

6. Chaque agent se met automatiquement à jour lorsqu’il exécute une tâche pour laquelle une version plus récente de l’agent est nécessaire. Si vous souhaitez mettre à jour certains agents manuellement, 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é situé derrière un pare-feu, veillez à ce qu’il puisse établir la communication avec les URL et adresses IP suivantes.

URL du domaine	Description
https://{organization_name}.pkgs.visualstudio.com	API de packaging Azure DevOps pour les organisations utilisant le domaine {organization_name}.visualstudio.com
https://{organization_name}.visualstudio.com	Pour les organisations utilisant le domaine {organization_name}.visualstudio.com
https://{organization_name}.vsblob.visualstudio.com	Télémétrie Azure DevOps pour les organisations utilisant le domaine {organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com	Services de gestion des mises en production pour les organisations utilisant le domaine {organization_name}.visualstudio.com
https://{organization_name}.vssps.visualstudio.com	Services de plateforme Azure DevOps pour les organisations utilisant le domaine {organization_name}.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com	Services de gestion des tests Azure DevOps pour les organisations utilisant le domaine {organization_name}.visualstudio.com
https://*.blob.core.windows.net	Azure Artifacts
https://*.dev.azure.com	Pour les organisations utilisant le domaine dev.azure.com
https://*.vsassets.io	Azure Artifacts avec CDN
https://*.vsblob.visualstudio.com	Télémétrie Azure DevOps pour les organisations utilisant le domaine dev.azure.com
https://*.vssps.visualstudio.com	Services de plateforme Azure DevOps pour les organisations utilisant le domaine dev.azure.com
https://*.vstmr.visualstudio.com	Services de gestion des tests Azure DevOps pour les organisations utilisant le domaine dev.azure.com
https://app.vssps.visualstudio.com	Pour les organisations utilisant le domaine {organization_name}.visualstudio.com
https://dev.azure.com	Pour les organisations utilisant le domaine dev.azure.com
https://login.microsoftonline.com	Connexion à Azure Active Directory
https://management.core.windows.net	API de gestion Azure
https://vstsagentpackage.azureedge.net	Package d’agent

Pour que votre organisation fonctionne avec les restrictions de pare-feu ou d’adresses 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 du protocole. Si vous êtes actuellement en train d’autoriser les adresses IP 13.107.6.183 et 13.107.9.183, laissez-les en place. Il n’est pas nécessaire de les supprimer.

Plages IPv4

• 13.107.6.0/24
• 13.107.9.0/24
• 13.107.42.0/24
• 13.107.43.0/24

Plages IPv6

• 2620:1ec:4::/48
• 2620:1ec:a92::/48
• 2620:1ec:21::/48
• 2620:1ec:22::/48

Notes

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 autosigné ?

Notes

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

Cf. Exécution de l’agent avec un certificat autosigné.

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

Cf. Exécution de 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 qui figurent dans Exécution interactive. En cas d’exécution en tant que service, redémarrez l’agent suivant la procédure décrite dans Exécution en tant que service.

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

Créez un fichier .env sous le répertoire racine de l’agent, 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 de sorte qu’il contourne un proxy web et se connecte à Azure Pipelines ?

Si vous souhaitez que l’agent contourne votre proxy et se connecte directement à Azure Pipelines, configurez votre proxy web de façon à permettre à l’agent d’accéder aux URL suivantes.

Pour les organisations utilisant le domaine *.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

Pour les organisations utilisant le domaine 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://vssps.dev.azure.com

Pour que votre organisation fonctionne avec les restrictions de pare-feu ou d’adresses 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 du protocole. Si vous êtes actuellement en train d’autoriser les adresses IP 13.107.6.183 et 13.107.9.183, laissez-les en place. Il n’est pas nécessaire de les supprimer.

Plages IPv4

• 13.107.6.0/24
• 13.107.9.0/24
• 13.107.42.0/24
• 13.107.43.0/24

Plages IPv6

• 2620:1ec:4::/48
• 2620:1ec:a92::/48
• 2620:1ec:21::/48
• 2620:1ec:22::/48

Notes

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

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

Les URL des sections ci-dessus ne s’appliquent pas à ma situation, car j’utilise TFS. Comment obtenir de l’aide ?

Cf. Paramètres et sécurité des sites web.

Que signifie activer SERVICE_SID_TYPE_UNRESTRICTED pour le service d’agent ?

Lors de la configuration du logiciel de l’agent sur Windows Server, vous pouvez spécifier l’identificateur de sécurité du service dans l’invite suivante.

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

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

Pour plus d’informations, consultez Structure SERVICE_SID_INFO et Identificateurs de sécurité.