Partager via

Résoudre les problèmes liés aux pools DevOps managés

Cet article fournit des solutions aux problèmes courants liés aux pools DevOps managés.

Erreurs de création de pool

Code d'erreur Descriptif
PoolProvisioningFailed Échec de création de pool en raison des autorisations de l’organisation Azure DevOps
UnauthorizedAccessToVirtualNetwork Échec de création de pool en raison des autorisations de réseau virtuel

Échec de création de pool en raison des autorisations de l’organisation Azure DevOps

La création du pool échoue avec une erreur similaire à celle des messages d’erreur suivants.

L’utilisateur connecté n’a pas été trouvé dans l’organisation Azure DevOps

  • Validation failure "PoolProvisioningFailed": "Failed to provision agent pool. Exception: The logged in user, <your user>, was not found in the Azure DevOps organization provided, <your Azure DevOps organization>."

Pour résoudre le problème :

L’utilisateur connecté ne dispose pas des autorisations Gérer dans l’organisation Azure DevOps

  • Validation failure "PoolProvisioningFailed": "Failed to provision agent pool. Exception: The logged in user, <your user>, does not have Manage permissions in the Azure DevOps organization provided, <your Azure DevOps organization>."

Pour résoudre le problème :

Échec de création de pool en raison des autorisations de réseau virtuel

La création du pool échoue avec une UnauthorizedAccessToVirtualNetwork erreur similaire à l’erreur suivante : Validation failure "UnauthorizedAccessToVirtualNetwork": "DevOpsInfrastructure service principal does not have Read access to virtual network <your VNet> in resource group <your resource group>. Give Reader and Network Contributor access to DevOpsInfrastructure service principal and try again..

Pour résoudre ce problème :

Retards dans le démarrage du pipeline

Lorsque vous utilisez des pools DevOps managés, vous pouvez rencontrer des situations où il existe un long délai avant qu’un pipeline ne commence à s’exécuter une fois qu’il est déclenché. Cette section du guide de résolution des problèmes décrit les éléments courants qui peuvent avoir un impact sur les performances de vos pools. Pour plus d’informations, consultez Gérer les coûts et les performances.

Vérifier les tâches parallèles insuffisantes

Les agents de pools DevOps managés sont considérés comme des agents auto-hébergés par Azure DevOps et nécessitent des travaux parallèles auto-hébergés à exécuter. Par exemple, si le nombre parallèle auto-hébergé de votre organisation est égal à 10, votre organisation ne peut exécuter que 10 travaux de pipeline auto-hébergés simultanément. Si plus de 10 pipelines sont mis en file d'attente, seuls 10 à la fois peuvent être exécutés.

Vérifiez le nombre de tâches parallèles auto-hébergées pour vous assurer que vous disposez d'une capacité suffisante pour satisfaire aux besoins simultanés de votre charge de travail en matière de pipelines. Pour plus d’informations, consultez Configurer et payer des travaux parallèles.

Vérifier la configuration maximale des agents

Le paramètre Nombre maximal d’agents configure le nombre maximal d’agents en cours d’exécution dans votre pool DevOps managé. Si le paramètre Nombre maximal d’agents est 5, les pools DevOps managés peuvent exécuter un maximum de cinq pipelines simultanés. Si plus de cinq pipelines sont mis en file d’attente, les pipelines supplémentaires ne démarreront pas tant qu'un des cinq agents disponibles n'est pas libre.

Remarque

Les agents maximum configurent le nombre maximal d’agents pouvant être provisionnés en même temps, mais le nombre de travaux parallèles auto-hébergés de votre organisation spécifie le nombre de travaux pouvant s’exécuter simultanément. Vérifiez que vous disposez de suffisamment de travaux parallèles auto-hébergés dans votre organisation pour permettre à vos agents d’exécuter des travaux. Pour plus d’informations, consultez la tarification des travaux parallèles Azure DevOps Services.

Envisagez de préprovisionner des agents en utilisant un calendrier d'agents de réserve

Si le mode de l’agent de veille est désactivé, les agents des pools DevOps gérés sont démarrés à la demande lorsqu’un pipeline est mis en file d’attente, et bien qu’un nouvel agent ne prenne généralement que quelques instants pour démarrer, il peut parfois prendre jusqu’à 15 minutes.

Lorsque le mode de l’agent de secours est activé, vous pouvez spécifier une planification et un nombre d’agents pour rester prêts à répondre aux demandes de votre charge de travail.

