Gouvernance de l’infrastructure Azure DevTest Labs

Cet article traite de l’alignement et de la gestion des ressources pour DevTest Labs au sein de votre organisation.

Ressources

Aligner des ressources DevTest Labs dans un abonnement Azure

Avant qu’une organisation utilise Azure pour le développement général d’applications, les planificateurs informatiques doivent examiner comment intégrer la fonctionnalité au portefeuille global des services. L’examen doit prendre en compte les problématiques suivantes :

• Comment mesurer les coûts associés au cycle de vie du développement d’applications ?
• Comment l’organisation aligne-t-elle les offres de service proposées sur la stratégie de sécurité de l’entreprise ?
• La segmentation est-elle nécessaire pour séparer les environnements de développement et de production ?
• Quels contrôles sont introduits pour faciliter à long terme la gestion, la stabilité et la croissance ?

La première pratique recommandée est d’examiner la taxonomie Azure des organisations. Cette taxonomie souligne les divisions entre les abonnements de développement et de production. Dans le diagramme suivant, la taxonomie suggérée permet une séparation logique entre l’environnement de développement/test et celui de production. Grâce à cette approche, une organisation peut introduire des codes de facturation, qui lui permettront d’effectuer un suivi des coûts associés à chaque environnement séparément. Pour plus d’informations, consultez la section sur la gouvernance normative de l’abonnement. En outre, vous pouvez utiliser les balises Azure pour organiser les ressources à des fins de suivi et de facturation.

La deuxième pratique recommandée consiste à activer l’abonnement DevTest au sein du portail Azure Enterprise. Elle permet à une organisation d’exécuter des systèmes d’exploitation clients qui ne sont en général pas disponibles dans un abonnement d’entreprise Azure. Utilisez ensuite des logiciels d’entreprise où vous payez uniquement pour le calcul sans vous soucier des licences. Cela garantit que la facturation pour les services désignés (y compris les images de galerie dans les systèmes IaaS telles que Microsoft SQL Server) est basée sur la consommation uniquement. Pour accéder à plus d’informations sur l’abonnement Azure DevTest, cliquez ici pour les clients Contrat Entreprise (EA) et cliquez ici pour les clients Go.

Ce modèle offre à une organisation la flexibilité nécessaire pour déployer Azure DevTest Labs à grande échelle. Une organisation peut prendre en charge des centaines de laboratoires pour différentes entités commerciales, avec 100 à 1 000 machines virtuelles s’exécutant en parallèle. Le modèle promeut la notion d’une solution de laboratoire d’entreprise centralisée, qui permet de partager les mêmes principes relatifs à la gestion de la configuration et aux contrôles de sécurité.

Ce modèle garantit également que l’organisation n’épuise pas ses limites de ressources associées à son abonnement Azure. Pour plus d’informations sur l’abonnement et les limites du service, consultez Abonnement Azure et limites, quotas et contraintes du service. Le processus d’approvisionnement de DevTest Labs peut utiliser un grand nombre de groupes de ressources. Vous pouvez demander l’augmentation des limites en effectuant une demande de support dans l’abonnement Azure DevTest. Les ressources au sein de l’abonnement de production ne sont pas affectées à mesure que l’utilisation de l’abonnement de développement augmente. Pour plus d’informations sur le scaling de DevTest Labs, consultez la section Scaling des quotas et des limites dans DevTest Labs.

Une limite de niveau abonnement courante qui doit être prise en compte est la façon dont les affectations de plage d’adresses IP réseau sont allouées pour prendre en charge les abonnements de développement et de production. Ces affectations doivent expliquer la croissance au fil du temps (en partant du principe qu’il existe une connectivité locale ou une autre topologie de mise en réseau qui oblige l’entreprise à gérer sa pile de mise en réseau au lieu de définir par défaut sur la mise en œuvre d’Azure). La pratique recommandée est d’avoir plusieurs réseaux virtuels qui disposent d’un grand préfixe d’adresse IP. Ce grand préfixe est affecté à plusieurs sous-réseaux volumineux et divisé entre eux. Cette méthode est mieux que d’avoir plusieurs réseaux virtuels avec de petits sous-réseaux. Par exemple, avec 10 abonnements, vous pouvez définir 10 réseaux virtuels (un pour chaque abonnement). Tous les labos qui ne nécessitent pas d’isolation peuvent partager le même sous-réseau sur le réseau virtuel de l’abonnement.

