Agents Microsoft Azure Virtual Machine Scale Sets

Azure DevOps Services

Les agents de groupe de machines virtuelles identiques Azure, ci-après dénommés agents de groupe identique, sont une forme d’agents autohébergés qui peuvent être automatiquement mis à l’échelle pour répondre à vos besoins. 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.

Si vous aimez les agents hébergés par Microsoft, mais que vous vous sentez limité par ce qu’ils offrent, envisagez d’utiliser des agents de groupe identique. Voici quelques exemples :

• Vous avez besoin de plus de mémoire, de processeurs, de stockage ou d’E/S que ce qu’offrent les agents natifs hébergés par Microsoft.
• Vous avez besoin d’une machine virtuelle NCv2 avec des ensembles d’instructions spécifiques pour le Machine Learning.
• Vous devez déployer sur une instance Azure App Service privée dans un réseau virtuel privé sans connectivité entrante.
• Vous devez ouvrir un pare-feu d’entreprise à des adresses IP spécifiques afin que les agents hébergés par Microsoft puissent communiquer avec vos serveurs.
• Vous devez restreindre la connectivité réseau des machines d’agent et leur permettre d’atteindre uniquement les sites approuvés.
• Vous ne pouvez pas obtenir suffisamment d’agents de Microsoft pour répondre à vos besoins.
• Vos travaux dépassent le délai d’attente de l’agent hébergé par Microsoft.
• Vous ne pouvez pas partitionner des travaux parallèles hébergés par Microsoft dans des équipes ou projets individuels au sein de votre organisation.
• Vous souhaitez exécuter plusieurs travaux consécutifs sur un agent pour tirer parti des caches de package source incrémentiel et au niveau de la machine.
• Vous souhaitez exécuter une configuration ou un préchauffage du cache avant qu’un agent commence à accepter les travaux.

Si vous aimez les agents autohébergés, mais que vous souhaitez simplifier leur gestion, envisagez d’utiliser des agents de groupe identique. Voici quelques exemples :

• Vous ne voulez pas exécuter d’agents dédiés en permanence. Vous souhaitez déprovisionner les machines d’agent qui ne sont pas utilisées pour exécuter des travaux.
• Vous exécutez du code non approuvé dans votre pipeline et souhaitez réimager les machines de l’agent après chaque travail.
• Vous souhaitez simplifier la mise à jour périodique de l’image de base pour vos agents.

Création du jeu de mise à l’échelle

En préparation de la création d’agents de groupe identique, vous devez d’abord créer un groupe de machines virtuelles identiques dans le portail Azure. Vous devez créer le groupe de machines virtuelles identiques de manière à ce qu’Azure Pipelines puisse le gérer. En particulier, vous devez désactiver la mise à l’échelle automatique afin qu’Azure Pipelines puisse déterminer comment effectuer la mise à l’échelle en fonction du nombre de travaux de pipeline entrants. Nous vous recommandons d’utiliser les étapes suivantes pour créer le groupe identique.

Dans l’exemple suivant, un nouveau groupe de ressources et un groupe de machines virtuelles identiques sont créés avec Azure Cloud Shell à l’aide de l’image de machine virtuelle UbuntuLTS.

1. Accédez à Azure Cloud Shell à l’adresse https://shell.azure.com/.

2. Exécutez la commande suivante pour vérifier votre abonnement Azure par défaut.

   az account list -o table
   

   Si votre abonnement souhaité n’est pas répertorié comme abonnement par défaut, sélectionnez l’abonnement souhaité.

   az account set -s <your subscription ID>
   

3. Créez un groupe de ressources pour votre groupe de machines virtuelles identiques.

   az group create \
   --location westus \
   --name vmssagents
   

