Scale up de votre infrastructure Azure DevTest Labs

L’orchestration d’une implémentation réussie de DevTest Labs à l’échelle d’une entreprise nécessite la prise en considération de points de décision clés et la planification d’une approche pour déployer et implémenter rapidement Azure DevTest Labs.

Cet article décrit les points de décision clés que vous devez prendre en compte pour planifier votre implémentation et propose une approche de déploiement recommandée.

Points de décision clés

Avant d’implémenter DevTest Labs à l’échelle de l’entreprise, plusieurs points de décision clés sont à examiner. La compréhension de ces points de décision à un niveau hiérarchique élevé éclaire les décisions de conception à venir de l’organisation. Toutefois, ces points ne doivent pas retenir une organisation de démarrer une preuve de concept.

Les trois domaines les plus importants en matière de planification initiale de scale-up sont :

• Le réseau et la sécurité
• La topologie de l’abonnement
• Rôles et responsabilités

Le réseau et la sécurité

La mise en réseau et la sécurité sont des pierres angulaires pour toutes les organisations. Alors qu’un déploiement à l’échelle de l’entreprise nécessite une analyse beaucoup plus approfondie, une preuve de concept réussie ne demande que peu de conditions. Portez votre attention sur les thèmes suivants :

• Abonnement Azure : pour déployer DevTest Labs, vous devez avoir accès à un abonnement Azure avec les droits appropriés de création des ressources. Il existe plusieurs façons d’accéder aux abonnements Azure, y compris un Accord Entreprise et l’option de paiement au fur et à mesure. Pour plus d’informations sur l’accès à un abonnement Azure, consultez Licences Azure pour l’entreprise.
• Accès aux ressources locales : certaines organisations ont besoin de donner un accès aux ressources locales à leurs ressources dans DevTest Labs. Vous avez besoin d’une connexion sécurisée entre votre environnement local et Azure. Il est important que vous définissiez/configuriez un VPN ou une connexion Express Route avant de commencer. Pour en savoir plus, consultez Vue d’ensemble des Réseaux virtuels.
• Exigences de sécurité supplémentaires : les autres exigences de sécurité (stratégies de l’ordinateur, accès à des adresses IP publiques, connexion à internet...) sont des scénarios qui nécessiteront peut-être d’être passés en revue avant d’implémenter une preuve de concept.

La topologie de l’abonnement

La topologie de l’abonnement est un élément de conception essentiel lors du déploiement de DevTest Labs dans l’entreprise. Il n’est cependant pas nécessaire de consolider toutes les décisions jusqu’à l’exécution d’une preuve de concept. Lorsque vous évaluez le nombre d’abonnements requis pour une implémentation dans l’entreprise, deux extrêmes sont possibles :

• Un abonnement pour toute l’organisation
• Un abonnement par utilisateur

Nous allons ensuite mettre en avant les avantages de chaque approche.

Abonnement unique

Souvent, cette approche n’est pas facile à gérer pour une grande entreprise. Toutefois, la limitation du nombre d’abonnements offre les avantages suivants :

• Prévisibilité des coûts pour l’entreprise. La budgétisation est beaucoup plus facile avec un seul abonnement, car toutes les ressources se trouvent dans un seul pool. Cette approche simplifie la prise de décision concernant le moment de mettre en place des mesures de contrôle des coût au cours du cycle de facturation.
• La gestion des machines virtuelles, des artefacts, des formules, de la configuration réseau, des autorisations et des stratégies est plus facile, car les mises à jour ne sont nécessaires que dans un seul abonnement et non pas dans plusieurs.
• La mise en réseau demande un effort moins important s’agissant d’un abonnement unique pour les entreprises où la connectivité locale est obligatoire. La connexion de réseaux virtuels entre différents abonnements (modèle hub-and-spoke), requise pour les abonnements supplémentaires, nécessite davantage de configuration, de gestion et d’espaces d’adressage IP.
• La collaboration d’équipe est plus facile lorsque tout le monde travaille dans le même abonnement. Par exemple, il est plus facile de réaffecter une machine virtuelle à un collègue ou de partager des ressources d’équipe.

Un abonnement par utilisateur

