Partager via

Configurer la mise à l’échelle

Vous pouvez gérer les performances et le coût de votre instance de pools DevOps managés en configurant les paramètres de mise à l’échelle. Pour en savoir plus sur les tarifs et les performances, consultez la rubrique Gérer les coûts et les performances.

État de l’agent

Vous pouvez configurer des pools comme suit :

  • Sans état : fournir un nouvel agent pour chaque tâche.
  • Stateful : permettre le partage d’agents entre plusieurs processus.

Le paramètre par défaut d’un pool est sans état, que vous pouvez obtenir à l’aide de l’agent Fresh à chaque fois. Dans certains cas, les équipes peuvent souhaiter réutiliser les agents pour réutiliser les packages ou les fichiers créés lors de l’exécution du pipeline précédent. C’est souvent le cas pour les charges de travail de type build, où la conservation de l’état permet de gagner du temps. Grâce aux pools DevOps managés, vous pouvez activer cette réutilisation tout en respectant les bonnes pratiques de sécurité. Un agent peut être réutilisé pendant un maximum de sept jours par défaut, mais vous pouvez le configurer pour être recyclé plus tôt.

Note

Les agents de sécurité recommandent aux utilisateurs d’utiliser des pools sans état comme défense contre les attaques de chaîne d’approvisionnement. Utilisez le paramètre d’état Fresh agent every time.

Pools sans état

Lorsque vous configurez un agent sans état, un nouvel agent est provisionné pour chaque tâche. L’agent est supprimé lorsque la tâche est achevée.

Pour en savoir plus sur le cycle de vie des agents sans état et leur utilisation dans Azure Pipelines, consultez la section Cycle de vie des agents et retards potentiels dans l'allocation.

Capture d’écran montrant un agent sans état.

Lorsque vous définissez l’état de l’agent sur Nouvel agent à chaque fois, un nouvel agent est procuré pour chaque tâche. L’agent est supprimé une fois le travail terminé.

Pools avec état

Capture d’écran montrant un agent avec état.

Lorsque vous activez Un même agent peut servir à plusieurs builds (le paramètre dans les "kind": "stateful" modèles de ressources ou le { "stateful": {...} } paramètre dans Azure CLI), les agents du pool conservent leur état. Vous pouvez configurer des pools avec état à l’aide des paramètres suivants :

  • La durée maximale de vie des agents de secours (maxAgentLifetime) configure la durée maximale pendant laquelle un agent dans un pool avec état peut s’exécuter avant d'être arrêté et supprimé. Le format attendu pour le paramètre Durée de vie maximale des agents en attente est dd.hh:mm:ss. La valeur par défaut du paramètre Durée de vie maximale des agents en attente est définie sur la durée maximale autorisée de sept jours (7.00:00:00).

  • Le délai de grâce (gracePeriodTimeSpan) configure la durée pendant laquelle un agent dans un pool avec état attend l'arrivée de nouvelles tâches avant de se fermer après que toutes les tâches actuelles et en file d'attente soient terminées. Le format attendu pour le paramètre Période de grâce est dd.hh:mm:ss. Par défaut, aucune période de grâce n’est définie.

    Importante

    Si une tâche est en cours d'exécution lorsque la durée maximale de vie des agents de secours expire, les agents ne s'arrêtent pas tant que la tâche n'est pas terminée, sauf si la tâche met plus de deux jours à s'exécuter. Les travaux individuels dans les pools DevOps managés peuvent s’exécuter pendant un maximum de deux jours, même s’ils s’exécutent sur un agent de secours avec plus de deux jours configurés pour la durée de vie maximale des agents de secours. Contactez le support technique si votre flux de travail nécessite l’exécution d’un seul travail qui prend plus de deux jours.

