Architecture de référence d’entreprise pour Azure DevTest Labs

Cet article fournit une architecture de référence pour le déploiement d’Azure DevTest Labs en entreprise. L’architecture inclut les éléments clés suivants :

• Connectivité locale via Azure ExpressRoute
• Passerelle Bureau à distance pour se connecter à distance aux machines virtuelles
• Connectivité à un référentiel d’artefacts privés
• Autres composants PaaS (platform as a service) que les labos utilisent

Architecture

Le diagramme suivant illustre un déploiement en entreprise typique de DevTest Labs. Cette architecture connecte plusieurs labos dans différents abonnements Azure au réseau local d’une entreprise.

Composants DevTest Labs

DevTest Labs facilite et accélère pour les entreprises l’octroi d’accès aux ressources Azure. Chaque labo contient des ressources SaaS (software as a service), IaaS (infrastructure as a service) et PaaS (platform as a service). Les utilisateurs de labo peuvent créer et configurer des machines virtuelles, des environnements PaaS et des artefacts de machine virtuelle.

Dans le diagramme précédent, Team Lab 1 dans Azure Subscription 1 présente un exemple de composants Azure accessibles et utilisables par les labos. Pour plus d’informations, consultez À propos de DevTest Labs.

Composants de connectivité

Vous avez besoin d’une connectivité locale si vos labos doivent accéder à des ressources d’entreprise locales. Voici des cas d’utilisation courants :

• Certaines données locales ne peuvent migrer vers le cloud.
• Vous souhaitez joindre des machines virtuelles de labo à un domaine local.
• Vous souhaitez forcer le passage de tout le trafic réseau cloud via un pare-feu local pour des raisons de sécurité ou de conformité.

Cette architecture utilise ExpressRoute pour la connectivité au réseau local. Cependant, vous pouvez aussi utiliser un VPN site à site.

En local, une passerelle Bureau à distance active des connexions via le Protocole Bureau à distance (Remote Desktop Protocol, RDP) sortantes à DevTest Labs. Les pare-feu d’entreprise bloquent généralement les connexions sortantes au niveau du pare-feu. Pour activer la connectivité, vous devez :

• Utilisez une passerelle des services Bureau à distance, et autorisez l’adresse IP statique de l’équilibreur de charge de la passerelle.
• Utiliser un tunneling forcé pour rediriger tout le trafic RDP sur la connexion ExpressRoute ou VPN site à site. Le tunneling forcé est une fonctionnalité courante pour les déploiements de DevTest Labs à l’échelle d’une entreprise.

Composants de mise en réseau

Dans cette architecture, Microsoft Entra ID assure la gestion des identités et des accès sur tous les réseaux. Les machines virtuelles de labo ont généralement un compte administratif local pour l’accès. Si un domaine Microsoft Entra ID local ou Microsoft Entra Domain Services sont disponibles, vous pouvez joindre des machines virtuelles de labo au domaine. Les utilisateurs peuvent alors utiliser leurs identités basées sur le domaine pour se connecter aux machines virtuelles.

La topologie de mise en réseau Azure contrôle la manière dont les ressources de labo accèdent aux réseaux locaux et à Internet, et communiquent par ce biais. Cette architecture montre une façon courante pour les entreprises de mettre en réseau DevTest Labs. Les labos se connectent au réseau local avec des réseaux virtuels appairés dans une configuration hub-and-spoke, via la connexion ExpressRoute ou VPN site à site.

DevTest Labs utilisant directement le Réseau virtuel Azure, il n’existe aucune restriction quant à la configuration de l’infrastructure réseau. Vous pouvez configurer un groupe de sécurité réseau pour limiter le trafic cloud en fonction des adresses IP de source et de destination. Par exemple, vous pouvez autoriser uniquement le trafic provenant du réseau d’entreprise vers les réseaux du labo.

Considérations relatives à l’extensibilité

DevTest Labs n’a pas de quotas ou limites intégrés, mais d’autres ressources Azure que les labos utilisent ont des quotas d’abonnement. Dans un déploiement d’entreprise classique, vous avez besoin de plusieurs abonnements Azure pour couvrir un déploiement conséquent de DevTest Labs. Les entreprises atteignent généralement les quotas suivants :

• Groupes de ressources. DevTest Labs crée un groupe de ressources pour chaque nouvelle machine virtuelle, et les utilisateurs de labo créent des environnements dans des groupes de ressources. Les abonnements peuvent contenir jusqu’à 980 groupes de ressources, ce qui constitue la limite du nombre de machines virtuelles et d’environnements dans un abonnement.

  Deux stratégies peuvent vous aider à rester sous les limites de groupes de ressources :

  • Toutes les machines virtuelles vont dans le même groupe de ressources. Cette stratégie vous aide à respecter la limite de groupes de ressources, mais affecte la limite du type de ressource par groupe de ressources.
  • Utiliser des adresses IP publiques partagées. Si les machines virtuelles sont autorisées à avoir des adresses IP publiques, placez toutes les machines virtuelles de la même taille et de la même région dans le même groupe de ressources. Cette configuration permet de respecter les quotas de groupes de ressources et les quotas de types de ressources par ressource.