Un abonnement distinct par utilisateur fournit des opportunités similaires à l’autre extrême. Les avantages d’avoir plusieurs abonnements incluent :

• Les quotas de mise à l’échelle Azure n’empêchent pas l’adoption. Par exemple, à ce jour, Azure autorise 200 comptes de stockage par abonnement. Il existe des quotas opérationnels pour la plupart des services Azure (nombre d’entre eux peuvent être personnalisés, mais certains non). Dans ce modèle d’un abonnement par utilisateur, il est très peu probable que la plupart des quotas soient atteints. Pour plus d’informations sur les quotas Azure actuels, consultez Abonnement Azure et limites, quotas et contraintes du service.
• Les rétrofacturations à des développeurs individuels ou des groupes de développeurs sont facilitées, permettant aux organisations d’intégrer les coûts à l’aide de leur modèle actuel.
• La propriété et les autorisations relatives aux environnements DevTest Labs sont simples. Vous donnez aux développeurs un accès de niveau abonnement et ils sont entièrement responsables de tout, y compris la configuration du réseau, les stratégies de laboratoire et la gestion des machines virtuelles.

Dans l’entreprise, les contraintes aux extrêmes du spectre peuvent être importantes. Par conséquent, vous devrez peut-être configurer les abonnements de façon à vous trouver au milieu de ces extrêmes. En guise de meilleure pratique, l’objectif d’une organisation est d’utiliser le plus petit nombre d’abonnements possibles. N’oubliez pas les fonctions de forçage, qui augmentent le nombre total d’abonnements. À nouveau, la topologie de l’abonnement est critique pour le déploiement en entreprise de DevTest Labs mais ne doit pas différer une preuve de concept. Vous trouverez des détails supplémentaires dans l’article Gouvernance sur la façon de décider de la granularité d’abonnement et du laboratoire dans l’organisation.

Rôles et responsabilités

Une preuve de concept DevTest Labs comporte trois rôles principaux avec des responsabilités définies : propriétaire de l’abonnement, propriétaire DevTest Labs, utilisateur DevTest Labs et éventuellement un contributeur.

• Propriétaire de l’abonnement : le propriétaire de l’abonnement dispose des droits d’administrer un abonnement Azure, y compris d’affecter les utilisateurs, de gérer les stratégies, de créer et gérer la topologie de réseau et de demander des augmentations de quota. Pour plus d’informations, consultez cet article.
• Propriétaire DevTest Labs : le propriétaire DevTest Labs dispose d’un accès administratif complet au laboratoire. Cette personne est responsable de l’ajout/de la suppression des utilisateurs, des paramètres des coûts de gestion, des paramètres de laboratoire généraux et d’autres tâches basées sur la machine virtuelle/l’artefact. Un propriétaire de laboratoire a également tous les droits d’un utilisateur DevTest Labs.
• Utilisateur DevTest Labs : l’utilisateur DevTest Labs peut créer et consommer les machines virtuelles dans le laboratoire. Ces personnes disposent de pouvoirs d’administration minimum sur les machines virtuelles qu’ils créent (démarrer/arrêter/supprimer/configurer leurs machines virtuelles). Les utilisateurs ne peuvent pas gérer les machines virtuelles d’autres utilisateurs.

Orchestrer l’implémentation de DevTest Labs

Cette section présente l’approche recommandée pour déployer et implémenter rapidement Azure DevTest Labs. L’illustration suivante met l’accent sur l’ensemble du processus sous forme de conseils prescriptifs tout en observant la flexibilité pour prendre en charge différents scénarios et différentes exigences du secteur.

Hypothèses

Cet article suppose que les éléments suivants sont en place avant d’implémenter un pilote DevTest Labs :

• Abonnement Azure : l’équipe pilote a accès au déploiement des ressources dans un abonnement Azure. Si les charges de travail sont uniquement des charges de développement et de test, il est recommandé de sélectionner l’offre Enterprise DevTest pour obtenir des images disponibles supplémentaires et des tarifs inférieurs sur les machines virtuelles Windows.
• Accès local : si nécessaire, l’accès local a déjà été configuré. Il peut être établi via une connexion VPN de site à site ou ExpressRoute. Établir la connectivité via Express Route prend généralement plusieurs semaines, il est recommandé qu’ExpressRoute soit déjà en place avant de démarrer le projet.
• Équipes pilotes : les équipes de projet de développement initial qui utilisent DevTest Labs ont été identifiées, ainsi que les activités de développement ou de test applicables et des exigences/objectifs ont été établis pour ces équipes.