4. Créez un groupe de machines virtuelles identiques dans votre groupe de ressources. Dans cet exemple, l’image de machine virtuelle Ubuntu2204 est spécifiée.

   az vmss create \
   --name vmssagentspool \
   --resource-group vmssagents \
   --image Ubuntu2204 \
   --vm-sku Standard_D2_v4 \
   --storage-sku StandardSSD_LRS \
   --authentication-type SSH \
   --generate-ssh-keys \
   --instance-count 2 \
   --disable-overprovision \
   --upgrade-policy-mode manual \
   --single-placement-group false \
   --platform-fault-domain-count 1 \
   --load-balancer "" \
   --orchestration-mode Uniform
   

   Remarque

   Azure Pipelines ne prend pas en charge le surapprovisionnement et la mise à l’échelle automatique des groupes identiques. Vérifie que les deux fonctionnalités sont désactivées pour votre groupe identique.

   Étant donné qu’Azure Pipelines gère le groupe identique, les paramètres suivants sont obligatoires ou recommandés :

   • --disable-overprovision : obligatoire
   • --upgrade-policy-mode manual : obligatoire
   • --load-balancer "" : Azure Pipelines ne nécessite pas d’équilibreur de charge pour router les travaux vers les agents du pool d’agents de groupe identique, mais la configuration d’un équilibreur de charge est un moyen d’obtenir une adresse IP pour vos agents de groupe identique que vous pouvez utiliser pour les règles de pare-feu. Une autre option permettant d’obtenir une adresse IP pour vos agents de groupe identique consiste à créer votre groupe identique à l’aide des options --public-ip-address. Pour plus d’informations sur la configuration de votre groupe identique avec un équilibreur de charge ou une adresse IP publique, consultez la documentation Microsoft Azure Virtual Machine Scale Sets et az vmss create.
   • --instance-count 2 : ce paramètre n’est pas obligatoire, mais il vous donne la possibilité de vérifier que le groupe identique est entièrement fonctionnel avant de créer un pool d’agents. La création des deux machines virtuelles peut prendre plusieurs minutes. Plus tard, lorsque vous créez le pool d’agents, Azure Pipelines supprime ces deux machines virtuelles et en crée de nouvelles.

   Important

   Si vous exécutez ce script à l’aide d’Azure CLI sur Windows, vous devez placer le "" dans --load-balancer "" avec des guillemets simples comme suit : --load-balancer '""'

   Si la taille de votre machine virtuelle prend en charge les disques de système d’exploitation éphémères, les paramètres suivants pour activer les disques de système d’exploitation éphémères sont facultatifs, mais recommandés pour améliorer les temps de réinitialisation des machines virtuelles.

   • --ephemeral-os-disk true
   • --os-disk-caching readonly

   Important

   Les disques de système d’exploitation éphémères ne sont pas pris en charge sur toutes les tailles de machine virtuelle. Pour obtenir la liste des tailles de machine virtuelle prises en charge, consultez Disques de système d’exploitation éphémères pour les machines virtuelles Azure.

   Sélectionnez une image Linux ou Windows ( à partir de la Place de marché Azure ou de votre propre image personnalisée) pour créer le groupe identique. Ne préinstallez pas l’agent Azure Pipelines dans l’image. Azure Pipelines installe automatiquement l’agent au fur et à mesure qu’il approvisionne de nouvelles machines virtuelles. Dans l’exemple ci-dessus, nous avons utilisé une image simple UbuntuLTS. Pour obtenir des instructions sur la création et l’utilisation d’une image personnalisée, consultez FAQ.

   Sélectionnez un SKU de machine virtuelle et un SKU de stockage.

   Remarque

   Les considérations relatives aux licences nous empêchent de distribuer des images hébergées par Microsoft. Nous ne pouvons pas vous fournir ces images pour que vous les utilisiez dans vos agents de groupe identique. Toutefois, les scripts que nous utilisons pour générer ces images sont open source. Vous êtes libre d’utiliser ces scripts et de créer vos propres images personnalisées.

5. Après avoir créé votre groupe identique, accédez à votre groupe identique dans le portail Azure et vérifiez les paramètres suivants :

   • Stratégie de mise à niveau - Manuelle

     

     Vous pouvez également vérifier ce paramètre en exécutant la commande Azure CLI suivante.

     az vmss show --resource-group vmssagents --name vmssagentspool --output table
     
     Name            ResourceGroup    Location    Zones    Capacity    Overprovision    UpgradePolicy
     --------------  ---------------  ----------  -------  ----------  ---------------  ---------------
     vmssagentspool  vmssagents       westus               0           False            Manual
     

   • Mise à l’échelle - Mise à l’échelle manuelle

     

Modes d’orchestration

Les groupes de machines virtuelles identiques Azure peuvent être configurés avec deux modes d’orchestration : Uniforme et Flexible. La prise en charge d’Azure Pipelines pour le mode d’orchestration uniforme est généralement disponible pour tous les clients.

Le mode d’orchestration flexible permet à Azure Pipelines de mettre en file d’attente plusieurs opérations de groupe identique en parallèle. La prise en charge d’Azure Pipelines pour l’orchestration flexible est disponible sur demande et est soumise à évaluation. Les modèles d’utilisation des clients doivent indiquer un avantage significatif. Ces clients ont des groupes identiques volumineux, ne réutilisent pas d’agents pour plusieurs travaux, exécutent plusieurs travaux de courte durée en parallèle et utilisent exclusivement des disques éphémères dans leurs machines virtuelles. Si vous souhaitez utiliser cette fonctionnalité, contactez notre équipe de support technique.

Créer le pool d’agents de groupe identique

1. Accédez à vos paramètres de projet Azure DevOps, sélectionnezPools d’agents sous Pipelines, puis sélectionnezAjouter un pool pour créer un nouveau pool d’agents.

   

   Important

   Vous pouvez créer votre pool de groupes identiques dans Paramètres du projet ou Paramètres de l’organisation, mais lorsque vous supprimez un pool de groupes identiques, vous devez le supprimer de Paramètres de l’organisation et non de Paramètres du projet.

2. Sélectionnez Groupe de machines virtuelles identiques Azure pour le type de pool. Sélectionnez l’abonnement Azure qui contient le groupe identique, choisissez Autoriser, puis choisissez le groupe de machines virtuelles identiques souhaité à partir de cet abonnement. Si vous disposez d’une connexion de service existante, vous pouvez le choisir dans la liste au lieu de l’abonnement.

   Important

   • Pour configurer un pool d’agents de groupe identique, vous devez disposer des autorisations Propriétaire ou Administrateur de l’accès utilisateur sur l’abonnement sélectionné. Si vous disposez de l’une de ces autorisations, mais que vous obtenez une erreur lorsque vous choisissez Autoriser, consultez la résolution des problèmes.

   • La seule connexion de service actuellement prise en charge est une connexion de service Azure Resource Manager (ARM) basée sur une clé de principal de service. Les connexions de service ARM basées sur des informations d’identification de certificat ou une identité managée échouent. Lorsque vous tentez de répertorier les groupes identiques existants dans votre abonnement, une erreur semblable à celle-ci s’affiche :

     Invalid Service Endpoint with Id <guid> and Scope <guid>

