Partager via

Agents de Azure Pipelines

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

Vous avez besoin d’au moins un agent pour générer votre code ou déployer votre logiciel à l’aide d’Azure Pipelines. À mesure que votre base de code et votre équipe augmentent, vous avez besoin de plusieurs agents.

Quand votre pipeline s’exécute, le système démarre un ou plusieurs travaux. Un agent est une infrastructure informatique avec un logiciel agent installé, qui exécute les travaux un par un.

Azure Pipelines fournit plusieurs types d’agent différents.

Type d’agent Description Disponibilité
Agents hébergés par Microsoft Agents hébergés et gérés par Microsoft. Azure DevOps Services
Agents auto-hébergés Agents que vous configurez et gérez qui sont hébergés sur vos machines virtuelles. Azure DevOps Services, Azure DevOps Server
Agents Managed DevOps Pools Les pools DevOps managés sont un service entièrement managé. Les machines virtuelles ou conteneurs qui alimentent les agents vivent dans un abonnement de Microsoft Azure et non dans votre propre abonnement Azure. Azure DevOps Services
Agents des ensembles de mise à l'échelle de machines virtuelles Azure Une forme d’agents auto-hébergés qui utilise les jeux d'échelle de machines virtuelles Azure et qui peuvent être mis à l’échelle automatiquement pour répondre aux demandes.

Si vous envisagez d’utiliser des pools d’agents extensibles automatiquement et auto-hébergés, nous vous recommandons d’envisager des pools DevOps gérés. Pour plus d’informations, consultez Comparaison des pools DevOps managés avec les agents Azure Virtual Machine Scale Sets et la vue d’ensemble des pools DevOps managés.		 Azure DevOps Services

Vous pouvez exécuter des travaux directement sur l’ordinateur hôte de l’agent ou dans un conteneur.

Agents hébergés par Microsoft

Si vos pipelines se trouvent dans Azure Pipelines, vous pouvez exécuter facilement vos travaux à l’aide d’un agent hébergé par Microsoft. Avec les agents hébergés par Microsoft, la maintenance et les mises à niveau se produisent automatiquement.

Vous disposez toujours de la dernière version de l’image de machine virtuelle que vous spécifiez dans votre pipeline. Chaque fois que vous exécutez un pipeline, vous obtenez une nouvelle machine virtuelle pour chaque travail du pipeline. La machine virtuelle est supprimée après une tâche. Toute modification apportée par un travail au système de fichiers de machine virtuelle, comme l’extraction du code, n’est pas disponible lors du travail suivant.

Les agents hébergés par Microsoft peuvent exécuter des travaux directement sur la machine virtuelle ou dans un conteneur.

Azure Pipelines fournit un pool d’agents prédéfini appelé Azure Pipelines avec des agents hébergés par Microsoft.

Pour de nombreuses équipes, ce processus est le moyen le plus simple d’exécuter vos travaux. Vous pouvez d’abord essayer de voir s’il fonctionne pour votre build ou votre déploiement. Sinon, vous pouvez utiliser des agents de Machine Scale Sets virtuels ou un agent auto-hébergé.

Conseil

Vous pouvez essayer gratuitement un agent hébergé par Microsoft.

En savoir plus sur les agents hébergés par Microsoft.

Agents auto-hébergés

Un agent auto-hébergé est un agent que vous avez configuré pour exécuter des travaux et gérer vous-même. Vous pouvez utiliser des agents auto-hébergés dans Azure Pipelines ou Azure DevOps Server. Les agents auto-hébergés vous offrent un contrôle accru pour installer des logiciels dépendants dont vous avez besoin pour vos compilations et déploiements. En outre, les caches et la configuration au niveau de la machine persistent d’une exécution à l’autre, ce qui permet d’améliorer la vitesse.

Bien que plusieurs agents puissent être installés par ordinateur, nous vous recommandons vivement d’installer un seul agent par ordinateur. Lorsque vous installez deux agents ou plus, cela peut affecter les performances et le résultat de vos pipelines.

Conseil

Avant d’installer un agent auto-hébergé, vous pouvez voir si un pool d’agents hébergés par Microsoft fonctionne pour vous. Dans de nombreux cas, un pool d’agents hébergés par Microsoft est le moyen le plus simple de commencer. Faites un essai.

Vous pouvez installer l’agent sur des machines Linux, macOS et Windows. Vous pouvez également installer l’agent sur un conteneur Docker. Pour plus d’informations sur l’installation d’un agent autohébergé, consultez :

Sur macOS, vous devez effacer l’attribut spécial sur l’archive de téléchargement pour empêcher la protection macOS Gatekeeper de s’afficher pour chaque assembly dans le fichier TAR lors de l’exécution de ./config.sh. La commande suivante efface l’attribut étendu sur le fichier :

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

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

Après avoir installé l’agent sur un ordinateur, vous pouvez installer n’importe quel autre logiciel sur cet ordinateur dont vos travaux ont besoin.

Note