Phase 1 : établir la conception et la topologie de réseau initiales

La première chose à faire lors du déploiement d’une solution Azure DevTest Labs est d’établir la connectivité planifiée pour les machines virtuelles. Voici les procédures à suivre :

1. Définir les plages d’adresses IP initiales qui sont assignées à l’abonnement DevTest dans Azure. Cette étape nécessite de prévoir l’utilisation attendue en nombre de machines virtuelles afin de pouvoir fournir un bloc assez grand pour une expansion future.
2. Identifier les méthodes d’accès souhaité dans les DevTest Labs (par exemple, l’accès externe / interne). Un point clé de cette étape consiste à déterminer si les machines virtuelles ont des adresses IP publiques (autrement dit, accessibles directement à partir d’internet).
3. Identifier et établir des méthodes de connectivité en local et avec le reste de l’environnement cloud Azure. Si le routage forcé avec ExpressRoute est activé, il est probable que les machines virtuelles nécessitent des configurations de proxy appropriées pour traverser le pare-feu d’entreprise.
4. Si les machines virtuelles doivent être jointes à un domaine, déterminer si elles sont jointes un domaine basé sur le cloud (services d’annuaire Microsoft Entra, par exemple) ou un domaine local. Au niveau local, déterminer quelle unité d’organisation (UO) dans Active Directory est jointe par les machines virtuelles. En outre, vérifier que les utilisateurs ont accès aux jonctions (ou établir un compte de service qui a la possibilité de créer des enregistrements machine dans le domaine)

Phase 2 : déployer le laboratoire pilote

Une fois la topologie du réseau en place, le premier laboratoire/pilote peut être créé en suivant les étapes suivantes :

1. Créer un environnement DevTest Labs initial.
2. Déterminer les images et les tailles de machine virtuelle autorisées pour une utilisation avec le laboratoire. Décider si les images personnalisées peuvent être téléchargées dans Azure pour une utilisation avec DevTest Labs.
3. Sécurisez l’accès au laboratoire en créant un contrôle d’accès en fonction du rôle Azure initial (Azure RBAC) pour le laboratoire (propriétaires de laboratoires et utilisateurs de laboratoire). Nous vous recommandons d’utiliser des comptes Active Directory synchronisés avec Microsoft Entra ID pour l’identité avec DevTest Labs.
4. Configurer DevTest pour utiliser des stratégies comme les planifications, la gestion des coûts, les machines virtuelles revendicables, les images personnalisées ou les formules.
5. Établir un référentiel en ligne tel que Azure Repos/Git.
6. Décider de l’utilisation de référentiels publics ou privés ou d’une combinaison des deux. Organiser les modèles JSON pour les déploiements et le maintien en état à long terme.
7. Si besoin, créer des artefacts personnalisés. Cette étape est facultative.

Phase 3 : documentation, support, apprentissage et amélioration

Les équipes pilotes initiales peuvent nécessiter une prise en charge approfondie pour débuter. Basez-vous sur leurs expériences pour vous assurer que la documentation et le support appropriés sont en place pour un lancement continu d’Azure DevTest Labs.

1. Présenter les nouvelles ressources DevTest Labs (démonstrations, documentation) aux équipes pilotes
2. Selon les expériences des équipes pilote, planifier et fournir une documentation en fonction des besoins
3. Formaliser le processus pour l’intégration des nouvelles équipes (création et configuration des laboratoires, accès, etc.)
4. Selon l’adoption initiale, vérifier que la prévision d’origine de l’espace d’adressage IP est toujours raisonnable et juste
5. S’assurer que les révisions de conformité et de sécurité appropriées ont été conduites

Étapes suivantes

Voir l’article suivant de cette série : Gouvernance de l’infrastructure Azure DevTest Labs