Nombre d’utilisateurs par laboratoire et nombre de laboratoires par organisation

Les départements et les groupes de développement associés au même projet de développement doivent être rattachés au même labo. Cela permet d’appliquer les mêmes types de stratégies, d’images et de stratégies d’arrêt aux deux groupes.

Vous serez peut-être amené à prendre en compte des limites géographiques. Par exemple, les développeurs du nord-est des États-Unis (US) peuvent utiliser un laboratoire configuré dans USA Est2. Par ailleurs, les développeurs de Dallas (Texas) et Denver (Colorado) peuvent être redirigés afin d’utiliser une ressource de USA Centre Sud. S’il existe un travail collaboratif avec un tiers externe, ils peuvent être affectés à un labo qui n’est pas utilisé par les développeurs internes.

Vous pouvez également utiliser un labo pour un projet spécifique au sein d’Azure DevOps Projects. Vous appliquez ensuite la sécurité via un groupe Microsoft Entra spécifié, qui autorise l’accès aux deux ensembles de ressources. Le réseau virtuel attribué au laboratoire peut constituer une autre limite permettant de consolider les utilisateurs.

Empêcher la suppression de ressources

Définissez des autorisations au niveau du labo afin que seuls les utilisateurs autorisés puissent supprimer des ressources ou modifier les stratégies de labo. Les développeurs doivent être placés dans le groupe DevTest Labs Users (Utilisateurs DevTest Labs). Le développeur en chef ou le responsable de l’infrastructure doit correspondre au titre de DevTest Labs Owner (Propriétaire DevTest Labs). Nous vous conseillons de ne pas avoir plus de deux propriétaires de laboratoire. Cette stratégie s’étend au référentiel de code pour éviter toute corruption. Les utilisateurs du labo sont autorisés à utiliser des ressources, mais ils ne peuvent pas mettre à jour les stratégies du labo. Consultez l’article suivant, qui répertorie les rôles et les droits dont chaque groupe intégré dispose au sein d’un laboratoire : Ajouter des propriétaires et des utilisateurs dans Azure DevTest Labs.

Gérer le coût et la propriété

Le coût et l’appartenance sont les principaux éléments à prendre en compte lors de la création de vos environnements de développement et de test. Dans cette section, vous trouvez des informations qui vous aideront à optimiser les coûts et à aligner l’appartenance au sein de votre environnement.

Optimiser le coût

Plusieurs fonctionnalités intégrées de DevTest Labs vous aident à optimiser les coûts. Consultez les articles sur la gestion du coût, les seuils et les stratégies afin de limiter des activités des utilisateurs.

Si vous utilisez DevTest Labs pour des charges de travail de développement et de test, songez à tirer parti de l’avantage de l’abonnement Enterprise Dev/Test inclus dans votre Contrat Entreprise. Ou bien, si vous payez à l’utilisation, vous pouvez également considérer l’offre DevTest assortie d’un paiement à l’utilisation.

Cette approche offre plusieurs avantages :

• Tarifs Dev/Test inférieurs préférentiels sur les machines virtuelles, les services cloud, HDInsight, App Service et Logic Apps sous Windows
• Tarifs de contrat Entreprise (EA) avantageux sur d’autres services Azure
• Accès aux images Dev/Test exclusives de la galerie, par exemple Windows 8.1 et Windows 10

Seuls les abonnés Visual Studio actifs (abonnements standard, abonnements cloud annuels et mensuels) peuvent utiliser les ressources Azure exécutées dans le cadre d’un abonnement Enterprise Dev/Test. Toutefois, les utilisateurs finaux peuvent accéder à l’application pour formuler des commentaires ou effectuer des tests d’acceptation. Vous pouvez utiliser les ressources de cet abonnement uniquement à des fins de développement et de test d’applications. Il n’existe aucune garantie quant à la durée de bon fonctionnement.