Les agents offrent généralement une compatibilité descendante. Toute version de l’agent doit être compatible avec n’importe quelle version d’Azure DevOps, tant qu’Azure DevOps ne demande pas de version supérieure de l’agent.

Nous prenons uniquement en charge la version la plus récente de l’agent, car il s’agit de la seule version garantie d’avoir tous les correctifs et correctifs de bogues up-to-date.

versions de l’exécuteur Node.js

L’agent est fourni avec plusieurs versions de bibliothèques Node.js pour prendre en charge les tâches cibles qui utilisent différents gestionnaires Node.js.

Toutes les tâches Azure DevOps officielles utilisent Node.js bibliothèque 20 en tant que gestionnaire universel. Toutefois, les clients peuvent toujours utiliser des tâches personnalisées qui utilisent les versions de fin de prise en charge Node.js. Les auteurs de tâches d’extension/personnalisés doivent mettre à jour/tester leurs tâches avec les versions Node.js actuelles.

Pour plus d’informations sur le cycle de vie de l’exécuteur Node.js dans Azure Pipelines, consultez Node.js exécuteurs dans l’agent Azure Pipelines.

Agents de jeux d'échelles de machines virtuelles Azure

Les agents Azure Virtual Machine Scale Sets sont une forme d’agents auto-hébergés qui peuvent être mis à l’échelle automatiquement pour répondre à vos demandes. Cette élasticité réduit votre besoin d’exécuter des agents dédiés tout le temps. Contrairement aux agents hébergés par Microsoft, vous disposez d’une flexibilité sur la taille et l’image des ordinateurs sur lesquels les agents s’exécutent.

Azure Pipelines gère la mise à l’échelle de vos agents pour vous. Spécifiez les facteurs suivants :

  • Un ensemble de mise à l'échelle des machines virtuelles
  • Nombre d’agents à conserver en veille
  • Nombre maximal de machines virtuelles dans l'ensemble de mise à l'échelle

Pour plus d’informations, consultez les agents Azure Virtual Machine Scale Sets.

Agents de pools DevOps gérés

Les Managed DevOps Pools permettent aux équipes de développement de créer rapidement et facilement des pools d’agents Azure DevOps adaptés aux besoins spécifiques d’une équipe.

Pools DevOps gérés :

  • Implémente les meilleures pratiques de sécurité.
  • Fournit des moyens d’équilibrer les coûts et les performances.
  • Fournit des chemins pour les scénarios les plus courants.
  • Réduit considérablement le temps nécessaire pour créer et gérer des pools personnalisés.

Les pools DevOps managés sont une évolution des pools d’agents Azure Virtual Machine Scale Sets. Il simplifie encore davantage la création de pool personnalisé en améliorant la scalabilité et la fiabilité des pools personnalisés. Les pools DevOps managés sont un service entièrement managé. Les machines virtuelles ou conteneurs qui hébergent les agents résident dans un abonnement Microsoft Azure et non dans votre propre abonnement Azure, à l'image des pools d'agents d'Azure Virtual Machine Scale Sets. Pour plus d’informations, veuillez consulter la documentation des Managed DevOps Pools.

Travaux parallèles

Le concept de travaux parallèles représente le nombre de travaux que vous pouvez exécuter en même temps dans votre organisation. Si votre organisation a un travail parallèle unique, vous pouvez exécuter un seul travail à la fois dans votre organisation. Tous les autres travaux simultanés sont mis en file d’attente jusqu’à la fin du premier travail. Pour exécuter deux travaux simultanément, vous avez besoin de deux travaux parallèles. Dans Azure Pipelines, vous pouvez exécuter des travaux parallèles sur une infrastructure hébergée par Microsoft ou sur votre propre infrastructure (auto-hébergée).

Microsoft fournit un niveau de service gratuit par défaut dans chaque organisation comprenant au moins un travail parallèle. Selon le nombre de pipelines simultanés à exécuter, vous pouvez avoir besoin de travaux parallèles supplémentaires pour utiliser plusieurs agents hébergés par Microsoft ou auto-hébergés simultanément. Pour plus d’informations sur les travaux parallèles et les différents niveaux de service gratuits, consultez Travaux parallèles dans Azure Pipelines.

Vous avez peut-être besoin de travaux parallèles supplémentaires pour utiliser plusieurs agents simultanément :

Importante

À compter d’Azure DevOps Server 2019, vous ne payez pas pour les travaux simultanés auto-hébergés dans les versions. Vous n’êtes limité que par le nombre d’agents que vous avez.

Fonctionnalités

Chaque agent auto-hébergé présente un ensemble de capacités indiquant les opérations possibles. Les fonctionnalités sont des paires nom/valeur qui sont les suivantes :

  • Fonctionnalités découvertes par le logiciel de l’agent, appelées fonctionnalités système.
  • Fonctionnalités que vous définissez, appelées fonctionnalités utilisateur.

Le logiciel de l’agent détermine automatiquement différentes fonctionnalités système. Ces fonctionnalités incluent le nom de l’ordinateur, le type de système d’exploitation et les versions de certains logiciels installés sur l’ordinateur. En outre, les variables d’environnement définies dans la machine apparaissent automatiquement dans la liste des capacités du système.