3. Choisissez le groupe de machines virtuelles identiques souhaité à partir de cet abonnement.

4. Spécifiez un nom pour votre pool d’agents.

5. Configurez les options suivantes :

   • Supprimer automatiquement les machines virtuelles après chaque utilisation : une nouvelle instance de machine virtuelle est utilisée pour chaque travail. La machine virtuelle est hors connexion après avoir exécuté un travail et est réinitialisée avant de récupérer un autre travail.
   • Enregistrer un agent non sain à des fins d’investigation : indique s’il faut enregistrer des machines virtuelles d’agent non sain pour la résolution des problèmes au lieu de les supprimer.
   • Nombre maximal de machines virtuelles dans le groupe identique : Azure Pipelines effectue automatiquement un scale-out du nombre d’agents, mais ne dépasse pas cette limite.
   • Nombre d’agents à maintenir en veille : Azure Pipelines est automatiquement mis à l’échelle dans le nombre d’agents, mais garantit qu’il existe toujours ce nombre d’agents disponibles pour exécuter de nouveaux travaux. Si vous définissez Nombre d’agents à maintenir en veille sur 0, par exemple pour conserver le coût d’un faible volume de travaux, Azure Pipelines démarre une machine virtuelle uniquement lorsqu’il a un travail.
   • Retard en minutes avant la suppression d’agents inactifs excédentaires : pour tenir compte de la variabilité de la charge de build tout au long de la journée, Azure Pipelines attend la durée spécifiée avant de supprimer un agent inactif excédentaire.
   • Configurer des machines virtuelles pour exécuter des tests interactifs (système d’exploitation Windows Server uniquement) : les agents Windows peuvent être configurés pour s’exécuter sans élévation avec la session automatique et avec l’interface utilisateur interactive, ou ils peuvent être configurés pour s’exécuter avec des autorisations élevées. Cochez cette case pour une exécution sans élévation avec l’interface utilisateur interactive. Dans les deux cas, l’utilisateur de l’agent est membre du groupe Administrateurs.

6. Lorsque vos paramètres sont configurés, choisissez Créer pour créer le pool d’agents.

Utiliser le pool d’agents de groupe identique

L’utilisation d’un pool d’agents de groupe identique est similaire à n’importe quel autre pool d’agents. Vous pouvez l’utiliser dans les pipelines de build, de mise en production ou YAML classiques. Les autorisations utilisateur, les autorisations de pipeline, les approbations et d’autres vérifications fonctionnent de la même façon que dans tout autre pool d’agents. Pour plus d’informations, consultez Pools d’agents.

Comment Azure Pipelines gère le groupe identique

Une fois le pool d’agents de groupe identique créé, Azure Pipelines met automatiquement à l’échelle les machines de l’agent.

Azure Pipelines échantillonne l’état des agents dans le pool et les machines virtuelles du groupe identique toutes les 5 minutes. La décision d’effectuer un scale-in ou un scale-out est basée sur le nombre d’agents inactifs à ce moment-là. Un agent est considéré comme inactif s’il est en ligne et n’exécute pas de travail de pipeline. Azure Pipelines effectue une opération de scale-out si l’une des conditions suivantes est satisfaite :

• Le nombre d’agents inactifs est inférieur au nombre d’agents en attente que vous spécifiez
• Il n’existe aucun agent inactif pour les travaux de pipeline de service en attente dans la file d’attente

Si l’une de ces conditions est remplie, Azure Pipelines augmente le nombre de machines virtuelles. Le scale-out est effectué par incréments d’un certain pourcentage de la taille maximale du pool. Attendez 20 minutes pour que les machines soient créées à chaque étape.

Azure Pipelines effectue un scale-in dans les agents lorsque le nombre d’agents inactifs dépasse le nombre en attente pendant plus de 30 minutes (configurable à l’aide de Retard en minutes avant de supprimer des agents inactifs excédentaires).

Pour mettre tout cela dans un exemple, imaginez un pool d’agents de groupe identique configuré avec deux agents en attente et quatre agents maximum. Supposons que vous souhaitiez supprimer la machine virtuelle après chaque utilisation. Supposons également qu’il n’y a pas de machines virtuelles avec laquelle commencer dans le groupe identique.

• Étant donné que le nombre d’agents inactifs est égal à 0 et que le nombre d’agents inactifs est inférieur au nombre de 2, Azure Pipelines effectue un scale-out et ajoute deux machines virtuelles au groupe identique. Une fois ces agents en ligne, il y aura deux agents inactifs.

• Supposons qu’un travail de pipeline arrive et qu’il est alloué à l’un des agents.

• À ce stade, le nombre d’agents inactifs est égal à 1 et inférieur au nombre en attente de 2. Par conséquent, Azure Pipelines effectue un scale-out et ajoute deux machines virtuelles supplémentaires (la taille d’incrément utilisée dans cet exemple). À ce stade, le pool a trois agents inactifs et un agent occupé.

• Supposons que le travail sur le premier agent se termine. Azure Pipelines met cet agent hors connexion pour réinitialiser cette machine. Après quelques minutes, il revient avec une nouvelle image. À ce stade, nous avons quatre agents inactifs.