Si vous décidez d’utiliser l’offre DevTest, n’utilisez cet avantage qu’à des fins de développement et de test de vos applications. L’utilisation dans le cadre de l’abonnement n’est pas associée à un contrat de niveau de service avec compensations financières, sauf au sein d’Azure DevOps et de HockeyApp.

Définir un accès en fonction du rôle au sein de votre organisation

L’équipe informatique centrale doit posséder uniquement ce qui est nécessaire, et permettre aux équipes de projet et d’application de disposer du niveau de contrôle dont elles ont besoin. En règle générale, cela signifie que le centre informatique possède l’abonnement et gère les fonctions informatiques clés telles que les configurations de mise en réseau. L’ensemble de propriétaires pour un abonnement doit être réduit. Ces propriétaires peuvent désigner d’autres propriétaires si nécessaire, ou appliquer des stratégies de niveau abonnement, par exemple « Aucune adresse IP publique ».

Un sous-ensemble d’utilisateurs peut nécessiter un accès à un abonnement, comme le support de niveau 1 ou 2. Dans ce cas, nous vous recommandons d’accorder à ces utilisateurs l’accès contributeur afin qu’ils puissent gérer les ressources, mais pas attribuer des accès aux utilisateurs ou ajuster les stratégies.

Les propriétaires de ressources DevTest Labs doivent être proches de l’équipe du projet ou de l’application. Ils comprennent les exigences liées à la machine et aux logiciels. Dans la plupart des organisations, le propriétaire de cette ressource DevTest Labs dirige également le projet ou le développement. Ce propriétaire peut gérer les utilisateurs et les stratégies dans l’environnement de laboratoire, ainsi que toutes les machines virtuelles dans l’environnement DevTest Labs.

Ajoutez des membres de l’équipe du projet et de l’application au rôle Utilisateurs de DevTest Labs. Ces utilisateurs peuvent créer des machines virtuelles conformes aux stratégies du laboratoire et de l’abonnement. Les utilisateurs peuvent également gérer leurs propres machines virtuelles, mais pas des machines virtuelles appartenant à d’autres utilisateurs.

Pour plus d’informations, consultez Structure d’entreprise Azure : gouvernance normative de l’abonnement.

Stratégie d’entreprise et conformité

Cette section fournit des conseils concernant la gouvernance de la stratégie et la conformité de l’entreprise pour l’infrastructure Azure DevTest Labs.

Référentiel d’artefacts public/privé

Le référentiel d’artefacts public fournit un ensemble initial de progiciels les plus couramment utilisés. Il permet un déploiement rapide sans avoir besoin de consacrer beaucoup de temps à la reproduction d’outils de développement et de compléments courants. Vous pouvez choisir de déployer leur propre référentiel privé. Vous pouvez utiliser un référentiel public avec un référentiel privé en parallèle. Vous pouvez également choisir de désactiver le référentiel public. Les critères de déploiement d’un référentiel privé doivent reposer sur les questions et les considérations suivantes :

• L’organisation doit-elle disposer de logiciels d’entreprise sous licence dans le cadre de son offre DevTest Labs ? Dans l’affirmative, un référentiel privé doit être créé.
• L’organisation développe-t-elle un logiciel personnalisé assurant une fonction particulière nécessaire dans le cadre du processus général d’approvisionnement ? Dans l’affirmative, un référentiel privé doit être déployé.
• Si la stratégie de gouvernance de l’organisation exige l’isolation et que la configuration des référentiels externes n’est pas directement gérée par l’organisation, un référentiel privé d’artefacts doit être déployé. Dans le cadre de ce processus, il est possible de copier une version initiale du référentiel public et de l’intégrer au référentiel privé. Le référentiel public peut ensuite être désactivé afin que personne ne puisse plus y accéder au sein de l’organisation. Cette approche oblige tous les utilisateurs de l’organisation à ne disposer que d’un seul référentiel approuvé par l’organisation et à limiter la dérive des configurations.

Référentiel unique ou référentiels multiples

Dans le cadre de la stratégie générale de gouvernance et de la gestion des configurations au sein de votre organisation, nous vous recommandons d’utiliser un référentiel centralisé. Lorsque plusieurs référentiels sont utilisés, ils peuvent au fil du temps se transformer en silos de logiciels non managés. Avec un référentiel central, plusieurs équipes peuvent utiliser les artefacts de ce référentiel pour leurs projets. Il renforce la normalisation, la sécurité et la facilité de gestion. Cela permet également d’éviter de faire double emploi. Dans le cadre de la centralisation, nous recommandons les mesures suivantes pour la gestion et la viabilité à long terme :

