AVD Solo : Start and Stop !

Azure Virtual Desktop est souvent associé aux environnements mutualisés. Mais on oublie souvent qu’AVD propose également à des environnements individuels, comme peut aussi le faire Windows 365. Comme toujours, les produits estampillés Azure apportent de la flexibilité dans la configuration et des optimisations possibles. Par exemple, des machines virtuelles équipées de puissantes cartes graphiques.

Aujourd’hui, Azure Virtual Desktop continue d’évoluer et propose maintenant l’arrêt automatique des VMs pour les environnements individuels.

En effet, il est déjà possible depuis un certains de temps faire automatiquement démarrer la machine virtuelle AVD d’utilisateur quand celui-ci s’y connecte. Cela s’appelle le Start on connect et j’en avait déjà parlé juste ici. Bien pratique et facile à configurer, cette fonction avait pour défaut de ne jamais arrêter la VM quand l’utilisateur n’en avait plus besoin.

Rappelons-le : une machine virtuelle éteinte au niveau OS continue de coûter de l’argent car des ressources Azure lui sont toujours allouées.

Des parades existent déjà depuis quelques temps déjà, mais elles nécessitent bien souvent une configuration annexe :

J’avais d’ailleurs écrit un article sur ce sujet. Mais depuis, les choses se compliquent car certaines fonctionnalités des comptes Azure Automation vont bientôt être dépréciées…

Bref, je suis bien content que Microsoft ait rajouté cette fonctionnalité d’arrêt automatique des VMs dans Azure Virtual Desktop.

Qu’est-ce que la mise à l’échelle automatique ?

La mise à l’échelle automatique vous permet d’effectuer un scale-up ou un scale-down de vos hôtes de session de machines virtuelles dans un pool d’hôtes pour optimiser les coûts de déploiement.
Microsoft Learn

La mise à l’échelle automatique, ou autoscaling, est déjà disponible pour les environnements AVD mutualisés. Un autre article en parle juste ici.

Comme indiqué dans le titre, la grande nouveauté concerne les environnements AVD individuels. La documentation Microsoft en parle déjà : la mise à l’échelle automatique pour les pools d’hôtes individuels est actuellement en préversion.

Voici donc un petit exercice pour tester cette fonctionnalité :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Azure Virtual Desktop, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Etape I – Déploiement de l’environnement AVD :

Pour déployer un environnement AVD, commencez par déployer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail d’Azure et utilisez la barre de recherche :

Renseignez tous les champs, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création de votre réseau virtuel :

Attendez environ une minute que le déploiement se termine :

Utilisez encore une fois la barre de recherche Azure pour créer votre environnement AVD :

Cliquez-ici pour créer un nouvel environnement AVD :

Renseignez tous les champs en prenant soin de choisir un type d’environnement individuel :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Renseignez les champs liés aux machines virtuelles AVD de votre environnement :

Choisissez la taille et le nombre de VMs AVD, ainsi que le réseau virtuel créé précédemment :

Dans notre environnement, une jointure des VMs à Azure Active Directory suffira. N’oubliez pas de joindre également vos VMs à Intune pour terminer cet exercice, puis cliquez sur Suivant :

Renseignez les champs pour créer un espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources puis attendez environ 10 minutes :

Une fois le déploiement terminé, cliquez-ici pour terminer la configuration de votre AVD :

Cochez l’option pour activer le SSO sur Azure Virtual Desktop. Cela évite de devoir s’authentifier deux fois pour arriver sur le bureau de la VM AVD :

Afin de pouvoir tester notre environnement AVD, il est nécessaire de rajouter des rôles à nos utilisateurs de test :

Desktop Virtualization User
Virtual Machine User Login

Enfin, mon environnement AVD de test nécessite d’assigner des utilisateurs aux VMs AVD. Pour cela, rendez-vous sur cet écran pour les assigner manuellement :

Comme je dispose de 2 VMs dans mon environnement AVD, j’ai assigné à chacune d’entre-elles un utilisateur de test :

Vérifiez que les machines virtuelles sont bien présentes et disponibles :

Ouvrez le client Remote Desktop, ou installez-le depuis ce lien si cela n’est pas encore le cas :

Utilisez la fonction suivante pour faire apparaître les machines AVD :

Vous pouvez répéter cette opération avec votre second utilisateur de test :

Cliquez sur l’icône de bureau à distance :

Authentifiez-vous une seconde fois pour activer la fonction SSO :

Autorisez-les connections de bureau à distance à partir de l’identité Azure AD de votre utilisateur de test :

Attendez que le bureau à distance Windows 11 s’ouvre :

Une fois la session AVD ouverte, fermez cette dernière en utilisant la déconnexion habituelle de Windows :

Votre environnement AVD est prêt et fonctionnel. Notre objectif est maintenant d’ajouter la fonction d’allumage et d’extinction automatique des VMs.

Etape II – Configuration de l’allumage et de l’extinction automatique :

Pour cela, nous devons rajouter un nouveau rôle Azure RBAC pour permettre à Azure Virtual Desktop (ou anciennement Windows Virtual Desktop) de pouvoir allumer et éteindre les VMs AVD :

Ajoutez le rôle RBAC suivant au niveau du groupe de ressources Azure contenant votre environnement AVD :

Retournez dans le menu Azure Virtual Desktop afin d’ajouter le scaling plan qui pilotera les VMs individuelles selon les besoins de connexion, puis cliquez sur Créer :

Donnez-lui un nom, placez-le dans la même région Azure que votre pool d’hôtes AVD, puis cliquez sur Suivant :

Ajoutez un ou plusieurs plannings selon vos besoins, sachant qu’une journée de la semaine ne peut être présent que dans un seul planning :

Sélectionnez les jours de la semaine correspondant à vos besoins, puis cliquez sur Suivant :

L’onglet suivant reprend le fuseau horaire du premier onglet et vous demande de renseigner les champs ci-dessous, puis de cliquer sur Suivant :

Heure de début : heure correspondant au début de la phase.
Démarrage de la VM : permet à l’utilisateur de pouvoir démarrer une VM éteinte pendant la phase. Cette option prend le pas sur la configuration renseignée dans le pool d’hôtes.
VMs à démarrer : propose de démarrer automatiquement des VMs si nécessaire dès le début de la phase, ou pas.
Paramètres de déconnexion : permet d’effectuer ou non une action après un temps donné.
Paramètres de fermeture de session : permet d’effectuer ou non une action après un temps donné.

Renseignez les mêmes options que pour la phase précédente, puis cliquez sur Suivant :

Renseignez les mêmes options que pour la phase précédente, puis cliquez sur Suivant :

Renseignez les mêmes options que pour la phase précédente, puis cliquez sur Ajouter :

Cliquez sur Suivant pour continuer :

Rattachez votre pool d’hôtes à la configuration en n’oubliant pas de cocher la case pour l’activer, puis cliquez ici pour lancer la validation Azure :

Une fois la validation Azure réussie, cliquez sur Créer pour valider la configuration :

Attendez quelques minutes que la configuration soit déployée :

Votre environnement individuel AVD est enfin géré par un planning de démarrage et d’arrêt automatique.

Nous allons maintenant effectuer différents tests pour voir le comportement d’Azure Virtual Desktop d’un point de vue utilisateur.

Etape III – Test de l’allumage et de l’extinction automatique :

Dans mon environnement de démonstration AVD, les machines virtuelles individuelles sont bien arrêtées.

Test A – Fermeture de la session utilisateur en Phase 1 :

A 9h22, j’ouvre un navigateur web afin de me rendre sur la page de connexion AVD. Une fois authentifié avec un utilisateur de test, j’ouvre une session de bureau à distance :

Comme la machine virtuelle affectée à cet utilisateur est arrêtée, Azure Virtual Desktop la démarre et ce message s’affiche :

Le statut de la machine virtuelle change bien dans Azure :

Une fois la machine démarrée, le message d’attente change également :

Peu après, le bureau virtuel Windows apparaît bien. Je décide donc d’effectuer une fermeture de session Windows par le menu Démarrer :

Environ 15 minutes plus tard, la machine virtuelle retrouve bien son précédent état :

Le premier test est concluant. Effectuons maintenant un second test en ne fermant pas la session AVD, mais en utilisant la croix pour simuler une déconnexion :

Test B – Déconnexion utilisateur en Phase 2 :

J’ouvre à nouveau une session de bureau à distance :

Comme la machine virtuelle affectée s’était précédemment arrêtée, Azure Virtual Desktop est obligé de la redémarrer à nouveau :

Le statut de la machine virtuelle rechange bien une nouvelle fois dans Azure :

Peu après, le bureau virtuel Windows apparaît bien. Je décide donc déconnexion de la session par la croix, en haut de la fenêtre AVD :

La session est bien marquée comme déconnectée dans l’écran de contrôle du pool d’hôtes AVD :

A 10h56, la VM est déjà éteinte depuis quelques temps :

Cette information est confirmée par le journal d’audit de la machine virtuelle :

Les fonctions de déconnexion de l’utilisateur et de fermeture de session sont bien prises en compte dans le processus d’arrêt des machines virtuelles par Azure Virtual Desktop.

Prenons maintenant le temps de vérifier le respect des paramétrages renseignés dans la configuration.

Test C – Fermeture de la session utilisateur en Phase 3 :

A 11h01, j’ouvre à nouvelle fois une session Windows :

Encore une fois, Azure Virtual Desktop est obligé de redémarrer la machine virtuelle de l’utilisateur :

Le statut de la machine virtuelle rechange bien une nouvelle fois dans Azure :

Je décide donc d’effectuer à nouveau une fermeture de session Windows par le menu Démarrer :

A 11h25, soit exactement 20 minutes après la fermeture de session, la machine virtuelle AVD change de statut pour s’éteindre :

Cela confirme bien le paramétrage de temps renseigné dans cette phase :

Je décide de continuer mon test en vérifiant mon raisonnement en phase 4, dans laquelle j’ai configuré un arrêt de la VM seulement 5 minutes après la fermeture ou déconnexion de la session.

Test D – Fermeture de la session utilisateur en Phase 4 :

A 12h01, j’ouvre à nouvelle fois une session Windows :

Encore une fois, Azure Virtual Desktop est obligé de redémarrer la machine virtuelle de l’utilisateur :

Le statut de la machine virtuelle rechange bien une nouvelle fois dans Azure :

Je décide donc d’effectuer à nouveau une fermeture de session Windows par le menu Démarrer :

A 12h08, soit exactement 5 minutes après la fermeture de session, la machine virtuelle AVD change de statut pour s’éteindre à nouveau :

Cela confirme bien le respect du paramétrage selon la phase dans laquelle l’utilisateur se trouve :

Le paramétrage de démarrage et d’arrêt des machines virtuelles individuelles AVD fonctionne bien.

Afin d’aller plus loin dans le test, je décide d’y intégrer une session de déconnexion des sessions inactives, passé un certain temps.

Pour cela, je vais utiliser Intune pour déployer une police de configuration Windows sur les sessions de bureau à distances inactives.

Etape IV – Configuration log off Windows via Intune :

Afin de déployer une configuration Intune, démarrez les machines virtuelles AVD via la fonction suivante :

Sur la page d’Azure AD, créez un nouveau groupe et ajoutez-y les machines virtuelles AVD :

Rendez-vous dans la console Intune afin de créer un nouveau profil de configuration Windows comme ceci :

Choisissez le type de profil suivant, puis cliquez sur Créer :

Nommez votre profil de configuration, puis cliquez sur Suivant :

A droite, recherchez l’option suivante afin de l’ajouter et de la configurer sur la partie gauche de l’écran, puis cliquez sur Suivant :

Les Tags ne sont pas utilisés dans notre test, cliquez sur Suivant :

Ajoutez le groupe précédemment créé et contenant les machines virtuelles AVD, puis cliquez sur Suivant :

Vérifiez une dernière fois les options de votre profil de configuration, puis cliquez sur Créer :

Attendez environ 15-30 minutes que le profil de configuration soit bien déployée sur vos VMs AVD :

Ma configuration Intune et maintenant en place. Maintenant, nous allons pouvoir tester la combinaison des deux configurations.

Test E – Combinaison AVD + Intune :

Rouvrez une nouvelle fois une session AVD :

Comme la machine virtuelle AVD est déjà démarrée, la session s’ouvre bien plus rapidement :

Environ 15 minutes plus tard et sans avoir rien fait, un premier message d’avertissement apparaît sur la session AVD m’indiquant que la session sera déconnecté dans environ 2 minutes :

Environ 2 minutes plus tard et n’ayant toujours rien touché, le message suivant apparaît :

Là encore, la session est bien marquée comme déconnectée dans l’écran de contrôle du pool d’hôtes AVD :

Environ 5 minutes après la déconnexion de la session, la machine virtuelle AVD change encore de statut pour s’éteindre une nouvelle fois :

Cette dernière démonstration montre bien la combinaison habille entre la nouvelle fonctionnalité AVD et la configuration Windows installée via une police de configuration Intune.

Conclusion :

Comme toujours, les nouveautés sur Azure Virtual Desktop font plaisir. Elles sont pratiques et vous ferons gagner du temps dans la configuration et dans la mise en place.

Voici d’ailleurs quelques une des dernières nouveautés AVD que j’ai pu tester récemment :

Bonne lecture 😎

Azure Update Management Center

Dans la même veine que la gestion des mots de passe, les cycles de mises à jour Cloud ou sur site incombent aux équipes IT de façon régulière. Azure continue d’automatiser les choses depuis de nombreuses années, et les mises à jour des VMs en fait également partie. Avec Azure Update Management Center v2, Microsoft pourrait bien y parvenir.

Comme beaucoup de services prénommés Center et récemment créés par Microsoft, ces derniers apportent de l’unification, de la simplification et de l’automatisation de traitements impactant une ou plusieurs ressources Azure.

Le centre de gestion des mises à jour (préversion) est un service unifié qui permet de gérer et de régir les mises à jour pour toutes vos machines. Vous pouvez surveiller la conformité des mises à jour Windows et Linux sur vos déploiements dans Azure, localement et sur les autres plateformes cloud à partir d’un seul tableau de bord. De plus, vous pouvez utiliser le centre de gestion des mises à jour (préversion) pour effectuer des mises à jour en temps réel ou les planifier dans une fenêtre de maintenance définie.
Microsoft Learn

En deux mots, les principales caractéristiques d’Azure Update Management Center sont :

Qu’il ne nécessite pas de déploiements annexes (Compte Automation, Log Analytics workspace, …)
Qu’il est disponible gratuitement
Qu’il apporte une vue synthétique sur le périmètre des mises à jour OS (VM Azure, VMSS, Azure Arc, …)

D’un seul coup d’œil, vous serez capables de visualiser les points suivants :

Les machines virtuelles présentes et leur statut
Les mises à jour à venir via des assessments automatiques
L’historique des mises jour installées ou échouées
Les paramètres des fenêtres de mises à jour

Voici une copie d’écran de la vue d‘Azure Update Management Center :

L’outil est encore en préversion à l’heure où ces lignes sont écrites. Mais cela ne vous empêchera pas de commencer à l’utiliser sur ou une plusieurs de vos VMs Azure.

Cette vidéo en français est très intéressante afin de vous faire une première idée :

Comment fonctionne Azure Update Management Center ?

Cette fois, Microsoft a conçu les choses au plus simple, le système repose uniquement sur deux étapes :

L’assessment qui scan et détermine les mises à jour disponibles. Il est configurable via un Police Azure ou via une configuration VM par VM
La méthode d’orchestration qui appliquera les mises à jour selon une méthode précise et convenu VM par VM ou globalement

Quelles sont les méthodes d’orchestration disponibles ?

Microsoft les détaille juste ici, dont voici l’extrait :

Planifications gérées par le client (préversion) : permet de planifier la mise à jour corrective sur vos machines virtuelles existantes. La nouvelle option d’orchestration des correctifs active les deux propriétés de machine virtuelle : Mode patch = orchestré par Azure et BypassPlatformSafetyChecksOnUserSchedule = TRUE en votre nom après avoir reçu votre consentement.
Déploiement sécurisé géré par Azure : pour un groupe de machines virtuelles faisant l’objet d’une mise à jour, la plateforme Azure orchestre les mises à jour. La machine virtuelle est définie sur la mise à jour corrective automatique de l’invité de machine virtuelle. (c’est-à-dire), le mode correctif est AutomaticByPlatform.
Automatique par le système d’exploitation : la machine est automatiquement mise à jour par le système d’exploitation.
Image par défaut : pour les machines Linux, la configuration de mise à jour corrective par défaut est utilisée.
Manuel : vous contrôlez l’application de correctifs sur une machine en appliquant manuellement des correctifs au sein de la machine. Dans ce mode, les mises à jour automatiques sont désactivées pour le système d’exploitation Windows.

Afin de vous faire une meilleure idée de la solution, je vous propose un petit exercice sur plusieurs machines virtuelles Azure :

Quels sont les prérequis pour tester Azure Update Management Center ?

Pour réaliser cet exercice sur Azure Update Management Center, il vous faudra disposer d’une souscription Azure valide.

Dans notre exercice, nous allons créer plusieurs machines virtuelles, utilisant différents OS, versions et méthodes d’orchestration des mises à jour. Ces essais vont nous permettre d’en savoir un peu plus sur la gestion des mises à jour via Azure Update Management Center.

Commençons par créer nos machines virtuelles de test sure Azure.

Etape I – Création des machines virtuelles Azure :

Pour cela, rendez-vous dans le portail d’Azure et utilisez la barre de recherche :

Cliquez-ici pour créer la première machine virtuelle :

Sur ce premier onglet, renseignez toutes les informations de base, puis choisissez l’image OS suivante – Windows Server 2022 Datacenter: Azure Edition x64 Gen2 :

Renseignez la taille et les identifiants du compte administrateur, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Retirez la fonction d’arrêt automatique de la VM :

Modifiez la configuration d’orchestration comme ceci, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Attendez environ deux minutes, puis cliquez-ici pour créer une seconde machine virtuelle :

Conservez les mêmes options à l’exception de l’OS – Ubuntu Server 20.04 LTS – x64 Gen2 :

Gardez les options de sécurité SSH de base, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Retirez la fonction d’arrêt automatique, modifiez la configuration d’orchestration comme ceci, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Validez le téléchargement de la paire de clefs SSH :

Attendez environ deux minutes, puis cliquez-ici pour créer une troisième machine virtuelle :