• Si aucun autre travail n’arrive pendant 30 minutes (configurable à l’aide de Retard en minutes avant de supprimer des agents inactifs excédentaires), Azure Pipelines détermine qu’il existe plus d’agents inactifs que nécessaire. Il effectue donc un scale-in dans le pool à deux agents.

Tout au long de l’opération, l’objectif d’Azure Pipelines est d’atteindre le nombre souhaité d’agents inactifs en attente. Les pools effectuent le scale-out et le scale-in lentement. Au cours d’une journée, le pool est mis à l’échelle à mesure que les requêtes sont mises en file d’attente le matin et à mesure que la charge diminue le soir. Vous pouvez observer plus d’agents inactifs que vous le souhaitez à différents moments, ce qui est attendu, car Azure Pipelines converge progressivement vers les contraintes que vous spécifiez.

Pour obtenir une stabilité maximale, les opérations de groupe identique sont effectuées de manière séquentielle. Par exemple, si le pool doit effectuer un scale-out et qu’il existe également des machines non saines à supprimer, Azure Pipelines effectue d’abord un scale-out du pool. Une fois que le pool a effectué un scale-out pour atteindre le nombre souhaité d’agents inactifs en veille, les machines non saines sont supprimées, selon le paramètre Enregistrer un agent non sain pour investigation. Pour plus d’informations, consultez Agents non sains.

En raison de la taille d’échantillonnage de 5 minutes, il est possible que tous les agents puissent exécuter des pipelines pendant une courte période et qu’aucun scale-out ne se produise.

Personnalisation de la configuration de l’agent de pipeline

Vous pouvez personnaliser la configuration de l’agent Azure Pipelines en définissant des variables d’environnement dans votre image personnalisée du système d’exploitation pour votre groupe identique. Par exemple, le répertoire de travail de l’agent de groupe identique est défini par défaut sur C:\a pour Windows et /agent/_work pour Linux. Si vous souhaitez modifier le répertoire de travail, définissez une variable d’environnement nommée VSTS_AGENT_INPUT_WORK avec le répertoire de travail souhaité. Pour plus d’informations, consultez la documentation Configuration sans assistance de l’agent de pipelines. Voici quelques exemples :

• VSTS_AGENT_INPUT_WORK
• VSTS_AGENT_INPUT_PROXYURL
• VSTS_AGENT_INPUT_PROXYUSERNAME
• VSTS_AGENT_INPUT_PROXYPASSWORD

Personnalisation du démarrage de la machine virtuelle via l’extension de script personnalisé

Les utilisateurs peuvent souhaiter exécuter des scripts de démarrage sur leurs ordinateurs d’agent de groupe identique avant que ces ordinateurs commencent à exécuter des travaux de pipeline. Certains cas d’usage courants pour les scripts de démarrage incluent l’installation de logiciels, la mise en route des caches ou la récupération de référentiels. Vous pouvez exécuter des scripts de démarrage en installant l’extension de script personnalisé pour Windows ou l’extension de script personnalisé pour Linux.

Cette extension est exécutée sur chaque machine virtuelle du groupe identique immédiatement après sa création ou sa réinitialisation. L’extension de script personnalisé est exécutée avant l’exécution de l’extension de l’agent Azure Pipelines.

Voici un exemple pour créer une extension de script personnalisé pour Linux.

az vmss extension set \
--vmss-name <scaleset name> \
--resource-group <resource group> \
--name CustomScript \
--version 2.0 \
--publisher Microsoft.Azure.Extensions \
--settings '{ \"fileUris\":[\"https://<myGitHubRepoUrl>/myScript.sh\"], \"commandToExecute\": \"bash ./myScript.sh /myArgs \" }'

Voici un exemple pour créer une extension de script personnalisée pour Windows.

az vmss extension set \
--vmss-name <scaleset name> \
--resource-group <resource group> \
--name CustomScriptExtension \
--version 1.9 \
--publisher Microsoft.Compute \
--settings '{ \"FileUris\":[\"https://<myGitHubRepoUrl>/myscript.ps1\"], \"commandToExecute\": \"Powershell.exe -ExecutionPolicy Unrestricted -File myscript.ps1 -myargs 0 \" }'

Il se peut que votre extension s’exécute avant l’approvisionnement de toutes les ressources de machine virtuelle, auquel cas vous verrez une erreur similaire à « Échec de l’installation des prérequis de base ». Vous pouvez résoudre ce problème en ajoutant une commande sleep au début de votre script, par exemple sleep 30.

Cycle de vie d’un agent de groupe identique

Voici le flux d’opérations d’un agent de groupe de machines virtuelles identiques Azure Pipelines

1. Le travail de dimensionnement du pool d’agents de groupe identique Azure DevOps détermine que le pool a trop peu d’agents inactifs et doit effectuer un scale-out. Azure Pipelines appelle les groupes identiques Azure pour augmenter la capacité du groupe identique.

2. Le groupe identique Azure commence à créer les nouvelles machines virtuelles. Une fois les machines virtuelles en cours d’exécution, les groupes identiques Azure exécutent séquentiellement toutes les extensions de machine virtuelle installées.

3. Si l’extension de script personnalisé est installée, elle est exécutée avant l’extension de l’agent Azure Pipelines. Si l’extension de script personnalisé retourne un code de sortie non nul, le processus de création de machine virtuelle est abandonné et sera supprimé.