Lorsque vous stockez des variables d’environnement en tant que fonctionnalités, les valeurs de capacité stockées sont utilisées pour définir les variables d’environnement lorsqu’un agent s’exécute. En outre, lorsque vous apportez des modifications aux variables d’environnement pendant l’exécution de l’agent, elles ne sont pas récupérées et utilisées par n’importe quelle tâche. Si vous ne souhaitez pas que les variables d’environnement sensibles qui changent soient stockées en tant que fonctionnalités, vous pouvez diriger l’agent pour les ignorer. Définissez la variable d’environnement VSO_AGENT_IGNORE , avec une liste délimitée par des virgules de variables à ignorer. Par exemple, PATH est une variable critique que vous pouvez ignorer si vous installez un logiciel.

Quand vous créez un pipeline, vous spécifiez certaines exigences de l’agent. Le système envoie le travail uniquement aux agents qui ont des fonctionnalités qui correspondent aux demandes spécifiées dans le pipeline. Par conséquent, les capacités de l’agent permettent de diriger les travaux vers des agents spécifiques.

Les demandes et les capacités sont conçues pour être utilisées avec des agents autohébergés afin que les travaux soient attribués à un agent qui répond aux exigences du travail. Lorsque vous utilisez des agents hébergés par Microsoft, vous sélectionnez une image pour l’agent qui correspond aux exigences du travail. Bien qu’il soit possible d’ajouter des fonctionnalités à un agent hébergé par Microsoft, vous n’avez pas besoin d’utiliser des fonctionnalités avec des agents hébergés par Microsoft.

Configurer des demandes

Pour ajouter une demande à votre pipeline de build YAML, ajoutez la ligne demands: à la section pool.

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

Vous pouvez vérifier l’existence d’une fonctionnalité ou effectuer une comparaison avec la valeur d’une fonctionnalité. Pour obtenir plus d’informations, consultez Schéma YAML – Demandes.

Configurer les capacités de l’agent