Conservez les mêmes options à l’exception de l’OS – Windows Server 2022 Datacenter: Azure Edition Hotpach -x64 Gen2 :

Renseignez la taille et les identifiants du compet administrateur, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Retirez la fonction d’arrêt automatique, modifiez la configuration d’orchestration comme ceci, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Attendez que le déploiement de la 3ème machine virtuelle se termine :

Nos machines virtuelles de test sont maintenant en place. Nous allons pouvoir tester différentes fonctions d’Azure Update Management Center. La première tâche va consister à mettre en place l’assessment périodique.

Etape II – Configuration de l’assessment périodique :

Pour cela, utilisez la barre de recherche, puis sélectionnez Azure Update Management Center :

Vérifiez la présence des 3 machines virtuelles créées précédemment ainsi que l’absence de données sur les mises à jour disponibles :

Afin de récolter ces données, nous allons mettre en place l’assessment périodique via une police d’Azure. Pour cela cliquez sur le lien ci-dessous :

Choisissez Azure Policy, puis cliquez sur OK :

Sélectionnez cette définition de police dans la liste ci-dessous :

Cliquez-ici afin d’assigner la définition à votre souscription Azure :

Choisissez votre souscription Azure, et si besoin le groupe de ressources, puis lancez la validation Azure :

Lancez l’assignation de la police Azure :

Vérifiez la bonne assignation à votre souscription Azure dans le menu suivant :

Malgré que l’assessment dû à la police Azure n’ait pas encore remonté d’informations, des mises à jour sont déjà marquées comme disponibles sur la machine virtuelle sous orchestration Azure Managed – Safe Deployment :

Quelques minutes et un rafraichissement plus tard, l’assessment périodique commence à remonter des mises à jour dans le tableau ci-dessous :

Encore un rafraichissement plus tard, celui-ci continu son chemin et remonte les mises à jour disponibles sur nos différentes VMs :

La gestion des mises à jour de la VM Linux a été configurée comme étant en Image par défaut (il s’agit donc de la méthode standard pour l’OS Linux). Vous retrouvez d’ailleurs la méthode d’orchtestration choisie directement dans le template de la VM :

Avant de nous focaliser sur la partie mise à jour, nous allons nous intéresser à la partie assessment.

Nous pouvons aussi configurer l’assessment périodique des mises à jour depuis Azure Update Management Center sans passer par une police Azure :

Activez l’assessment périodique sur votre VM Linux, puis sauvegardez :

Cette information modifie la variable suivante dans le template de votre VM :

La valeur change alors à Yes comme ceci :

Pour accélérer les choses, il est aussi possible de lancer une vérification des mises à jour :

Cliquez-ici pour démarrer le traitement :

Une notification apparaît alors :

Et le statut de la VM change également :

Eventuellement, des mises à jour apparaissent :

La gestion de la vérification des mises à jour Windows ou Linux est maintenant plus clair. Nous allons maintenant prendre le temps de mieux comprendre et gérer les méthodes pour orchestrer l’installation des mises à jour.

Etape III – Configuration de la méthode de mise à jour :

Comme annoncé plus haut, plusieurs gestions de l’orchestration des mises à jour sont possibles. La méthode retenue est présente dans le template de la machine virtuelle.

Celle-ci néanmoins modifiable, en modifiant le template ou via Azure Update Management Center.

Pour cela, sélectionnez les deux VMs ci-dessous, puis cliquez sur Mise à jour des paramètres :

Confirmez votre choix en cliquant ici :

Pour les deux VMs, choisissez la méthode d’orchestration des mises à jour suivante : Planifications gérées par le client (préversion), puis cliquer sur Sauvegarder :

Cliquez-ici pour mettre en place de votre fenêtre des mises à jour :

Définissez toute la configuration de base :

Choisissez la fréquence de la fenêtre selon vos propres règles :

Une fois la validation réussie, lancez la création de votre configuration de maintenance :

Attendez environ une minute :

Il ne reste qu’à attendre la prochaine fenêtre pour constater l’installation des mises à jour :

L’installation des mises à jour est programmée pour deux VMs sur trois. Nous allons maintenant voir les différentes possibilités d’orchestration.

Etape IV – Méthodes d’installation des mises à jour :

En attendant que la fenêtre des mises à jour arrive, une autre méthode consiste à installer manuellement les mises à jour sur la VM.

Pour cela, sélectionnez la troisième VM puis cliquez sur Mise à jour ponctuelle :

Confirmez votre choix en cliquant ici :

Cliquez sur Suivant :

Choisissez la ou les mises à jour installer, puis cliquez sur Suivant :

Définissez la méthode de redémarrage souhaitée :

Lancez l’installation des mises à jour :

Une notification apparaît alors :

Et le statut de la VM change également :

La fenêtre d’historique montre le détail des mises à jour installées :

Repartons un moment sur les VMs configurées dans une fenêtre de mise à jour :

Quelques minutes après le début de la fenêtre, seule la VM Linux a installées toutes ses mises à jour.

Cliquez-ici pour savoir pourquoi la machine virtuelle Windows n’en a pas fait autant :

Observez la classification des mises à jour non installées :

Retournez sur la configuration de la fenêtre afin de voir si ces classifications en font partie :

Lancez également une mise à jour ponctuelle pour cette VM :

Confirmez votre choix en cliquant ici :

Cliquez sur Suivant :

Choisissez la ou les mises à jour installer, puis cliquez sur Suivant :

Définissez la méthode de redémarrage souhaitée :

Lancez l’installation des mises à jour :

Le statut de la VM change également :

Et voilà, toutes vos VMs sont maintenant à jour !

Enfin, la page de Vue d’ensemble permet d’avoir une vision assez rapide des VMs à jour de la répartition des méthodes de mise à jour :

Quelques anecdotes :

Afin d’en savoir un peu plus sur le fonctionnement Azure Update Management Center toujours en préversion, j’ai créé et laissé tourner plusieurs machines virtuelles :

La VM w-update-autop2 avec orchestration Azure Managed – Safe Deployment et hotpatch n’a toujours pas été mise à jour.

Je n’ai pas vu de mises à jour dans l’historique. Aussi je me demande à quel moment Azure décrète que l’installation est saine et qu’il peut procéder.

La VM l-updatep2 avec sous Azure Policy concernant l’assessment est toujours marquée à No concernant l’assessment périodique :

Conclusion :

En conclusion, la nouvelle version Azure Update Management Center me semble très prometteuse et permettra de visualiser d’un seul coup d’œil toutes les mises à jour OS disponibles pour les VMs Azure, mais aussi des machines virtuelles connectées via Azure Arc.

L’autre bonne nouvelle est la disponibilité générale d’Hotpatch, désormais disponible directement dans l’image Windows Server 2022 Datacenter Azure Edition 😎.

Azure Stack HCI est à votre porte !

Le Cloud est présent dans beaucoup d’infrastructures IT. Utilisé à 100% ou seulement de manière partielle pour certains services, il offre une flexibilité inégalée, aussi bien dans son financement que dans les besoins techniques disponibles et les évolutions possibles.

Mais alors, si le cloud est merveilleux, pourquoi les principaux fournisseurs de cloud cherchent aussi à proposer des solutions dites hybrides (on-premise + cloud) ?

Peut-être qu’il en faut pour tous les goûts 😁?

D’abord, faisons un rapides tour de plusieurs concepts avant tester ensemble une solution hybride via un exercice que propose justement Microsoft.

Qu’est-ce que le cloud hybride ?

Le cloud hybride combine généralement deux types de cloud : public et privé. Par privé est souvent entendu local.

Un cloud hybride est un peu comme une voiture hybride. Les voitures hybrides combinent deux technologies totalement distinctes : un moteur qui brûle de l’essence et un autre qui consomme de l’énergie électrique. Chaque technologie fonctionne de manière totalement différente, et chacune a ses avantages et ses inconvénients. Cependant, lorsque les deux sont combinées efficacement, le résultat est une voiture plus performante que la plupart des voitures uniquement à essence et pourtant plus puissante que la plupart des voitures entièrement électriques. De même, les cloud hybrides combinent les avantages de plusieurs types d’environnements cloud pour une efficacité et une fonctionnalité accrue.
Oracle

Qu’est-ce qu’Azure Stack HCI ?

Azure Stack HCI est une solution développée par Microsoft pour justement aider les entreprises à exploiter les avantages d’un environnement hybride, expliqué précédemment, via les interfaces connues d’Azure et de Windows Admin Center.

Il s’agit d’une solution d’infrastructure hyperconvergée basée sur les technologies Azure de Microsoft. Elle permet de :

d’intégrer de façon transparente leur environnement
De créer une expérience hybride cohérente à Azure.
D’apporter toujours plus de scalabilité et flexibilité.
De conserver un haut niveau de sécurité et de conformité.
De profiter d’une passerelle de modernisation de l’infrastructure existante.

Existe-t-il du matériel certifié Azure Stack HCI ?

Microsoft met à disposition un site web dédié à Azure Stack HCI dont voici le lien. Vous pourrez y planifier votre solution en fonction des charges de travail prévues :

Peut-on tester Azure Stack HCI sans forcément acheter du matériel ?

Cela est possible, grâce à … Azure ! En effet, les fournisseurs de cloud autorisent pratiquement toutes les créations de ressources, donc on peut simuler un Azure Stack HCI dans le cloud de Microsoft.

Cette approche permet donc de ne pas dépenser de grandes sommes d’argent pour tester la solution Azure Stack HCI avant de se laisser convaincre. Pour cela je vous laisse lire les différentes étapes ci-dessous pour y parvenir :

La version originale de l’exercice conçu par Microsoft est également disponible en anglais sur leur page GitHub juste ici.

Rappel des prérequis :

Pour réaliser cet exercice sur Azure Stack HCI, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Afin de tester Azure Stack HCI, nous allons avoir besoin créer un environnement virtuel, dans lequel nous allons simuler la présence de nœuds HCI, mais aussi de Windows Admin Center.

Dans Azure, il est en effet possible d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.

Important : Attention à ne pas laisser tourner l’environnement de démonstration Azure Stack HCI tourner un peu trop longtemps. Beaucoup de ressources Azure sont créées et le compteur des € défile assez vite 🤑.

Etape I – Déploiement de l’environnement virtuel sur Azure :

Commencez par cliquez sur le lien ci-dessous afin déployer les ressources nécessaires sur votre souscription Azure :

Renseignez les champs suivants, puis lancez la validation Azure :

Une fois la validation Azure réussie, cliquez-ici pour commencer la création :

Le déploiement dure environ 30 minutes, attendez que celui-ci se termine, puis cliquez-ici :

Constatez la présence de nombreuses ressources Azure créées pour cette démonstration, puis cliquez sur la machine virtuelle présente, appelée AzSHCIHost001 :

Rendez-vous dans le menu Bastion, puis cliquez-ici pour en déployer un :

Attendez environ 5 minutes que la création d’Azure Bastion se termine :

Modifier la règle NSG suivante créée dans le template Microsoft afin de débloquer l’accès RDP à votre machine Hyper-V :

Retournez sur votre machine virtuelle Hyper-V, puis lancez une session Bastion avec les identifiants renseignés lors de la création du template :

Sur la session RDP ouverte via Azure Bastion, cliquez-ici pour modifier le script de déploiement d’Azure Stack HCI :

Rendez-vous sur la ligne suivante pour modifier la ligne comme ceci :

AVANT :

Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

APRES :

Set-ExecutionPolicy Bypass -Scope Process -Force; Invoke-WebRequest -Uri 'https://chocolatey.org/install.ps1' -OutFile 'install.ps1'; .\install.ps1 -ChocolateyDownloadUrl "https://community.chocolatey.org/api/v2/package/chocolatey/1.4.0"

Vous avez aussi la possibilité de récupérer celui-ci en version corrigée sur mon GitHub

Lancez le script, puis faites preuve d’un petit peu de patience, car celui dure environ … 2 heures 🤣

Si aucune erreur ne s’est manifestée durant le traitement, vous devriez apercevoir le message de succès suivant :

Si le script ne s’est pas correctement terminé, la commande PowerShell suivante permet d’effacer les ressources crées dans Hyper-V afin de pouvoir recommencer le lancement du script :

.\New-AzSHCISandbox.ps1 -Delete $true

Un tour rapide dans la console Hyper-V montre l’apparition de 3 machines virtuelles :

AzSHOST1 : nœud Azure Stack HCI 1
AzSHOST2 : nœud Azure Stack HCI 2
AzSMGMT : Console de management pour Windows Admin Center

Sur le bureau de votre machine virtuelle Hyper-V, une icône de type RDP vient de faire son apparition :

Notre environnement fictif de départ est maintenant terminé. Nous avons besoin d’enregistrer notre cluster Azure Stack HCI sur le portail Azure afin de commencer la facturation mais aussi tester le déploiement de services depuis le portail Azure.

Etape II – Enregistrement du Cluster Azure Stack HCI sur Azure :

Pour cela, cliquez sur l’icône RDP pour ouvrir une session sur la VM WAC puis renseignez les identifiants suivants (mot de passe : Password01) :

Notez la présence d’un domaine Active Directory nommé Contoso. Attendez quelques minutes que la session se charge entièrement :

Sur le bureau, ouvrez le raccourci menant à la page suivante et ayant un icône Google Chrome :

https://admincenter.contoso.com/

Renseignez les identifiants suivants (mot de passe : Password01) :

Attendez quelques secondes que se charge la console de Windows Admin Center :

Fermez la fenêtre de notification de Windows Admin Center :

Attendez environ 10 minutes que tous les modules présents dans Windows Admin Center soient bien mis à jour :

Une fois les mises à jour effectuées, les notifications suivantes devraient apparaître dans WAC :

Afin de pouvoir piloter votre Cluster de serveurs Azure Stack HCI, il est nécessaire de le rajouter dans la console WAC pour terminer la configuration.

Cliquez-ici pour ajouter votre cluster Azure Stack HCI à WAC :

Saisissez le nom AzStackCluster, attendez quelques secondes que WAC retrouve ce dernier, puis cliquez sur Ajouter :

Une fois l’ajout réussi, vérifiez la liste des connexions existantes avec WAC, puis cliquez sur votre cluster de serveurs :

Rendez-vous dans le menu appelé SDN Infrastructure :

Renseignez les identifiants suivants (mot de passe : Password01), puis cochez la case suivante :

Renseignez le contrôleur de réseau suivant, puis cliquez sur Continuer :

Constatez l’apparition des nouveaux menus suivants sous la section Réseau :

Afin de pouvoir utiliser pleinement le portail Azure pour piloter notre cluster Azure Stack HCI, il est nécessaire de passer par quelques étapes d’enregistrement.

Pour cela, rendez-vous toujours depuis WAC dans la section Azure Arc, puis cliquez sur le bouton suivant :

Cliquez-ici pour démarrer l’enregistrement de notre cluster sur Azure :

Utilisez le code Azure pour valider l’authentification Azure AD avec un compte disposant de suffisamment de droits sur la souscription Azure :

Une fois l’authentification Azure AD réussie, vous devriez recevoir l’information suivante, puis cliquez sur Authentifier :

Acceptez la demande de permission de Windows Admin Center avec le consentement global de l’organisation :

Vérifiez la disparition du message sur la page Azure Arc de votre WAC :

Avant d’aller plus loin, retournez sur votre portail Azure afin d’activer le fournisseur de ressources suivant sur votre souscription Azure :

Attendez environ deux minutes que le statut soit correctement changé sur le fournisseur de ressources :

Retournez sur Windows Admin Center, puis cliquez-ici :

Cliquez-ici pour démarrer le processus avec la connexion Azure Arc précédemment créée :

Renseignez les informations qui vous conviennent, puis cliquez sur Enregistrer :

La notification suivante devrait alors apparaître dans WAC :

Attendez environ 5 minutes pour confirmer le bon enregistrement :

Retournez sur le portail Azure afin de constater la présence de votre Azure Stack HCI, puis cliquez dessus :

Naviguez dans les différents menus pour mieux comprendre les informations remontées sur Azure.

Nous allons avoir maintenant besoin d’un autre composant, appelé Azure Resource Bridge. Si l’on souhaite gérer et déployer des ressources sur son cluster depuis Azure, celui-ci est indispensable.

Etape III – Configuration d’Azure Ressource Bridge :

Le pont de ressources Arc est une machine virtuelle empaquetée qui héberge un cluster Kubernetes de gestion nécessitant une gestion minimale des utilisateurs. La machine virtuelle est déployée sur l’infrastructure locale et une ressource ARM du pont de ressources Arc est créée dans Azure. Les deux ressources sont ensuite connectées, ce qui permet la gestion et l’utilisation en libre-service des machines virtuelles à partir d’Azure
Microsoft Learn

Ensuite, cliquez ici pour installer un second module, appelé Azure Resource Bridge :

Attention : certaines étapes sont à faire sur les 2 nœuds présents dans votre cluster Azure Stack HCI

Cliquez sur le lien suivant pour ouvrir le guide d’installation d’Arc Resource Bridge :

Retournez sur votre serveur Hyper-V, puis dans la console Hyper-V, cliquez sur le premier nœud de votre cluster Azure Stack HCI afin d’ouvrir une session :

Renseignez les identifiants suivants (mot de passe : Password01) :

Effectuez le choix 15 pour ouvrir une console PowerShell :

Profitez-en pour ouvrir Notepad depuis PowerShell afin de faciliter les copier / coller :

Saisissez la commande suivante pour installer les premiers modules nécessaires :

Install-PackageProvider -Name NuGet -Force 
Install-Module -Name PowershellGet -Force -Confirm:$false -SkipPublisherCheck

Continuez avec celles-ci pour installer d’autres modules :

Install-Module -Name Moc -Repository PSGallery -AcceptLicense -Force
Initialize-MocNode
Install-Module -Name ArcHci -Force -Confirm:$false -SkipPublisherCheck -AcceptLicense

Fermez la fenêtre PowerShell afin de revenir au menu principal, puis entrez le choix 13 pour redémarrer votre premier nœud :

Retournez sur votre serveur Hyper-V, puis dans la console Hyper-V, cliquez sur le second nœud de votre cluster Azure Stack HCI afin d’ouvrir une session :

Renseignez les identifiants suivants (mot de passe : Password01) :

Effectuez le choix 15 pour ouvrir une console PowerShell :

Profitez-en pour également ouvrir Notepad depuis PowerShell afin de faciliter les copier / coller :

