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
• Une passerelle de bureau à distance pour les connexions à distance aux machines virtuelles (VM)
• Connectivité à un référentiel d’artefacts privés
• Autres composants de la plateforme en tant que service (PaaS) utilisés par les laboratoires

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 logiciels en tant que service (SaaS), une infrastructure en tant que service (IaaS) et des ressources PaaS. 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.

Connectivity components

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 pas être déplacées vers le cloud.
• Vous souhaitez joindre des machines virtuelles de labo à un domaine local.
• Vous souhaitez forcer tout le trafic réseau cloud via un pare-feu local pour la sécurité ou la 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 entreprises bloquent généralement les connexions sortantes au niveau du pare-feu d’entreprise. 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.

Networking components

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 méthode courante que les entreprises utilisent pour 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.

Scalability considerations

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 :

• Resource groups. 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. Il s’agit donc de la limite des machines virtuelles et des environnements dans un abonnement.

  Deux stratégies peuvent vous aider à rester dans les limites du groupe de ressources :

  • Placez toutes les machines virtuelles 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 peut vous aider à respecter les quotas de groupe de ressources et les quotas de type de ressource par groupe de ressources.

• Ressources par groupe de ressources, par type de ressource. La limite par défaut pour les ressources par groupe de ressources, par type de ressource est de 800. Si vous placez toutes les machines virtuelles dans le même groupe de ressources, vous atteignez cette limite beaucoup plus tôt, en particulier si les machines virtuelles ont de nombreux disques supplémentaires.

• Storage accounts. 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 de quota, vous pouvez créer autant de 500 comptes de stockage par région. Pour plus d’informations, consultez Augmenter les quotas du compte de stockage Azure.

• Role assignments. Une attribution de rôle donne à un utilisateur ou à un principal accès à une ressource. Azure a une limite de 4 000 attributions de rôles 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 obtient 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.

• API reads/writes. Vous pouvez automatiser Azure et DevTest Labs en utilisant des API REST, PowerShell, Azure CLI et le SDK Azure. Chaque abonnement Azure permet au maximum 12 000 demandes de lecture et 1 200 requêtes d’écriture par heure. Si vous automatisez DevTest Labs, vous pouvez atteindre la limite des demandes d’API.

Manageability considerations

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 laboratoires.

• 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 à des utilisateurs ce rôle au lieu d’un rôle lab 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 que pour d’autres fins. Par exemple, Azure Policy s’applique aux machines virtuelles que vous créez dans un laboratoire. 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.

Security considerations

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.

Next step

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