Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Le service Azure DevTest Labs améliore l’efficacité et l’efficacité des développeurs et des testeurs. Cet article se concentre sur la possibilité de revendiquer ou d’annuler la revendication de machines virtuelles dans Azure DevTest Labs. Il répertorie également différentes façons dont cette fonctionnalité améliore l’expérience utilisateur. Avant d’examiner différents scénarios dans lesquels cette fonctionnalité peut être utilisée, examinons ce qu’est la revendication et son fonctionnement.
Machines pouvant être revendiquées
Une machine pouvant être revendiquée est une machine virtuelle créée dans un laboratoire sans propriétaire. Une fois la machine revendiquée, l’utilisateur dispose d’une gamme complète d’options pour cette machine virtuelle. Lorsqu’un utilisateur réclame une machine, quelques modifications sont apportées. La machine virtuelle est déplacée de la liste des machines virtuelles pouvant être revendiquées vers la liste Mes machines virtuelles dans le portail Azure.
L'utilisateur peut se connecter à la machine virtuelle, personnaliser les artefacts, redémarrer, arrêter ou libérer la machine. Il existe plusieurs façons de rendre une machine virtuelle pouvant être revendiquée :
- Créer une machine et cesser de la revendiquer afin de la transférer vers le pool pouvant être revendiqué.
- Créez une machine virtuelle et placez-la dans le pool partagé à l’aide de paramètres avancés.
Il existe deux cas où les fonctionnalités de revendication/non revendication peuvent être utilisées efficacement. Le premier cas nécessite une conception et une planification plus approfondies pour être conçu et exécuté correctement. Et la seconde est plus situationnelle. Voici quelques exemples des différents cas.
Utilisation conçue de machines revendicables
- Développement / test de logiciels : Permettre aux développeurs ou aux testeurs d’être plus productifs en ayant configuré des machines prêtes et dans un état non revendiqué. Avoir un ensemble de machines virtuelles avec différentes configurations, outils nécessaires et avec le code le plus récent permet aux utilisateurs de revendiquer une machine virtuelle et de commencer à travailler sans avoir à passer le temps de configurer une machine. Avant que les machines virtuelles ne soient revendiquées, les machines sont approvisionnées, mais elles sont mises hors tension pour réduire le coût des machines utilisées moins souvent. Lorsque les machines virtuelles sont nécessaires, un utilisateur demande simplement la machine virtuelle, ce qui démarre la machine. L’option unclaim n’est pas aussi utile dans ce cas, car la création d’une machine virtuelle est souvent plus facile et moins coûteuse.
- Salles de classe/Laboratoires : Avoir des machines virtuelles préconfigurées pour une classe ou un laboratoire afin que les étudiants puissent immédiatement se connecter à une machine à l’aide du portail Azure. Une fois qu’un étudiant déclare une machine virtuelle, le laboratoire garantit qu’aucun utilisateur ne peut revendiquer la même machine. L’automatisation de ce processus garantit que le nombre requis de machines avec l’environnement spécifié est disponible. Si les étudiants ne se présentent pas ou sont en retard, les machines non revendiquées peuvent être conservées disponibles jusqu’à ce que la session soit terminée à un coût minimal. L’option unclaim n’est pas aussi efficace dans ce scénario, car la machine virtuelle est dans un état inconnu lorsque l’utilisateur précédent est terminé.
- Démonstrations: Utilisez des machines pour des démonstrations, où les machines du laboratoire sont configurées avec des environnements spécifiques. Cette fonctionnalité est utile lorsque plusieurs personnes peuvent donner une démonstration en même temps ou à des moments aléatoires, comme lors d’une conférence. L’option unclaim peut être utile dans cette situation, car la démonstration ne doit pas changer l’état de la machine, ce qui permet aux utilisateurs de retourner une machine virtuelle au pool pouvant être revendiqué pour la prochaine démonstration. Avec la machine non revendiquée étant désapprovisionnée et n'engendrant qu'un coût minimal, les machines virtuelles peuvent être laissées dans le laboratoire pendant des périodes plus longues.
- Travailleurs temporaires/contractuels : Autoriser les utilisateurs à utiliser un ordinateur. Lorsqu’ils quittent, ils retournent la machine virtuelle au pool pouvant être revendiqué sans perte de données. Avec la machine virtuelle non revendiquée, un autre utilisateur peut revendiquer la machine virtuelle et continuer ou passer en revue l’ordinateur pour obtenir des informations supplémentaires.
- En général: La possibilité d’avoir une source unique configure et déploie automatiquement des machines virtuelles, à une cadence spécifique, est utile dans de nombreuses situations différentes. Il existe plusieurs situations où la fonctionnalité revendication/non revendication permet aux utilisateurs d’être plus efficaces en ayant un processus automatisé pour générer les machines virtuelles dans un état non revendiqué avec une configuration définie. La ou les configurations peuvent inclure différents systèmes d’exploitation, langages, disques ou autres logiciels (artefacts) en fonction de vos besoins. La possibilité de revendiquer une machine virtuelle à partir du labo permet à l’utilisateur du labo d’obtenir un système correctement configuré sans passer le temps ou l’effort de configuration de l’ordinateur. Le gestionnaire de laboratoire peut utiliser l’état revendiqué des machines virtuelles pour améliorer le nombre de machines générées, nettoyer les machines et déterminer la priorité des configurations. Le Générateur d’images de machine virtuelle Azure est un bon exemple de processus automatisé de génération de machines virtuelles et d’images pour plusieurs laboratoires. Les scripts peuvent être modifiés pour exécuter l’une des situations suivantes avec les modifications appropriées ou être utilisés comme référence pour créer un système personnalisé.
Utilisation situationnelle des machines pouvant être revendiquées
- Utilisez la fonctionnalité de revendication/de non-revendication qui permet aux utilisateurs de passer le contrôle des machines d’un à l’autre et de ne pas avoir à savoir explicitement qui va récupérer l’ordinateur suivant.
- Développement, test et débogage d’un scénario dans lequel une configuration d’ordinateur spécifique peut reproduire un bogue, et l’ordinateur peut alors être libéré, permettant à un autre développeur de le revendiquer et de poursuivre le travail. Cette fonctionnalité est particulièrement utile, car plus de personnes travaillent à distance dans différentes régions du monde.
- Les membres de l’équipe peuvent travailler avec un seul environnement. Par exemple, vous pouvez configurer manuellement un environnement complexe qui ne peut pas être automatisé ou créer des ressources qui peuvent gérer uniquement les modifications d’une seule entrée, comme les images. Dans le passé, ce problème a été traité en ayant un ordinateur dédié opérationnel. La fonctionnalité pouvant être revendiquée est une amélioration du processus manuel en ayant un contrôle d’accès utilisateur intégré et une identification visuelle lorsqu’elle est disponible. Lorsqu’elle n’est pas déclarée, la machine virtuelle est déprovisionnée pour réduire les coûts.
- Disposer d’un disque de données attaché à une machine virtuelle. Chaque disque jusqu’à ~ 1 To de données permet de transmettre un grand volume de données sans avoir à copier ou à dupliquer les données. La machine virtuelle serait initialement créée avec un disque attaché qui disposait du grand volume de données. Tout utilisateur peut ensuite revendiquer l’ordinateur et accéder aux données. Lorsque vous avez terminé, libérez la machine virtuelle pour permettre à d'autres utilisateurs d'accéder à l'ordinateur.
L'utilisation de machines pouvant être revendiquées implique quelques précautions, le plus souvent au niveau de l'accès à la machine. Si l’ordinateur est joint à un domaine, l’utilisateur qui revendique l’ordinateur doit déjà avoir reçu l'autorisation d'accès, ce qui est généralement fait en accordant l'accès à un groupe qui regroupe tous les utilisateurs du laboratoire lors de la création de la machine virtuelle. Si la machine n’est pas jointe à un domaine, l’artefact Réinitialiser le mot de passe de machine virtuelle dans le référentiel public doit être exécuté pour ajouter l’utilisateur en tant qu’administrateur. Les artefacts peuvent être appliqués même après le démarrage ou la revendication de la machine.
Étapes suivantes
Consultez l’article suivant : Créer et gérer des machines virtuelles pouvant être revendiquées dans Azure DevTest Labs