Saisissez la commande suivante pour installer les même premiers modules nécessaires :

Install-PackageProvider -Name NuGet -Force 
Install-Module -Name PowershellGet -Force -Confirm:$false -SkipPublisherCheck

Continuez avec celles-ci pour installer les mêmes autres modules :

Install-Module -Name Moc -Repository PSGallery -AcceptLicense -Force
Initialize-MocNode
Install-Module -Name ArcHci -Force -Confirm:$false -SkipPublisherCheck -AcceptLicense

Fermez la fenêtre PowerShell afin de revenir au menu principal, puis entrez le choix 13 pour redémarrer votre second nœud :

Retournez sur votre serveur Hyper-V, puis dans la console Hyper-V, cliquez à nouveau sur le premier nœud de votre cluster Azure Stack HCI afin d’ouvrir une session :

Renseignez à nouveau les identifiants suivants (mot de passe : Password01) :

Effectuez à nouveau le choix 15 pour rouvrir une console PowerShell :

Saisissez la commande suivante pour installer le module CLI d’Azure, uniquement nécessaire sur le premier nœud :

$ProgressPreference = 'SilentlyContinue'; Invoke-WebRequest -Uri https://aka.ms/installazurecliwindows -OutFile .\AzureCLI.msi; Start-Process msiexec.exe -Wait -ArgumentList '/I AzureCLI.msi /quiet'; Remove-Item .\AzureCLI.msi

Fermez la fenêtre PowerShell afin de revenir au menu principal, puis entrez le choix 13 pour redémarrer à nouveau votre premier nœud :

Retournez sur votre serveur Hyper-V, puis dans la console Hyper-V, cliquez à nouveau sur le premier nœud de votre cluster Azure Stack HCI afin d’ouvrir une session :

Renseignez à nouveau les identifiants suivants (mot de passe : Password01) :

Effectuez à nouveau le choix 15 pour rouvrir une console PowerShell :

Rouvrez à nouveau Notepad depuis PowerShell afin de faciliter les copier / coller.

Préparer les variables suivantes puis lancez-les :

$VswitchName="sdnSwitch"
$ControlPlaneIP="192.168.1.200"
$csv_path="C:\ClusterStorage\S2D_vDISK1\"
$VMIP_1="192.168.1.201"   
$VMIP_2="192.168.1.202"
$DNSServers="192.168.1.254"
$IPAddressPrefix="192.168.1.0/24"
$Gateway="192.168.1.1"
$CloudServiceIP="192.168.1.203"

Lancez le script suivant pour préparer la configuration d’Azure Resource Bridge :

mkdir $csv_path\ResourceBridge

Set-MocConfig -workingDir $csv_path\ResourceBridge -imageDir $csv_path\imageStore -skipHostLimitChecks -cloudConfigLocation $csv_path\cloudStore -catalog aks-hci-stable-catalogs-ext -ring stable -CloudServiceIP $cloudServiceIP -createAutoConfigContainers $false

Install-Moc

Retirer les extensions du module PowerShell Az si jamais elles existaient déjà :

az extension remove --name arcappliance
az extension remove --name k8s-extension
az extension remove --name customlocation
az extension remove --name azurestackhci

Installer à nouveaux ces mêmes extensions Az :

az extension add --upgrade --name arcappliance
az extension add --upgrade --name k8s-extension
az extension add --upgrade --name customlocation
az extension add --upgrade --name azurestackhci

Renseignez les informations sur votre environnement Azure :

$subscription="d9b60b07-0ae9-4de3-bfdd-062268de474a"
$resource_group="azurestack-rg"
$location="westeurope"

Continuez avec le script suivant :

az login --use-device-code
az account set --subscription $subscription
az provider register --namespace Microsoft.Kubernetes --wait
az provider register --namespace Microsoft.KubernetesConfiguration --wait
az provider register --namespace Microsoft.ExtendedLocation --wait
az provider register --namespace Microsoft.ResourceConnector --wait
az provider register --namespace Microsoft.AzureStackHCI --wait
az provider register --namespace Microsoft.HybridConnectivity --wait
$hciClusterId= (Get-AzureStackHci).AzureResourceUri
$resource_name= ((Get-AzureStackHci).AzureResourceName) + "-arcbridge"
$customloc_name= ((Get-AzureStackHci).AzureResourceName) + "-CL"

Saisissez le code Azure donnée dans le log des commandes Power Shell :

Utilisez un compte disposant de suffisamment de droits sur la souscription Azure :

Lancez le script suivant pour commencer la configuration K8s :

New-ArcHciConfigFiles -subscriptionID $subscription -location $location -resourceGroup $resource_group -resourceName $resource_name -workDirectory $csv_path\ResourceBridge -controlPlaneIP $controlPlaneIP -vipPoolStart $controlPlaneIP -vipPoolEnd $controlPlaneIP -k8snodeippoolstart $VMIP_1 -k8snodeippoolend $VMIP_2 -gateway $Gateway -dnsservers $DNSServers -ipaddressprefix $IPAddressPrefix -vswitchName $vswitchName

Continuez avec le fichier YAML pour la configuration K8s :

az arcappliance validate hci --config-file $csv_path\ResourceBridge\hci-appliance.yaml

Préparez votre environnement K8s avec la préparation au déploiement de pods :

az arcappliance prepare hci --config-file $csv_path\ResourceBridge\hci-appliance.yaml

Déployez le contenaire K8s dédié à la communication du module Azure Arc Bridge :

az arcappliance deploy hci --config-file  $csv_path\ResourceBridge\hci-appliance.yaml --outfile "$csv_path\ResourceBridge\kubeconfig"

Continuez avec le script suivant :

az arcappliance create hci --config-file $csv_path\ResourceBridge\hci-appliance.yaml --kubeconfig "$csv_path\ResourceBridge\kubeconfig"

Vérifiez que les deux statuts soient bien sur Succeded et Connected, retentez quelques minutes plus tard si nécessaire :

az arcappliance show --resource-group $resource_group --name $resource_name --query '[provisioningState, status]'

Continuez avec le script suivant :

az k8s-extension create --cluster-type appliances --cluster-name $resource_name --resource-group $resource_group --name hci-vmoperator --extension-type Microsoft.AZStackHCI.Operator --scope cluster --release-namespace helm-operator2 --configuration-settings Microsoft.CustomLocation.ServiceAccount=hci-vmoperator --config-protected-file $csv_path\ResourceBridge\hci-config.json --configuration-settings HCIClusterID=$hciClusterId --auto-upgrade true

Vérifiez que le statut soit bien sur Succeded, retentez quelques minutes plus tard si nécessaire :

az k8s-extension show --cluster-type appliances --cluster-name $resource_name --resource-group $resource_group --name hci-vmoperator --out table --query '[provisioningState]'

Terminez par la commande de création d’un emplacement personnalisé sur Azure. Ce dernier va nous être utile pour indiquer lors de la création de ressources depuis le portail Azure que celle-ci doit-être créée sur Azure Stack HCI :

az customlocation create --resource-group $resource_group --name paris --cluster-extension-ids "/subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.ResourceConnector/appliances/$resource_name/providers/Microsoft.KubernetesConfiguration/extensions/hci-vmoperator" --namespace hci-vmoperator --host-resource-id "/subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.ResourceConnector/appliances/$resource_name" --location $location

Constatez la bonne création de ce dernier depuis le portail Azure :

Retournez sur la page Azure de votre cluster Azure Stack HCI afin de constater l’avancement des prérequis :

Azure Resource Bridge est maintenant correctement installé. Nous allons enfin pouvoir créer notre machine virtuelle depuis le portail Azure, et déployée directement sur un des 2 nœuds de notre cluster.

Etape IV – Création de la VM sur le Stack :

Cliquez comme ceci pour transférer vers votre cluster une image de VM provenant de la marketplace Microsoft d’Azure :

Renseignez les champs comme ceci, puis lancez la validation :

Une fois la validation réussie, cliquez-ici pour commencer le transfert de données de l’image de Windows Server vers votre cluster :

Ce processus est assez long, comptez environ une bonne heure avant que le transfert de l’image ne se termine :

En cas d’erreur lors du transfert, relancez celui-ci afin d’avoir une image complète sur votre cluster :

De retour sur votre premier nœud de votre cluster Azure Stack HCI, lancez la commande suivante pour initialiser le réseau virtuel :

$vnetName="vnetwork-paris3"
New-MocGroup -name "Default_Group" -location "MocLocation"
New-MocVirtualNetwork -name "$vnetName" -group "Default_Group" -tags @{'VSwitch-Name' = "$vswitchName"} 
az azurestackhci virtualnetwork create --subscription $subscription --resource-group $resource_group --extended-location name="/subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.ExtendedLocation/customLocations/paris" type="CustomLocation" --location $Location --network-type "Transparent" --name $vnetName

Retournez sur le portail Azure afin de constater sa bonne création :

Cliquez ensuite ici pour créer votre première VM sur votre Stack HCI :

Renseignez les informations de base :

Définissez sa taille et son identifiant local, puis cliquez sur Suivant :

Ajoutez si besoin des disques de données, puis cliquez sur Suivant :

Ajoutez une carte réseau :

Utilisez le réseau virtuel créé précédemment :

Cliquez-ici pour lancer la validation :

Une fois la validation Azure réussie, cliquez sur Créer :

Le déploiement des ressources est en cours sur votre cluster, comptez environ 30 minutes pour que celui-ci se termine :

Au bout de quelques minutes Il est aussi possible de suivre la création de la VM depuis la console WAC :

Une fois la création de la machine virtuelle terminée, cliquez-ici pour y accéder :

Prenez le temps de vérifier la configuration de celle-ci :

Retournez sur la console WAC afin d’initialiser une connection directe :

Renseignez les identifiant votre compte admin chez Contoso (mot de passe : Password01) :

Cliquez-ici pour déverrouiller la session distante :

Renseignez les identifiants indiqués lors de la création de la VM depuis le portail Azure :

Vous voilà connecté sur votre VM hébergée sur un stack HCI virtuel, hosté sur un serveur Hyper-V, lui-même hosté sur Azure 😁😎💪 :

Conclusion

Après quelques jours de tests, l’intégration des outils Azure et WAC pour piloter le Cluster un véritable tour de force de Microsoft ! Nul doute que certains projets ou infrastructures ne peuvent être hébergées sur le Cloud pour un grand nombre de raisons. C’est pour cela que Microsoft et les autres fournisseurs de Cloud se doivent de proposer des solutions « à mi-chemin ».

Il faudra enfin voir ce que ça donne dans la version publique généralisée car encore beaucoup de scripts à faire dont beaucoup encore en préversion.

Jouez avec des conteneurs Azure

Continuons à nous intéresser à un autre service disponible sur Azure : le conteneur, aussi appelé virtualisation en micro-service. La conteneurisation est une méthode populaire pour le déploiement et la mise à l’échelle des applications depuis déjà plusieurs années. Peu importe l’hébergeur de Cloud public choisi, le conteneur reste un modèle très plébiscité par son fonctionnement, ses coûts et sa rapidité de mise en œuvre.

Avant de partir dans un exercice sur Azure, je vous propose de parcourir ensemble quelques notions importantes.

Qu’est-ce qu’un conteneur ?

Les conteneurs sont des environnements virtualisés, dont le but est d’exécuter généralement un micro-service. A la différence des machines virtuelles IaaS, les conteneurs sont dépourvus du système d’exploitation, car cette gestion OS est réalisée à un niveau supérieur. Cela rend leur création plus facile et ils sont beaucoup plus légers.

Un orchestrateur de conteneurs est utile pour gérer les conteneurs, mais également aussi pour manager les ressources exécutants ces conteneurs.

Conteneur ou machines virtuelles ?

Les machines virtuelles s’exécutent dans un hyperviseur (hôte) dans lequel chacune d’entre elles doit inclure son propre système d’exploitation invité (guest). En revanche, chaque conteneur partage le même système d’exploitation hôte ou noyau système. Donc l’un s’appuie sur l’autre :

Par contre, construire une application dans des conteneurs apportent plusieurs avantages non négligeables :

Moins lourd : Les conteneurs requièrent moins de ressources que les environnements de machines virtuelles, car ils n’incluent pas les images du système d’exploitation.
Plus rapide : Le démarrage d’un conteneur ne prend donc généralement que quelques secondes, contre plusieurs minutes pour une machine virtuelle.
Amélioration de la portabilité : Les applications qui s’exécutent dans des conteneurs peuvent être facilement déployées sur différents types de systèmes d’exploitation et de plateformes matérielles.
Efficacité accrue : Les conteneurs permettent de déployer, de corriger ou de faire évoluer les applications beaucoup plus rapidement.
Optimisation du développement d’applications : Les conteneurs accélèrent les cycles de développement, de test et de production grâce à la méthodologie agile et DevOps.

ACI vs AKS (K8s) ?

AKS et ACI sont deux plateformes populaires d’orchestration de conteneurs proposées par Microsoft Azure.

AKS est un service Kubernetes entièrement géré qui fournit une plateforme d’orchestration de conteneurs hautement disponible, évolutive et sécurisée.
ACI est une plateforme de conteneurs sans serveur qui vous permet d’exécuter des conteneurs sans avoir à gérer l’infrastructure sous-jacente.

Nodes vs Pods ?

Node : Un nœud correspond à une machine virtuelle. Cependant, vous pourriez créer un nœud à partir de presque n’importe quoi. Considérons un node comme un ensemble de ressources CPU et RAM qui peuvent être utilisées.
Pods : Kubernetes n’exécute pas les conteneurs directement ; ces derniers sont contenus dans une structure intermédiaire appelée Pod. Tous les conteneurs d’un même pod partagent les mêmes ressources et le même réseau local. Les conteneurs peuvent facilement communiquer avec d’autres conteneurs dans le même pod, comme s’ils étaient sur la même machine, tout en maintenant un certain degré d’isolation par rapport aux autres.

Kubernetes vs. Docker ?

Docker est une plateforme de conteneurisation et un moteur d’exécution, tandis que Kubernetes est une plateforme permettant d’exécuter et de gérer des conteneurs à partir de nombreux moteurs d’exécution de conteneurs. Kubernetes prend en charge de nombreux moteurs d’exécution de conteneurs, y compris Docker.

En résumé, Docker et Kubernetes ne poursuivent pas le même objectif : Docker vous permet de développer, déployer et donc itérer plus vite sur votre produit, tandis que Kubernetes est la solution pour le “runner” en production.
Padok

Afin de vous familiariser les conteneurs disponibles sur Azure sous différentes formes, je vous propose de suivre cet exercice dédié à ACI et AKS. La version originale de l’exercice conçu par Microsoft est également disponible en anglais sur la page GitHub juste ici.

Voici la liste des tâches modifiées que nous allons réaliser :

Comme je le répète régulièrement, une ressource déployée entraîne un début de facturation de la part de Microsoft. Il est donc important de correctement dimensionner les ressources, et de les supprimer quand elles ne sont plus utilisées.

Rappel des prérequis :

Pour réaliser cet exercice sur ASK / ACI, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Mon environnement Azure de départ ne contient aucune autre ressource, commençons par Azure Container Instances.

Etape I – Test d’Azure Container Instances :

Connectez-vous sur le portail Azure, puis authentifiez-vous :

Commencez par rechercher le service Container instances depuis la barre, en haut de votre portail Azure :

Cliquez-ici pour créer votre service Azure Container Instance :

Remplissez tous les champs comme ceci, puis cliquez sur Suivant :

Dans l’onglet Réseau, nommez votre ACI. Celui-ci doit être valide et unique, puis cliquez sur Suivant :

Lancez la validation Azure :

Une fois la validation Azure réussie, cliquez-ici pour commencer la création :

Attendez environ une minute que le processus de création se termine, puis cliquez ici :

Reprenez le FQDN de votre instance ACI :

Ouvrez un nouvel onglet de navigateur, puis collez l’URL correspondante :

Retournez sur votre portail afin de consulter le log de votre instance.

Vérifiez l’entrée représentant la requête HTTP GET générée par l’affichage de l’application dans le navigateur :

Cette première étape très rapide sur ACI est maintenant terminé. Intéressons-nous maintenant à Azure Kubernetes Service (AKS), un orchestrateur managé de conteneurs disponible sur Azure.

Etape II – Enregistrement les fournisseurs de ressources AKS :

Pour cela, ouvrez Azure Cloud Shell depuis la barre bleue en haut de votre portail Azure :

Si besoin, créez un compte de stockage si celui-ci vous le demande :

Saisissez les deux commandes suivantes pour enregistrer les fournisseurs de ressources suivants :

Microsoft.Kubernetes
Microsoft.KubernetesConfiguration

Register-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes

Register-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

Vérifiez l’avancement de l’enregistrement de ces 2 fournisseurs au niveau de votre souscription Azure :

Quelques minutes plus tard, constatez le changement de statut :

Nous environnement est maintenant prêt pour AKS. Nous allons maintenant créer notre premier cluster AKS composé d’un seul worker node.

Etape III – Déploiement d’un cluster Azure Kubernetes Service :

Depuis la barre de recherche, trouvez le service Kubernetes :

Cliquez-ici pour créer votre cluster Kubernetes sur Azure :

Renseignez les champs suivants :

Prenez soin de désactiver la mise à l’échelle automatique, puis cliquez sur Suivant :

Cochez la case suivante pour activer les nœuds virtuels ACI, puis cliquez sur Suivant :

Conservez l’option Kubernetes RBAC, puis cliquez sur Suivant :

Azure CNI est grisé à cause de l’ajout de nœuds virtuels ACI, cliquez sur Suivant :

Décochez la case des alertes, puis lancez la validation Azure :

Une fois la validation Azure réussie, cliquez-ici pour commencer la création :

Attendez environ trois minutes que le processus de création se termine :

Constatez la bonne disponibilité du nœud ASK déployé :

Notre environnement AKS est prêt à recevoir des conteneurs. Passons à l’étape suivante pour réaliser cela.

Etape IV – Déploiement des pods dans le cluster AKS :

Ouvrez à nouveau Azure Cloud Shell :

Basculez de PowerShell à Bash, puis confirmez :

Exécutez la procédure suivante pour récupérer les informations d’identification permettant d’accéder au cluster AKS :

RESOURCE_GROUP='az104-09c-rg1'

AKS_CLUSTER='az104-9c-aks1'

az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER

Exécutez la commande suivante pour obtenir la liste des nœuds actifs sur AKS :

 kubectl get nodes