• Associez Azure Repos au même locataire Microsoft Entra que celui utilisé par l’abonnement Azure pour l’authentification et l’autorisation.
• Créez un groupe nommé Tous les développeurs DevTest Labs dans Microsoft Entra ID qui est géré de façon centralisée. Tous les développeurs qui contribuent au développement d’artefacts doivent être placés dans ce groupe.
• Le même groupe Microsoft Entra peut être utilisé pour donner accès au dépôt Azure Repos et au labo.
• Dans Azure Repos, la création de branches ou la duplication doit permettre de séparer un dépôt de développement du dépôt de production principal. Le contenu n’est ajouté à la branche primaire qu’avec une requête d’extraction après un examen approprié du code. Une fois la modification approuvée par l’examinateur du code, le code actualisé est fusionné par un développeur principal responsable de la maintenance de la branche primaire.

Stratégies de sécurité de l’entreprise

Une organisation peut appliquer des stratégies de sécurité d’entreprise :

• Élaboration et publication d’une stratégie de sécurité exhaustive. La stratégie énonce les règles d’utilisation acceptable en ce qui a trait à l’utilisation des logiciels et des ressources du cloud. Elle définit également ce qui la contrevient de façon évidente.
• En développant une image personnalisée, des artefacts personnalisés et un processus de déploiement permettant l’orchestration dans le domaine de la sécurité qui est défini avec un annuaire actif. Cette démarche permet de faire respecter les limites de l’entreprise et d’établir un ensemble commun de contrôles en matière d’environnement. Il s’agit des contrôles relatifs à l’environnement qu’un développeur peut prendre en compte dans le cadre de l’élaboration et du suivi d’un cycle de vie de développement sécurisé dans l’ensemble de son processus. L’objectif n’est pas de fournir un environnement qui soit trop contraignant et susceptible d’entraver le développement, mais un ensemble raisonnable de contrôles. Les stratégies de groupe de l’unité d’organisation (OU) qui héberge les machines virtuelles du laboratoire peuvent constituer un sous-ensemble de toutes les stratégies de groupe qui se trouvent en production. Ils peuvent également constituer un autre ensemble permettant de limiter de façon appropriée tous les risques identifiés.

Intégrité des données

Une organisation peut garantir l’intégrité des données pour que les développeurs distants ne puissent ni supprimer du code, ni installer des logiciels malveillants ou non approuvés. Il existe plusieurs couches de contrôle pour limiter les menaces liées aux consultants externes, aux prestataires ou aux employés qui se connectent à distance pour collaborer dans DevTest Labs.

Comme indiqué précédemment, la première étape consiste à élaborer et à définir une stratégie d’utilisation acceptable qui décrit clairement les sanctions en cas de violation de celle-ci.

La première couche de contrôles de l’accès à distance consiste à appliquer une stratégie d’accès à distance via une connexion VPN qui n’est pas directement connectée au laboratoire.

La deuxième couche de contrôles consiste à appliquer un ensemble d’objets de stratégie de groupe qui empêchent de copier-coller sur le bureau distant. Une stratégie de réseau peut être implémentée afin de ne pas autoriser les services sortants de l’environnement comme les services FTP et RDP ne faisant pas partie de l’environnement. Le routage défini par l’utilisateur peut contraindre l’ensemble du trafic réseau Azure à revenir en local, mais le routage ne peut pas tenir compte de toutes les URL susceptibles d’autoriser des téléchargements de données sans un contrôle via proxy permettant d’analyser les contenus et les sessions. Les adresses IP publiques peuvent être restreintes au sein du réseau virtuel prenant en charge DevTest Labs afin d’éviter le pontage d’une ressource réseau externe.

En définitive, le même type de restrictions doit être appliqué dans toute l’organisation qui doit également tenir compte de toutes les méthodes possibles de supports amovibles ou d’URL externes susceptibles d’accepter une publication de contenu. Consultez votre professionnel de la sécurité afin d’examiner et de mettre en œuvre une stratégie en matière de sécurité. Pour obtenir davantage de suggestions, consultez la section Cybersécurité Microsoft.