Les agents dans les pools sans état sont arrêtés et supprimés après chaque tâche. Les agents dans les pools avec état continuent à s’exécuter si l’une des conditions suivantes est remplie :

  • Si un autre travail est mis en file d’attente lorsque le premier travail se termine, les pools DevOps managés envoient le travail mis en file d’attente à l’agent qui a exécuté le premier travail au lieu de l’arrêter.
  • S’il existe une période de grâce configurée pour le pool, les agents attendent les nouveaux travaux pendant la durée spécifiée par la période de grâce avant de s’arrêter.
  • Les agents en attente sont activés, et l’image de l’agent correspond aux critères de la période de provisionnement active ; l’agent continue alors à s’exécuter et à attendre d’autres tâches.

Les agents qui s’exécutent dans des pools avec état sont arrêtés et supprimés s’ils s’exécutent en continu pendant la durée de vie maximale spécifiée pour les agents de secours, même si les conditions précédentes sont remplies. Par exemple, si la durée maximale de vie des agents de secours est configurée pendant trois jours et que le mode Agent de secours est défini sur Manuel, All Week Scheme (Machines disponibles 24/7), les agents redémarrent après trois jours de temps d’activité continus.

Importante

Les agents dans les pools avec état peuvent toujours être arrêtés et supprimés après la fin d’un travail s’il n’y a pas de période de grâce, aucune période d’approvisionnement active pour les agents en attente et aucun travail en file d’attente ne correspondant à l’agent. Lorsqu’un agent est supprimé, tout état est perdu.

Les délais de grâce offrent la manière la plus économique de gérer des pools à états pour des pipelines avec une charge cohérente. Les périodes de grâce ne nécessitent pas l’utilisation du mode agent de secours pour maintenir les agents en ligne et prêts à accepter des travaux.

Mode agents en attente

Lorsque vous créez un pool, le mode Agent de secours est désactivé par défaut. Lorsque le mode agent de secours est réglé sur désactivé, il n’existe aucun agent de secours à affecter immédiatement à vos pipelines. Vos pipelines peuvent être obligés d'attendre entre quelques instants et 15 minutes pour qu’un agent soit déployé à la demande. Pour optimiser les performances, activez le mode agents en attente et configurez un planning d’agents en attente qui correspond à la capacité nécessaire pour votre charge de travail.

Lorsque vous configurez une planification d’agent de secours, les pools DevOps managés comparent régulièrement le nombre d’agents provisionnés au nombre d’agents de secours que vous spécifiez dans le schéma d’approvisionnement actuel. Il lance de nouveaux agents si nécessaire pour maintenir le nombre d'agents en attente. Vous pouvez afficher l’état actuel et le nombre d’agents dans votre pool à l’aide du volet Agents .

Importante

Le nombre d’approvisionnement dans un schéma ne peut pas être supérieur à la valeur maximale des agents que vous configurez dans les paramètres du pool.

Vous pouvez configurer le mode agent de secours à l’aide des paramètres suivants :

  • Désactivé : le mode agent en attente est désactivé et les agents sont approvisionnés à la demande quand les tâches sont en file d'attente.
  • Manuel : configurer une planification manuelle de secours.
  • Automatique : utilisez une planification de secours automatique basée sur l’historique d’utilisation de l’agent. Vous pouvez l'optimiser pour réduire les coûts et améliorer les performances.

Capture d’écran montrant les sélections pour le mode agent de secours.

Manuel

Le mode manuel est idéal pour les équipes qui connaissent leurs modèles d’utilisation de pipeline d’intégration continue et de livraison continue (CI/CD). Lorsque vous utilisez l’option manuelle, vous devez définir votre schéma de préprovisionnement. Vous définissez votre schéma en fonction de votre compréhension des agents dans le pool qui sont les plus susceptibles d’être utilisés et du nombre d’agents susceptibles d’être utilisés. Vous spécifiez un nombre d’agents qui répondent à la demande projetée.

Vous pouvez créer votre propre planification d’approvisionnement ou choisir parmi l’une des planifications prédéfinies. Vous pouvez configurer le fuseau horaire à utiliser pour spécifier les planifications. Par défaut, le fuseau horaire de préprovisionnement est défini sur (UTC) Temps universel coordonné.

Vous pouvez configurer des agents de secours manuels de l’une des trois façons suivantes :