Notez la présence d’un nœud virtuel représenté par ACI :

Exécutez la commande suivante afin de déployer l’image nginx depuis le Docker Hub :

 kubectl create deployment nginx-deployment --image=nginx

Exécutez la commande suivante pour obtenir la liste des pods actifs sur AKS :

 kubectl get pods

Exécutez la commande suivante pour obtenir les statuts et le nombre de la conteneurs actifs sur AKS :

 kubectl get deployment

Retrouvez cette même information sur le portail Azure :

Exécutez la commande suivante pour exposer, donc rendre le pod accessible depuis Internet :

 kubectl expose deployment nginx-deployment --port=80 --type=LoadBalancer

Exécutez la commande suivante afin d’obtenir l’adresse IP publique de l’équilibreur de charge dédié à votre application :

 kubectl get service

Retrouvez cette même information sur le portail Azure, puis ouvrez un nouvel onglet de navigateur en collant l’adresse IP correspondante :

Vérifiez que la page du navigateur affiche bien le message suivant :

Afin de comprendre la force des conteneurs, jouons un peu avec le nombre de pods dans l’étape suivante.

Etape V – Variation du nombre de Pods :

Nous allons faire évoluer les charges de travail conteneurisées dans votre cluster Azure Kubernetes.

Exécutez la commande suivante pour mettre à l’échelle le déploiement en augmentant le nombre de pods à 2 :

 kubectl scale --replicas=2 deployment/nginx-deployment

Contrôler la mise à l’échelle du déploiement via la commande suivante :

 kubectl get pods

Retrouvez cette même information sur le portail Azure :

Il est également possible d’augmenter le nombre de worker nodes dans notre environnement AKS. Pour cela, l’étape suivante nous le montre.

Etape VI – Variation du nombre de Nodes :

Exécutez la procédure suivante pour mettre à l’échelle le cluster en augmentant le nombre de nœuds à 2 :

RESOURCE_GROUP='az104-09c-rg1'

AKS_CLUSTER='az104-9c-aks1'

az aks scale --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER --node-count 2

Attendez plusieurs minutes que le traitement de création du nœud se termine :

Retrouvez ce nombre actualisé sur le portail Azure :

Exécutez la commande suivante pour vérifier le résultat de la mise à l’échelle du cluster :

 kubectl get nodes

Retrouvez cette même information sur le portail Azure :

Exécutez la commande suivante pour mettre le déploiement à l’échelle sur 10 répliques :

 kubectl scale --replicas=10 deployment/nginx-deployment

Exécutez la commande suivante pour vérifier le résultat :

 kubectl get pods

Retrouvez cette même information sur le portail Azure :

Exécutez la commande suivante pour vérifier la répartition des pods sur les nœuds du cluster :

kubectl get pod -o=custom-columns=NODE:.spec.nodeName,POD:.metadata.name

Retrouvez cette même information sur le portail Azure :

Exécutez la procédure suivante pour remettre à l’échelle le cluster à 1 nœud :

 az aks scale --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER --node-count 1

Quelques minutes plus tard, retrouvez cette même information sur le portail Azure :

 kubectl get pod -o=custom-columns=NODE:.spec.nodeName,POD:.metadata.name

Exécutez la commande suivante pour vérifier la répartition des pods sur le seul nœud restant du cluster :

AKS supporte très bien l’ajout de conteneurs managés ACI. Testons un peu cela.

Etape VII – Mix entre AKS et ACI :

Vérifiez l’état de l’enregistrement du fournisseur ACI à l’aide de la commande suivante :

az provider list --query "[?contains(namespace,'Microsoft.ContainerInstance')]" -o table

L’exemple suivant montre que le fournisseur Microsoft.ContainerInstance est enregistré :

Si le fournisseur n’est pas enregistré, il faut l’enregistrer à l’aide de la commande suivante :

az provider register --namespace Microsoft.ContainerInstance

Exécutez la commande suivante pour obtenir la liste des noeux actifs sur AKS :

kubectl get nodes

Créez un fichier nommé virtual-node.yaml en y copiant le contenu YAML suivant, ou récupérez son contenu juste ici :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: aci-helloworld
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aci-helloworld
  template:
    metadata:
      labels:
        app: aci-helloworld
    spec:
      containers:
      - name: aci-helloworld
        image: mcr.microsoft.com/azuredocs/aci-helloworld
        ports:
        - containerPort: 80
      nodeSelector:
        kubernetes.io/role: agent
        beta.kubernetes.io/os: linux
        type: virtual-kubelet
      tolerations:
      - key: virtual-kubelet.io/provider
        operator: Exists

Cliquez sur Téléverser pour lancer l’opération de transfert vers Azure :

Choisissez le fichier précédemment généré :

Exécutez l’application à l’aide de la commande suivante :

kubectl apply -f virtual-node.yaml

Constatez l’apparition de l’application sur votre portail Azure, puis attendez :

Exécutez la commande suivante pour exposer, donc rendre le pod disponible depuis Internet :

kubectl expose deployment aci-helloworld --port=80 --type=LoadBalancer

Ouvrez un nouvel onglet de navigateur, puis collez l’adresse IP correspondante.

Vérifiez que la page du navigateur affiche bien le message Welcome to Azure Container Instances! :

Exécutez la commande suivante pour mettre à l’échelle le déploiement en augmentant le nombre de pods à 5 :

kubectl scale --replicas=5 deployment/aci-helloworld

Retrouvez cette même information sur le portail Azure :

Cliquez sur votre nœud ACI :

Constatez la bonne présence de votre application et de ses répliques :

Un dernier test pour mieux comprendre le découplage d’une application dans plusieurs conteneurs.

Etape VIII – Test d’une application multi-conteneurs :

Créer un fichier nommé azure-vote-v2.yaml en y copiant le contenu YAML suivant, ou récupérez son contenu juste ici :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: azure-vote-back
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-vote-back
  template:
    metadata:
      labels:
        app: azure-vote-back
    spec:
      nodeSelector:
        kubernetes.io/role: agent
        beta.kubernetes.io/os: linux
        type: virtual-kubelet
      tolerations:
      - key: virtual-kubelet.io/provider
        operator: Exists
      containers:
      - name: azure-vote-back
        image: mcr.microsoft.com/oss/bitnami/redis:6.0.8
        env:
        - name: ALLOW_EMPTY_PASSWORD
          value: "yes"
        ports:
        - containerPort: 6379
          name: redis
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-back
spec:
  ports:
  - port: 6379
  selector:
    app: azure-vote-back
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: azure-vote-front
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-vote-front
  template:
    metadata:
      labels:
        app: azure-vote-front
    spec:
      nodeSelector:
        kubernetes.io/role: agent
        beta.kubernetes.io/os: linux
        type: virtual-kubelet
      tolerations:
      - key: virtual-kubelet.io/provider
        operator: Exists
      containers:
      - name: azure-vote-front
        image: mcr.microsoft.com/azuredocs/azure-vote-front:v1
        ports:
        - containerPort: 80
        env:
        - name: REDIS
          value: "azure-vote-back"
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front

Cliquez sur Téléverser pour lancer l’opération de transfert vers Azure :

Exécutez l’application à l’aide de la commande suivante :

kubectl apply -f azure-vote-v2.yaml

Constatez l’apparition de l’application sur votre portail Azure, puis attendez :

Environ 2 minutes plus, constatez le changement de statut en vert :

Vérifiez la bonne affectation de votre application sur le nœud ACI :

Cette information avait été renseigné dans le fichier YAML :

Ouvrez un nouvel onglet de navigateur en collant l’adresse IP correspondante :

Vérifiez que la page du navigateur affiche bien l’application de vote :

Testez l’application en votant pour Chiens ou Chats :

Ouvrez un nouvel onglet en navigation privée :

Vérifiez la persistance des votes précédemment réalisés :

Effacez votre résultat, puis fermez l’onglet de navigation privé :

Rafraichissez la page de test, puis constatez le même effacement des précédents votes :

Conclusion

Grâce à ce petit exercice, nous avons bien compris que le conteneur n’est qu’un moyen parmi d’autres pour faire tourner une application, avec de nombreux avantages.

Mais, quelle que soit la plateforme choisie, il est toujours primordial de suivre les bonnes pratiques pour concevoir, mettre en œuvre et gérer vos applications : à savoir la surveillance, optimisations, sécurité, confirmé et coûts 😎.

Azure Bastion est votre ami !

Par moment, les machines virtuelles ont besoin de passer entre les mains de l’IT pour différentes tâches : mises à jour OS, installation d’applications, résolution de problème, etc … A l’inverse des accès utilisateurs, les connexions réalisées par les équipes IT, dont les privilèges sont potentiellement plus élevés, sont souvent occasionnelles et externes.

Ce besoin de connexion irrégulier ne doit pas pourtant donner lieu à abaissement de la sécurité, car des risques pour vos VMs Azure sont toujours présents :

Risques d’attaque plus élevés si la sécurité de l’accès IT est dégradée
Risques de dégâts plus importants compte tenu des privilèges IT élevés

Comme pour n’importe quel accès, des mesures de sécurité en couche sont nécessaires, même pour les équipes IT. Voici des liens vers des articles précédemment écrits de blog :

Qu’est-ce qu’Azure Bastion ?

Voici la définition d’Azure Bastion donnée par Microsoft

Azure Bastion est un service complètement managé qui offre un accès RDP (Remote Desktop Protocol) et SSH (Secure Shell) plus sécurisé et transparent pour les machines virtuelles sans aucune exposition via des adresses IP publiques. Approvisionnez le service directement dans votre réseau virtuel local ou appairé pour prendre en charge toutes les machines virtuelles qu’il contient.
Documentation Azure

Azure Bastion est donc un service de jump pour accéder aux machines virtuelles sur Azure, que celles-ci soient Windows ou Linux.

Le schéma ci-dessous nous montre le tunnel d’accès créé entre Azure Bastion et l’utilisateur initiateur (via une connexion inversée) grâce au protocole TLS :

J’ai également trouvé une vidéo dédiée à Azure Bastion en français, dont voici le lien :

Quel est son point fort ?

Un seul mot doit vous venir en tête :

La sécurité

Comme tout service de jump, Azure Bastion devient de facto la ressource exposée de votre infrastructure Cloud. Dans les faits, ce dernier intègre des fonctions de pare-feu et des mesures périmétriques de sécurité.

De plus, l’accès au service depuis le portail Azure apporte la couche de pré-authentification d’Azure AD. Celui-ci profite alors de toutes ses mesures de sécurité, comme l’Accès conditionnel, la gestion des droits RBAC, etc …

L’approche d’une connexion sécurisée via TLS permet de s’affranchir de règles sécurités lourdes.

Enfin, Azure Bastion mettra tout le monde d’accord grâce au retrait des adresses IP publiques sur vos VMs Azure, car la connexion RDP/SSH entre Bastion et votre machine virtuelle se fera via le réseau virtuel privé Azure, donc grâce et uniquement par son adresse IP privée.

Combien coûte Azure Bastion ?

Disons-le tout de suite, Azure Bastion n’est pas un service gratuit 🤣. La documentation Azure nous donne toutes les informations tarifaires. Voici la copie d’écran du service dans la région Azure Suisse Nord :

Voici ces mêmes données tarifaires pour un mois complet, dans le cas où le service reste actif :

Azure Bastion Basic : 125 CHF environ
Azure Bastion Standard : 192 CHF environ

Gardez à l’esprit que ce service ne nécessite pas systématiquement un déploiement aussi long. Dans beaucoup d’infrastructures IT, il est possible d’envisager son déploiement à la demande.

Cinq petites minutes vous suffiront pour déployer Azure Bastion !

Comment choisir son SKU Bastion ?

Choisir le SKU d’Azure Bastion adapté à vos besoins doit reposer sur les fonctionnalités voulues. Quelques fonctionnalités diffèrent entre les versions Basic et Standard :

A noter qu’il est possible de migrer du SKU Basic au SKU Standard après le déploiement de Bastion, mais pas le chemin inverse n’est plus possible.

Comment mettre en place Azure Bastion ?

Rien de plus simple ! Quelques clics suffisent pour déployer Azure Bastion.

Dans cet article, nous allons déployer Azure Bastion, puis tester quelques fonctionnalités de connexion. Bref, ne perdons pas de temps :

Etape 0 – Rappel des prérequis
Etape I – Préparation de votre environnement Azure
Etape II – Déploiement d’Azure Bastion
Etape III – Azure Bastion via un appairage entre réseaux virtuels Azure
Etape IV – Upgrade d’Azure Bastion vers le SKU Standard
Etape V – Support du client natif d’Azure Bastion
Etape VI – Utilisation de liens partageables Azure Bastion
Etape VII – Utilisations des adresses IP privées

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Azure Bastion, dont certaines fonctionnalités sont encore en préversion, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Mon environnement Azure de départ ne contient aucune autre ressource, commençons par la préparation d’un nouvel environnement Azure :

Etape I – Préparation de votre environnement Azure :

Commencez par rechercher le service Réseau Virtuel dans la barre de recherche tout en haut :

Cliquez ici pour créer votre premier réseau virtuel Azure :

Créez un premier groupe de ressources, donnez un nom à votre réseau virtuel, puis lancez la validation Azure :

Une fois la validation Azure réussie, cliquez-ici pour commencer la création :

Attendez environ une minute que le processus de création se termine :

Une fois terminé, recherchez le service des Machines Virtuelles Azure :

Cliquez-ici pour créer une première machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM :

Pensez à désactiver les règles publiques de port entrant, puis cliquez sur Suivant :

Aucune option n’est à modifier sur l’onglet des disques, cliquez sur Suivant :

Dans l’onglet réseau, effectuez les modifications suivantes :

Retirez l’adresse IP publique proposée par Azure
Vérifiez que les règles publiques du NSG lié à la carte réseau de la VM sont bien désactivées

Puis, cliquez-ici pour lancer la validation :

Une fois la validation réussie, cliquez-ici pour démarrer le processus de création :

Environ deux minutes plus tard, cliquez-ici pour accéder à votre machine virtuelle Azure :

Cliquez sur Connecter pour démarrer une session de bureau à distance :

Azure commence par effectuer contrôles d’accès. Deux points sur trois sont déjà considérés comme des blocages potentiels :

Port RDP fermé : L’accès publique au port RDP a été volontairement fermé lors de la création de la machine virtuelle.
Absence d’adresse IP publique : celle-ci a volontairement été retirée lors de la création de la machine virtuelle.

Cliquez-ici pour télécharger le fichier RDP préconfiguré pour vous connecter à votre VM :

Exécutez le fichier RDP téléchargé précédemment, puis attendez :

Environ vingt secondes plus tard, un message d’échec de connexion doit apparaître :

Pas d’adresse IP publique et pas de port RDP ouvert en public sont bien les explications logiques du blocage de l’accès distant.

Retrouvez la configuration de ces deux points justes ici :

L’accès RDP à notre machine virtuelle est bien sécurisé. Mais du coup … personne en dehors d’Azure peut s’y connecter ! Il nous faut trouver une solution sans exposer la machine virtuelle.

C’est ici qu’Azure Bastion rentre en scène.

Etape II – Déploiement d’Azure Bastion :

Comme l’indique le schéma ci-dessous, Azure Bastion s’installe sur un sous-réseau dédié dont son nom est normé : AzureBastionSubnet.

Sur votre Portail Azure, recherchez le réseau virtuel créé précédemment :

Dans la section des sous-réseaux, ajoutez-en un :

Le sous-réseau doit avoir la configuration suivante :

Le nom du sous-réseau doit être AzureBastionSubnet.
La taille du sous-réseau doit être /26 ou plus grand
Le sous-réseau ne pourra pas contenir d’autres ressources Azure

Renseignez les champs, puis sauvegardez-le :

Recherchez ensuite le service Bastion dans la barre de recherche du portail Azure :

Cliquez-ici pour créer votre Azure Bastion :

Renseignez les champs nécessaires, en prenant soin de sélectionner un SKU de type Basic, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création de votre Azure Bastion :

Attendez environ 5 minutes pour que le service soit entièrement déployé sur votre environnement :

*Selon la charge présente sur la région Azure sélectionnée, il arrive que le processus de création soit un peu plus long.*

Retournez sur votre machine virtuelle de test, puis lancez une connexion comme ceci :

Renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM, puis cliquez sur Connecter :

Un nouvel onglet dans votre navigateur interne s’ouvre et ouvre une session Windows sur votre machine virtuelle :

*Si rien ne se passe, vérifiez si ce dernier ne bloque pas les pop-ups Azure.*

Gardez ouverte la session de bureau à distance via Azure Bastion.

Sur la partie gauche de votre session, notez la présence de deux flèches, cliquez dessus, puis constatez le presse-papier de base :

Retournez sur le portail Azure, le menu Session affiche une liste des utilisateurs connectés à Azure Bastion.

Note : Il est en effet possible d’ouvrir plusieurs sessions Bastions vers différentes machines virtuelles.

Votre service Bastion fonctionne bien, l’accès RDP à votre machine virtuelle Windows est sécurisé. Continuons un peu en testant une autre méthode de connexion grâce à Azure Bastion.

Etape III – Azure Bastion via un appairage entre réseaux virtuels Azure :

Bien souvent, les infrastructures Azure contiennent plusieurs réseaux virtuels. Cela fait sens dans le cadre d’architecture multi-régions. Ici, nul besoin de créer et de payer plusieurs Bastion !

Afin de tester le bon fonctionnement d’un seul service Azure Bastion sur un autre réseau virtuel, j’ai créé les ressources Azure suivantes :

Second réseau virtuel Azure
Seconde machine virtuelle Azure
Appairage entre les 2 réseaux virtuels

Voici l’appairage et son statut Connecté sur un des 2 réseaux virtuels :

Sur la seconde machine virtuelle, cliquez sur le service Azure Bastion pour m’y connecter :

Azure recherche si un service Bastion est déployé sur le même réseau virtuel
Si non, Azure recherche un Bastion sur un réseau virtuel appairé à celui-ci

Renseignez les identifiants de l’administrateur local de ma seconde VM, puis cliquez sur Connecter :

Constatez la bonne connexion RDP à ma seconde machine virtuelle :

Azure Bastion fonctionne donc de manière étendue à plusieurs réseaux virtuels. Cette fonction est accessible dès le SKU Basic. Aucun doute que cela est fortement apprécié car il simplifie les méthodes de connexion, mais réduit aussi les coûts !