4. L’extension de l’agent Azure Pipelines est exécutée. Cette extension télécharge la dernière version de l’agent Azure Pipelines, ainsi que la dernière version du script de configuration. Les scripts de configuration sont disponibles dans les URL avec les formats suivants :

   • Linux : https://vstsagenttools.blob.core.windows.net/tools/ElasticPools/Linux/<script_version>/enableagent.sh, par exemple, version 15
   • Windows : https://vstsagenttools.blob.core.windows.net/tools/ElasticPools/Windows/<script_version>/enableagent.ps1, par exemple, version 17

5. Le script de configuration crée un utilisateur local nommé AzDevOps si le système d’exploitation est Windows Server ou Linux. Pour le système d’exploitation client Windows 10, l’agent s’exécute en tant que LocalSystem. Ensuite, le script décompresse, installe et configure l’agent Azure Pipelines. Dans le cadre de la configuration, l’agent s’inscrit auprès du pool d’agents Azure DevOps et apparaît dans la liste des pools d’agents dans l’état hors connexion.

6. Pour la plupart des scénarios, le script de configuration démarre ensuite immédiatement l’agent pour qu’il s’exécute en tant qu’utilisateur local AzDevOps. L’agent est en ligne et est prêt à exécuter des travaux de pipeline.

   Si le pool est configuré pour l’interface utilisateur interactive, la machine virtuelle redémarre une fois l’agent configuré. Après le redémarrage, l’utilisateur local se connecte automatiquement et l’agent de pipelines démarre. L’agent est ensuite en ligne et est prêt à exécuter des travaux de pipeline.

Créer un groupe identique avec une image personnalisée, un logiciel ou une taille de disque

Si vous souhaitez simplement créer un groupe identique avec le disque de système d’exploitation par défaut de 128 Go à l’aide d’une image Azure disponible publiquement, passez directement à l’étape 10 et utilisez le nom de l’image publique (UbuntuLTS, Win2019DataCenter, etc.) pour créer le groupe identique. Sinon, suivez ces étapes pour personnaliser votre image de machine virtuelle.

1. Créez une machine virtuelle avec votre image de système d’exploitation souhaitée et développez éventuellement la taille du disque du système d’exploitation de 128 Go à <myDiskSizeGb>.

   • Si vous commencez avec une image Azure disponible, par exemple <myBaseImage> = (Win2019DataCenter, UbuntuLTS) :

     az vm create --resource-group <myResourceGroup> --name <MyVM> --image <myBaseImage> --os-disk-size-gb <myDiskSize>  --admin-username myUserName --admin-password myPassword
     

   • Si vous commencez par un disque dur virtuel généralisé :

     1. Commencez par créer la machine virtuelle avec un disque non managé de la taille souhaitée, puis convertissez-la en disque managé :

        az vm create --resource-group <myResourceGroup> --name <MyVM> --image <myVhdUrl> --os-type windows --os-disk-size-gb <myDiskSizeGb> --use-unmanaged-disk --admin-username <myUserName> --admin-password <myPassword> --storage-account <myVhdStorageAccount>
        

     2. Arrêter la machine virtuelle

        az vm stop --resource-group <myResourceGroup> --name <MyVM>
        

     3. Libérer la machine virtuelle

        az vm deallocate --resource-group <myResourceGroup> --name <MyVM>
        

     4. Convertir en disque managé

        az vm convert --resource-group <myResourceGroup> --name <MyVM>
        

     5. Redémarrez la machine virtuelle.

        az vm start --resource-group <myResourceGroup> --name <MyVM>
        

2. Bureau à distance (ou SSH) vers l’adresse IP publique de la machine virtuelle pour personnaliser l’image. Vous devrez peut-être ouvrir des ports dans le pare-feu pour débloquer les ports RDP (3389) ou SSH (22).

   1. Windows : si <MyDiskSizeGb> est supérieur à 128 Go, étendez la taille du disque du système d’exploitation pour remplir la taille du disque que vous avez spécifiée par <MyDiskSizeGb>.

      Ouvrez l’outil DiskPart en tant qu’administrateur et exécutez ces commandes DiskPart :

      1. list volume (pour afficher les volumes)
      2. select volume 2 (dépend du volume qui correspond au lecteur du système d’exploitation)
      3. extend size 72000 (pour étendre le lecteur de 72 Go, de 128 Go à 200 Go)

3. Installez tous les logiciels supplémentaires souhaités sur la machine virtuelle.

4. Pour personnaliser les autorisations de l’utilisateur de l’agent de pipeline, vous pouvez créer un utilisateur nommé AzDevOpset accorder à cet utilisateur les autorisations dont vous avez besoin. Cet utilisateur est créé par le script de démarrage de l’agent de groupe identique s’il n’existe pas déjà.

5. Redémarrer la machine virtuelle une fois les personnalisations terminées

6. Généralisez la machine virtuelle.

   • Windows : à partir d’une fenêtre de console d’administration :

     C:\Windows\System32\sysprep\sysprep.exe /generalize /oobe /shutdown
     

   • Linux :

     sudo waagent -deprovision+user -force
     

   Important

   Attendez que la machine virtuelle termine la généralisation et l’arrêt. Ne continuez pas tant que la machine virtuelle n’est pas arrêtée. Attendez 60 minutes.

7. Libérer la machine virtuelle

   az vm deallocate --resource-group <myResourceGroup> --name <MyVM>
   

8. Indiquer que la machine virtuelle est généralisée

   az vm generalize --resource-group <myResourceGroup> --name <MyVM>
   