• Ressources par groupe de ressources par type de ressource. le nombre maximal par défaut des ressources par groupe de ressources et par type de ressources est fixé à 800. Le placement de toutes les machines virtuelles dans le même groupe de ressources atteint cette limite beaucoup plus tôt, en particulier si les machines virtuelles ont beaucoup de disques supplémentaires.

• Comptes de stockage. Chaque labo dans DevTest Labs est assorti d’un compte de stockage. Le quota Azure pour le nombre de comptes de stockage par région par abonnement est de 250 par défaut. Le nombre maximal de DevTest Labs dans une même région s’élève également à 250. Avec une augmentation du quota, vous pouvez créer jusqu’à 500 comptes de stockage par région. Pour plus d’informations, consultez Augmenter de quotas du compte de stockage Azure.

• Attributions de rôle. Une attribution de rôle donne à un utilisateur ou à un principal accès à une ressource. Azure impose une limite de 2 000 attributions de rôle par abonnement.

  Par défaut, DevTest Labs crée un groupe de ressources pour chaque machine virtuelle de labo. Le créateur de machine virtuelle reçoit l’autorisation propriétaire pour la machine virtuelle, et l’autorisation lecteur pour le groupe de ressources. Chaque machine virtuelle de laboratoire utilise donc deux attributions de rôles. L’octroi d’autorisations utilisateur au labo utilise également des attributions de rôles.

• Lectures/écritures d’API. Vous pouvez automatiser Azure et DevTest Labs en utilisant des API REST, PowerShell, Azure CLI et le SDK Azure. Chaque abonnement Azure autorise jusqu’à 12 000 demandes de lecture et 1 200 demandes d’écriture par heure. En automatisant DevTest Labs, vous pouvez atteindre la limite des demandes d’API.

Considérations relatives à la facilité de gestion

Vous pouvez utiliser le portail Azure pour gérer une seule instance DevTest Labs à la fois, mais des entreprises peuvent avoir plusieurs abonnements Azure et de nombreux labos à administrer. Un script d’automatisation est nécessaire pour apporter des modifications à tous les labos de manière cohérente.

Voici quelques exemples d’utilisation de scripts dans des déploiements DevTest Labs :

• Modification de paramètres de labo. Mettez à jour un paramètre de labo spécifique dans tous les labos à l’aide de scripts PowerShell, d’Azure CLI ou d’API REST. Par exemple, mettez à jour tous les labos afin d’autoriser une nouvelle taille d’instance de machine virtuelle.

• Mise à jour de jetons d’accès personnel (PAT) au référentiel d’artefacts. Un PAT pour référentiel Git expire généralement après 90 jours, un an ou deux ans. Pour garantir la continuité, il est important d’étendre le PAT. Vous pouvez également créer un nouveau PAT et utiliser l’automatisation pour l’appliquer à tous les labos.

• Restriction des modifications apportées aux paramètres de labo. Pour restreindre certains paramètres, par exemple, l’autorisation d’utilisation d’image de la Place de marché, vous pouvez utiliser Azure Policy pour empêcher la modification d’un type de ressource. Vous pouvez également créer un rôle personnalisé et accorder aux utilisateurs ce rôle au lieu du rôle de labo intégré. Vous pouvez restreindre les modifications pour la plupart des paramètres de labo, tels que le support interne, les annonces de labo et les tailles de machine virtuelle autorisées.

• Application d’une convention d’affectation de noms pour les machines virtuelles. Vous pouvez utiliser Azure Policy pour spécifier un modèle d’affectation de noms facilitant l’identification de machines virtuelles dans des environnements cloud.

Vous gérez les ressources Azure pour DevTest Labs de la même façon qu’à d’autres fins. Par exemple, Azure Policy s’applique aux machines virtuelles que vous créez dans un labo. Microsoft Defender pour le cloud peut rendre compte de la conformité des machines virtuelles. Le service Sauvegarde Azure peut fournir des sauvegardes régulières pour les machines virtuelles de laboratoire.

Considérations relatives à la sécurité

DevTest Labs tire automatiquement parti des fonctionnalités de sécurité Azure intégrées. Pour exiger que les connexions Bureau à distance entrantes proviennent uniquement du réseau de l’entreprise, vous pouvez ajouter un groupe de sécurité réseau au réseau virtuel sur la passerelle Bureau à distance.

Un autre aspect de la sécurité à prendre en considération est le niveau d’autorisation que vous accordez aux utilisateurs de labo. Les propriétaires de labo utilisent un contrôle d’accès en fonction du rôle Azure (RBAC Azure) pour attribuer des rôles aux utilisateurs et définir des autorisations de ressources et de niveau d’accès. Les autorisations DevTest Labs les plus courantes sont Propriétaire, Contributeur et Utilisateur. Vous pouvez également créer et attribuer des rôles personnalisés. Pour plus d’informations, consultez Ajouter des propriétaires et des utilisateurs dans Azure DevTest Labs.

Étapes suivantes

Consultez l’article suivant de cette série : Fournir une preuve de concept.