Exercice - Déployer une architecture multiniveau
Souvenez-vous de notre scénario de migration d’une application d’un environnement local vers Azure. À quoi cette architecture pourrait-elle ressembler ? Votre organisation dispose d’une application non critique qui est un bon candidat pour un essai. Il s’agit d’une application écrite pour résoudre le problème bien trop fréquent de savoir ce qu’on va manger au déjeuner.
Pensez à la dernière fois où vous êtes sorti déjeuner avec un groupe d’amis ou de collègues. Avez-vous facilement fait votre choix ou avez-vous passé beaucoup de temps à essayer de comprendre ce que tout le monde voulait vraiment dire par « J’aime tout » ? Déployons une application basée sur une architecture à trois niveaux qui peut vous aider à résoudre ce problème. Cette application vous permet d’effectuer des suggestions de déjeuner et tous les utilisateurs peuvent voter pour leur choix préféré.
Nous avons créé un modèle pour cette application. Il déploie chaque niveau sous la forme de ressources Azure, puis déploie le code réel. Cette application est une application ASP.NET Core MVC déployée sur des serveurs Linux, mais vous pouvez utiliser ce style d’architecture indépendamment du SDK ou des plateformes de système d’exploitation sous-jacents.
Voici une visualisation d’ensemble de ce que ce modèle déploie.
Déployer une architecture multiniveau
Exécutez la commande suivante pour démarrer le déploiement. La commande
az deployment group createdémarre un déploiement dans notre groupe de ressources de bac à sable (sandbox) avec le fichier de modèle et les paramètres que nous spécifions. Nous spécifions également une chaîne de 32 caractères aléatoires générée à partir de la commandehead /dev/urandom | tr -dc A-Za-z0-9 | head -c 32en tant que paramètre de mot de passe.Ce déploiement prend environ 5 minutes.
az deployment group create \ --resource-group <rgn>[sandbox resource group name]</rgn> \ --template-uri https://raw.githubusercontent.com/MicrosoftDocs/mslearn-n-tier-architecture/master/Deployment/azuredeploy.json \ --parameters password="$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32)"
Afficher les ressources déployées et tester l’application
Une fois le déploiement terminé, testez l’application. Exécutez la commande suivante, qui retourne l’URL de l’application.
az deployment group show \
--output table \
--resource-group <rgn>[sandbox resource group name]</rgn> \
--name azuredeploy \
--query properties.outputs.webSiteUrl
Ouvrez un navigateur web, puis accédez au site. Vous voyez une zone dans laquelle vous pouvez ajouter des choix d’aliments. Après l’ajout d’une option, sa sélection entraîne l’ajout d’un vote.
Trois niveaux de l’application « What’s For Lunch? » (Qu’est-ce qu’on mange au déjeuner ?)
La complexité de cette application est volontairement minimale. Il s’agit d’une application ludique, mais qui illustre tout de même une architecture à trois niveaux. Le modèle crée deux machines virtuelles, une base de données Azure SQL et les ressources nécessaires pour prendre en charge ces ressources, par exemple des disques, des cartes réseau et des réseaux virtuels. Il déploie également le code pour exécuter l’application sur chaque niveau. Le réseau virtuel que nous avons déployé comprend deux sous-réseaux : un pour le niveau Présentation et un pour le niveau Application. Chaque niveau dispose ainsi d’une limite de sécurité.
Nous avons également appliqué des étiquettes aux ressources dans le cadre du déploiement afin de refléter le niveau que la ressource prend en charge (tier:presentation, tier:application, tier:data). Les étiquettes sont une méthode d’application de métadonnées à des ressources Azure. Dans le cas présent, elles nous permettent de filtrer facilement les ressources de chaque niveau.
Examinons plus en détail chaque niveau. Voici une visualisation détaillée des ressources déployées.
Niveau Présentation
Exécutez la commande suivante pour lister les ressources du niveau Présentation.
az resource list --tag tier=presentation --output table
Dans l’architecture à trois niveaux que nous utilisons en référence, il s’agit du niveau de présentation. Nous avons déployé le code chargé de l’interface web sur ce niveau. Il présente l’interface utilisateur et traite directement les demandes des utilisateurs. Ce niveau se concentre sur la présentation du site web à l’utilisateur. Il n’a pas d’accès direct aux données et n’inclut pas de logique métier.
Nous avons déployé un serveur web appelé demo-web-vm qui exécute le site web auquel nous accédons. Le serveur a une interface réseau, demo-web-vm-nic, à laquelle une adresse IP publique, demo-web-vm-nic-pip, est associée. Cette adresse IP publique est l’URL que nous avons récupérée précédemment. Il a également un groupe de sécurité réseau, demo-web-nsg, qui autorise uniquement le trafic du port 80 (HTTP) entrant à partir d’Internet. Ce groupe de sécurité réseau restreint l’accès au seul site web, et empêche l’accès par le biais de ports inutiles qui pourraient être utilisés à des fins malveillantes. Ce niveau communique avec le niveau Présentation sur HTTP pour répondre à la demande de l’utilisateur.
Niveau Application
Exécutez la commande suivante pour lister les ressources du niveau Application.
az resource list --tag tier=application --output table
Nous avons déployé le niveau Application sur une machine virtuelle appelée demo-biz-vm qui exécute la logique métier. Il dispose également d’une interface réseau, demo-biz-vm-nic, mais cette interface réseau a uniquement une adresse IP privée, ce qui ne fournit pas de mécanisme pour une connectivité entrante directe au serveur. Il a également un groupe de sécurité réseau, demo-biz-nsg, qui autorise l’accès uniquement à partir du sous-réseau du niveau Présentation.
Ce niveau est l’intermédiaire qui permet à l’application d’accéder aux données. Le code qui expose l’API appelée par le niveau Présentation est déployé sur ce serveur. Aucune donnée n’est stockée ici, et les utilisateurs ne peuvent pas accéder directement à ce serveur. Pour accéder aux données et répondre aux demandes de l’utilisateur, ce niveau communique avec le niveau Données par le biais de commandes T-SQL.
Il existe un exemple simple de logique métier incorporée dans l’application à ce niveau. Une validation côté serveur des suggestions de déjeuner est effectuée, en les comparant à une liste de valeurs acceptables. Si vous essayez d’ajouter quelque chose qui ne figure pas sur cette liste, votre entrée n’est pas acceptée. Un message est retourné avec les options de déjeuner valides.
Niveau Données
Exécutez la commande suivante pour lister les ressources du niveau Données.
az resource list --tag tier=data --output table
Le niveau Données est un serveur Azure SQL Database, demo-dbserver-abc123 (nous ajoutons une chaîne aléatoire au nom du serveur pour garantir une unicité globale). Ce serveur stocke les données de l’application dans une base de données appelée demo-sqldb. Ce niveau de l’application se concentre uniquement sur le stockage des données et fournit une méthode pour y accéder. Dans ce cas, l’accès se fait via T-SQL, que l’application exécute sur la base de données. Nous ne traitons aucune logique métier dans ce niveau, ni n’effectuons aucune présentation des données à l’utilisateur.
Ce niveau expose la connectivité sur le port 1433 via un point de terminaison de service de réseau virtuel. Les points de terminaison de service de réseau virtuel sont un mécanisme permettant de connecter des services PaaS (par exemple, Azure SQL Database) à un sous-réseau et de limiter la connectivité aux seules ressources de ce sous-réseau.
Il s’agit également d’un exemple d’utilisation des services PaaS (platform as a service) à la place de machines virtuelles IaaS (infrastructure as a service) pour exécuter un niveau d’une application. Nous associons souvent les applications multiniveaux à des applications basées sur des machines virtuelles, mais ce n’est pas obligatoire. En utilisant les services PaaS à la place de machines virtuelles, vous pouvez diminuer vos coûts, renforcer la sécurité et réduire les besoins d’administration.