9. Créer une image de machine virtuelle basée sur l’image généralisée. Lorsque vous effectuez ces étapes pour mettre à jour une image de groupe identique existante, notez l’URL de l’ID d’image dans la sortie.

   az image create  --resource-group <myResourceGroup> --name <MyImage> --source <MyVM>
   

10. Créer le groupe identique en fonction de l’image de machine virtuelle personnalisée

    az vmss create --resource-group <myResourceGroup> --name <myScaleSet> --image <MyImage> --admin-username <myUsername> --admin-password <myPassword> --instance-count 2 --disable-overprovision --upgrade-policy-mode manual --load-balancer '""'
    

11. Vérifier que les deux machines virtuelles créées dans le groupe identique sont mises en ligne, ont des noms différents et atteignent l’état de réussite

Vous êtes maintenant prêt à créer un pool d’agents à l’aide de ce groupe identique.

Mettre à jour un groupe identique existant avec une nouvelle image personnalisée

Pour mettre à jour l’image sur un groupe identique existant, suivez les étapes décrites dans la section précédente Créer un groupe identique avec une image personnalisée, un logiciel ou une section de taille de disque jusqu’à l’étape az image create pour générer l’image de système d’exploitation personnalisée. Notez l’URL de la propriété ID qui est la sortie de la commande az image create. Ensuite, mettez à jour le groupe identique avec la nouvelle image, comme illustré dans l’exemple suivant. Une fois l’image de groupe identique mise à jour, toutes les futures machines virtuelles du groupe identique seront créées avec la nouvelle image.

az vmss update --resource-group <myResourceGroup> --name <myScaleSet> --set virtualMachineProfile.storageProfile.imageReference.id=<id url>

Systèmes d’exploitation pris en charge

Les agents de groupe identique prennent actuellement en charge Ubuntu Linux, Windows Server/DataCenter 2016/2019 et le client Windows 10.

Problèmes connus

• Les distributions Debian ou RedHat Linux ne sont pas prises en charge. Seul Ubuntu l’est.
• Le client Windows 10 ne prend pas en charge l’exécution de l’agent de pipeline en tant qu’utilisateur local. Par conséquent, l’agent ne peut pas interagir avec l’interface utilisateur. L’agent s’exécute en tant que service local à la place.

Résolution des problèmes

Accédez aux paramètres de votre projet Azure DevOps, sélectionnez Pools d’agents sous Pipelines, puis sélectionnez votre pool d’agents. Sélectionnez l’onglet intitulé Diagnostics.

L’onglet Diagnostic affiche toutes les actions exécutées par Azure DevOps pour créer, supprimer ou réinitialiser des machines virtuelles dans votre groupe identique Azure. Les diagnostics enregistrent également toutes les erreurs rencontrées lors de la tentative d’exécution de ces actions. Passez en revue les erreurs pour vous assurer que votre groupe identique dispose de ressources suffisantes pour effectuer un scale-out. Si votre abonnement Azure a atteint la limite de ressources dans les machines virtuelles, les cœurs de processeur, les disques ou les adresses IP, ces erreurs s’affichent ici.

Agents non sains

Lorsque des agents ou des machines virtuelles ne parviennent pas à démarrer, ne peuvent pas se connecter à Azure DevOps ou se déconnectent de manière inattendue, Azure DevOps enregistre les échecs dans l’onglet Diagnostics du pool d’agents et tente de supprimer la machine virtuelle associée. La configuration de mise en réseau, la personnalisation de l’image et les redémarrages en attente peuvent provoquer ces problèmes. La connexion à la machine virtuelle pour déboguer et collecter des journaux peut vous aider à effectuer l’investigation.

Si vous souhaitez qu’Azure DevOps enregistre une machine virtuelle d’agent non saine à des fins d’investigation et ne la supprime pas automatiquement lorsqu’il détecte l’état non sain, accédez à vos paramètres de projet Azure DevOps, sélectionnez Pools d’agent sous Pipelines, puis sélectionnez votre pool d’agent. Choisissez Paramètres, sélectionnez l’option Enregistrer un agent non sain pour investigation, puis sélectionnez Enregistrer.

À présent, lorsqu’un agent non sain est détecté dans le groupe identique, Azure DevOps enregistre cet agent et la machine virtuelle associée. L’agent enregistré est visible sous l’onglet Diagnostics de l’interface utilisateur du pool d’agents. Accédez à vos paramètres de projet Azure DevOps, sélectionnez Pools d’agent sous Pipelines, sélectionnez votre pool d’agent, choisissez Diagnostics et notez le nom de l’agent.

Recherchez la machine virtuelle associée dans votre groupe de machines virtuelles identiques Azure via le portail Azure, dans la liste Instances.

Sélectionnez l’instance, choisissez Se connecteret effectuez votre investigation.

Pour supprimer l’agent enregistré lorsque vous avez terminé votre investigation, accédez à vos paramètres de projet Azure DevOps, sélectionnez Pools d’agents sous Pipelines, puis sélectionnez votre pool d’agents. Sélectionnez l’onglet intitulé Diagnostics. Recherchez l’agent sur la carte Agents enregistrés pour investigation, puis choisissez Supprimer. Cela supprime l’agent du pool et supprime la machine virtuelle associée.

FAQ