D’autres méthodes de connexion sont disponibles via Azure Bastion, mais elles nécessitent de changer le SKU de notre service.

Etape IV – Upgrade d’Azure Bastion vers le SKU Standard :

Pour tester les autres méthodes de connexion, il nous est nécessaire de changer le SKU d’Azure Bastion de Basic vers Standard :

*Attention, la migration du SKU en **Standard** n’est pas réversible !*

Attendez quelques minutes qu’Azure applique votre upgrade :

Le changement de SKU d’Azure Bastion entraine d’ailleurs une fermeture des sessions ouvertes via Azure Bastion :

Quelques minutes plus tard, le traitement d’upgrade est terminé :

Notre Azure Bastion est maintenant Standard. Nous allons pouvoir tester d’autres moyens de connexion, comme par exemple via le client natif.

Etape V – Support du client natif d’Azure Bastion :

La fonctionnalité de client natif vous permet de vous connecter à vos machines virtuelles cibles par le biais de Bastion en utilisant Azure CLI
Microsoft Learn

En quelques mots, cette méthode est utile quand on souhaite se passer du portail Azure. Pour utiliser ce moyen de connexion, il est nécessaire d’activer ce service sur Bastion.

Comme les options supplémentaires de Bastion sont maintenant dégrisées, cochez la case Support du client natif, puis cliquez sur Appliquer :

Attendez quelques minutes qu’Azure applique votre modification :

Sur votre poste local, ouvrez une session Terminal :

Commencez par mettre à jour le sous-module réseau d’Azure, utilisé par Azure Bastion :

Update-Module Az.Network -Force

Attendez quelques minutes que le téléchargement, puis l’installation du module se termine :

Copiez l’ID de la souscription contenant votre service Azure Bastion :

Dans votre fenêtre Terminal, lancez le processus d’authentification à Azure :

az login

Microsoft Edge doit alors s’ouvrir pour vous proposer de réutiliser un compte Azure déjà authentifié. Cliquez sur celui-ci si cela est votre cas :

Le message suivant apparaît alors dans votre navigateur :

De retour sur Terminal, saisissez la commande pour vous positionner sur la souscription Azure de votre Bastion :

az account set --subscription "<subscription ID>"

Sur le portail Azure, récupérez l’ID de ressource de votre première machine virtuelle :

Dans votre fenêtre Terminal, saisissez la commande suivante en prenant soin de modifier les 3 variables suivantes :

Nom de votre ressource Azure Bastion
Groupe de ressources votre service Azure Bastion
ID de ressource de votre machine virtuelle

az network bastion rdp --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-resource-id "<VMResourceId>"

Un pop-up RDP s’ouvre alors, cliquez sur Connecter :

Renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM :

Acceptez le risque en cliquant sur Oui :

Une connexion RDP s’ouvre sur le bureau de votre VM :

Fermez la session de bureau à distance.

Comme Microsoft et d’autres le rappellent, la sécurité de la connexion native peut être renforcée en limitant l’accès uniquement aux ports 22/3389 :

Continuons en testant une autre méthode de connexion à Azure Bastion: les liens partageables.

Etape VI – Utilisation de liens partageables Azure Bastion :

La fonctionnalité lien partageable Bastion permet aux utilisateurs de se connecter à une ressource cible (machine virtuelle ou groupe de machines virtuelles identiques) à l’aide d’Azure Bastion sans accéder au Portail Azure.
Microsoft Learn

Là encore, l’accès au portail Azure n’est peut-être pas possible ou voulue. Le lien partageable peut être communiqué à un tier afin que celui-ci puisse se connecter à la machine virtuelle et y effectuer des opérations IT.

Dans l’écran de configuration d’Azure Bastion, cochez la case suivante, puis cliquez sur Appliquer :

Attendez quelques minutes afin qu’Azure applique votre modification :

Un nouveau menu dédié aux liens partagés fait son apparition dans les paramètres votre Azure Bastion. Cliquez-ici pour créer votre premier lien partagé :

Cochez la ou les machines virtuelles accessibles grâce à ce lien, puis cliquer sur Appliquer :

Le nouveau lien partagé s’ajoute aux liens déjà générés, copiez votre lien dans le presse-papier :

Ouvrez un navigateur privé :

Collez votre lien partageable dans la barre d’adresse, renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM, puis cliquez-ici pour ouvrir la session :

Attendez quelques secondes, puis constatez l’ouverture du bureau à distance :

Avant de fermer la session ouverte grâce au lien partagé, supprimez le lien généré :

Constatez l’absence de fermeture de session, malgré la suppression du lien.

Fermez la session puis retentez l’ouverture par la même URL précédemment copiée :

L’utilisateur est bien bloqué dans sa seconde tentative de connexion.

Ces liens partagés sont donc intéressant si les utilisateurs sont externes au service IT doivent intervenir très ponctuellement sur une machine virtuelle.

Continuons nos tests sur une autre méthode de connexion : les adresses IP privées.

Etape VII – Utilisations des adresses IP privées :

Une connexion basée sur IP vous permet de vous connecter à vos machines virtuelles Azure et non Azure locales via Azure Bastion sur ExpressRoute ou une connexion VPN site à site en utilisant une adresse IP privée spécifiée.
Microsoft Learn

Grâce à cette fonctionnalité, les équipes IT peuvent se connecter à presque tous les VMS grâce à Azure Bastion ! Peu importe où la ressource se trouve : dans ou en dehors d’Azure.

Pour tester cette fonctionnalité, j’ai modifié quelques peu mon infrastructure Azure déjà en place. J’ai simulé une connexion site à site entre mes 2 réseaux virtuels comme ceci :

J’ai supprimé l’appairage entre mes deux réseaux virtuels
Sur chacun de mes deux réseaux virtuels Azure, j’ai déployé les ressources suivantes :
- Passerelle VPN Basic
- Passerelle de réseau local reprenant l’IP publique du VPN opposé
- Connexion VPN IP Sec

Une des 2 passerelles VPNs configurées :

Une des 2 passerelles de réseau local configurées :

Une des 2 connexions VPN configurées :

Une fois l’infrastructure réseau en place, cochez la case suivante dans la configuration d’Azure Bastion, puis cliquez sur Appliquer :

Attendez quelques minutes qu’Azure applique votre modification :

Un nouveau menu dédié aux adresses IP privées fait son apparition sur votre configuration Azure Bastion. Cliquez-ici pour créer établir une connexion directe :

Attendez quelques secondes, puis constatez l’ouverture du bureau à distance :

Sur une des 2 connexions VPNs, modifiez la clef partagée afin de briser la connexion entre les 2 réseaux virtuels, et de ce fait, couper la session de bureau à distance :

Attendez quelques secondes :

La session d’Azure Bastion fini bien par s’interrompre :

Restaurez la bonne clef partagée, puis sauvegardez :

La connexion du bureau à distance transitant par Bastion est alors automatiquement rétablie :

Conclusion

Bastion rejoint la liste des services managés Azure très utile et très facile à mettre en oeuvre. La non-maîtrise des réseaux rend l’outil encore plus accessible aux débutants, et apporte une première couche de sécurité.

Il ne faut jamais douter des capacités d’attaque de pirates quand des ressources se retrouvent exposées sur internet, Cloud ou pas.

Bodybuildez votre AVD !

Azure Virtual Desktop n’en finit plus d’évoluer ! Aujourd’hui est une grande journée pour l’automatisation des environnements AVD. Jusqu’à présent, Azure proposait peu de solutions adéquates pour AVD pour faciliter le processus de gestion des images des VMs. Pour enfoncer le clou(d), d’autres solutions tierces faisaient déjà mieux et rendaient le travail IT beaucoup plus léger.

Microsoft vient donc de sortir une nouvelle fonctionnalité à son produit AVD, encore en préversion à ce jour, mais attendue depuis fort longtemps : Custom image templates, ou Modèles d’images personnalisés pour les francophones.

Aucun doute que les administrateurs d’AVD vont aimer !

Pourquoi doit-on gérer des images avec Azure Virtual Desktop ?

La gestion des applications et des mises à jour d’un environnement AVD reste très proche d’un environnement RDS traditionnel. De temps à autre, il vous faut penser à :

Les applications doivent être mises à jour
Les mises à jour correctives ou sécuritaires doivent être appliquées
Les besoins logiciels des utilisateurs évoluent
De nouvelles optimisations sont disponibles

Toutes ces raisons et encore d’autres font que les machines virtuelles d’un environnement Azure Virtual Desktop doivent être mises à jour régulièrement, et si possible, avec un mode opératoire le plus automatisé.

Que proposait Azure Virtual Desktop avant cette fonctionnalité ?

En cherchant un peu, on retrouvait déjà plusieurs méthodes qui avaient déjà fait leurs preuves :

Gestion 100% manuelle via Golden Image / Sysprep / Snapshot :

Gestion 50% manuelle via l’utilisation d’un Template d’Azure Image Builder :

Solutions tierces, comme par exemple la très connue Nerdio :

Sur quoi repose la fonction Custom image templates d’AVD ?

Disons-le tout de suite, Custom image templates fonctionne toujours avec Azure Image Builder.

Mais tout est maintenant intégré dans la console Azure Virtual Desktop. Et le meilleur dans tout ça :

l’intégration d’optimisations est gérée dans le template, qu’elles soient préconstruites par Microsoft ou créées par vos soins !

C’est tout le processus de préparation qui peut alors s’intégrer dans la seule étape de création du template. Fini les aller et retours !

Bref, ne perdons pas de temps, et testons ensemble cette fonctionnalité.

Etape 0 – Rappel des prérequis
Etape I – Préparation de votre environnement Azure Virtual Desktop
Etape II – Azure VM Image Builder
Etape III – Création d’un modèle d’image personnalisé
Etape IV – Préparation de l’image AVD
Etape V – Création de l’environnement AVD
Etape VI – Test de connexion à votre environnement AVD

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les templates d’Azure Virtual Desktop, encore en préversion, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Afin de ne pas rendre cet article trop long, j’ai déjà préparé un environnement Azure. Je vous liste dans l’étape suivante tous les composants déjà mis en place sur mon environnement avant de démarrer le test.

Etape I – Préparation de votre environnement Azure Virtual Desktop :

J’ai créé un premier groupe de ressources Azure, dans lequel j’ai déployé 2 VMs :

Une première machine virtuelle Windows Server avec des rôles AD DS / DNS
Une seconde machine virtuelle Windows Server avec Azure AD Connect

J’ai également déployé dans un second groupe de ressources pour :

Un réseau virtuel pour l’ensemble de mon infrastructure AD DS / AVD :
Un service Azure Bastion pour me connecter aux différentes machines de mon domaine

Dans ce réseau virtuel Azure, nous retrouvons les sous-réseaux suivants :

Sous-réseau pour la partie domaine / Azure AD Connect
Sous-réseau pour les machines virtuelles AVD
Sous-réseau dédié au service Azure Bastion

Je n’ai pas oublié non plus de renseigner l’adresse IP locale de mon AD en tant que DNS de premier niveau sur mon réseau virtuel :

J’ai également déployé une Azure Compute Gallery, dans laquelle se trouvent une définition de base d’une image pour mon environnement AVD :

Grâce à la mise en place du domaine Active Directory et d’Azure AD Connect, j’ai pu synchroniser deux utilisateurs AD vers Azure AD :

J’ai également créé un compte de stockage Azure. Grâce à la tâche 6 de cet article, j’ai configuré ce compte de stockage pour être joint à mon Active Directory.

J’ai également créé un partage de fichier pour la gestion des profiles en itinérance via FSLogix :

Je n’ai pas oublié de rajouter les rôles Azure RBAC spécifiques au partage SMB FSLogix :

J’ai également transposé ces droits Azure RBAC en droits NTFS sur ce même partage FSLogix :

J’ai enfin vérifié, au niveau de ma souscription Azure, le bon enregistrement des fournisseurs de ressources suivants :

Microsoft.VirtualMachineImages
Microsoft.KeyVault

Si cela n’est pas fait, voici la procédure qui vous prendra à peine deux minutes :

Votre environnement de départ est enfin prêt pour commencer la mise en place de Modèles d’images personnalisés pour AVD.

L’étape suivante est donc consacré à la mise en place d’une identité managée pour Azure VM Image Builder.

Etape II – Azure VM Image Builder :

VM Image Builder est un service Azure complètement managé qui est accessible aux fournisseurs de ressources Azure. Les fournisseurs de ressources le configurent en spécifiant une image source, une personnalisation à effectuer et l’emplacement où la nouvelle image doit être distribuée.
Microsoft Learn

Pour que Azure VM Image Builder gère des images AVD, il est nécessaire de lui créer une identité managée Azure. Celle-ci disposera des autorisations nécessaires pour lire et écrire des images :

Microsoft.Compute/images/write
Microsoft.Compute/images/read
Microsoft.Compute/images/delete
Microsoft.Compute/galleries/read
Microsoft.Compute/galleries/images/read
Microsoft.Compute/galleries/images/versions/read
Microsoft.Compute/galleries/images/versions/write

Au niveau de votre souscription Azure, rendez-vous dans le menu suivant pour commencer la création d’un rôle personnalisé :

Donnez-lui un nom, puis cliquez sur Suivant :

Parcourez la liste des permissions disponibles afin d’ajouter celles ci-dessous :

Dean met aussi à disposition sur son GitHub un template JSON contenant ces permissions.

Définissez le périmètre de la souscription Azure pour ce nouveau rôle :

Lancez la création en cliquant sur Créer :

Sur votre portail, recherchez dans la barre du haut le services des Identités Managées :

Cliquez-ici pour créer votre Identité Managée dédiée à Azure VM Image Builder :

Nommez celle-ci, puis lancez la validation :

Une fois la validation passée, cliquez sur Créer :

Retournez au niveau de la souscription Azure pour assigner le rôle personnalisé à votre nouvelle identité managée :

Recherchez le rôle personnalisé en utilisant le filtre :

Cliquez ici pour rechercher dans Azure AD votre nouvelle identité managée :

Lancez la validation de votre affectation :

Une fois la validation passée, cliquez sur Assigner :

Toutes les étapes préparatoires à la création d’un modèle d’image personnalisé sont maintenant terminées. Nous allons pouvoir maintenant commencer la création de notre template AVD.

Comme le rappelle Dean durant sa vidéo, d’autres options seront prochainement rajoutées par la suite.

Etape III – Création d’un modèle d’image personnalisé :

Recherchez le service Azure Virtual Desktop en utilisant la barre du haut :

Dans le menu Modèle d’image personnalisés, cliquez-ici pour ajouter votre premier template :

Nommez votre template, choisissez sa localisation, reprenez l’identité managée créée et affectée précédemment, puis cliquez sur Suivant :

*Comme il s’agit de votre premier template, cliquez sur Non à la question d’importation :*

Sélectionnez votre image source, en utilisant par exemple la Marketplace Microsoft :

Attention à la génération rattachée à votre Image.
Celle-ci devra également utiliser des tailles de VM compatibles.

Concernant le stockage de votre template AVD, deux destinations sont possibles avec Azure VM Image Builder :

Image managée : utilisable pour AVD ou Windows 365
Azure Compute Gallery : utilisable pour AVD

Cochez la cible Azure Compute Gallery, renseignez les informations nécessaires, puis cliquez sur Suivant :

*L’option **Latest** sera un choix intéressant pour positionner l’image en dernière version à déployer.*

Azure VM Image Builder a besoin de quelques informations durant le processus de fabrication :

Timeout : à définir si besoin. Si vide, alors 240 minutes
Taille de la VM : taille sans rapport direct avec les futures VMs AVD
Taille du disque OS : taille avec rapport direct sur celui des futures VMs AVD
Groupe de ressources temporaire : Si laissé vide, le groupe sera créé par Azure
Réseau Virtuel : champs facultatifs

Puis cliquez sur Suivant :

Azure VM Image Builder vous propose d’exécuter à votre place des traitements post-déploiement. Vous pouvez lancer vos propres scripts, ou piochez dans la longue liste mise à disposition par Microsoft.

Cliquez-ici pour ajouter votre propre script, si besoin :

Cliquez-ici pour consulter la liste des scripts dédiés à AVD et construits par Microsoft :

Choix dans la liste les options voulues, puis sauvegardez :

Vérifier une dernière fois les options choisies, puis cliquez sur Suivant :

Ajoutez les étiquettes pour une meilleure classification de vos ressources Azure, puis cliquez sur Suivant :

Lancez la création de votre template en cliquant sur Créer :

Environ quelques secondes plus tard, le processus de création du template se lance, le statut passe alors en Création :

La création d’un template est assez rapide, le statut doit alors changer en Succès et le nom du groupe de ressources temporaire doit apparaître.

Cliquez dessus pour voir la première ressource créée :

Seul un compte de stockage est pour l’instant créé, cliquez dessus :

Un premier conteneur Blob est créé, dans lequel se trouvent les optimisations de votre template AVD :

Retournez sur les Modèles d’images personnalisés, puis cliquez sur le groupe de ressources de votre template :

Constatez la présence de votre template :

Le template, ou la recette de votre VM AVD, est maintenant prêt. Un second processus doit être lancé pour créer l’image AVD en elle-même. Azure VM Image Builder va réaliser les actions suivantes :

Créer une machine virtuelle à partir de la marketplace
Lui appliquer votre configuration personnalisée
La capturer et la stocker dans votre Azure Compute Gallery

Etape IV – Préparation de l’image AVD :

Ce processus peut prendre beaucoup de temp. Celui-ci dépendra également des personnalisations choisies à appliquer.

Cliquez-ici pour démarrer le processus de construction de votre image :

Le statut de construction change comme ceci :

Deux nouveaux conteneurs sont créés sur votre compte de stockage temporaire :

packerlogs : Journal d’évènements d’Azure VM Image Builder
vhds : fichier VHD de votre image créé par Azure VM Image Builder

Cliquez sur le premier conteneur afin de consulter, si besoin, le journal de log d’Azure VM Image Builder :

Rafraichissez cette page afin de voir le changement de statut :

Rafraichissez également cette seconde page afin de voir les changements de date de modification du journal d’évènements :

Environ 2 heures plus tard, le statut est enfin passé à Succès :

Vérifiez que la définition de votre image est bien stockée dans votre Azure Compute Gallery :

La version de l’image est également visible dans le groupe de ressources cible :

Notre image est enfin prête à intégrer un environnement Azure Virtual Desktop.

