Agents hébergés par Microsoft
Azure DevOps Services
Les agents hébergés par Microsoft sont disponibles uniquement avec Azure DevOps Services, qui est hébergé dans le cloud. Vous ne pouvez pas utiliser les agents hébergés par Microsoft ou le pool d’agents Azure Pipelines avec les instances locales de TFS ou Azure DevOps Server. Avec ces versions locales, vous devez utiliser des agents auto-hébergés.
Important
Sélectionnez la version de cet article qui correspond à votre plateforme et à votre version. Le sélecteur de version se trouve au-dessus de la table des matières. Recherchez votre plateforme et votre version Azure DevOps.
Si vos pipelines se trouvent dans Azure Pipelines, vous disposez d’une option pratique pour exécuter vos tâches à l’aide d’un agent hébergé par Microsoft. Avec les agents hébergés par Microsoft, la maintenance et les mises à niveau sont effectuées pour vous. Vous obtenez toujours 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 abandonnée après un travail (ce qui signifie que toute modification apportée par un travail au système de fichiers de machine virtuelle, comme l’extraction du code, n’est pas disponible pour le 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, il s’agit du moyen le plus simple d’exécuter les travaux. Vous pouvez essayer cette méthode en premier pour voir si elle est adaptée à vos besoins de génération et de déploiement. Si ce n’est pas le cas, vous pouvez utiliser des agents de groupe identique ou un agent auto-hébergé.
Conseil
Vous pouvez essayer gratuitement un agent hébergé par Microsoft.
Logiciel
Le pool d’agents Azure Pipelines propose plusieurs images de machine virtuelle, chacune incluant un large éventail d’outils et de logiciels.
Image | Spécification de l’agent de l’éditeur classique | Étiquette d’image de machine virtuelle YAML | Logiciels inclus |
---|---|---|---|
Windows Server 2022 avec Visual Studio 2022 | windows-2022 | windows-latest OU windows-2022 |
Lien |
Windows Server 2019 avec Visual Studio 2019 | windows-2019 | windows-2019 |
Lien |
Ubuntu 24.04 | ubuntu-24.04 | ubuntu-24.04 |
Lien |
Ubuntu 22.04 | ubuntu-22.04 | ubuntu-latest OU ubuntu-22.04 |
Lien |
Ubuntu 20.04 | ubuntu-20.04 | ubuntu-20.04 |
Lien |
macOS 14 Sonoma | macOS-14 | macOS-latest OU macOS-14 |
Lien |
macOS 13 Ventura | macOS-13 | macOS-13 |
Lien |
macOS 12 Monterey | macOS-12 | macOS-12 |
déconseillé |
L’image d’agent par défaut pour les pipelines de build classiques est windows-2019, et l’image d’agent par défaut pour les pipelines de build YAML est ubuntu-latest
. Pour plus d’informations, consultez Désigner un pool dans votre pipeline.
Vous pouvez voir les logiciels installés pour chaque agent hébergé en choisissant le lien Logiciels inclus dans le tableau. Lorsque vous utilisez des images macOS, vous pouvez sélectionner manuellement parmi les versions de l’outil. En savoir plus.
Mises à jour récentes
- L'image macOS-12 Monterey est dépréciée et sera mise hors service le 3 décembre 2024.
- L'image Ubuntu-22.04 est disponible
- L’image macOS 14 Sonoma est disponible en préversion
- L'image macOS-11 Big Sur est déconseillée et sera supprimée le 28 juin 2024.
- Tous les agents hébergés par Microsoft commenceront à utiliser PowerShell 7.2 LTS vers PowerShell 7.4 LTS à compter du 28 janvier. Pour plus d’informations, y compris des changements importants potentiels, consultez Les agents hébergés par Microsoft utilisent PowerShell 7.4.
- Mise à la disposition générale de l’image de macOS 13
- L’image macOS 10.15 n’est pas entièrement prise en charge à compter du 24/04/2023
- Ubuntu 18.04 a été mis hors service
- Les images
ubuntu-latest
utilisentubuntu-22.04
. - Disponibilité générale d’Ubuntu 22.04 pour les pools hébergés Azure Pipelines.
- L’image Ubuntu 18.04 commencera à être déconseillée le 8/8/2022 et sera entièrement non prise en charge à compter du 1/4/2023.
- L’image macOS 10.15 commencera à être déconseillée le 31/5/2022 et sera entièrement non prise en charge à compter du 1/12/2022.
- Les images
windows-latest
utilisentwindows-2022
. - Les images
macOS-latest
utilisentmacOS-11
. - L’image hébergée Ubuntu 16.04 a été supprimée en septembre 2021.
- L’image Windows Server 2016 avec Visual Studio 2017 a été dépréciée et sera mise hors service le 30 juin 2022. Lisez ce billet de blog sur l’identification des pipelines avec des images dépréciées.
- En décembre 2021, nous avons supprimé l’image hébergée Azure Pipelines suivante :
- macOS X Mojave 10.14 (
macOS-10.14
)
- macOS X Mojave 10.14 (
- En mars 2020, nous avons supprimé les images hébergées Azure Pipelines suivantes :
- Windows Server 2012 R2 avec Visual Studio 2015 (
vs2015-win2012r2
) - macOS X High Sierra 10.13 (
macOS-10.13
) - Windows Server Core 1803 (
win1803
)
- Windows Server 2012 R2 avec Visual Studio 2015 (
Les clients sont encouragés à migrer vers des versions plus récentes ou un agent auto-hébergé.
Pour plus d’informations et pour obtenir des instructions sur la mise à jour de vos pipelines qui utilisent ces images, consultez Suppression d’images plus anciennes dans les pools hébergés Azure Pipelines.
Remarque
La capacité de macOS est actuellement limitée. Contrairement aux images Linux et Windows, où notre capacité est limitée par la capacité maximale d’Azure, la capacité macOS est limitée par la quantité de matériel disponible. Bien que nous travaillons à mettre à disposition une capacité supplémentaire au cours du printemps 2024, certains travaux peuvent subir un retard d’exécution. Dans la mesure du possible, par exemple pour les travaux qui ne créent pas d’applications de l’écosystème Apple, les clients doivent opter pour des images Linux ou Windows.
Remarque
Le pool hébergé Azure Pipelines remplace les pools hébergés précédents qui avaient des noms mappés aux images correspondantes. Tous les travaux que vous aviez dans les pools hébergés précédents sont automatiquement redirigés vers l’image correcte dans le nouveau pool hébergé Azure Pipelines. Dans certains cas, vous pouvez toujours voir les anciens noms de pool, mais en arrière-plan, les travaux hébergés sont exécutés à l’aide du pool Azure Pipelines. Pour plus d’informations sur cette mise à jour, consultez les notes de publication du Pool hébergé unique des Notes de publication du 1er juillet 2019 - Sprint 154.
Important
Pour demander l’installation de logiciels supplémentaires sur des agents hébergés par Microsoft, ne créez pas de demande de commentaires sur ce document ou n’ouvrez pas de ticket de support. Au lieu de cela, ouvrez un problème dans notre référentiel, où nous gérons les scripts pour générer diverses images.
Comment identifier des pipelines à l’aide d’une image hébergée déconseillée
Pour identifier les pipelines qui utilisent une image déconseillée, accédez à l’emplacement suivant dans votre organisation : https://dev.azure.com/{organization}/{project}/_settings/agentqueues
, et filtrez le nom de l’image à vérifier. L’exemple suivant vérifie l’image vs2017-win2016
.
Vous pouvez également interroger l’historique des travaux pour les images dépréciées dans les projets à l’aide du script qui se trouve ici, comme illustré dans l’exemple suivant.
./QueryJobHistoryForRetiredImages.ps1 -accountUrl https://dev.azure.com/{org} -pat {pat}
Utiliser un agent hébergé par Microsoft
Dans les pipelines YAML, si vous ne spécifiez pas de pool, les pipelines sont par défaut le pool d’agents Azure Pipelines. Vous devez simplement spécifier l’image de machine virtuelle que vous souhaitez utiliser.
jobs:
- job: Linux
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo hello from Linux
- job: macOS
pool:
vmImage: 'macOS-latest'
steps:
- script: echo hello from macOS
- job: Windows
pool:
vmImage: 'windows-latest'
steps:
- script: echo hello from Windows
Notes
La spécification d’un pool peut être effectuée à plusieurs niveaux dans un fichier YAML. Si vous remarquez que votre pipeline n’est pas en cours d’exécution sur l’image attendue, veillez à vérifier la spécification du pool au niveau du pipeline, de la phase et du travail.
Éviter les références codées en dur
Lorsque vous utilisez un agent hébergé par Microsoft, utilisez toujours des variables pour faire référence à l’environnement de build et aux ressources de l’agent. Par exemple, ne codez pas en dur la lettre de lecteur ou le dossier qui contient le référentiel. La disposition précise des agents hébergés est susceptible d’être modifiée sans avertissement.
Matériel
Les agents hébergés par Microsoft qui exécutent des images Windows et Linux sont provisionnés sur des machines virtuelles à usage général Azure avec un processeur de 2 cœurs, 7 Go de RAM et 14 Go d’espace disque SSD. Ces machines virtuelles sont colocalisées dans la même zone géographique que votre organisation Azure DevOps.
Les agents qui exécutent des images macOS sont provisionnés sur les Mac pros avec un processeur de 3 cœurs, 14 Go de RAM et 14 Go d’espace disque SSD. Ces agents s’exécutent toujours aux États-Unis, quel que soit l’emplacement de votre organisation Azure DevOps. Si la souveraineté des données est importante pour vous et si votre organisation n’est pas aux États-Unis, vous ne devez pas utiliser d’images macOS. Plus d’informations
Toutes ces machines disposent d’au moins 10 Go d’espace disque disponible pour l’exécution de vos pipelines. Cet espace libre est consommé lorsque votre pipeline extrait le code source, télécharge des packages, extrait des images Docker ou génère des fichiers intermédiaires.
Important
Nous ne pouvons pas honorer les demandes d’augmentation de l’espace disque sur les agents hébergés par Microsoft ou de provisionnement de machines plus puissantes. Si les spécifications des agents hébergés par Microsoft ne répondent pas à vos besoins, vous devez envisager des agents auto-hébergés ou des agents de groupe identique.
Mise en réseau
Dans certaines configurations, vous devrez peut-être connaître la plage d’adresses IP où les agents sont déployés. Par exemple, si vous devez accorder l’accès aux agents hébergés via un pare-feu, vous pouvez restreindre cet accès par adresse IP. Étant donné qu’Azure DevOps utilise le réseau global Azure, les plages d’adresses IP varient au fil du temps. Microsoft publie un fichier JSON hebdomadaire répertoriant les plages d’adresses IP pour les centres de données Azure, réparties par région. Ce fichier est mis à jour chaque semaine avec de nouvelles plages d’adresses IP planifiées. Seule la dernière version du fichier est disponible en téléchargement. Si vous avez besoin de versions précédentes, vous devez les télécharger et les archiver chaque semaine à mesure qu’elles deviennent disponibles. Les nouvelles plages d’adresses IP prennent effet la semaine suivante. Nous vous recommandons de revenir fréquemment (au moins une fois par semaine) pour vous assurer que vous conservez une liste à jour. Si les travaux de l’agent commencent à échouer, une première étape clé de résolution des problèmes consiste à vérifier que votre configuration correspond à la dernière liste d’adresses IP. Les plages d’adresses IP pour les agents hébergés sont répertoriées dans le fichier hebdomadaire sous AzureCloud.<region>
, par exemple AzureCloud.westus
pour la région USA Ouest.
Vos agents hébergés s’exécutent dans la même zone géographique Azure que votre organisation. Chaque zone géographique contient une ou plusieurs régions. Même si votre agent peut s’exécuter dans la même région que votre organisation, il n’est pas garanti qu’il le fasse. Pour obtenir la liste complète des plages d’adresses IP possibles pour votre agent, vous devez utiliser les plages d’adresses IP de toutes les régions contenues dans votre zone géographique. Par exemple, si votre organisation se trouve dans la zone géographique États-Unis, vous devez utiliser les plages d’adresses IP pour toutes les régions de cette zone géographique.
Pour déterminer votre zone géographique, accédez à https://dev.azure.com/<your_organization>/_settings/organizationOverview
, récupérez votre région et recherchez la zone géographique associée à partir du tableau Zones géographiques Azure. Une fois que vous avez identifié votre zone géographique, utilisez les plages d’adresses IP du fichier hebdomadaire pour toutes les régions de cette zone géographique.
Important
Vous ne pouvez pas utiliser de connexions privées, comme ExpressRoute ou VPN pour connecter des agents hébergés par Microsoft à votre réseau d’entreprise. Le trafic entre les agents hébergés par Microsoft et vos serveurs se fera sur le réseau public.
Pour identifier les plages d’adresses IP possibles pour les agents hébergés par Microsoft
- Identifiez la région de votre organisation dans les paramètres de l’organisation.
- Identifiez la zone géographique Azure pour la région de votre organisation.
- Mappez les noms des régions de votre zone géographique au format utilisé dans le fichier hebdomadaire, en suivant le format
AzureCloud.<region>
, commeAzureCloud.westus
. Vous pouvez mapper les noms des régions à partir de la liste Zone géographique Azure au format utilisé dans le fichier hebdomadaire en vérifiant les noms des régions transmis au constructeur des régions définies dans le code source de la classe Region, à partir des bibliothèques de gestion Azure pour .NET.Notes
Étant donné qu’il n’existe aucune API dans les bibliothèques de gestion Azure pour .NET pour répertorier les régions d’une zone géographique, vous devez les répertorier manuellement, comme indiqué dans l’exemple suivant.
- Récupérez les adresses IP de toutes les régions dans votre zone géographique à partir du fichier hebdomadaire. Si votre région est Brésil Sud ou Europe Ouest, vous devez inclure des plages d’adresses IP supplémentaires en fonction de votre zone géographique de secours, comme décrit dans la note suivante.
Notes
En raison de restrictions de capacité, certaines organisations dans les régions Brésil Sud ou Europe Ouest peuvent occasionnellement voir leurs agents hébergés situés en dehors de leur zone géographique attendue. Dans ce cas, en plus d’inclure les plages d’adresses IP pour toutes les régions de votre zone géographique, comme décrit dans la section précédente, des plages d’adresses IP supplémentaires doivent être incluses pour les régions dans la zone géographique de secours de capacité.
Si votre organisation se trouve dans la région Brésil Sud, votre zone géographique de secours de capacité est États-Unis.
Si votre organisation se trouve dans la région Europe Ouest, la zone géographique de secours de capacité est France.
Nos plages d’adresses IP Mac ne sont pas incluses dans les adresses IP Azure ci-dessus, car elles sont hébergées dans le cloud macOS de GitHub. Les plages d’adresses IP peuvent être récupérées avec l’API de métadonnées GitHub en suivant les instructions fournies ici.
Exemple
Dans l’exemple suivant, les plages d’adresses IP de l’agent hébergé pour une organisation dans la région USA Ouest sont récupérées à partir du fichier hebdomadaire. Étant donné que la région USA Ouest se trouve dans la zone géographique États-Unis, les adresses IP de toutes les régions de la zone géographique États-Unis sont incluses. Dans cet exemple, les adresses IP sont écrites dans la console.
using Newtonsoft.Json.Linq;
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
namespace WeeklyFileIPRanges
{
class Program
{
// Path to the locally saved weekly file
const string weeklyFilePath = @"C:\MyPath\ServiceTags_Public_20230904.json";
static void Main(string[] args)
{
// United States geography has the following regions:
// Central US, East US, East US 2, East US 3, North Central US,
// South Central US, West Central US, West US, West US 2, West US 3
// This list is accurate as of 9/8/2023
List<string> USGeographyRegions = new List<string>
{
"centralus",
"eastus",
"eastus2",
"eastus3",
"northcentralus",
"southcentralus",
"westcentralus",
"westus",
"westus2",
"westus3"
};
// Load the weekly file
JObject weeklyFile = JObject.Parse(File.ReadAllText(weeklyFilePath));
JArray values = (JArray)weeklyFile["values"];
foreach (string region in USGeographyRegions)
{
string tag = $"AzureCloud.{region}";
Console.WriteLine(tag);
var ipList =
from v in values
where tag.Equals((string)v["name"], StringComparison.OrdinalIgnoreCase)
select v["properties"]["addressPrefixes"];
foreach (var ip in ipList.Children())
{
Console.WriteLine(ip);
}
}
}
}
}
Balises de service
Les agents hébergés par Microsoft ne peuvent pas être répertoriés par étiquettes de service. Si vous essayez d’accorder aux agents hébergés l’accès à vos ressources, vous devez suivre la méthode de référencement des plages d’adresses IP autorisées.
Sécurité
Les agents hébergés par Microsoft s’exécutent sur une plateforme Azure sécurisée. Toutefois, vous devez connaître les considérations de sécurité suivantes.
- Bien que les agents hébergés par Microsoft s’exécutent sur un réseau public Azure, ils ne se voient pas attribuer d’adresses IP publiques. Par conséquent, les entités externes ne peuvent pas cibler les agents hébergés par Microsoft.
- Les agents hébergés par Microsoft sont exécutés sur des machines virtuelles individuelles, qui sont réimagées après chaque exécution. Chaque agent est dédié à une seule organisation, et chaque machine virtuelle héberge uniquement un seul agent.
- L’exécution de votre pipeline sur des agents hébergés par Microsoft présente plusieurs avantages du point de vue de la sécurité. Si vous exécutez du code non approuvé dans votre pipeline, par exemple des contributions à partir de duplications, il est plus sûr d’exécuter le pipeline sur des agents hébergés par Microsoft que sur des agents auto-hébergés qui résident dans votre réseau d’entreprise.
- Lorsqu’un pipeline doit accéder à vos ressources d’entreprise derrière un pare-feu, vous devez autoriser la plage d’adresses IP pour la zone géographique Azure. Cela peut augmenter votre exposition, car la plage d’adresses IP est assez grande et les machines de cette plage peuvent également appartenir à d’autres clients. La meilleure façon d’éviter cela consiste à éviter d’avoir à accéder aux ressources internes. Pour plus d’informations sur le déploiement d’artefacts sur un ensemble de serveurs, consultez Communication à déployer sur des serveurs cibles.
- Les images hébergées ne sont pas conformes aux benchmarks de renforcement CIS. Pour utiliser des images renforcées CIS, vous devez créer des agents auto-hébergés ou des agents de groupe identique.
Capacités et limitations
Agents hébergés par Microsoft :
- Utilisez le logiciel ci-dessus. Vous pouvez également ajouter des logiciels pendant votre build ou mise en production à l’aide de tâches du programme d’installation de l’outil.
- Vous obtenez un agent fraîchement imagé pour chaque travail dans votre pipeline.
- Fournissez 10 Go de stockage pour vos sorties source et build.
- Fournissez un niveau gratuit :
- Projet public : 10 travaux parallèles gratuits hébergés par Microsoft qui peuvent s’exécuter jusqu’à 360 minutes (6 heures) à chaque fois sans limite de temps globale par mois. Contactez-nous pour augmenter vos limites de niveau gratuit.
- Projet privé : Un travail parallèle gratuit pouvant s’exécuter pendant un maximum de 60 minutes chaque fois, jusqu’à ce que vous ayez utilisé 1 800 minutes (30 heures) par mois. Vous pouvez payer pour profiter d’une capacité supplémentaire par travail parallèle. Les travaux parallèles payants suppriment la limite de temps mensuelle et vous permettent d’exécuter chaque travail pendant un maximum de 360 minutes (6 heures). Achetez des travaux parallèles hébergés par Microsoft.
- Lorsque vous créez une organisation Azure DevOps, vous ne recevez pas ces subventions gratuites par défaut. Pour demander la subvention gratuite pour des projets publics ou privés, envoyez une demande.
- Exécutez sur des machines virtuelles à usage général Microsoft Azure Standard_DS2_v2.
- Exécutez en tant qu’administrateur sur Windows et utilisateur sudo sans mot de passe sur Linux.
- (Linux uniquement) Exécutez des étapes dans un
cgroup
qui offre 6 Go de mémoire physique et 13 Go de mémoire totale. - Utilisez des images de machine virtuelle régulièrement mises à jour (toutes les 3 semaines).
Les agents hébergés par Microsoft n’offrent pas :
- La possibilité de se connecter à distance.
- La possibilité de supprimer des artefacts vers un partage de fichiers UNC.
- La possibilité de joindre des machines directement à votre réseau d’entreprise.
- La possibilité d’obtenir des machines de build plus grandes ou plus puissantes.
- Possibilité de précharger des logiciels personnalisés. Vous pouvez installer des logiciels pendant l’exécution d’un pipeline, par exemple via des tâches du programme d’installation de l’outil ou dans un script.
- Des avantages potentiels en matière de performances que vous pourriez obtenir avec des agents auto-hébergés qui peuvent démarrer et exécuter des builds plus rapidement. En savoir plus
- Possibilité d’exécuter des builds XAML.
- La possibilité de restaurer une version précédente de l’image de machine virtuelle. Vous utilisez toujours la dernière version.
Si les agents hébergés par Microsoft ne répondent pas à vos besoins, vous pouvez alors déployer vos propres agents auto-hébergés, utiliser des agents de groupe de machines virtuelles ou des agents de pools DevOps managés.
Forum aux questions
Comment puis-je voir quels logiciels sont inclus dans une image ?
Vous pouvez voir les logiciels installés pour chaque agent hébergé en choisissant le lien Logiciels inclus dans le tableau Logiciels.
Notes
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 une variable de pipeline nommée
System.PreferGitFromPath
surtrue
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 Microsoft choisit-il les logiciels et les versions à mettre sur l’image ?
Pour plus d’informations sur les versions des logiciels inclus dans les images, consultez Recommandations pour les éléments installés.
Quand les images sont-elles mises à jour ?
Les images sont généralement mises à jour chaque semaine. Vous pouvez vérifier les badges d’état qui sont au format 20200113.x
, où la première partie indique la date à laquelle l’image a été mise à jour.
Que puis-je faire si le logiciel dont j’ai besoin est supprimé ou remplacé par une version plus récente ?
Vous pouvez nous en informer en signalant un problème GitHub en choisissant les liens Logiciels inclus dans le tableau Utiliser un agent hébergé par Microsoft.
Vous pouvez également utiliser un agent auto-hébergé qui inclut les versions exactes des logiciels dont vous avez besoin. Pour plus d’informations, consultez Agents auto-hébergés.
Que se passe-t-il si j’ai besoin d’une machine plus grande avec plus de puissance de traitement, de mémoire ou d’espace disque ?
Nous ne pouvons pas augmenter la mémoire, la puissance de traitement ou l’espace disque pour les agents hébergés par Microsoft, mais vous pouvez utiliser des agents auto-hébergés ou des agents de groupe identique hébergés sur des machines avec les spécifications souhaitées.
Je ne peux pas sélectionner un agent hébergé par Microsoft et je ne peux pas mettre en file d’attente ma build ou mon déploiement. Que dois-je faire ?
Les agents hébergés par Microsoft sont disponibles uniquement dans Azure Pipelines et non dans TFS ou Azure DevOps Server.
Par défaut, tous les contributeurs de projet d’une organisation ont accès aux agents hébergés par Microsoft. Toutefois, votre administrateur d’organisation peut limiter l’accès des agents hébergés par Microsoft pour sélectionner des utilisateurs ou des projets. Demandez au propriétaire de votre organisation Azure DevOps de vous accorder l’autorisation d’utiliser un agent hébergé par Microsoft. Consultez Sécurité du pool d’agents.
Mes pipelines s’exécutant sur des agents hébergés par Microsoft prennent plus de temps. Comment puis-je les accélérer ?
Si votre pipeline est récemment devenu plus lent, consultez notre page d’état pour toute panne. Nous pouvons avoir des problèmes avec notre service. Sinon, passez en revue les modifications que vous avez apportées au code ou au pipeline de votre application. La taille de votre référentiel pendant l’extraction peut avoir augmenté, vous chargez peut-être des artefacts plus volumineux ou vous exécutez peut-être d’autres tests.
Si vous configurez simplement un pipeline et que vous comparez les performances des agents hébergés par Microsoft à votre ordinateur local ou à un agent auto-hébergé, notez les spécifications du matériel que nous utilisons pour exécuter vos travaux. Nous ne sommes pas en mesure de vous fournir des machines plus grandes ou puissantes. Vous pouvez envisager d’utiliser des agents auto-hébergés ou des agents de groupe identique si ces performances ne sont pas acceptables.
J’ai besoin de plus d’agents. Que puis-je faire ?
Toutes les organisations Azure DevOps bénéficient de plusieurs travaux parallèles gratuits pour les projets open source, d’un travail parallèle gratuit et de minutes limitées chaque mois pour les projets privés. Si vous avez besoin de minutes ou de travaux parallèles supplémentaires pour votre projet open source, contactez le support technique. Si vous avez besoin de minutes ou de travaux parallèles supplémentaires pour votre projet privé, vous pouvez en acheter plus.
Mon pipeline fonctionne sur les agents auto-hébergés, mais échoue sur les agents hébergés par Microsoft. Que dois-je faire ?
Votre agent auto-hébergé dispose probablement de toutes les dépendances appropriées installées, alors que les mêmes dépendances, outils et logiciels ne sont pas installés sur les agents hébergés par Microsoft. Tout d’abord, passez en revue attentivement la liste des logiciels installés sur les agents hébergés par Microsoft en suivant le lien vers les Logiciels inclus dans le tableau ci-dessus. Ensuite, comparez cela avec les logiciels installés sur votre agent auto-hébergé. Dans certains cas, les agents hébergés par Microsoft peuvent avoir les outils dont vous avez besoin (par exemple, Visual Studio), mais tous les composants facultatifs nécessaires peuvent ne pas avoir été installés. Si vous remarquez des différences, vous avez deux options :
Vous pouvez créer un nouveau problème sur le référentiel, où nous suivons les demandes de logiciels supplémentaires. Contacter le support technique ne peut pas vous aider à configurer de nouveaux logiciels sur les agents hébergés par Microsoft.
Vous pouvez utiliser des agents auto-hébergés ou des agents de groupe identique. Avec ces agents, vous contrôlez entièrement les images utilisées pour exécuter vos pipelines.
Ma build réussit sur mon ordinateur local, mais échoue sur les agents hébergés par Microsoft. Que dois-je faire ?
Toutes les dépendances appropriées sont probablement installées sur votre ordinateur local, alors que les mêmes dépendances, outils et logiciels ne sont pas installés sur les agents hébergés par Microsoft. Tout d’abord, passez en revue attentivement la liste des logiciels installés sur les agents hébergés par Microsoft en suivant le lien vers les Logiciels inclus dans le tableau ci-dessus. Ensuite, comparez cela avec les logiciels installés sur votre ordinateur local. Dans certains cas, les agents hébergés par Microsoft peuvent avoir les outils dont vous avez besoin (p. ex. Visual Studio), mais tous les composants facultatifs nécessaires peuvent ne pas avoir été installés. Si vous remarquez des différences, vous avez deux options :
Vous pouvez créer un nouveau problème sur le référentiel, où nous suivons les demandes de logiciels supplémentaires. C’est votre meilleur choix pour installer de nouveaux logiciels. Contacter le support ne vous aidera pas à configurer de nouveaux logiciels sur les agents hébergés par Microsoft.
Vous pouvez utiliser des agents auto-hébergés ou des agents de groupe identique. Avec ces agents, vous contrôlez entièrement les images utilisées pour exécuter vos pipelines.
Mon pipeline échoue avec l’erreur : Il n’y a plus d’espace disponible sur l’appareil.
Les agents hébergés par Microsoft n’ont que 10 Go d’espace disque disponible pour l’exécution de votre travail. Cet espace est consommé lorsque vous consultez le code source, téléchargez des packages, téléchargez des images Docker ou produisez des fichiers intermédiaires. Malheureusement, nous ne pouvons pas augmenter l’espace libre disponible sur les images hébergées par Microsoft. Vous pouvez restructurer votre pipeline pour qu’il puisse tenir dans cet espace. Vous pouvez également envisager d’utiliser des agents auto-hébergés ou des agents de groupe identique.
Mon pipeline s’exécutant sur des agents hébergés par Microsoft nécessite l’accès aux serveurs de notre réseau d’entreprise. Comment obtenir une liste d’adresses IP à autoriser dans notre pare-feu ?
Consultez la section Plages d’adresses IP de l’agent
Notre pipeline s’exécutant sur des agents hébergés par Microsoft ne peut pas résoudre le nom d’un serveur sur notre réseau d’entreprise. Comment pouvons-nous corriger cette erreur ?
Si vous faites référence au serveur par son nom DNS, assurez-vous que votre serveur est accessible publiquement sur Internet via son nom DNS. Si vous faites référence à votre serveur par son adresse IP, assurez-vous que l’adresse IP est accessible publiquement sur Internet. Dans les deux cas, vérifiez que les plages d’adresses IP de l’agent sont autorisées pour tout pare-feu entre les agents et votre réseau d’entreprise.
J’obtiens une erreur d’autorisation IP SAP à partir d’un compte de stockage Azure
Si vous obtenez un code d’erreur SAP, c’est probablement parce que les plages d’adresses IP des agents hébergés par Microsoft ne sont pas autorisées en raison de vos règles de stockage Azure. Il existe quelques solutions de contournement :
- Gérez les règles de réseau IP pour votre compte stockage Azure et ajoutez les plages d’adresses IP pour vos agents hébergés.
- Dans votre pipeline, utilisez Azure CLI pour mettre à jour l’ensemble de règles réseau de votre compte stockage Azure juste avant d’accéder au stockage, puis restaurez l’ensemble de règles précédent.
- Utilisez des agents auto-hébergés ou des agents de groupe identique.
Comment sélectionner manuellement des versions des outils sur l’agent macOS hébergé ?
Xcode
Si vous utilisez la tâche Xcode incluse avec Azure Pipelines et TFS, vous pouvez sélectionner une version de Xcode dans les propriétés de cette tâche. Sinon, pour définir manuellement la version de Xcode à utiliser sur le pool d’agents macOS hébergé, avant votre tâche de build xcodebuild
, exécutez cette ligne de commande dans le cadre de votre build, en remplaçant le numéro de version Xcode 13.2 si nécessaire :
/bin/bash -c "sudo xcode-select -s /Applications/Xcode_13.2.app/Contents/Developer"
Les versions de Xcode sur le pool d’agents macOS hébergé sont disponibles ici pour l’agent macos-12
.
Cette commande ne fonctionne pas pour les applications Xamarin. Pour sélectionner manuellement une version de Xcode pour créer des applications Xamarin, consultez les instructions ci-dessus.
Mono
Pour sélectionner manuellement une version Mono à utiliser sur le pool d’agents macOS hébergés, exécutez ce script dans chaque tâche de votre build avant votre tâche de build Mono, en spécifiant le lien symbolique avec la version Mono requise :
SYMLINK=<symlink>
MONOPREFIX=/Library/Frameworks/Mono.framework/Versions/$SYMLINK
echo "##vso[task.setvariable variable=DYLD_FALLBACK_LIBRARY_PATH;]$MONOPREFIX/lib:/lib:/usr/lib:$DYLD_LIBRARY_FALLBACK_PATH"
echo "##vso[task.setvariable variable=PKG_CONFIG_PATH;]$MONOPREFIX/lib/pkgconfig:$MONOPREFIX/share/pkgconfig:$PKG_CONFIG_PATH"
echo "##vso[task.setvariable variable=PATH;]$MONOPREFIX/bin:$PATH"