• Agents Microsoft Azure Virtual Machine Scale Sets
  • Création du jeu de mise à l’échelle
    • Modes d’orchestration
  • Créer le pool d’agents de groupe identique
  • Utiliser le pool d’agents de groupe identique
  • Comment Azure Pipelines gère le groupe identique
  • Personnalisation de la configuration de l’agent de pipeline
  • Personnalisation du démarrage de la machine virtuelle via l’extension de script personnalisé
  • Cycle de vie d’un agent de groupe identique
  • Créer un groupe identique avec une image personnalisée, un logiciel ou une taille de disque
  • Mettre à jour un groupe identique existant avec une nouvelle image personnalisée
  • Systèmes d’exploitation pris en charge
    • Problèmes connus
  • Résolution des problèmes
    • Agents non sains
  • Questions fréquentes (FAQ)
    • Quels sont les problèmes courants et leurs solutions ?
      • Vous observez plus d’agents inactifs que souhaité à différents moments
      • L’augmentation d’échelle des Virtual Machine Scale Sets ne se produit pas dans l’intervalle de cinq minutes prévu
      • Le groupe de machines virtuelles identiques Linux Azure DevOps échoue fréquemment à démarrer le pipeline
      • Vous cochez l’option pour désactiver automatiquement les machines virtuelles après chaque utilisation du pool d’agents, mais vous voyez que les machines virtuelles ne sont pas réimagées comme elles le devraient et qu’elles récupèrent simplement de nouveaux travaux à mesure qu’elles sont mises en file d’attente
      • Les Virtual Machine Scale Sets affichent l’agent comme hors ligne si la machine virtuelle redémarre
      • Vous pouvez voir plusieurs étiquettes comme _AzureDevOpsElasticPoolTimeStamp pour Virtual Machine Scale Sets dans la gestion des coûts
      • Vous ne pouvez pas créer un pool d’agents de groupe identique et voyez un message d’erreur indiquant qu’un pool portant le même nom existe déjà
      • Le travail de maintenance des Virtual Machine Scale Sets ne s’exécute pas sur les agents ou n’obtient pas de journaux
      • Si vous spécifiez AzDevOps comme administrateur principal dans votre script pour Virtual Machine Scale Sets, vous pourriez observer des problèmes avec la configuration des agents sur les instances de l’ensemble d’échelles
      • L’installation de l’extension de l’agent échoue sur les instances de groupe identique en raison de la configuration de la sécurité réseau et du pare-feu
      • Pourquoi mon script de configuration de l'agent de groupe identique appelle-t-il Add-MpPreference et configure-t-il Windows Defender sur l'agent ?
      • Je veux augmenter la taille de mon pool. Que dois-je prendre en compte ?

Quels sont les problèmes courants et leurs solutions ?

Vous observez plus d’agents inactifs que souhaité à différents moments

Pour mieux comprendre pourquoi cela se produit, consultez Comment Azure Pipelines gère le groupe identique. Tout au long de l’opération de mise à l’échelle, l’objectif d’Azure Pipelines est d’atteindre le nombre souhaité d’agents inactifs en attente. Les pools effectuent le scale-out et le scale-in lentement. Sur une journée, le pool est mis à l’échelle à mesure que les requêtes sont mises en file d’attente le matin et à mesure que la charge diminue le soir. Il s’agit d’un comportement attendu, car Azure Pipelines converge progressivement vers les contraintes que vous spécifiez.

L’augmentation d’échelle des Virtual Machine Scale Sets ne se produit pas dans l’intervalle de cinq minutes prévu

Le travail de mise à l’échelle s’exécute toutes les cinq minutes, mais si une seule opération est traitée, vous pouvez constater que le scale-up ne se produit pas dans les cinq minutes ; c’est actuellement un comportement voulu.

Le groupe de machines virtuelles identiques Linux Azure DevOps échoue fréquemment à démarrer le pipeline

Le premier endroit à vérifier lorsque vous rencontrez des problèmes avec des agents de groupe identique est l’onglet Diagnostics dans le pool d’agents.

Envisagez également d’enregistrer la machine virtuelle non saine à des fins de débogage. Pour plus d’informations, consultez Agents non sains.

Les agents enregistrés restent là, sauf si vous les supprimez. Si l’agent n’est pas en ligne après 10 minutes, il est marqué comme défectueux et enregistré si possible. Une seule machine virtuelle est conservée dans un état enregistré. Si l’agent se met hors connexion de manière inattendue (en raison d’un redémarrage de machine virtuelle ou d’un événement qui se produit sur l’image), il n’est pas enregistré pour investigation.

Seules les machines virtuelles pour lesquelles les agents ne parviennent pas à démarrer sont enregistrées. Si une machine virtuelle a un état d’échec lors de la création, elle n’est pas enregistrée. Dans ce cas, le message dans l’onglet Diagnostics est « Suppression de la machine défectueuse » au lieu d’« Échec du démarrage ».

Vous cochez l’option pour désactiver automatiquement les machines virtuelles après chaque utilisation du pool d’agents, mais vous voyez que les machines virtuelles ne sont pas réimagées comme elles le devraient et qu’elles récupèrent simplement de nouveaux travaux à mesure qu’elles sont mises en file d’attente

L’option permettant de détruire la machine virtuelle après chaque build fonctionne uniquement pour Windows Server et les images Linux prises en charge. Elle n’est pas prise en charge pour les images de clients Windows.

Les Virtual Machine Scale Sets affichent l’agent comme hors ligne si la machine virtuelle redémarre