Chacun des guides de démarrage rapide de préprovisionnement comporte les paramètres courants suivants (en plus des paramètres spécifiques à ce guide de démarrage rapide) :

  • Fuseau horaire de préprovisionnement : vous permet de configurer le fuseau horaire pour les périodes de votre schéma de préprovisionnement. Par défaut, le fuseau horaire de préprovisionnement est défini sur (UTC) Temps universel coordonné.
  • Pourcentage d’agent de secours : configure le pourcentage d’agents de secours souhaités pour chaque image. Vous pouvez entrer * pour répartir équitablement le provisionnement entre toutes les images, ou bien spécifier un entier entre 0 et 100 correspondant à un pourcentage. Si vous utilisez des pourcentages, la somme pour toutes les images doit être égale à 100. Pour une seule image, utilisez * ou 100. Lorsque vous utilisez des modèles Azure Resource Manager (modèles ARM), vous pouvez configurer le paramètre pourcentage de l’agent de secours dans la images section. Pour en savoir plus, consultez la rubrique Configurer des images.

Capture d’écran montrant le mode de secours manuel.

Commencer à partir de zéro

Si vous choisissez de commencer à partir de zéro, vous pouvez ajouter une liste de périodes d’approvisionnement en tant que schéma d’approvisionnement. Chaque période d’approvisionnement se compose d’un jour de début, d’un jour de fin, d’un fuseau horaire, d’une heure de début, d’une heure de fin et d’un nombre. Les périodes de provisionnement ne peuvent pas se chevaucher.

Propriété Descriptif
Multijour Lorsque vous sélectionnez cette option, vous pouvez configurer à la fois le jour de début et le jour de fin de votre schéma d’approvisionnement.
Jusqu’à la prochaine période Lorsque vous sélectionnez cette option, la période d’approvisionnement s’exécute à partir de la valeur Heure de début jusqu’au début de la période d’approvisionnement suivante.
Jour de début Le jour où commence la période de provisionnement.
Jour de fin Jour de fin de la période d’approvisionnement. Obligatoire si l’option Multi-Day est sélectionnée.
Heure de début Heure de début de la période d’approvisionnement.
Fin des temps Heure de fin de la période d’approvisionnement. Obligatoire, sauf si jusqu'à la prochaine période est sélectionné.
Nombre Le nombre d’agents en attente à provisionner. Ce nombre doit être supérieur à zéro et ne doit pas être supérieur à la valeur maximale des agents dans les paramètres du pool.

Après avoir créé une période d’approvisionnement, vous pouvez supprimer ou modifier la période de la liste des schémas de préprovisionnement .

L’exemple suivant montre comment configurer un schéma manuel avec un agent approvisionné le lundi matin de 12h00 à 17h00 EST.

Capture d’écran montrant un schéma de mise à l’échelle manuelle.

Schéma en jours ouvrés

Si vous sélectionnez le schéma de la semaine, vous pouvez spécifier une heure de début et une heure de fin, entre lesquelles le nombre spécifié d’agents de secours est en veille chaque jour de la semaine.

Propriété Descriptif
Heure de début Heure de début de la période d’approvisionnement.
Fin des temps Heure de fin de la période d’approvisionnement.
Nombre d’approvisionnement Le nombre d’agents en attente à provisionner. Ce nombre doit être supérieur à zéro et ne doit pas être supérieur à la valeur maximale des agents configurés dans les paramètres du pool.

L'exemple suivant configure quatre agents à utiliser pendant les heures de travail et aucun agent pendant les heures non-travail et les week-ends, à l'aide de l'heure de l'Est (UTC-5).

Capture d’écran montrant un schéma de semaine.

Schéma de la semaine entière

Si vous choisissez le schéma toutes les semaines, vous pouvez spécifier le nombre d’agents que vous souhaitez mettre à disposition à tout moment.

Capture d’écran montrant un schéma de toute la semaine.

Automatique