L’étape suivante consiste donc à créer un premier pool AVD en choisissant comme source cette nouvelle image personnalisée.

Etape V – Création de l’environnement AVD :

Sur la page Azure Virtual Desktop, commencez la création de votre environnement Azure Virtual Desktop comme ceci :

Définissez les options de base de votre pool d’hôtes :

Ajoutez une ou plusieurs machines virtuelles en prenant le soin de choisir l’image créée et stockée dans votre Azure Compute Gallery :

Renseignez les informations réseaux pour que votre VMs AVD se trouve sur le même réseau virtuel que votre AD :

Renseignez les informations liées à votre AD et les identifiants pour disposer d’un compte administrateur local, puis cliquez sur Suivant :

Créez un nouvel Espace de travail, puis lancez la validation :

Une fois la validation terminée, cliquez sur Créer :

Attendez environ 5 à 10 minutes, le temps que la création de votre environnement AVD se termine, puis cliquez ici :

Changez l’option d’authentification d’Azure AD, puis sauvegardez :

Cliquez sur le groupe d’applications AVD :

Ajoutez vos utilisateurs ou votre groupe d’utilisateurs de test :

C’est enfin fini ! Toutes les configurations sont faites ! Il ne vous reste plus qu’à tester votre nouvel environnement Azure Virtual Desktop.

Etape VI – Test de connexion à votre environnement AVD :

Pour cela, utilisez le client Remote Desktop disponible ici, ou l’URL suivante pour une connexion en HTLML5 via le navigateur internet.

Ouvrez votre application, souscrivez à un nouvel espace de travail, puis authentifiez-vous avec un compte utilisateur de test :

Réauthentifiez-vous une seconde fois, localement :

Attendez que la session de bureau à distance s’ouvre :

Vérifiez quelques paramétrages personnalisés, comme la langue ou les applications installées :

Les choses semblent pas mal pour moi sauf le pays et encore l’heure de la VM :

Vérifiez également sur votre compte de stockage dédié à FSLogix que l’ouverture de session AVD génère bien la création d’un profil itinérant :

On peut dire qu’on est pas mal, non ? 😎

Conclusion :

L’intégration Azure VM Image Builder dans la console Azure Virtual Desktop, mais aussi l’ajout direct de personnalisations, proposées par Microsoft, est un véritable pas en avant concernant la simplification !

Azure Virtual Desktop conserve malgré tout la caractéristique de pouvoir être personnalisé manuellement, mais apporte en parallèle une couche d’automatisme pour les petits environnements.

Nul doute que tout cela sera très fortement apprécié !

Checkez la disponibilité de vos VMs Azure

Beaucoup de projets d’infrastructure Cloud contiennent des services Cloud de type IaaS. Entièrement configurable, une machine virtuelle en est un bon exemple chez tous les principaux fournisseurs de Cloud. Le IaaS apporte des avantages par une grande flexibilité, mais aussi des inconvénients, comme par exemple sa gestion des mises à jour.

Dans le cadre d’un hébergement d’un service web, la machine virtuelle n’est d’ailleurs pas le premier choix proposé par les fournisseurs Cloud. Néanmoins, il arrive qu’une machine virtuelle soit le seul choix technique possible.

Dans cet article, nous n’allons pas nous intéresser au choix VM / App Service. Mais à la mise en place d’une alerte de disponibilité HTTP, dans le but vérifier le bon fonctionnement de l’accès externe.

Que sont les alertes d’Azure Monitor ?

Les alertes vous permettre de détecter et de résoudre des problèmes avant que les utilisateurs ne les remarquent en vous informant de manière proactive quand les données Azure Monitor indiquent qu’il peut y avoir un problème avec votre infrastructure ou votre application.

Vous pouvez définir une alerte sur n’importe quelle source de données de métrique ou de journal dans la plateforme de données Azure Monitor.
Microsoft Learn

Il est très facile de créer une alerte sur un Web App. Mais il est aussi possible d’en créer sur d’autres services, comme sur un service IIS hébergé sur une machine virtuelle.

Afin des tester ce scénario, nous allons créer une machine virtuelle avec un rôle IIS afin de créer une alerte HTTP pour vérifier sa bonne disponibilité à travers le globe :

Etape 0 – Rappel des prérequis
Etape I – C réation de la machine virtuelle Azure
Etape II – Installer un rôle IIS sur votre machine virtuelle
Etape III – Configuration du test de disponibilité HTTP
Etape IV – Vérification du test de disponibilité HTTP
Etape V – Configuration des alertes de disponibilité
Etape VI – Test de la notification d’alerte

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les alertes d’Azure Monitor, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Si vous ne disposez pas de machine virtuelle Azure sur votre environnement, commencez par l’étape I afin de préparer l’environnement nécessaire à la mise en place de l’alerte.

Etape I – Création de la machine virtuelle Azure :

Commencez par créer une Machine Virtuelle Azure en utilisant la barre de recherche en haut du portail :

Sélectionnez le premier choix pour créer votre machine virtuelle :

Sur le premier onglet, renseignez les champs relatifs aux principales caractéristiques de votre VM :

Définissez un compte d’administrateur local, ouvrez le port HTTP pour le traffic entrant, puis cliquez sur Suivant :

Cliquez sur Suivant pour continuer la configuration :

Vérifiez sur cet onglet que le port HTTP est toujours listé, puis cliquez-ici pour lancer la validation de la configuration :

Une fois la validation correctement terminée, cliquez sur Créer :

Environ 3 minutes plus tard, votre machine virtuelle est créée et est accessible.

Cliquez-ici pour rentrer dans la configuration de votre VM :

Copiez l’adresse IP publique de votre machine virtuelle :

Ouvrez un nouvel onglet dans votre navigateur, puis collez l’adresse IP publique précédemment copiée :

Le message d’erreur affiché s’explique par l’absence d’écoute sur le port 80 (HTTP) de votre machine virtuelle.

Pour y remédier, nous allons installer le rôle IIS (Internet Information Services) sur votre machine virtuelle.

Etape II – Installer un rôle IIS sur votre machine virtuelle :

Comme aucun port RDP n’est ouvert sur la machine virtuelle, utilisez le menu suivant pour lancer le script d’installation de IIS depuis le portail Azure :

Collez la commande ci-dessous :

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Lancez le script, puis attendez que celui-ci se termine :

Environ 2 minutes plus tard, constatez la bonne exécution du script :

Dans l’onglet précédemment ouvert avec l’adresse IP publique de votre machine virtuelle, rafraichissez la page web, puis constatez l’apparition de la page d’accueil de IIS :

Notre environnement est maintenant en place, il ne nous reste qu’à installer le mécanisme d’alerte. Avant cela, il est nécessaire d’ajouter d’autres composants Azure.

Etape III – Configuration du test de disponibilité HTTP :

Sur votre portail Azure, commencez par rechercher le service Application Insights :

Créez votre premier application Insights :

Renseignez tous les champs, également ceux concernant la création d’un Log Analytics Workspace, puis lancez la validation :

Une fois validation terminée, lancez le processus de création des ressources :

Environ 3 minutes plus tard, cliquez-ici pour configurer votre Application insights :

Cliquez-ici pour ajouter votre test HTTP :

Renseignez les informations demandées, ainsi que l’adresse IP publique de votre VM au format HTTP://, puis choisissez la fréquence et les régions Azure dont le signal de test doit provenir :

Le test est maintenant en place

Etape IV – Vérification du test de disponibilité HTTP :

Attendez environ 2 minutes, puis cliquez sur Rafraichir :

Les premiers succès de réponse apparaissent :

A droite se trouvent des compteurs de succès et d’échecs
Le détail par région source est affiché en bas
Un graphique avec un taux de disponibilité est présent en haut à gauche

Un tour dans les logs de notre Application Insights affiche bien toutes les informations stockées par chaque test :

Toutes ces informations bien pratiques, mais les administrateurs IT doivent aussi être alertés quand le service HTTP est en panne. Il est donc nécessaire de mettre en place une règle d’alerte pour les avertir au plus tôt.

Un mail sur une messagerie surveillée est une bonne pratique.

Etape V – Configuration des alertes de disponibilité :

Toujours dans votre Application Insights, rendez-vous dans la section des alertes pour modifier la règle d’alerte déjà en place :

Cliquez sur la règle d’alerte portant le nom combo « alerte »-« Application Insight » :

Cliquez ensuite sur Editer :

Sous la section Actions, cliquez-ci dessous :

Cliquez-ici pour créer un groupe d’actions :

Nommez-le, puis passer sur l’onglet suivant :

Dans l’onglet Notifications, définissez un type de notification Email, puis nommez-le également :

Renseignez une adresse email à cibler :

Cliquez sur Créer votre groupe d’actions :

Sauvegardez votre règle d’alerte :

Attendez quelques secondes, puis constatez la bonne modification de celle-ci :

Quelques secondes après, le destinataire du groupe d’actions reçoit un email lui informant son intégration dans un système de règle d’alerte Azure :

Il ne nous reste plus qu’à tester la notification par email. Pour cela, rien de plus simple, un arrêt de la machine virtuelle Azure devrait suffire.

Etape VI – Test de la notification d’alerte :

Avant d’arrêter votre machine virtuelle, vérifier la bonne santé du test de disponibilité de votre HTTP :

Retournez sur la page des machines virtuelles, puis déclenchez un arrêt de celle-ci :

Confirmez la procédure d’arrêt :

Retournez sur l’onglet internet ouvert sur l’adresse IP publique de votre machine virtuelle, puis constatez l’apparition d’un message d’indisponibilité :

Retournez sur le test d’alerte de votre Application Insights, les premiers échecs devraient apparaître.

Notez que la notion de 5 minutes entre deux tests ne s’applique que pour chaque région Azure. C’est donc pour cela que les tests sont très fréquents, car le test de disponibilité repose ici sur 5 régions :

Une fois que 2 localisations sur 5 constatent des échecs, l’alerte est déclenchée et le mail est envoyé sur l’adresse de message renseignée sur le groupe d’actions :

Consultez le détail de cette alerte :

Retournez sur la page des machines virtuelles, puis redémarrez la VM précédemment éteinte :

Quelques minutes plus tard, un autre email arrive sur la boite de messagerie. Celui-ci indique une bonne reprise de la disponibilité sur les régions concernées :

De retour sur la page des alertes de notre Applications Insights, l’alerte n’y figure plus car elle a été automatiquement levée :

Il est malgré tout possible de retrouver l’historique de cette alerte en retirant un filtre :

Conclusion :

L’architecture Cloud n’est pas infaillible et la mise en place d’alerte permet de gérer au plus tôt un incident. Ce type de règle alerte ne coûte pas cher et permet de centraliser l’information sur un seul point. Un autre test intéressant serait de créer une alerte sur la charge d’une machine virtuelle ou d’un autre service de calcul.

Apprivoisez le stockage Azure

Le stockage de données est présent dans toute infrastructure IT. Il peut se présenter sous différentes formes selon le besoin. Une base de données ou un serveur de fichiers sont les exemples les plus connus. Mais il est possible d’en avoir besoin sous d’autres formes, comme pour du stockage objet (sauvegardes) ou des services de messageries (transitoires) entre applications.

Quel que soit son type, les fournisseurs de Cloud disposent d’une flexibilité inégalée, car leur offre de stockage peut s’adapter aux besoins dans la forme et dans le temps. Pour cela, les calculateurs de prix, comme Azure Pricing Calculator, sont d’une grande aide pour estimer au mieux le coût du stockage.

Prenons en exemple le compte de stockage Azure. Il s’agit est une ressource régulièrement utilisée car elle couvre justement plusieurs types de stockage :

Voici d’ailleurs quelques articles de ce blog parlant du stockage Azure, ainsi qu’une très bonne vidéo d’introduction en français :

Enfin, cet article s’inscrit dans la continuité des précédents exercices ateliers, dont voici les liens directs :

Afin de vous familiariser avec le compte de stockage Azure, je vous propose de suivre cet exercice dédié. La version originale de Microsoft est également disponible en anglais sur la page GitHub juste ici. Voici la liste des tâches que nous allons réaliser :

Tâche 1 : Préparez votre environnement Azure
Tâche 2 : Créez votre compte de stockage Azure
Tâche 3 : Testez le stockage Azure blob
Tâche 4 : Créez un partage de fichiers Azure
Tâche 5 : Gérer l’accès au réseau du compte de stockage Azure
Tâche 6 : Joignez le compte de stockage à un Active Directory

Je me répète souvent, mais une ressource déployée entraîne un début de facturation de la part de Microsoft. Il est donc important de correctement dimensionner les ressources, et de les supprimer quand elles ne sont plus utilisées.

Rappel des prérequis :

Pour réaliser cet exercice Azure, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure active

Tâche 1 – Préparez votre environnement Azure :

Commencez par télécharger localement les fichiers de scripts Microsoft disponibles juste ici :

Décompressez cette archive ZIP sur votre poste local :

Depuis votre portail Azure, ouvrez Azure Cloud Shell via l’icône situé en haut à droite :

Configurez si besoin les options liées à la création du compte de stockage utilisé pour Azure Cloud Shell :

Attendez que le compte de stockage soit créé et que la ligne de commande d’Azure Cloud Shell vous soit accessible :

Dans la barre d’outils d’Azure Cloud Shell, cliquez sur l’icône pour téléverser des fichiers vers le compte de stockage :

Commencez par téléverser le premier fichier présent dans l’archive précédemment décompressée :

\Allfiles\Labs\07\az104-07-vm-template.json

Puis téléversez le second fichier suivant :

\Allfiles\Labs\07\az104-07-vm-parameters.json

Copiez la commande suivante en modifiant si besoin la région Azure souhaitée :

$location = 'West Europe'

Faites-en de même pour une seconde variable, en modifiant si besoin le nom du groupe de ressources à créer :

$rgName = 'az104-07-rg0'

Exécutez la commande suivante dans votre Azure Cloud Shell pour créer le groupe de ressources qui hébergera la machine virtuelle créée juste après :

New-AzResourceGroup -Name $rgName -Location $location

Attendez quelques secondes, puis constatez le succès de la création :

Exécutez ensuite la commande suivante pour déployer une machine virtuelle grâce aux deux fichiers précédemment téléversés :

New-AzResourceGroupDeployment `
   -ResourceGroupName $rgName `
   -TemplateFile $HOME/az104-07-vm-template.json `
   -TemplateParameterFile $HOME/az104-07-vm-parameters.json `
   -AsJob

Spécifiez un mot de passe pour le compte de l’administrateur local de votre Windows Server :

La création de la machine est alors effectuée en tâche de fond. Il n’est donc pas nécessaire d’attendre que le déploiement se termine :

Fermez le volet d’Azure Cloud Shell.

Suivez l’avancement du déploiement de votre VM depuis le groupe de ressources :

Quelques minutes plus tard, retrouvez les ressources créées dans la page principale du groupe de ressources :

Recherchez dans vos machines virtuelles celle créée à l’instant par le script :

Afin de préparer une connexion future, cliquez-ici pour déployer le service Azure Bastion :

Cliquez-ici pour déployer un Azure Bastion en utilisant une configuration par défaut :

Le déploiement d’Azure Bastion a commencé, inutile d’attendre la fin de son déploiement. Nous allons pouvoir nous intéresser au compte de stockage Azure.

Tâche 2 – Créez votre compte de stockage Azure :

Depuis le portail Azure, recherchez puis sélectionnez le service comptes de stockage :

Cliquez sur Créer pour ajouter un second compte de stockage :

Sur le premier onglet, commencez par créer un nouveau groupe de ressources Azure :

Donnez à votre compte de stockage un nom, unique dans tout l’environnement Azure :

Prenez du temps pour passer en revue les options disponibles, puis cliquez sur Suivant :

Prenez du temps pour passer en revue les options disponibles, puis cliquez sur Suivant :

Prenez du temps pour passer en revue les options disponibles, puis cliquez sur Suivant :

Prenez du temps pour passer en revue les options disponibles, puis cliquez sur Suivant :

Prenez du temps pour passer en revue les options disponibles, puis cliquez sur Valider :

Une fois la validation terminée, lancez la création de votre compte de stockage :

Environ une minute plus tard, la création de votre compte de stockage est terminée. Cliquez-ici pour accéder directement à votre compte de stockage :

Dans la section Redondance, notez l’emplacement secondaire, présent grâce à l’option GRS laissée lors de la création de votre compte de stockage :

Un compte de stockage vide ne coûte rien. Le volume de données et les transactions vont générer les coûts.

Tâche 3 – Testez le stockage Azure blob :

Cliquez sur Conteneurs, puis cliquez sur Créer pour en créer un nouveau :

Créez un conteneur blob avec les options suivantes, puis cliquez sur Créer :

Dans la liste des conteneurs blob, cliquez sur le conteneur az104-07-container nouvellement créé :

Cliquez sur Téléverser pour déposer un fichier depuis votre ordinateur vers votre conteneur :

Retrouvez les fichiers de l’archive décompressée, puis choisissez le fichier LICENCE :

Dans l’onglet Avancée, ajoutez le dossier licenses, puis cliquez sur Téléverser :

Environ une seconde plus tard, Azure vous confirme le succès de l’envoi du fichier et la création du dossier :

Retrouvez sur la page le dossier nouvellement créé, puis cliquez dessus :

Dans ce dossier, constatez le tier utilisé par le fichier LICENSE précédemment téléversé :

Cliquez sur le fichier LICENSE, puis copiez l’URL du blob comme ceci :

Ouvrez un navigateur privé depuis votre poste local :

Collez l’URL du blob copiée précédemment dans la barre d’adresse, puis constatez le message erreur d’accès, dû à un manque d’autorisations :

Afin de pouvoir accéder au blob, générez un accès SAS, en y indiquant une date de validité supérieure à la date du jour :

Copiez l’URL générée par votre accès SAS de votre blob LICENSE :

Voici en exemple URL avec mon accès SAS :

https://jlosto2.blob.core.windows.net/az104-07-container/licenses/LICENSE?sp=r&st=2023-04-25T19:34:42Z&se=2023-04-27T03:34:42Z&spr=https&sv=2021-12-02&sr=b&sig=YQUFaXmpBJhi7E3bt5WmmuF%2FmszjQ29UP46YS9747zU%3D

Rouvrez à nouveau un navigateur privé depuis votre poste local :

Collez l’URL précédemment copiée, puis constatez le téléchargement ou l’affichage du fichier LICENSE :

Ouvrez le fichier LICENSE si celui-ci ne s’est pas affiché :