Intégration et migration d’applications

Une vois votre environnement de développement/test en place, posez-vous les questions suivantes :

• Comment utilisez-vous l’environnement dans votre équipe de projet ?
• Que faites-vous pour respecter les stratégies organisationnelles requises et préserver l’agilité pour valoriser votre application ?

Images Place de marché Microsoft Azure ou images personnalisées

Par défaut, utilisez une image Place de marché Azure, sauf si vous avez des impératifs particuliers ou des exigences organisationnelles. Voici quelques exemples communs :

• Configuration logicielle complexe qui requiert l’intégration d’une application dans l’image de base.
• L’installation et la configuration d’une application peut prendre plusieurs heures, ce qui retarde d’autant plus le temps d’ajout d’une image Place de marché Microsoft Azure.
• Les développeurs et les testeurs ont besoin d’accéder rapidement à une machine virtuelle et souhaitent minimiser la durée de configuration d’une nouvelle machine virtuelle.
• Conformité ou conditions réglementaires (par exemple, stratégies de sécurité) qui doivent être en place pour toutes les machines.

Songez à utiliser les images personnalisées avec précaution. Elles ajoutent de la complexité, car vous devez maintenant gérer les fichiers VHD de ces images de base sous-jacentes. Vous devez également appliquer des mises à jour logicielles à ces images de base. Celles-ci incluent les nouvelles mises à jour du système d’exploitation ainsi que toutes les mises à jour ou modifications de configuration nécessaires au package logiciel lui-même.

Formule ou image personnalisée

En général, les facteurs décisifs dans ce scénario sont le coût et la réutilisation.

Vous pouvez réduire le coût en créant une image personnalisée dans les cas suivants :

• De nombreux utilisateurs ou laboratoires requièrent l’image.
• L’image requise présente un grand nombre de logiciels par-dessus l’image de base.

Cette solution signifie que vous créez l’image une seule fois. Une image personnalisée réduit le temps de configuration de la machine virtuelle. Vous n’avez pas à exposer de coûts pour l’exécution de la machine virtuelle pendant la configuration.

Un autre facteur est la fréquence des modifications apportées à votre package logiciel. Si vous générez des builds quotidiennes et s’il faut que les logiciels résident sur les machines virtuelles de vos utilisateurs, envisagez d’utiliser une formule au lieu d’une image personnalisée.

Modèles de configuration du réseau

Quand vous faites en sorte que les machines virtuelles de développement et de test ne puissent pas accéder à l’Internet public, deux aspects sont à prendre en compte : le trafic entrant et le trafic sortant.

Trafic entrant : si la machine virtuelle n’a pas d’adresse IP publique, elle n’est pas accessible via Internet. Une approche courante consiste à définir une stratégie au niveau abonnement pour qu’aucun utilisateur ne puisse créer une adresse IP publique.

Trafic sortant : si vous voulez éviter que des machines virtuelles accèdent directement à l’Internet public, et forcer le trafic à passer par un pare-feu d’entreprise, vous pouvez acheminer le trafic localement via Azure ExpressRoute ou un VPN, en utilisant un routage forcé.

Notes

Si vous avez un serveur proxy qui bloque le trafic sans paramètres proxy, n’oubliez pas d’ajouter des exceptions dans le compte de stockage d’artefacts du labo.

Vous pouvez également utiliser des groupes de sécurité réseau pour les machines virtuelles ou les sous-réseaux. Cette étape ajoute une autre couche de protection pour autoriser ou bloquer le trafic.

Réseau virtuel nouveau ou existant

Si vos machines virtuelles doivent interagir avec l’infrastructure existante, envisagez d’utiliser un réseau virtuel existant dans votre environnement DevTest Labs. Si vous utilisez ExpressRoute, réduisez au minimum le nombre de réseaux virtuels et de sous-réseaux afin de ne pas fragmenter l’espace d’adressage IP affecté à vos abonnements. Songez également à utiliser l’appairage de réseaux virtuels ici (modèle Hub-Spoke). Cette approche permet la communication via réseau virtuel et sous-réseau entre abonnements au sein d’une région donnée.