Pour plus d’informations, consultez Gérer les coûts et les performances - Préprovisionnement avec des agents de secours.

Mode de secours automatique pour les nouveaux pools

La gestion des pools DevOps utilise des données historiques sur l'utilisation des pools pour aider à prévoir les besoins de mise à l’échelle en activant automatiquement le mode de veille. Les nouveaux pools n’ont pas de données historiques. Les agents peuvent donc être créés à la demande. Pour améliorer les performances, vous pouvez basculer vers le mode de secours manuel pour le premier mois et basculer vers le mode de secours automatique une fois que les pools DevOps gérés ont eu le temps d’observer l’utilisation de votre pool.

Vérifiez le pourcentage d’agents de veille si vous utilisez des agents de veille avec plusieurs images

Si vous utilisez des agents de secours avec plusieurs images, vérifiez l’historique d’utilisation par image et comparez-le au paramètre de pourcentage de l’agent de secours de vos images pour vous assurer que votre ratio de secours correspond à votre utilisation. Par exemple, si vous avez une image Windows et une image Ubuntu, et que votre charge de travail utilise windows 75% de temps, vérifiez que votre image Windows est configurée avec un pourcentage d’agent de secours de 75.

Envisagez d’utiliser des pools d'état avec un délai de grâce pour maintenir les agents en ligne.

Une option pour améliorer les performances des agents sans utiliser d'agents en attente consiste à utiliser des agents à états avec une courte période de grâce. Lorsqu'un agent d'état disposant d'une période de grâce effectue un travail, il reste en ligne pendant la durée spécifiée par cette période de grâce et attend des travaux supplémentaires. Si votre charge de travail est en rafales, vous pouvez configurer une période de grâce qui maintient les agents en ligne lorsque les travaux sont stables et les démarre à partir de zéro pendant des périodes plus lentes.

Pour plus d’informations, consultez les agents de veille et les pools à état conservé.

Vérifier les codes d’erreur de délai d’attente

Si votre affectation d’agent expire, vous pouvez vérifier le code d’erreur dans la section Codes d’erreur de la page Vue d’ensemble .

Échec de la réussite du pipeline

Vérifier s’il y a eu une mise à jour d’image

Si vos pipelines commencent à échouer après une mise à jour d’image, vous pouvez configurer temporairement vos pipelines pour utiliser la version précédente de l’image. Vous pouvez configurer vos pipelines défaillants pour utiliser la version d’image précédente par pipeline, ou vous pouvez configurer la version d’image précédente pour tous les pipelines de votre pool DevOps managé qui utilisent cette image.

Pour déterminer si vos pipelines échouent en raison d’une modification de version d’image, comparez la version de l’image sur une exécution de pipeline ayant échoué avec la version de l’image à partir de la dernière exécution réussie du pipeline.

  1. Accédez à votre pipeline et consultez l’historique des exécutions de celui-ci.

    Capture d’écran des exécutions de pipeline.

  2. Affichez les détails de l’exécution pour les deux exécutions de pipeline que vous souhaitez comparer, puis choisissez la tâche de pipeline pour afficher les informations de diagnostic concernant cette tâche. Si votre pipeline a plusieurs travaux, choisissez le travail qui s’exécute à l’aide de votre pool DevOps managé.

    Capture d’écran des détails de l’exécution du pipeline.

  3. Choisissez Initialiser le travail et récupérez la version de l’image dans la section Version de l’image actuelle .

    Capture d’écran de la version de l’image d’exécution du pipeline.

Si les versions d’image sont différentes de l’exécution récente du pipeline ayant échoué et de la dernière exécution réussie, l’échec peut être dû à une mise à jour d’image. Vous avez deux choix pour revenir temporairement à la version précédente de l’image pendant que vous résolvez la cause racine.

  • Pour exécuter uniquement le pipeline défaillant à l’aide de la version d’image précédente, ajoutez une ImageVersionOverride demande à votre pipeline pour spécifier la version précédente. Pour plus d’informations, consultez ImageVersionOverride.
  • Pour mettre à jour les paramètres du pool afin que tous les pipelines utilisant l’image s’exécutent à l’aide de la version précédente, mettez à jour vos paramètres d’image et spécifiez la version souhaitée.

Les pools DevOps managés conservent les 20 dernières images disponibles pour les images de la Place de marché sélectionnées et les 10 dernières images disponibles pour les images Azure Pipelines. Les versions antérieures des images Azure Compute Gallery sont gérées par les propriétaires de ces Azure Compute Galleries.

Voir aussi

  • Last updated on