Dans un autre registre, un serveur de fichiers est aussi remplaçable par un service Azure PaaS. Déjà cité plus haut, l’article Stockez vos données sur un service PaaS vous explique également quelques notions importantes.

Tâche 4 – Créez un partage de fichiers Azure :

Sur votre compte de stockage, cherchez le menu Partages de fichiers afin d’en créer un nouveau :

Nommez ce partage de fichiers az104-07-share conservant les propriétés par défaut :

Une fois créé, cliquez sur votre partage de fichiers :

Cliquez sur le bouton Connecter :

Sur la partie de droite, choisissez de vous connecter via la clef du compte de stockage, puis affichez le script de connexion afin de le copiez dans votre presse-papier :

Retournez sur la machine virtuelle créée précédemment, puis allez dans le menu suivant :

Collez le script précédemment copié, puis lancez l’exécution du traitement :

Attendez environ deux minutes, puis constatez sa bonne exécution :

Ce script lancé à distance sur la machine virtuelle a monté un lecteur réseau Z. La connexion est passée par l’URL publique via une session HTTPS.

Copiez les deux lignes de code ci-dessous dans votre presse-papier :

New-Item -Type Directory -Path 'Z:\az104-07-folder'

New-Item -Type File -Path 'Z:\az104-07-folder\az-104-07-file.txt'

Encore une fois, collez ce code, puis lancez l’exécution du traitement :

Attendez environ deux minutes, puis constatez sa bonne exécution :

Ce second script lancé à distance a créé dans le partage un dossier et un fichier txt depuis la machine virtuelle.

Retournez sur le partage de fichiers depuis le compte de stockage Azure :

Cliquez sur le dossier nouvellement créé :

Constatez la bonne présence du fichier txt :

Intéressons-nous maintenant à la configuration réseau de votre compte de stockage. Les URLs précédemment utilisées pour le blob et le partage de fichiers reprenaient l’accès publique de votre compte de stockage.

Un filtrage réseau est possible pour bloquer l’accès en plus de l’authentification déjà en place.

Tâche 5 – Gérer l’accès au réseau du compte de stockage Azure :

Sur votre compte de stockage, activez la restriction firewall à des réseaux virtuels connus, ainsi que votre adresse IP publique comme ceci :

Ouvrez à nouveau un navigateur internet privé :

Collez l’URL précédemment générée pour l’accès SAS de votre blob dans la barre d’adresse :

https://jlosto2.blob.core.windows.net/az104-07-container/licenses/LICENSE?sp=r&st=2023-04-25T19:34:42Z&se=2023-04-27T03:34:42Z&spr=https&sv=2021-12-02&sr=b&sig=YQUFaXmpBJhi7E3bt5WmmuF%2FmszjQ29UP46YS9747zU%3D

Constatez le téléchargement ou l’affichage du fichier LICENSE :

Ouvrez Azure Cloud Shell via l’icône situé en haut à droite du portail Azure :

Reprenez la commande suivante et ajoutez-y l’URL précédemment générée pour l’accès SAS de votre blob :

Invoke-WebRequest -URI '[blob SAS URL]'

Cela donne dans mon cas la commande suivante :

Invoke-WebRequest -URI 'https://jlosto2.blob.core.windows.net/az104-07-container/licenses/LICENSE?sp=r&st=2023-04-25T19:34:42Z&se=2023-04-27T03:34:42Z&spr=https&sv=2021-12-02&sr=b&sig=YQUFaXmpBJhi7E3bt5WmmuF%2FmszjQ29UP46YS9747zU%3D'

Exécutez la commande, puis constatez l’erreur dû un blocage du firewall configuré précédemment sur le compte de stockage :

Retournez sur la configuration réseau et firewall de votre compte de stockage, puis ajoutez un réseau virtuel :

Sélectionnez le réseau virtuel et le sous-réseau rattaché à la machine virtuelle créée :

Attendez quelques secondes que le service endpoint s’active sur le sous-réseau sélectionné :

Une fois activé, ajoutez-le à la configuration :

N’oubliez pas de sauvegarde la configuration réseau du compte de stockage :

Si votre réseau virtuel n’apparait pas, exécutez les deux commandes PowerShell suivantes sous Azure Cloud Shell and modifiant les variables :

Get-AzVirtualNetwork -ResourceGroupName "myresourcegroup" -Name "myvnet" | Set-AzVirtualNetworkSubnetConfig -Name "mysubnet" -AddressPrefix "10.0.0.0/24" -ServiceEndpoint "Microsoft.Storage.Global" | Set-AzVirtualNetwork

$subnet = Get-AzVirtualNetwork -ResourceGroupName "myresourcegroup" -Name "myvnet" | Get-AzVirtualNetworkSubnetConfig -Name "mysubnet"
Add-AzStorageAccountNetworkRule -ResourceGroupName "myresourcegroup" -Name "mystorageaccount" -VirtualNetworkResourceId $subnet.Id

Nous avons vu certaines restrictions possibles pour bloquer des connexions réseaux non souhaitées. Dans la prochaine tâche, nous allons voir comment joindre un compte de stockage à un domaine AD.

Tâche 6 – Joindre le compte de stockage à un Active Directory :

A l’heure actuelle, il existe 3 méthodes de joindre un compte de stockage Azure à un domaine. Dans notre exercice, nous utiliserons la première méthode, grâce à la machine virtuelle créée précédemment :

Connectez-vous à la machine virtuelle créée précédemment via le script en reprenant comme identifiant Student, et comme mot de passe celui renseigné lors de la création de la VM :

Une fois connecté à la machine virtuelle, ajoutez des rôles à votre Windows Server :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cochez les deux rôles AD DS et DNS, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Attendez environ deux minutes que l’installation des 2 rôles se termine :

Cliquez-ici pour promouvoir votre machine virtuelle en tant que contrôleur de domaine :

Créez une nouvelle forêt et nommez votre domaine AD comme vous le souhaitez, puis cliquez sur Suivant :

Créez un mot de passe pour la DSRM, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Cliquez sur Fermer puis fermez l’onglet Azure Bastion :

Copiez l’adresse IP privée de votre machine virtuelle :

Sur le réseau virtuel de votre VM, renseignez l’adresse IP privée dans la section DNS :

Dans la section des partages de fichiers de votre compte de stockage, constatez l’absence de configuration Active Directory :

Rouvrez une session sur votre machine virtuelle via Azure Bastion :

Attendez la fin de l’ouverture de session plusieurs minutes :

Dans Server Manager, désactivez la sécurité renforcée d’Internet Explorer :

Désactivez la sécurité pour les utilisateurs ayant un profil administrateur :

Ouvrez Microsoft Edge :

Ouvrez l’URL suivante :

https://github.com/Azure-Samples/azure-files-samples/releases

Téléchargez l’archive ZIP contenant le script de jointure AD :

Décompressez l’archive ZIP :

Décompressez cette archive dans un dossier à la racine du disque C :

Ouvrez Windows PowerShell ISE :

Positionnez-vous dans le dossier contenant l’archive extraite :

Commencez par exécutez les commandes suivantes pour préparer votre environnement

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser

.\CopyToPSPath.ps1

Validez toutes les alertes de sécurité :

Installez les modules nécessaires à la configuration :

install-Module -Name Az
Import-Module -Name AzFilesHybrid

Validez toutes les alertes de sécurité :

Patientez plusieurs minutes avant l’installation complète des modules AZ :

Fermez puis rouvrez la session PowerShell si celui-ci vous le demande :

Connectez à vous à votre compte Azure AD :

Connect-AzAccount

Renseignez les variables suivantes depuis la page de votre compte de stockage Azure :

$SubscriptionId = "<your-subscription-id-here>"
$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Select-AzSubscription -SubscriptionId $SubscriptionId 

Join-AzStorageAccount `
        -ResourceGroupName $ResourceGroupName `
        -StorageAccountName $StorageAccountName

Le résultat de la commande devrait être le suivant :

En cas de souci, la commande de debug peut vous aider à comprendre ce qui se passe :

Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose

Enfin vérifiez la bonne jointure de votre compte de stockage à Azure Active Directory avec le changement de statut en Configured :

Il reste bien évidemment quelques étapes pour finaliser la configuration afin que les utilisateurs puissent accéder à un partage de fichier via leur compte AD :

Conclusion

Dans cet atelier dédié au stockage et conçu par Microsoft, vous avez :

Préparé votre environnement Azure
Créé votre compte de stockage Azure
Testé le stockage Azure blob
Créé un partage de fichiers Azure
Géré l’accès au réseau du compte de stockage Azure
Joint le compte de stockage à un Active Directory

J’espère que toutes opérations vous ont montré la facilité de déploiement d’un compte de stockage Azure. Enfin, pensez à supprimer les ressources une fois cet atelier terminé afin d’éviter les surcoûts inutiles :

Suppression des ressources Azure :

Allégez vos profils FSLogix !

Dans la plupart des environnements Azure Virtual Desktop, la gestion des profils utilisateurs est gérée grâce à la solution FSLogix. Pour rappel, FSLogix est une solution Microsoft très performante dans la gestion des profils utilisateurs Windows dans les environnements VDI. Azure Virtual Desktop est d’ailleurs le bon exemple, vous pouvez retrouver un article sur sa mise en place juste ici.

Bien souvent, il sera nécessaire d’effectuer par moment des opérations de routine, comme les mises à jour FSLogix, mais aussi dans sa configuration ou encore dans son stockage. En effet, les profils ont tendance à grossir avec le temps. Pour y remédier, plusieurs pistes existent, dont la redirection du cache.

Microsoft en parle d’ailleurs dans deux articles de Microsoft Learn :

Qu’est-ce que la redirection FSLogix ?

Un profil utilisateur contient de la donnée brute, mais aussi de la donnée de cache, issue d’un stockage externe, comme les outils 365. Pour faire simple, les produits comme OneDrive, Teams, Exchange, … stockent vos données dans le Cloud, et en copient une partie sous forme de cache local, pour des questions de performances VDI.

Les profils utilisateurs ont donc tendance à conserver ce cache et grossir avec le temps. FSLogix propose donc de faire de la redirection ciblée de ce cache pour alléger le profil utilisateur :

FSLogix redirections.xml fournit des fonctionnalités qui permettent d’exclure certaines parties du profil d’un utilisateur du conteneur d’un utilisateur
Microsoft Learn

Dans cet article, nous allons prendre de temps de tester deux configurations FSLogix (avec / sans la redirection) afin de mesurer le gain d’espace en résultant.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur FSLogix , il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Etape I – Déploiement du domaine managé Azure AD DS :

Il est possible d’effectuer ce test avec un domaine Active Directory ou via le service managé Azure AD DS. N’oubliez pas qu’il est pas encore possible de faire du roaming profile uniquement basé sur Azure AD, car l’intégration d’un compte de stockage Azure nécessite encore et toujours un environnement hybride.

Dans mon cas, j’ai choisi de déployer un Azure AD DS, que vous retrouvez dans le menu suivant :

Configurez-le de manière avant de pouvoir le déployer :

Lancez le déploiement, puis attendez une bonne heure que la configuration se termine entièrement :

Une fois le service Azure AD DS entièrement déployé, pensez à corriger les serveurs de DNS sur votre réseau virtuel Azure :

Profitez-en pour créer d’autres sous-réseaux selon les besoins de votre test :

Déployez également un Azure Bastion afin de vous connecter plus facilement sur les machines virtuelles Azure sans ouvrir de port RDP :

Complétez tous les champs pour créer votre Azure Bastion sur votre réseau virtuel :

Une fois la validation passée, cliquez sur Créer :

Afin de configurer notre domaine AD et de créer des GPOs FSLogix, nous allons avoir besoin d’une machine virtuelle de management.

En effet, les machines gérant le service Azure AD DS ne vous sont pas accessible. Rien ne nous empêche de gérer votre domaine grâce à une autre machine virtuelle disposant des fonctionnalités adéquates.

Etape II – Création d’une machine virtuelle de management :

N’attendez pas la fin de la création d’Azure Bastion pour créer votre machine virtuelle sur Azure. Un article dédié à la création de votre première machine virtuelle se trouve juste ici.

Renseignez tous les champs du premier onglet, puis cliquez sur Suivant :

Sur le second onglet, cliquez sur Suivant :

Reprenez votre réseau virtuel déjà en place, choisissez le bon sous-réseau, retirez l’adresse IP publique inutile, puis lancez sa création :

N’attendez pas la fin de la création de votre machine virtuelle de management pour créer un premier compte de stockage.

Etape III – Créations de deux comptes de stockage :

Le compte de stockage va vous servir pour stocker les profils FSLogix.

Cliquez-ici pour commencer sa création :

Donnez-lui un nom unique, les autres caractéristiques importent peu pour notre test, puis cliquez sur Suivant :

Cliquez sur Suivant pour passer au troisième onglet :

Restreignez l’accès public en spécifiant le réseau virtuel et les sous-réseaux adéquats pour nos tests FSLogix :

Une fois la validation passée, cliquez sur Créer :

Une fois la création terminée, retournez sur votre compte de stockage pour y ajoutez votre IP publique dans les règles de réseau :

Cliquez ici pour créer un partage de fichier sur ce compte de stockage :

Nommez le nom de ce partage et conservez la capacité provisionnée par défaut :

Cliquez-ici pour joindre votre compte de stockage à votre domaine Azure AD DS :

Dans le cadre d’un domaine Azure AD DS, choisissez l’option se trouvant au milieu :

Cochez la case ci-dessous, puis Sauvegarder :

Quelques secondes plus tard, le statut Active Directory change. Cliquez sur le nom de votre partage réseau :

Assignez des rôles RBAC à vos utilisateurs via le menu suivant :

Commencez par assigner un administrateur avec le rôle ci-dessous :

Choisissez l’administrateur adéquat dans votre Azure AD, puis validez l’assignation :

Refaite une seconde opération d’assignation, avec le rôle suivant, pour votre utilisateur de test AVD :

Choisissez l’utilisateur AVD adéquat dans votre Azure AD, puis validez l’assignation :

Une fois les assignations correctement faites, vérifiez que celles-ci sont bien présentes :

Comme nous souhaitons disposer deux environnements AVD, l’un avec la redirection et l’autre sans, refaites à nouveau l’étape du compte de stockage pour en créer un second, configuré de la même façon :

Etape IV – Configuration du serveur de management :

Connectez-vous à votre machine virtuelle de management grâce au service Azure Bastion :

Renseignez les identifiants d’administrateur local renseignés lors de la création de la VM :

Dans la console Server Manager, cliquez sur WORKGROUP pour joindre cette machine au domaine Azure AD DS :

Cliquez-ici pour modifier la configuration de domaine :

Saisissez le nom de votre domaine Azure AD DS, puis cliquez sur OK :

Renseignez les identifiants d’un compte de votre Azure AD et répliqué sur Azure AD DS :

Cliquez sur OK :

Redémarrez votre machine virtuelle de management :

Une fois redémarrée, dans la console Server Manager, vérifiez la bonne jointure du domaine Azure AD DS :

Cliquez-ici pour ajouter les fonctionnalités de gestion du domaine AD :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cochez les cases des fonctionnalités suivantes :

Group Policy Management
Remote Server Administration Tools

Puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Cliquez sur Fermer :

Fermez la session Windows de votre administrateur local

Sur le portail Azure, retournez sur le partage de fichier de votre premier compte de stockage dédié à FSLogix :

Récupérez la commande PowerShell pour créer un lecteur réseau Z, grâce à la clef du compte de stockage :

$connectTestResult = Test-NetConnection -ComputerName jlostoprem.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
    # Save the password so the drive will persist on reboot
    cmd.exe /C "cmdkey /add:`"jlostoprem.file.core.windows.net`" /user:`"localhost\jlostoprem`" /pass:`"odE9TV8+6IzIYVezHtzS2xcESUL2oegoqjEqhcQcBPAPIKMuZsNob0UErXTGyGU2d986MuhWPQme+AStVF/ofA==`""
    # Mount the drive
    New-PSDrive -Name Z -PSProvider FileSystem -Root "\\jlostoprem.file.core.windows.net\fslogix-profile" -Persist
} else {
    Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."
}

Retournez sur la machine virtuelle de management, puis ouvrez à nouveau une session RDP avec un compte d’administration Azure AD DS :

Ouvrez PowerShell ISE, collez la requête précédemment récupérée sur le compte de stockage, puis lancez-là :

Un premier lecteur réseau apparaît alors dans le poste de travail :

Modifiez la propriété de sécurité de ce lecteur réseau via la fonction Avancé :

Ajoutez un droit pour le compte administrateur Azure AD DS avec la configuration suivante :

Ajoutez un droit pour votre utilisateur de test AVD avec la configuration suivante :

Le résultat des droits sur le partage réseau devrait correspondre à cela :

Refaites les mêmes opérations sur le second compte de stockage :

Commande PowerShell pour monter le disque réseau Y
Propriété – Sécurité pour les deux utilisateurs

Etape V – Configurations des GPOs FSLogix :

Retournez sur la console Server Manager, puis cliquez-ici :

Désactivez la protection renforcée d’Internet Explorer, puis cliquez sur OK :

Depuis le menu Démarrer, ouvrez Microsoft Edge :

Rendez-vous à l’adresse internet suivante pour télécharger la configuration ADMX pour FSLogix :

https://learn.microsoft.com/en-us/fslogix/how-to-install-fslogix#download-fslogix

Cliquez-ici pour démarrer le téléchargement sous format ZIP :

Ouvrez l’archive ZIP précédemment téléchargée :

Copiez le fichier fslogix.admx dans le dossier suivant :

%SYSTEMROOT%\PolicyDefinitions

Copiez le fichier fslogix.adml dans le dossier suivant :

%SYSTEMROOT%\PolicyDefinitions\en-US

Toujours sur la console Server Manager, ouvrez le gestionnaire des GPOs :

Créez une première nouvelle OU pour notre environnement contenant la redirection FSLogix :

Cliquez comme ceci pour ajouter une GPO à cette première OU nouvellement créée :

Nommez cette GPO :

Cliquez ici pour configurer cette nouvelle police :

Descendez dans l’arborescence suivante :

Computer Configuration
- Policies
  - Administrative templates
    - FSLogix
      - Profile Containers

Activez et configurez les options suivantes :

Renseignez le chemin utilisé pour le montage de votre premier disque réseau Z :

\\jlostoprem.file.core.windows.net\fslogix-profile