Chaque environnement DevTest Labs pourrait avoir son propre réseau virtuel, mais il existe des limites au nombre de réseaux virtuels par abonnement. Le nombre par défaut est de 50, mais cette limite peut être portée à 100.

IP partagée, publique ou privée

Si vous utilisez un VPN de site à site ou Express Route, privilégiez les adresses IP privées pour que vos machines soient accessibles via votre réseau interne et inaccessibles par l’Internet publiques.

Notes

Les propriétaires de labo peuvent modifier cette stratégie de sous-réseau pour que personne ne crée accidentellement d’adresses IP publiques pour ses machines virtuelles. Le propriétaire de l’abonnement doit créer une stratégie d’abonnement empêchant la création d’adresses IP publiques.

Si vous utilisez des adresses IP publiques partagées, les machines virtuelles d’un labo partagent une adresse IP publique. Cette approche peut être utile pour éviter de dépasser les nombres limites d’adresses IP publiques pour un abonnement donné.

Limites du laboratoire

Il existe plusieurs limitations à connaître pour les labos. Ces limitations sont décrites dans les sections suivantes.

Limites de labos par abonnement

Il n’existe pas de limite spécifique concernant le nombre de laboratoires qui peuvent être créés par abonnement. Toutefois, la quantité de ressources utilisées par abonnement est limitée. Vous pouvez consulter des articles pour en savoir plus sur les quotas et les limites associés aux abonnements Azure et sur la façon d’augmenter ces limites.

Limites de machines virtuelles par labo

Il n’existe pas de limite spécifique concernant le nombre de machines virtuelles qui peuvent être créées par labo. Toutefois, les ressources (cœurs de machines virtuelles, adresses IP publiques, etc.) utilisées sont limitées par abonnement. Vous pouvez consulter des articles pour en savoir plus sur les quotas et les limites associés aux abonnements Azure et sur la façon d’augmenter ces limites.

Limites du nombre de machines virtuelles par utilisateur ou labo

Quand vous évaluez le nombre de machines virtuelles par utilisateur ou par labo, trois aspects principaux sont à prendre en compte :

• Le coût total que l’équipe peut consacrer aux ressources du labo. Avec de nombreuses machines, il est facile de mettre en place une rotation. Pour maîtriser les coûts, il est possible de limiter le nombre de machines virtuelles par utilisateur ou par labo
• Le nombre totale de machines virtuelles dans un labo est fonction des quotas d’abonnement disponibles. L’une des limites supérieures est de 800 groupes de ressources par abonnement. Actuellement, DevTest Labs crée un groupe de ressources pour chaque machine virtuelle (sauf si des adresses IP publiques partagées sont utilisées). Si un abonnement compte 10 labos, ceux-ci peuvent accueillir chacun environ 79 machines virtuelles (limite supérieure de 800 – 10 groupes de ressources pour les 10 labos) = 79 machines virtuelles par labo.
• Si le labo est connecté localement par Express Route (par exemple), des espaces d’adressage IP sont définis pour le réseau virtuel/sous-réseau. Pour vérifier que les machines virtuelles du labo sont effectivement créés (erreur : impossible d’obtenir l’adresse IP), les propriétaires de labo peuvent spécifier un nombre maximum de machines virtuelles par labo correspondant à l’espace d’adressage IP disponible.

Utiliser des modèles Resource Manager

Déployez vos modèles Resource Manager en suivant les étapes décrites dans Utiliser Azure DevTest Labs pour des environnements de test. Fondamentalement, vous intégrez vos modèles Resource Manager dans un référentiel Azure Repos ou un dépôt Git GitHub, puis ajoutez un référentiel privé pour vos modèles au labo.

Ce scénario peut ne pas être utile si vous utilisez DevTest Labs pour héberger des machines de développement. Utilisez-le pour créer un environnement intermédiaire représentatif de la production.

L’option du nombre de machines virtuelles par laboratoire ou par utilisateur ne limite que le nombre de machines créées en mode natif dans le laboratoire proprement dit. Elle ne limite pas leur création par des environnements quelconques avec des modèles Resource Manager.