Si vous ne connaissez pas vos modèles d’utilisation et que vous souhaitez vous appuyer sur la prévision automatique en fonction des données passées, sélectionnez Automatique. Vous pouvez équilibrer le coût et la performance des agents à l'aide d'un curseur avec les cinq options suivantes. Les pools DevOps gérés exécutent une requête au cours de vos trois dernières semaines de données historiques (le cas échéant). Il organise les sessions mises en file d’attente du pool en périodes de cinq minutes et affecte le centile spécifié à chaque heure pour éviter les pics.

  • Plus économique (MostCostEffective) : 10e centile.
  • Plus économique (MoreCostEffective) : 25e centile.
  • Équilibré (par défaut) (Balanced) : 50e centile.
  • Plus de performances (MorePerformance) : 75e percentile.
  • Meilleures performances (BestPerformance) : 90e centile.

Capture d’écran montrant le paramètre de mise à l’échelle automatique.

Cycle de vie des agents et retards potentiels dans l’allocation

Lorsque vous activez les agents de secours à l’aide d’un schéma sans état , vous devez installer et configurer l’agent Azure Pipelines avant de passer de l’état prêt à l’état alloué et d’exécuter un pipeline.

Lorsque les pools DevOps managés approvisionnent de nouveaux agents, il tente de télécharger le dernier agent Azure Pipelines afin qu’il soit déjà téléchargé sur les agents de secours avant de passer à l’état prêt. Le démarrage, la connexion ainsi que le début du travail peuvent prendre entre 10 secondes et une minute, selon la vitesse SKU du pool, l'image utilisée et la charge de réseau. En outre, lorsque vous spécifiez certains paramètres dans un travail de pipeline, cela peut entraîner un téléchargement et une exécution d’un autre agent. Les régressions et les restaurations de l’agent peuvent également entraîner un retéléchargement de l’agent.

Les agents prêts ont toujours un délai potentiel, car les pools DevOps managés utilisent cet agent de manière « éphémère », ce qui signifie que nous commençons et exécutons l’agent de tâche une fois par travail. Si vous voyez des retards dans les agents prêts à récupérer des travaux à partir d’Azure DevOps, tenez compte des questions suivantes :

  • Avez-vous des agents prêts ? Le problème le plus courant est l’incompréhension du moment où les agents doivent être préprovisionnés. Les machines doivent être lancées à partir de zéro lorsque les conditions suivantes sont réunies :
    • Le nombre de travaux en file d'attente est supérieur au nombre d'agents en attente dans une piscine.
    • Les travaux sont mis en file d’attente en dehors du calendrier de pré-provisionnement.
    • Le nombre d’agents en attente est défini comme inexistant.
  • Configurez-vous correctement les agents en veille ayant plusieurs images ? Si vous ne spécifiez pas l’image à utiliser dans votre pipeline à l’aide de la demande ImageOverride , les travaux ciblent la première image. Selon vos paramètres de mise à l’échelle, vous n’avez peut-être pas autant d’agents disponibles que prévu, car certains sont alloués à d’autres images.
  • Utilisez-vous la ImageVersionOverride requête dans vos pipelines ? Lorsque vous utilisez la ImageVersionOverride demande pour spécifier une version d’image différente de celle configurée dans les paramètres de votre pool, chaque agent démarre à la demande à l’aide de la version d’image spécifiée. Les agents de secours sont approvisionnés à l’aide des versions d’image spécifiées dans la configuration de votre pool. Si vous utilisez ImageVersionOverride, les agents en veille ne correspondront pas à cette version, ce qui entraînera le démarrage d'un nouvel agent.
  • Les paramètres de proxy, de réseau virtuel ou de pare-feu ralentissent-ils votre pool ? La lenteur potentielle de n’importe quel paramètre réseau entraîne la prise de plus de temps pour démarrer l’agent et la connecter à Azure DevOps.
  • Remplacez-vous la version de l’agent ? Par défaut, les pools DevOps gérés s’exécutent sur la version la plus récente de l’agent de tâche Azure DevOps. Les paramètres du pipeline YAML (par exemple, la Agent.Version demande) et les paramètres de l’organisation Azure DevOps peuvent forcer les pipelines à utiliser des versions antérieures de l’agent de tâche, ce qui nécessite un redownload après l’allocation d’une machine.

Contenu connexe

  • Last updated on