Descendez d’un niveau dans l’arborescence :

Activez et configurez les options suivantes :

Comme ce premier environnement va contenir la redirection FSLogix, positionnez-vous sur l’arborescence suivante :

Activez et configurez l’option suivante :

Renseignez le même chemin utilisé pour le montage de votre premier disque réseau Z :

\\jlostoprem.file.core.windows.net\fslogix-profile

Copiez le fichier de redirection « redirections.xml » à la racine du dossier précédemment indiqué, afin de le rendre accessible à tous.

Voici pour rappel la configuration utilisée pour mon test :

<?xml version="1.0"  encoding="UTF-8"?>
<FrxProfileFolderRedirection ExcludeCommonFolders="0">
<Excludes>
<Exclude Copy="0">AppData\Roaming\Microsoft\Teams\media-stack</Exclude>
<Exclude Copy="0">AppData\Local\Microsoft\Teams\meeting-addin\Cache</Exclude>
<Exclude Copy="0">AppData\Local\Microsoft\Outlook</Exclude>
<Exclude Copy="0">AppData\Local\Microsoft\OneDrive</Exclude>
<Exclude Copy="0">AppData\Local\Microsoft\Edge</Exclude>
</Excludes>
<Includes>
<Include>AppData\Local\Microsoft\Edge\User Data</Include>
</Includes>
</FrxProfileFolderRedirection>

Afin de tester la redirection FSLogix, pensez à rajoutez une seconde OU en la liant à une nouvelle police FSLogix, avec exactement la même configuration, à l’exception de la redirection FSLogix :

Nous allons maintenant pouvoir tester l’impact de la configuration FSLogix, avec et sans la redirection XML.

Etape VI – Configurations des 2 Azure Virtual Desktop :

Pour cela, créez votre premier environnement AVD :

Cliquez sur Créer :

Renseignez les champs du premier onglet, puis cliquez sur Suivant :

Ajoutez une ou plusieurs machines virtuelles AVD, en les joignant à la première OU votre domaine Azure AD DS, puis cliquez sur Suivant :

Ajoutez un Espace de travail à votre environnement AVD, puis lancez la validation :

Une fois la validation passée, cliquez sur Créer :

Une fois votre premier environnement AVD correctement créé, lancez la création d’un second AVD, en joignant cette fois ci les VMs à la seconde OU votre domaine Azure AD DS :

Sur les deux pools d’hôtes AVD, ajoutez votre utilisateur de tests AVD afin de l’autoriser à s’y connecter :

Les deux environnements AVD sont enfin prêts, il vous reste plus qu’à vous connectez sur les deux environnement AVD en simultané.

Etape VII – Tests des 2 Azure Virtual Desktop :

Sur la session Azure Bastion de la machine de management d’Azure AD DS, ouvrez deux explorateurs de fichier pour constater la variation de taille sur les profils FSLogix :

Sur votre poste, ouvrez un navigateur privé, puis rendez-vous sur l’URL AVD suivante :

aka.ms/wvdarmweb

Renseignez les identifiants de votre utilisateur AVD de test :

Ouvrez, une par une, les deux sessions AVD disponibles :

Sur la machine virtuelle FSLogix avec la redirection, ouvrez l’explorateur Windows sur le chemin suivant :

C:\ProgramData\FSLogix\Logs\Profile

Ouvrez le fichier de log ci-dessous :

Recherchez le mot « redirections« , puis vérifiez juste en-dessous la bonne prise en compte de votre configuration XML :

Sur deux machines virtuelles de test AVD, notez pour l’utilisateur de test la présence systématique deux dossiers suivants :

De retour sur votre portail Azure, retournez sur la session Azure Bastion, puis constatez l’apparition des 2 dossiers de profil :

Détaillez les 2 dossiers, puis comparez la taille identique des 2 fichiers VHDX :

Sur chacune des sessions AVD, configurer le même compte Outlook :

Attendez quelques minutes le chargement complet d’Outlook :

Quelques minutes plus tard, retournez sur la session Azure Bastion et constatez l’écart de taille entre les deux profils FSLogix :

Continuez l’exercice avec la configuration du même compte OneDrive sur les deux sessions AVD :

L’écart continue encore de se creuser :

Lancez une synchronisation OneDrive forcée sur les deux sessions AVD :

Les 2 profiles grossissent fortement, quelques minutes plus tard, l’écart est proportionnellement moins important que précédemment :

Finissions la comparaison avec l’ouverture de Microsoft Teams sur les 2 sessions AVD :

Là encore les deux profils AVD continuent de grossir fortement :

Conclusion

Suite aux différents tests menés précédemment, il existe bien un gain dans la taille du profile FSLogix une fois la redirection configurée. Cela reste malgré tout modeste par profil, mais cela sera très conséquent pour plusieurs dizaines d’utilisateurs AVD.

Enfin, comme Dean le rappelle dans la vidéo ci-dessous :

Les profils FSLogix peuvent grossier sans limite, mais la réduction n’est plus possible
Il est important bien configurer la redirection en tenant compte des compatibilités !
La désactivation de la redirection est impossible mais prendra du temps pour s’appliquer sur tous les profils

Découvrez les Réseaux Virtuels Azure

Peu importe le type d’architecture déployée sur le Cloud, un réseau est indispensable pour son accès, son administration, mais aussi sa protection. Comme pour l’article dédié à Azure Migrate, ou encore celui consacré aux Machines virtuelles Azure, je vous propose un autre atelier portant les réseaux virtuels Azure. Il s’agit là encore d’un petit exercice que vous pouvez faire par vous-même.

Qu’est-ce qu’un réseau virtuel Azure ?

Le réseau virtuel permet à de nombreux types de ressources Azure, telles que les machines virtuelles (VM) Azure, de communiquer de manière sécurisée entre elles, avec Internet et avec les réseaux locaux. Un réseau virtuel est similaire à un réseau traditionnel que vous utiliseriez dans votre propre centre de données, mais avec les avantages supplémentaires de l’infrastructure Azure, tels que la mise à l’échelle, la disponibilité et l’isolation
Réseau virtuel Azure | Microsoft Learn

Le schéma ci-dessous montre la notion d’ensemble connecté grâce au réseau virtuel Azure :

J’avais déjà écrit plusieurs articles sur les réseaux virtuels d’Azure, voici les liens directs :

Enfin vous trouverez beaucoup d’excellentes vidéos sur YouTube sur les réseaux virtuels Azure. Je vous ai sélectionné les deux suivantes.

Enfin une vidéo simple et claire pour comprendre l’adressage IPv4 !

Comme toujours John nous sauve et nous explique le réseau virtual d’Azure en détail :

L’exercice que je vous propose ici est une reproduction quasi complète de celui proposé sur le GitHub de Microsoft. Comptez environ 1 heure pour le réaliser. J’ai uniquement transformé la tâche 6 de Microsoft par une autre plus intéressante : le peering.

Voici la liste des tâches à effectuer :

Tâche 1 : Créer et configurer un réseau virtuel
Tâche 2 : Déployer des machines virtuelles dans le réseau virtuel
Tâche 3 : Configurer les adresses IP privées et publiques des machines virtuelles
Tâche 4 : Configurer les groupes de sécurité du réseau
Tâche 5 : Configurer Azure DNS pour la résolution des noms internes
Tâche 6 : Configurer un peering de réseaux

Bien souvent, une ressource déployée entraîne un début de tarification par Microsoft. Il est donc important de correctement la dimensionner, et de la supprimer si cette dernière n’est plus utilisée.

Rappel des prérequis :

Pour réaliser cet exercice Azure, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure active

Un script en PowerShell est exécuté durant cet atelier. Commencez par télécharger et extraire les fichiers scripts Microsoft, disponibles depuis leur GitHub juste ici.

Tâche 1 – Créer et configurer un réseau virtuel :

Sur votre portail Azure, recherchez le service Réseau Virtuel Azure :

Cliquez sur Créer pour commencer la configuration de votre réseau virtuel :

Créez un nouveau groupe de ressources, donnez un nom à votre réseau virtuel, choisissez la région Azure où votre réseau Azure va se déployer, puis passez sur l’onglet Suivant :

Un réseau virtuel dans une région Azure ne supporte que des composants de cette même région.
Il sera peut être nécessaire de créer plusieurs réseaux virtuels si plusieurs régions.

Modifiez l’espace d’adressage de votre réseau virtuel comme ceci, puis ajoutez un sous-réseau compris dans l’espace d’adressage :

Une fois la validation passée, cliquez sur Créer :

Environ 30 secondes plus tard, votre premier réseau virtuel est créé, cliquez ici pour modifier sa configuration :

Dans la section des sous-réseaux, cliquez ici pour en ajouter un second :

Vous avez fini la première tâche de cet exercice. Nous allons maintenant créer des machines virtuelles via un script au réseau virtuel précédemment créé.

Tâche 2 – Déployer des machines virtuelles dans le réseau :

Le déploiement d’une machine virtuelle est possible de plusieurs manières (Portail, Azure, PowerShell, CLI, …). Nous allons utiliser un script en PowerShell, mis à disposition par Microsoft pour déployer nos machines virtuelles de test.

Cliquez sur Azure Cloud Shell pour commencer sa configuration :

Dans la configuration avancée, utilisez le même groupe de ressources que celui créé pour le réseau virtuel, puis lancez la création du compte de stockage :

Une fois le compte de stockage créé et la ligne de commande apparue, téléversez les 2 fichiers suivant :

\Allfiles\Labs\04\az104-04-vms-loop-template.json
\Allfiles\Labs\04\az104-04-vms-loop-parameters.json

Ne sélectionnez qu’un seul fichier à la fois :

Attendez le message de succès du téléversement pour commencer le second :

Recommencez l’opération avec le second fichier :

Avant de lancer le script, il est nécessaire de générer une variable. Modifiez celle-ci au besoin selon le nom de votre groupe de ressources précédemment créé :

$rgName = 'vnet-exercice-1'

Exécutez la commande de variable dans votre Azure Cloud Shell :

Lancez la commande suivante votre Azure Cloud Shell pour déployer vos deux machines virtuelles de test sur votre premier réseau virtuel :

New-AzResourceGroupDeployment `
   -ResourceGroupName $rgName `
   -TemplateFile $HOME/az104-04-vms-loop-template.json `
   -TemplateParameterFile $HOME/az104-04-vms-loop-parameters.json

Le suivi du déploiement est possible via le menu suivant. Tant que la ligne de commande n’est pas à nouveau disponible dans Azure Cloud Shell : cela veut dire que le déploiement n’est pas encore terminé :

Quelques minutes plus tard, constatez le succès du déploiement de votre script par le retour d’information dans Azure Cloud Shell :

Retournez sur votre groupe de ressource et constatez la présence de nouveaux composants Azure :

Nous allons maintenant effectuer quelques modifications sur la configuration réseau sur nos 2 machines virtuelles.

Tâche 3 – Configurer les adresses IP privées et publiques des machines virtuelles :

Une interface réseau permet à une machine virtuelle Azure de communiquer avec des ressources sur Internet, sur Azure et locales.
Microsoft Learn

Les adresses IP privées et publiques sont attribuées aux interfaces réseau, qui sont à leur tour attachées aux machines virtuelles Azure. Mais, il est assez courant de se référer aux adresses IP attribuées aux machines virtuelles Azure.

Cliquez sur votre réseau virtuel :

Dans la section des Périphériques connectés, constatez la présence de deux cartes réseaux rattachées aux deux machines virtuelles créées via le script, puis cliquez sur la première :

Dans la section Configurations IP, cliquez sur la première configuration :

Associez une adresse IP publique via une création juste en dessous :

Donnez-lui un nom, sélectionnez le SKU Standard, puis cliquez sur OK :

Modifiez l’assignation de l’adresse IP en statique, puis sauvegardez la configuration IP :

Répétez la même opération sur la carte réseau de la seconde machine virtuelle :

Notez que l’adresse IP privée est différente puisque la seconde machine virtuelle se trouve sur le second sous-réseau de notre réseau virtuel :

Toujours sur votre portail Azure, recherchez le composant Machine Virtuelle :

Veuillez noter la présence de l’adresse IP publique affectée lors de la modification de la configuration réseau :

Cliquez comme ceci pour vous connectez en RDP sur la première machine virtuelle :

Téléchargez le fichier RDP proposé par Azure :

Cliquez sur Connecter :

Constatez la présence d’un message d’erreur vous refusant la connexion RDP :

Cela s’explique par le fait qu’Azure est un modèle sécurisé par défaut. Il faut autoriser le trafic entrant via un groupe de sécurité réseau (NSG) si une IP publique st de SKU standard.

Tâche 4 – Configurer les groupes de sécurité du réseau virtuel :

Un groupe de sécurité réseau contient des règles de sécurité qui autorisent ou rejettent le trafic réseau entrant et sortant vers différents types de ressources Azure. Pour chaque règle, vous pouvez spécifier la source et la destination, le port et le protocole.
Microsoft Learn

Toujours sur votre portail Azure, recherchez le composant Groupe de sécurité réseau :

Cliquez ici pour créer votre premier groupe de sécurité réseau :

Renseignez tous les champs, puis lancez la validation :

Attendez que la validation se termine, puis lancez la création en cliquant sur Créer :

Environ une minute plus tard, le déploiement est terminé lorsque le message suivant apparaît, puis cliquez alors ici :

Ajoutez une règle de sécurité entrante à votre NSG :

Choisissez le service RDP, la priorité à 300, autorisez le traffic sur cette règle, puis cliquez sur Ajouter :

Il ne vous reste plus qu’à associer le NSG à un sous-réseau :

Choisissez le sous-réseau subnet0, puis cliquez sur OK :

Il est même possible d’associer ce NSG à une carte réseau :

Associez la carte réseau de la seconde machine virtuelle à votre NSG comme ceci :

Recommencez la connexion RDP vers une des deux machines virtuelles :

Téléchargez le fichier RDP :

Cliquez sur Connecter :

Entrez les identifiants suivants, puis cliquez sur OK :

Cliquez sur Oui pour accepter le risque :

Une fois la session de bureau à distance ouverte, réduisez celle-ci pour retourner sur le portail Azure :

Tâche 5 – Configurer Azure DNS pour la résolution de noms internes :

Azure Private DNS gère et résout les noms de domaine dans le réseau virtuel sans nécessiter la configuration d’une solution DNS personnalisée.
Microsoft Learn

Recherchez le service zone DNS privée via la barre du haut :

Cliquez ici pour créer votre première zone DNS privée :

Renseignez les champs suivants, puis lancez la validation :

Une fois la validation passée, cliquez sur Créer :

Environ deux minutes plus tard, le déploiement est terminé lorsque le message suivant apparaît :

Dans votre zone DNS privée, rajoutez le réseau virtuel via un lien comme ceci :

Renseignez les champs, cochez la case puis cliquez sur OK pour lancer la création d’un lien entre la zone DNS privée et votre réseau virtuel :

Attendez quelques secondes :

Sur la page principale, constatez la présence de 2 nouveaux enregistrements DNS, correspondants aux 2 machines virtuelles :

Retournez sur la session de bureau à distance, ouvrez une fenêtre de ligne de commande, puis saisissez les commandes suivantes :

nslookup az104-04-vm0.contoso.org

nslookup az104-04-vm1.contoso.org

Observez les résultats obtenus :

Tâche 6 – Configurer un peering de réseaux :

L’appairage de réseaux virtuels vous permet de connecter en toute transparence deux ou plusieurs réseaux virtuels dans Azure. Les réseaux virtuels apparaissent comme un seul réseau à des fins de connectivité. Le trafic entre les machines virtuelles des réseaux virtuels appairés utilise l’infrastructure principale de Microsoft.
Microsoft Learn

Retournez sur le portail Azure et recherchez le service Machine virtuelles via la barre du haut :

Cliquez ici pour créer une nouvelle machine virtuelle Azure :

Choisissez un groupe de ressources et une région Azure différente des premières ressources :

Attendez que la validation se termine, puis lancez la création de la machine virtuelle en cliquant sur Créer :

Cliquez ici pour conserver la clef privée du serveur Linux :

Environ deux minutes plus tard, le déploiement est terminé lorsque le message suivant apparaît :

Notez l’adresse IP privée affectée à cette nouvelle machine virtuelle :

Retournez sur le premier réseau virtuel créé :

Cliquez ici pour ajouter un peering entre le premier et le second réseau virtuel :

La première partie du peering est consacré au réseau initial, on y retrouve 3 principales options :

Trafic vers le réseau virtuel distant
Trafic transféré à partir d’un réseau virtuel distant
Passerelle de réseau virtuel ou serveur d’itinéraires (Azure Route Server)

Ces mêmes options sont à configurer sur le réseau de destination :

Trafic vers le réseau virtuel distant
Trafic transféré à partir d’un réseau virtuel distant
Passerelle de réseau virtuel ou serveur d’itinéraires (Azure Route Server)

Quelques secondes plus tard, la double opération de connexion est effectuée, et le statut du peering passe en Connecté :

Retournez sur la session de bureau à distance, ouvrez une fenêtre de ligne de commande, puis saisissez la commande suivante :

ping -t 10.0.0.4

Constatez le bon retour de la commande Ping vers la machine Linux :

Ouvrez le second NSG créé lors de la création de la troisième machine virtuelle :

Ajoutez une nouvelle règle de sécurité entrante :

Configurez cette règle pour bloquer les paquets dédiés au Ping :

Attendez quelques secondes pour constater l’ajout de cette règle NSG de refus :

De retour sur la session de bureau à distance, le Ping fini par ne plus répondre à cause de cette règle NSG bloquante :

Retournez sur le portail Azure et supprimez la règle précédemment ajoutée :

Retournez sur la session de bureau à distance pour constater, environ une minute après, le retour des réponses aux requêtes Ping :

Conclusion :

Dans cet atelier conçu par Microsoft, vous avez :

Créé et configuré un réseau virtuel Azure
Déployé des machines virtuelles dans le réseau virtuel
Configuré des adresses IP privées et publiques les machines virtuelles
Configuré un groupe de sécurité réseau NSG
Configuré un Azure DNS pour la résolution de noms internes
Configuré un peering entre deux réseaux virtuels

J’espère que toutes opérations vous auront montré la facilité de déploiement de composants réseaux sur Azure. Enfin, pensez à supprimer les ressources une fois cet atelier terminé afin d’éviter les surcoûts inutiles :

Suppression des ressources Azure :