Vous pouvez afficher les détails de l’agent, y compris les fonctionnalités de version et de système, et gérer ses fonctionnalités utilisateur. Accédez aux pools d’agents et sélectionnez l’onglet Fonctionnalités de l’agent souhaité.

  1. Dans votre navigateur web, accédez aux pools d’agents :

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

    2. Sélectionnezles paramètres de l’organisation>.

      Capture d’écran montrant comment sélectionner les paramètres de l’organisation.

    3. Sélectionnez Pools d’agents.

      Capture d’écran montrant comment sélectionner l’onglet Pools d’agents.

    1. Connectez-vous à votre collection de projets (http://your-server/DefaultCollection).

    2. Sélectionnezles paramètres de collection>.

      Capture d’écran montrant comment sélectionner les paramètres de collection.

    3. Sélectionnez Pools d’agents.

      Sélectionnez Pools d’agents.

    Capture d’écran montrant comment accéder et sélectionner des pools d’agents.

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

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

      Dans les pools d’agents, sélectionnez le pool d’agents souhaité.

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

      Sélectionnez Agents et choisissez l’agent.

    3. Choisissez l’onglet Fonctionnalités.

      Choisissez l’onglet Fonctionnalités.

      Note

      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.

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

      Sélectionnez le pool souhaité.

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

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

    3. Choisissez l’onglet Fonctionnalités.

      Onglet Capacités de l’agent.

  3. Pour inscrire une nouvelle fonctionnalité auprès de l’agent, sélectionnez Ajouter une nouvelle fonctionnalité.

Conseil

Après avoir installé un nouveau logiciel sur un agent auto-hébergé, vous devez redémarrer l’agent pour que la nouvelle capacité s’affiche. Pour plus d’informations, consultez Redémarrer l’agent Windows, Redémarrer l’agent Linux et Redémarrer l’agent Mac.

Communication

Communication avec Azure Pipelines

Communication avec Azure DevOps Server

L’agent communique avec Azure Pipelines ou Azure DevOps Server. Il détermine le travail qu'il doit exécuter et fournit les journaux ainsi que l'état du travail. L'agent est toujours à l'origine de cette communication.

Tous les messages de l’agent à destination d’Azure Pipelines ou Azure DevOps Server utilisent le protocole HTTPS, selon la façon dont vous configurez l’agent. Ce modèle de pull vous permet de configurer l’agent sur différentes topologies, comme illustré dans les exemples suivants.

Graphique montrant les topologies d’agent dans les installations locales.

Graphique montrant les topologies d’agent dans Azure DevOps Services.

Voici un modèle de communication courant entre l’agent et Azure Pipelines ou Azure DevOps Server :

  1. L’utilisateur inscrit un agent auprès d’Azure Pipelines ou d’Azure DevOps Server en l’ajoutant à un pool d’agents. Pour inscrire un agent dans ce pool d’agents, vous devez avoir le rôle d’administrateur du pool d’agents . Le rôle d’administrateur du pool d’agents est nécessaire uniquement au moment de l’inscription et n’est pas conservé sur l’agent. Elle n'est pas utilisée dans les communications ultérieures entre l'agent et Azure Pipelines ou Azure DevOps Server.

    Une fois l’inscription terminée, l’agent télécharge un listener OAuth token et l’utilise pour surveiller la file d'attente des tâches.

  2. L’agent écoute si une nouvelle demande de travail est publiée dans la file d’attente de travaux dans Azure Pipelines ou Azure DevOps Server à l’aide d’un sondage HTTP long. Lorsqu’une tâche est disponible, l’agent télécharge la tâche et un job-specific OAuth token. Azure Pipelines ou Azure DevOps Server génère un jeton de courte durée pour l’identité délimitée spécifiée dans le pipeline.

    L’agent utilise le jeton pour accéder ou modifier des ressources sur Azure Pipelines ou Azure DevOps Server au sein de ce travail. Par exemple, il utilise le jeton pour accéder au code source ou charger les résultats des tests.

  3. L'agent supprime le jeton de tâche spécifique OAuth après la fin du travail, puis vérifie s'il y a une nouvelle demande de travail avec le jeton OAuth de l'écoute.

La charge utile des messages échangés entre l’agent et Azure Pipelines ou Azure DevOps Server est sécurisée à l’aide du chiffrement asymétrique.

Chaque agent possède une paire de clés publique/privée et la clé publique est échangée avec le serveur lors de l’inscription. Le serveur utilise la clé publique pour chiffrer la charge utile du travail avant de l’envoyer à l’agent. L’agent déchiffre le contenu du travail à l’aide de sa clé privée.

Cette méthode sécurise les secrets stockés dans les pipelines ou les groupes de variables lorsqu'ils sont échangés avec l'agent.

Note

L’agent prend en charge l'encodage en UTF-8 pour la sortie du client. Toutefois, si votre système n’utilise pas l’encodage UTF-8, vous pouvez rencontrer des problèmes avec la sortie des logs. Par exemple, les journaux d’activité peuvent contenir des caractères que l’encodage de votre système ne peut pas reconnaître, ce qui peut donner des symboles illisibles ou manquants.

Communiquer pour effectuer un déploiement sur des serveurs cibles

Quand vous utilisez l’agent pour déployer des artefacts sur un ensemble de serveurs, il doit disposer d’une connectivité « à visibilité directe » à ces serveurs. Par défaut, les pools d’agents hébergés par Microsoft disposent d’une connectivité aux sites web et serveurs Azure qui s’exécutent dans Azure.

Si vos ressources Azure s’exécutent dans un réseau virtuel Azure, vous pouvez obtenir les plages d’adresses IP de l’agent où les agents hébergés par Microsoft sont déployés. Ensuite, vous pouvez configurer les règles de pare-feu pour votre réseau virtuel Azure afin d’autoriser l’accès par l’agent.

Si vos environnements locaux ne disposent pas de connectivité à un pool d'agents hébergés par Microsoft, ce qui est généralement le cas en raison de pare-feu intermédiaires, vous devez configurer manuellement des agents auto-hébergés sur des ordinateurs locaux. Les agents doivent avoir une connectivité aux environnements locaux cibles et accéder à Internet pour se connecter à Azure Pipelines ou Azure DevOps Server. Ce processus est illustré dans le schéma suivant :

Graphique montrant la connectivité de l’agent pour les environnements locaux.

Authentification

Pour inscrire un agent, vous devez être membre du rôle Administrateur dans le pool d’agents. L'identité de l'administrateur du pool d'agents n'est nécessaire qu'au moment de l'enregistrement et n'est pas conservée sur l'agent. Il n'est pas utilisé dans les communications ultérieures entre l'agent et Azure Pipelines ou Azure DevOps Server. Pour configurer l’agent, vous devez également être administrateur local sur le serveur.

Lorsque vous inscrivez un agent, sélectionnez parmi les types d’authentification suivants. Le processus d’installation de l’agent 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.
  • Alternative : Connectez-vous à Azure DevOps Server à l’aide de l’authentification de base. Lorsque vous sélectionnez Alternative, vous êtes invité à entrer vos informations d’identification.

En outre, les agents Windows disposent des deux options d'authentification suivantes sur Azure DevOps Server.

  • Négocier : Connectez-vous à Azure DevOps Server en tant qu’utilisateur autre que l’utilisateur connecté via un schéma d’authentification Windows (par exemple, New Technology LAN Manager (NTLM) ou Kerberos). Une fois que vous avez sélectionné Negotiate, vous êtes invité à entrer les informations d’identification.
  • Intégré : (par défaut) Connecter un agent Windows à Azure DevOps Server à l’aide des informations d’identification de l’utilisateur connecté via un schéma d’authentification Windows (par exemple, NTLM ou Kerberos). Vous ne serez pas invité à entrer les informations d’identification après avoir sélectionné cette méthode.

Importante

Vous devez configurer votre serveur pour prendre en charge la méthode d’authentification pour utiliser l’authentification alternative, négocier ou l’authentification intégrée.

La méthode d’authentification que vous utilisez pour inscrire l’agent est utilisée uniquement pendant l’inscription de l’agent. Pour en savoir plus sur la manière dont les agents communiquent avec Azure Pipelines après l'inscription, consultez Communication avec Azure Pipelines ou Azure DevOps Server.

Interactif vs. service

Vous pouvez exécuter votre agent autohébergé en tant que service ou processus interactif.

Après avoir configuré l’agent, nous vous recommandons de commencer par l’essayer en mode interactif pour vous assurer qu’il fonctionne. Ensuite, pour une utilisation en production, nous vous recommandons d’exécuter l’agent dans l’un des modes suivants afin qu’il reste continuellement en état de fonctionnement. Ces modes garantissent également que l’agent démarre automatiquement si la machine est redémarrée.

  • En tant que service : vous pouvez utiliser le gestionnaire de services du système d’exploitation pour gérer le cycle de vie de l’agent. L’expérience de mise à niveau automatique de l’agent est meilleure lorsque vous exécutez l’agent en tant que service.

  • En tant que processus interactif avec la connexion automatique activée : dans certains cas, vous devrez peut-être exécuter l’agent de manière interactive pour une utilisation en production (par exemple, pour exécuter des tests d’interface utilisateur). Lorsque vous configurez un agent pour qu’il s’exécute dans ce mode, l’économiseur d’écran est désactivé. Certaines stratégies de domaine peuvent vous empêcher d’activer la connexion automatique ou de désactiver l’économiseur d’écran. Dans ce cas, vous devrez peut-être demander une dérogation à la stratégie de domaine ou exécuter l'agent sur un ordinateur de groupe de travail où les stratégies de domaine ne s'appliquent pas.

    Note

    Il existe des risques de sécurité lorsque vous activez la connexion automatique ou désactivez l’économiseur d’écran. D’autres utilisateurs peuvent accéder à l’ordinateur et utiliser le compte qui se connecte automatiquement. Si vous configurez l’agent pour qu’il s’exécute de cette façon, vous devez vous assurer que l’ordinateur est physiquement protégé (par exemple, situé dans une installation sécurisée).

    Si vous utilisez un Bureau à distance pour accéder à un ordinateur sur lequel un agent s’exécute avec la connexion automatique, la fermeture du Bureau à distance entraîne le verrouillage de l’ordinateur. Tous les tests d’interface utilisateur qui s’exécutent sur cet agent peuvent échouer. Pour éviter ce problème, utilisez la tscon commande pour vous déconnecter du Bureau à distance. Par exemple :

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

Compte de l’agent

Que vous exécutiez un agent en tant que service ou de manière interactive, vous pouvez choisir le compte d’ordinateur à utiliser pour exécuter l’agent. Le choix du compte d’agent dépend uniquement des besoins des tâches qui s’exécutent dans vos travaux de génération et de déploiement.

Par exemple, pour exécuter des tâches à l’aide de l’authentification Windows pour accéder à un service externe, l’agent doit s’exécuter à l’aide d’un compte ayant accès à ce service. Toutefois, si vous exécutez des tests d’interface utilisateur tels que les tests d’interface utilisateur Selenium ou Codé qui nécessitent un navigateur, le navigateur s’ouvre dans le contexte du compte d’agent.

Sur Windows, nous vous recommandons d’utiliser un compte de service tel que le service réseau ou le service local. Ces autorisations de comptes sont restreintes et leurs mots de passe n’expirent pas. Par conséquent, l’agent nécessite moins de gestion au fil du temps.

Ces informations d'identification sont différentes de celles que vous utilisez lorsque vous enregistrez l'agent auprès d'Azure Pipelines ou d'Azure DevOps Server.

Version et mises à niveau de l’agent

Nous mettons à jour le logiciel de l’agent à un intervalle de quelques semaines dans Azure Pipelines. Nous indiquons la version de l’agent au format {major}.{minor}. Par exemple, si la version de l'agent est 2.1, la version majeure est 2 et la version mineure 1.

Nous maintenons les agents hébergés par Microsoft à jour. Si la version la plus récente de l’agent est différente uniquement dans la version mineure , Azure Pipelines peut automatiquement mettre à jour les agents auto-hébergés. Le paramètre par défaut est activé. Vous pouvez configurer ce paramètre dans les pools d’agents en sélectionnant votre agent, puis en sélectionnant Paramètres. Une mise à niveau est demandée lorsqu’une fonctionnalité de plateforme ou l’une des tâches du pipeline nécessite une version plus récente de l’agent.

Si vous exécutez un agent auto-hébergé de manière interactive, ou si une nouvelle version majeure de l'agent est disponible, il se peut que vous deviez mettre à jour manuellement les agents. Vous pouvez mettre à niveau les agents à partir de l’onglet Pools d’agents sous votre organisation. Les pipelines ne peuvent pas fonctionner sans un agent compatible.

Pour mettre à jour les agents auto-hébergés

  1. Accédez aux pools de l’Agent >des paramètres de projet.

    Capture d’écran montrant comment rechercher et sélectionner des pools d’agents.

  2. Sélectionnez votre pool d’agents, puis Mettez à jour tous les agents.

    Capture d’écran montrant comment sélectionner Mettre à jour tous les agents.

    Vous pouvez également mettre à jour des agents individuellement en sélectionnant Mettre à jour l’agent dans le menu ...

    Capture d’écran montrant comment sélectionner Update Agent.

  3. Sélectionnez Mettre à jour pour confirmer.

    Capture d’écran montrant comment sélectionner Mettre à jour pour confirmer.

  4. Une demande de mise à jour est mise en file d’attente pour chaque agent du pool et s’exécute quand des travaux en cours d’exécution se terminent. Une mise à niveau ne prend généralement que quelques instants. Ce temps est suffisamment long pour télécharger la dernière version du logiciel de l’agent (environ 200 Mo), décompressez-le et redémarrez l’agent avec la nouvelle version. Vous pouvez superviser l’état de vos agents sous l’onglet Agents.

Nous mettons à jour le logiciel de l’agent avec chaque mise à jour azure DevOps Server. Nous indiquons la version de l’agent au format {major}.{minor}. Par exemple, si la version de l’agent est 2.1, la version principale est 2 et la version mineure est 1.

Lorsque votre serveur Azure DevOps a une version plus récente de l’agent et que cet agent plus récent est différent uniquement dans la version mineure , il peut généralement être mis à niveau automatiquement. Une mise à niveau est demandée lorsqu’une fonctionnalité de plateforme ou l’une des tâches que vous utilisez dans le pipeline nécessite une version plus récente de l’agent. À compter d’Azure DevOps Server 2019, il n’est pas nécessaire d’attendre une nouvelle version du serveur. Vous pouvez charger une nouvelle version de l'agent dans votre niveau d'application, et cette version est proposée comme mise à niveau.

Si vous exécutez l’agent de manière interactive ou si une version majeure plus récente de l’agent est disponible, vous devrez peut-être mettre à niveau manuellement les agents. Vous pouvez facilement mettre à niveau l'agent à partir de l'onglet Pools d'agents sous votre collection de projets. Les pipelines ne peuvent pas fonctionner sans un agent compatible.

Vous pouvez consulter la version d’un agent. Accédez aux pools d’agents et sélectionnez l’onglet Fonctionnalités de l’agent souhaité, comme décrit dans Configurer les fonctionnalités de l’agent.

Pour déclencher la mise à jour de l’agent par programmation, vous pouvez utiliser l’API de mise à jour de l’agent comme décrit dans la section Comment déclencher les mises à jour de l’agent par programmation pour un pool d’agents spécifique ?.

Pour les serveurs sans accès Internet, copiez manuellement le fichier ZIP de l’agent dans le dossier suivant à utiliser comme fichier local. Créez le dossier Agents s’il n’est pas présent :

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

Structure de répertoires de l’agent

Lorsque les travaux de pipeline s’exécutent sur des agents, une structure de répertoires est créée pour stocker le code source, les fichiers binaires et les artefacts.

Le répertoire de base de l’agent est le répertoire où l’agent est installé. Le répertoire se trouve généralement :

  • Agents hébergés par Microsoft : C:\agents\<agent version> sur Windows, /Users/runner/runners/<agent version> sur macOS et /home/vsts/agents/<agent version> sur Linux.
  • Agents auto-hébergés : C:\agent sur Windows, Users/<username>/agent (~/agent) sur macOS et /home/vsts/agent sur Linux.

Le répertoire de travail de l’agent contient l’espace de travail où la source et la sortie des travaux sont stockées. Le répertoire de travail se trouve généralement :

  • Agent hébergé par Microsoft : C:\a sur Windows, /Users/runner/work sur macOS et/home/vsts/work sur Linux.
  • Agent auto-hébergé : C:\agent\_work sur Windows, ~/agent/work sur macOS et /home/agent/_work sur Linux.

La structure du répertoire de travail est la suivante :


    - /work directory
        - /1 build directory/pipeline workspace
            - /s source/working directory
            - /b binaries directory
            - /a artifacts staging directory
            - /TestResults Test results directory
Répertoire Description Exemples Variables prédéfinies
Répertoire de base de l’agent Où l’agent est installé. Agent hébergé par Microsoft :
   Windows : C:\agents\3.248.0
   Linux : /home/vsts/agents/3.248.0
   MacOS : /Users/runner/runners/3.248.0
Agent auto-hébergé :
   Windows : C:\agent
   Linux : home/agent
   MacOS : ~/agent		 Agent.HomeDirectory
Répertoire de travail Où l’agent stocke le code source, les fichiers binaires et les artefacts. Agent hébergé par Microsoft :
   Windows : C:\a
   Linux : /home/vsts/work
   MacOS : /Users/runner/work
Agent auto-hébergé :
   Windows : C:\agent\_work
   Linux : /home/agent/_work
   MacOS : ~/agent/work		 Agent.WorkFolder
Agent.RootDirectory
System.WorkFolder
Créer un répertoire ou un espace de travail Où le travail de pipeline s’exécute. Agent hébergé par Microsoft :
   Windows : C:\a\1
   Linux : /home/vsts/work/1
   MacOS : /Users/runner/work/1
Agent auto-hébergé :
   Windows : C:\agent\_work\1
   Linux : /home/agent/_work/1
   MacOS : ~/agent/work/1		 Agent.BuildDirectory
Pipeline.Workspace
s - Répertoire source ou de travail Contient le code source extrait du référentiel. S’il existe plusieurs checkout étapes dans votre travail, votre code source est extrait dans les répertoires ayant pour nom celui des référentiels, en tant que sous-dossier de s. Agent hébergé par Microsoft :
   Windows : C:\a\1\s
   Linux : /home/vsts/work/1/s
   MacOS : /Users/runner/work/1/s
Agent auto-hébergé :
   Windows : C:\agent\_work\1\s
   Linux : /home/agent/_work/1/s
   MacOS : ~/agent/work/1/s		 Build.SourcesDirectory
Build.RepositoryLocalPath
System.DefaultWorkingDirectory
b - Répertoire des binaires Contient les sorties de build. Agent hébergé par Microsoft :
   Windows : C:\a\1\b
   Linux : /home/vsts/work/1/b
   MacOS : /Users/runner/work/1/b
Agent auto-hébergé :
   Windows : C:\agent\_work\1\b
   Linux : /home/agent/_work/1/b
   MacOS : ~/agent/work/1/b		 Build.BinariesDirectory
a - Répertoire de préproduction d’artefacts Contient les artefacts de build. Est nettoyé entre les exécutions sur les agents auto-hébergés. Agent hébergé par Microsoft :
   Windows : C:\a\1\a
   Linux : /home/vsts/work/1/a
   MacOS : /Users/runner/work/1/a
Agent auto-hébergé :
   Windows : C:\agent\_work\1\a
   Linux : /home/agent/_work/1/a
   MacOS : ~/agent/work/1/a		 Build.StagingDirectory
Build.ArtifactStagingDirectory
System.ArtifactsDirectory
TestResults répertoire Contient les résultats des tests. Est nettoyé entre les exécutions sur les agents auto-hébergés. Agent hébergé par Microsoft :
   Windows : C:\a\1\TestResults
   Linux : /home/vsts/work/1/TestResults
   MacOS : /Users/runner/work/1/TestResults
Agent auto-hébergé :
   Windows : C:\agent\_work\1\TestResults
   Linux : /home/agent/_work/1/TestResults
   MacOS : ~/agent/work/1/TestResults		 Common.TestResultsDirectory

Sur les agents hébergés par Microsoft, un autre agent est utilisé sur chaque exécution. Par conséquent, le répertoire de travail n’est pas conservé entre les exécutions. Sur les agents auto-hébergés, seuls les répertoires de préproduction des artefacts et les répertoires de résultats de test sont nettoyés entre les exécutions par défaut. Pour plus d’informations sur l’option de nettoyage de l’espace de travail, consultez Espace de travail.

Pour plus d’informations sur les variables prédéfinies, consultez variables prédéfinies.

Questions fréquentes (FAQ)

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. Sélectionnezles paramètres de l’organisation>.

      Capture d’écran montrant comment sélectionner les paramètres de l’organisation.

    3. Sélectionnez Pools d’agents.

      Capture d’écran montrant comment sélectionner l’onglet Pools d’agents.

    1. Connectez-vous à votre collection de projets (http://your-server/DefaultCollection).

    2. Sélectionnezles paramètres de collection>.

      Capture d’écran montrant comment sélectionner les paramètres de collection.

    3. Sélectionnez Pools d’agents.

      Sélectionnez Pools d’agents.

    Capture d’écran montrant comment accéder et sélectionner des pools d’agents.

  2. Sélectionnez le pool qui contient l’agent.

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

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

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

      Dans les pools d’agents, sélectionnez le pool d’agents souhaité.

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

      Sélectionnez Agents et choisissez l’agent.

    3. Choisissez l’onglet Fonctionnalités.

      Choisissez l’onglet Fonctionnalités.

      Note

      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.

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

      Sélectionnez le pool souhaité.

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

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

    3. Choisissez l’onglet Fonctionnalités.

      Onglet Capacités de l’agent.

  5. Recherchez la capacité Agent.Version. Vous pouvez comparer cette valeur à la dernière version de l’agent publié sur la page Agent Azure Pipelines .

  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.

Puis-je mettre à jour mes agents qui font partie d’un pool Azure DevOps Server ?

Oui. À compter d’Azure DevOps Server 2019, vous pouvez configurer votre serveur pour rechercher des fichiers de package d’agent sur un disque local. Cette configuration remplace la version par défaut fourni avec le serveur au moment de sa publication. Ce scénario s’applique également quand le serveur n’a pas accès à Internet.

  1. À partir d’un ordinateur disposant d’un accès à Internet, téléchargez la dernière version des fichiers de package de l'agent (sous forme de .zip ou .tar.gz) depuis la page GitHub des versions de l’agent Azure Pipelines.

  2. Transférez les fichiers de package téléchargés vers chaque niveau d’application du serveur Azure DevOps à l’aide d’une méthode de votre choix (par exemple, lecteur USB, transfert réseau, etc.). Placez les fichiers de l’agent sous le dossier %ProgramData%\Microsoft\Azure DevOps\Agents. S’il n’existe aucun dossier étiqueté Agents, créez-en un.

  3. Vous êtes prêt à commencer ! Votre serveur Azure DevOps utilise désormais les fichiers locaux chaque fois que les agents sont mis à jour. Chaque agent est mis à jour automatiquement quand il exécute une tâche nécessitant une version plus récente de l’agent. Toutefois, si vous souhaitez mettre à jour manuellement certains agents, cliquez avec le bouton droit sur le pool, puis choisissez Mettre à jour tous les agents.

Les agents auto-hébergés présentent-ils des avantages en termes de performances par rapport aux agents hébergés par Microsoft ?

Dans de nombreux cas, oui. Si vous utilisez un agent auto-hébergé, vous pouvez exécuter des builds incrémentielles. Par exemple, si vous définissez un pipeline qui ne nettoie pas le référentiel et n'effectue pas de build propre, vos builds s'exécutent généralement plus rapidement. Vous n’obtenez pas ces avantages avec un agent hébergé par Microsoft, sauf si vous utilisez des fonctionnalités telles que la mise en cache, car l’agent est détruit une fois le pipeline terminé.

Un agent hébergé par Microsoft peut prendre plus de temps pour démarrer votre build. Bien qu’il suffit souvent de quelques secondes pour que votre travail soit affecté à un agent hébergé par Microsoft, il peut parfois prendre plusieurs minutes pour qu’un agent soit alloué, en fonction de la charge sur notre système.

Puis-je installer plusieurs agents auto-hébergés sur la même machine ?

Oui. Cette approche peut fonctionner correctement pour les agents qui exécutent des travaux qui n’utilisent pas de nombreuses ressources partagées. Par exemple, vous pouvez l’essayer pour les agents qui exécutent des versions qui orchestrent principalement des déploiements et ne font pas grand-chose sur l’agent lui-même.

Dans les autres cas, vous pouvez constater que l’exécution de plusieurs agents sur la même machine n’améliore pas sensiblement l’efficacité. Par exemple, il peut ne pas être utile pour les agents qui exécutent des builds qui consomment beaucoup d’espace disque et de ressources d’entrée/sortie.

Vous pouvez également rencontrer des problèmes si des travaux de génération parallèle utilisent le même déploiement d’outils singleton (par exemple, les packages npm). Une build peut mettre à jour une dépendance alors qu’une autre build l’utilise, ce qui peut entraîner des résultats et des erreurs non fiables.

Que font les agents quand des travaux de pipeline sont annulés ?

Pour les agents hébergés par Microsoft, l’agent est détruit et renvoyé au pool Azure Pipelines.

Pour les agents auto-hébergés :

  • Lorsqu’un pipeline est annulé, l’agent envoie une séquence de commandes au processus qui exécute l’étape actuelle.
  • La première commande est envoyée avec un délai d’expiration de 7,5 secondes.
  • Si le processus ne se termine pas, une deuxième commande est envoyée avec un délai d’expiration de 2,5 secondes.
  • Si le processus ne se termine pas, l'agent ordonne sa destruction.
  • Si le processus ignore les deux premières requêtes d'arrêt, il est tué de force.

La durée de la demande initiale d’arrêt est d’environ 10 secondes.

Les commandes émises au processus pour annuler le pipeline diffèrent en fonction du système d’exploitation de l’agent :

  • macOS et Linux : les commandes envoyées sont SIGINT, suivies par SIGTERM, suivies par SIGKILL.
  • Windows : les commandes envoyées au processus sont Ctrl+C, suivies par Ctrl+Break, suivies par Process.Kill.

Procédure pour déclencher des mises à jour de l’agent programmatiquement pour un pool d’agents spécifique

Vous pouvez déclencher des mises à jour de l’agent pour le pool en tirant parti de l’API suivante :

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

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

Note

Pour plus d’informations, consultez API et mappage de version d’Azure DevOps Server.

Paramètres d’URI

Nom Entrée Obligatoire Type Description
agentId requête False chaîne Agent à mettre à jour. S’il n’est pas spécifié, une mise à jour est déclenchée pour tous les agents.
organization path True chaîne Nom de l’organisation Azure DevOps.
poolId path True entier int32 Pool d’agents à utiliser.
api-version requête False chaîne Version de l’API à utiliser. Pour utiliser cette version de l’API, la valeur doit être définie sur 6.0.

Pour déclencher une mise à jour de l’agent, le corps de la requête doit être vide.

L’agent Azure Pipelines est open source sur GitHub.

Contenu connexe

Pour plus d’informations sur les agents, consultez les modules suivants du parcours de formation Créer des applications avec Azure DevOps :

  • Last updated on