Le comportement attendu est d’afficher les agents comme hors connexion si la machine virtuelle redémarre. Le service d’agent s’exécute uniquement dans le contexte système. Toutefois, si la machine redémarre pour une raison quelconque, elle est considérée comme une machine virtuelle non saine, et est supprimée. Pour plus d’informations, consultez Agents non sains.

Lorsque des agents ou des machines virtuelles ne parviennent pas à démarrer, ne peuvent pas se connecter à Azure DevOps ou se déconnectent de manière inattendue, Azure DevOps consigne les échecs dans l’onglet Diagnostics du pool d’agents et tente de supprimer la machine virtuelle associée. La configuration de mise en réseau, la personnalisation de l’image et les redémarrages en attente peuvent provoquer ces problèmes. Pour éviter le problème, désactivez la mise à jour logicielle sur l’image. Vous pouvez également vous connecter à la machine virtuelle pour déboguer et collecter des journaux pour vous aider à examiner le problème.

Vous pouvez voir plusieurs étiquettes comme _AzureDevOpsElasticPoolTimeStamp pour Virtual Machine Scale Sets dans la gestion des coûts

Lorsque le pool est créé, une étiquette est ajoutée au groupe identique pour marquer le groupe identique comme étant en cours d’utilisation (pour éviter que deux pools utilisent le même groupe identique), et une autre étiquette est ajoutée pour le timestamp qui se met à jour chaque fois que le travail de configuration s’exécute (toutes les deux heures).

Vous ne pouvez pas créer un pool d’agents de groupe identique et voyez un message d’erreur indiquant qu’un pool portant le même nom existe déjà

Vous pouvez obtenir un message d’erreur comme This virtual machine scale set is already in use by pool <pool name> parce que la balise existe toujours sur le groupe identique même après sa suppression. Lorsqu’un pool d’agents est supprimé, vous tentez de supprimer la balise du groupe identique, mais il s’agit d’une tentative d’effort optimale et vous abandonnez après trois nouvelles tentatives. En outre, il peut y avoir un intervalle maximal de deux heures pendant lequel un groupe de machines virtuelles identiques non utilisé par un pool d’agents ne peut toujours pas être affecté à un nouveau. Le correctif consiste à attendre que cet intervalle de temps soit passé ou à supprimer manuellement l’étiquette du groupe identique du Portail Azure. Lorsque vous affichez le groupe identique dans le Portail Azure, sélectionnez le lien Étiquettes à gauche et supprimez l’étiquette _AzureDevOpsElasticPool.

Le travail de maintenance des Virtual Machine Scale Sets ne s’exécute pas sur les agents ou n’obtient pas de journaux

Le travail de maintenance s’exécute une fois toutes les 24 heures. Il est possible que les machines virtuelles soient remplies avant cette heure. Envisagez d’augmenter la taille du disque sur la machine virtuelle et d’ajouter un script dans le pipeline pour supprimer le contenu.

Si vous spécifiez AzDevOps comme administrateur principal dans votre script pour Virtual Machine Scale Sets, vous pourriez observer des problèmes avec la configuration des agents sur les instances de l’ensemble d’échelles

Si vous spécifiez AzDevOps comme administrateur principal dans votre script pour le groupe de machines virtuelles identiques, vous pouvez observer des problèmes avec les configurations de l’agent sur les instances de groupe identique (le mot de passe de l’utilisateur est modifié s’il existe déjà).

Ce problème se produit parce que les scripts d’extension de l’agent tentent de créer l’utilisateur AzDevOps et de modifier son mot de passe.

L’installation de l’extension de l’agent échoue sur les instances de groupe identique en raison de la configuration de la sécurité réseau et du pare-feu

L’extension doit pouvoir télécharger les fichiers de l’agent de build à partir de https://vstsagentpackage.azureedge.net/agent, et l’agent de build doit pouvoir s’inscrire auprès d’Azure DevOps Services. Assurez-vous que cette URL et les adresses IP et URL associées à Azure DevOps Services sont ouvertes sur l’instance. Pour les adresses IP et URL qui doivent être débloquées sur votre pare-feu, consultez Adresses IP et URL de domaine autorisées.

Pourquoi mon script de configuration de l'agent de groupe identique appelle-t-il Add-MpPreference et configure-t-il Windows Defender sur l'agent ?

Pour améliorer les performances et la fiabilité, les scripts de configuration appellent Add-MpPreference avec un ExclusionPath contenant C:\ et D:\, qui désactive l’analyse planifiée et en temps réel de Windows Defender pour les fichiers de ces dossiers sur l’agent. Pour modifier le comportement par défaut, définissez une variable d’environnement nommée ELASTIC_POOLS_SKIP_DEFENDER_EXCLUSION sur true.

Je veux augmenter la taille de mon pool. Que dois-je prendre en compte ?

Avant d’augmenter la taille de votre pool, assurez-vous que le réseau virtuel Azure configuré pour votre pool de Microsoft Azure Virtual Machine Scale Sets dispose d’une plage d’espace d’adressage suffisante pour prendre en charge tous vos nouveaux agents. Si ce n’est pas le cas, vous pouvez obtenir une erreur similaire à Échec de l’augmentation de la capacité. Le sous-réseau azure-devops-agent-pool-fabrikam-fiber avec le préfixe d’adresse 12.123.45.224/28 n’a pas une capacité suffisante pour 5 adresses IP.