Partager via

  • Article

Février 2017

Volume 32, numéro 2

Cet article a fait l'objet d'une traduction automatique.

Azure - Au sein de l’architecture Azure App Service

Par Yochay Kiriaty | Février 2017

Azure App Service est considéré comme une excellente plateforme en tant que Service (PaaS), offre une plate-forme d’application aux développeurs de créer le site Web, les applications d’API et mobiles. Sa plage d’offres de marketing simple et numérique présence des applications à des solutions évolutives de commerce électronique et une évolutivité et personnalisable.

Service d’application est entièrement géré, ce qui signifie qu'aucune tâche d’administration n’est requises pour la gestion des infrastructures de calcul de soulignement (serveurs) sur lesquels exécuteront vos applications. Vous n’avez pas besoin de vous soucier de la maintenance de serveur de soulignement comme la plate-forme des correctifs du système d’exploitation et les infrastructures pour vous. Votre application s’exécute sur des serveurs virtualisés, mais vous devez uniquement soin pour définir le nombre maximal d’instances de serveur sur lequel vous souhaitez exécuter votre application. Les poignées de la plateforme à l’échelle lorsque votre application a besoin d’autres ressources de calcul et, en même temps, elle gère le trafic d’équilibrer la charge entre plusieurs instances de votre application.

Tandis que l’équipe du Service d’application fait de son mieux pour masquer les détails d’implémentation de soulignement, il est judicieux de connaître le fonctionnement sous le capot. Cet article traite de l’architecture interne de base du Service d’application (comment le service est construit et fonctionne) et offre quelques meilleures pratiques pour certains scénarios.

Architecture globale et géo-distribué

L’informatique en nuage rapidement échelles et possède une capacité infinie. L’échelle du cloud peut s’expliquer qu’à l’écran. Rechercher à distance et vous voyez une image claire et lisse ; Lorsque vous effectuez une présentation détaillée, vous remarquerez que l’image à l’écran est composée de pixels peu nombreux. Le cloud, comme une image, est composé de nombreux serveurs. Service d’application clusters grappes de serveurs dans une entité unique appelée une « unité d’échelle » (ou un « tampon »). Il existe plusieurs ces unités d’échelle dans le monde entier dans les centres de données Azure.

Dans le cadre d’Azure, App Service présente un encombrement global. Dans chaque région Azure pris en charge, vous trouverez des unités d’échelle App Service exécutant des charges de travail (applications) et des jeux d’unités de contrôle régional de clients. Unités de contrôle sont transparentes pour le client (jusqu'à ce qu’ils un dysfonctionnement) et considéré comme faisant partie de la plateforme. Il existe une unité de contrôle spéciales qui est utilisée comme une passerelle pour tous les appels d’API de gestion. Par exemple, lorsqu’un client soumet une demande de création d’une nouvelle application, via le portail, l’interface de ligne de commande ou directement via l’API REST Azure, la requête est routée vers un point de terminaison Azure central (management.azure.com). Le Gestionnaire de ressources Azure ou ARM (bit.ly/2i6UD07), permet de travailler avec différentes ressources Azure dans votre application en un seul groupe. L’API définie par ARM vous permet de gérer les ressources Azure. ARM ne gère pas réellement des ressources individuelles. Chaque service d’Azure possède sa propre implémentation API de gestion qui est transmise par ARM. Dans le cas d’App Service, ARM transfère les appels d’API de Service d’application à application géo-principale du Service.

La géo-Master possède un contexte sur toutes les unités d’échelle dans le monde entier. Par exemple, lorsque vous créez une nouvelle application Service application (ou site Web), géo-Master détecte que l’unité d’échelle plus appropriée pour votre application et transmet ensuite la demande de création à l’unité d’échelle appropriée. L’unité d’échelle est maintenant chargée avec une nouvelle application et allouer les ressources requises. Figure 1 illustre le flux de création d’une application.

Répartition mondiale des unités d’échelle de Service d’application
Figure 1 la Distribution mondiale des unités d’échelle de Service d’application

Voici le processus de création d’une application :

  1. Utilisateur effectue une requête pour créer un nouveau site.
  2. ARM est que l’utilisateur a accès à la ressource pour permettre à l’opération donnée (créer dans ce cas) et les transmet à application géo-principale du Service.
  3. Géo-Master recherche la meilleure unité de mise à l’échelle appropriée pour la demande de l’utilisateur et transfère la demande.
  4. L’unité d’échelle crée la nouvelle application.
  5. Géo-Master signale une réussite dans la demande de création.

Il est important de comprendre que le Service d’application a plusieurs unités d’échelle, votre application s’exécute généralement dans une seule unité d’échelle de Service d’application. Même si vous utilisez Azure Traffic Manager pour s’exécuter dans plusieurs régions, votre application s’exécute dans deux ou plusieurs unités d’échelle distinct. Cependant, la mise à l’échelle des unités point de vue, votre application est limitée à une seule unité d’échelle.

Qu’est une unité d’échelle App Service ?

Une unité d’échelle App Service est un ensemble de serveurs qui hébergent et exécuter vos applications. Une unité d’échelle classique peut avoir plus de 1 000 serveurs. Le clustering de serveurs permet des économies d’échelle et de réutiliser l’infrastructure partagée. Le bloc de construction fondamental de l’unité d’échelle App Service est un déploiement d’Azure Cloud Service (Souvenez-vous, apparus App Service en version préliminaire de juin 2012). L’unité d’échelle donnée est autonome et peut fonctionner sur sa propre.

Blocs de construction de l’échelle unité principale

La fonctionnalité principale de l’unité d’échelle consiste à héberger et exécuter des applications client. Les applications s’exécutent sur des serveurs Windows et sont appelées les travailleurs Web ou les alimentations. La majorité des serveurs dans une unité d’échelle donné sont employés. Toutefois, une unité d’échelle comprend plusieurs serveurs de prise en charge supplémentaire nécessaires pour obtenir les fonctionnalités fournies par le Service d’application. Prise en charge des serveurs ont des rôles et chaque rôle est déployé sur plusieurs instances de redondance et de mise à l’échelle.

Front-End

Le serveur frontal est un équilibreur de charge sept couche, agissant comme un proxy, distribuer les requêtes HTTP entrantes entre différentes applications et leurs employés respectifs. Actuellement, l’algorithme d’équilibrage de charge App Service est un simple tourniquet entre un ensemble de serveurs allouée pour une application donnée.

Traitements Web

Threads de travail sont l’épine dorsale de l’unité d’échelle Service d’application. Ils exécuter vos applications.

Avec App Service, vous pouvez choisir comment vous souhaitez exécuter votre application. Vous pouvez sélectionner votre application en cours d’exécution sur des serveurs partagés ou dédiés. Pour ce faire, sélectionnez un Plan App Service. Un Plan App Service définit un ensemble de fonctionnalités, les fonctionnalités et les allocations de serveur. Un processus de travail partagé héberge des applications à partir de plusieurs clients différents où travailleurs dédiés sont garanties pour exécuter une ou plusieurs applications d’un client unique. Il existe plusieurs types de serveurs dédiés et tailles à partir de laquelle vous pouvez choisir. Plus la taille du serveur, plus les ressources processeur et mémoire sont disponibles pour les applications affectées. Le Plan App Service définit la quantité de serveurs pré-allouée pour votre application.

Une unité d’échelle App Service possède plusieurs pools de threads de travail préconfigurés et prêts à héberger les applications, comme illustré dans Figure 2, Section 1. Lorsque vous définissez votre Plan de Service application dédiée à une taille de deux serveurs, App Service alloue deux serveurs, comme illustré dans Figure 2, Section 2. Ensuite, quand vous faire évoluer votre Plan App Service, par exemple, ajouter deux autres traitements, la disposition des employés sont allouées à partir d’un pool de threads de travail prêt-à-go, comme illustré dans Figure 2, Section 3. Threads de travail sont déjà pré-configurés et à chaud, tout ce qui doit se produire étant donné que pour votre application à déployer sur le thread de travail. Une fois que l’application est déployée, le processus de travail est inséré dans la rotation et le serveur frontal peut allouer le trafic. Ce processus prend généralement quelques secondes.

Processus d’Application de serveur dans l’unité d’échelle App Service
Figure 2 le processus Application serveur dans l’unité d’échelle App Service

Figure 2, Section 4 montre plusieurs Plans App Service, identifié comme rectangles multicolores, chacune représentant un Plan App Service qui peuvent appartenir à plusieurs clients.

Serveurs de fichiers

N’importe quelle application a besoin d’espace pour contenir le contenu tel que HTML, des fichiers .js, des images ou des fichiers de code et tout autre contenu requis pour l’application de fonctionner. Un serveur de fichiers monte les objets BLOB Azure Storage et les expose comme des lecteurs réseau pour le processus de travail. Un processus de travail mappe en retour, ces lecteurs réseau local, ce qui permet de n’importe quelle application en cours d’exécution sur n’importe quel travail donné d’utiliser le lecteur « local », tout comme vous espérez que si l’application était exécutée sur un serveur à l’aide de son disque local. Toute opération relatifs aux fichiers en lecture/écriture effectuée par l’application passe par un serveur de fichiers.

Contrôleurs d’API

Contrôleurs d’API peuvent être considérés comme une extension à application géo-principale du Service. Si la géo-Master est conscient de toutes les applications de Service d’application sur toutes les unités d’échelle, il est le contrôleur d’API qui effectue l’opération de gestion qui a une incidence sur vos applications. Respect de géo-Master délégués API vers une unité d’échelle donnée via les contrôleurs d’API. Par exemple, lors de la géo-Master passe un appel d’API pour créer une nouvelle application, le contrôleur d’API orchestre les étapes requises pour créer l’application à l’unité d’échelle. Lorsque vous utilisez le portail pour réinitialiser votre application, il est le contrôleur d’API qui avertit tous les traitements Web actuellement alloués à votre application à redémarrer votre application.

Serveurs de publication

Azure App Service prend en charge l’accès FTP à n’importe quelle application. Étant donné que le contenu de l’application est stocké dans les objets BLOB Azure Storage et mappé par les serveurs de fichiers, Service d’application a un rôle de serveur de publication pour exposer les fonctionnalités FTP. Le rôle de serveur de publication permet aux clients d’utiliser FTP pour accéder à leur contenu d’application et les journaux.

Il est important de noter qu’il existe de nombreuses autres façons de déployer des applications autres que FTP. Une des méthodes de déploiement courantes est Web Deploy (à partir de Visual Studio) ou les options de déploiement continue pris en charge tels que le Gestionnaire de versions de Visual Studio ou GitHub.

SQL Azure

Chaque unité d’échelle App Service utilise la base de données SQL Azure pour conserver les métadonnées de l’application. Chaque application qui est affectée à une unité d’échelle donnée a une représentation dans une base de données SQL. La base de données SQL est également utilisé pour stocker les informations d’exécution sur les applications.

Rôle des données

Tous les rôles requièrent des données que se trouvent dans la base de données de fonctionner. Exemples : un traitement Web a besoin d’informations de configuration de site lors du lancement d’une application ; serveurs frontaux doivent savoir quels serveurs sont affectés pour exécuter une application spécifique afin de transférer correctement les demandes HTTP vers les serveurs appropriés ; et les contrôleurs de lire et mettre à jour des données à partir de la base de données basée sur les appels API effectués par les clients. Le rôle de données peut être décrit comme une couche de cache entre la base de données SQL et tous les autres rôles dans une unité d’échelle donnée. Il extrait la couche données (base de données SQL) à partir du reste des rôles, améliorer l’évolutivité et performances, ainsi que ce qui simplifie le développement de logiciels et de maintenance.

Meilleures pratiques moins évident

Maintenant que vous savez comment Azure App Service est créé, nous allons examiner plusieurs trucs et astuces de l’équipe de Service d’application. Il s’agit des leçons apprises par les équipes d’ingénieurs App Service à partir des engagements de client numerus.

Contrôle de la densité

Majorité des clients à exécuter un nombre faible (inférieure à 10) d’applications par Plan App Service. Toutefois, il existe de nombreux scénarios où les clients exécutent de nombreuses applications plus. Il est important d’empêcher accidentellement sur saturer la capacité de calcul des serveurs sous-jacent.

Commençons par la hiérarchie de base des applications et leurs ressources de calcul. Il existe deux applications Web et une application de serveur principal mobile associé à ce Plan de Service d’application. La planification est définie sur deux serveurs.

Par défaut, toutes les applications contenues dans un Plan de Service application donné s’exécutent sur toutes les ressources de calcul disponibles (serveurs) allouées à ce Plan de Service. Tous les trois applications s’exécutent sur les deux serveurs. Dans le cas simple où un Plan App Service a un seul serveur, il est simple à comprendre : Toutes les applications dans le Plan App Service exécutent sur un seul serveur.

Il est un peu moins intuitive et que se passe-t-il lorsqu’il existe plusieurs ressources de calcul allouées à votre Plan App Service. Par exemple, si un seul Plan App Service a 10 ressources de calcul, chaque application dans le service d’application est exécuté sur chaque ressource de calcul. Si 50 applications dans le Plan App Service, tous les 50 s’exécuteront sur le premier serveur, et les 50 même s’exécuteront sur le second serveur etc., au serveur de 10, qui seront également exécutés 50 toutes les applications.

Dans certains scénarios, où votre application nécessite beaucoup de ressources de calcul, généralement à gérer une augmentation dans les requêtes HTTP entrantes, vous souhaiterez que votre application en cours d’exécution sur tous les serveurs disponibles. Toutefois, il est parfois une conséquence inattendue qui se produit lorsqu’un Plan App Service est montée en charge d’un serveur à plusieurs. Si un Plan App Service sollicitation du processeur ou la mémoire en raison d’un grand nombre d’applications en cours d’exécution, l’augmentation du nombre de serveurs dans ce Plan App Service ne résout pas le problème.

Au lieu de cela, envisagez la distribution du trafic pour chaque application et séparer de longue durée des applications de faible volume dans un Plan de Service application distincte. Envisagez d’exécuter des applications de gros volumes dans les Plans de Service application distincte. À l’aide de 50 exemple d’application précédemment, après avoir analysé les modèles de trafic, vous pouvez vous retrouver avec l’allocation suivante aux Plans App Service et les ressources de calcul :

  • les applications de faible volume 40 restent dans un seul Plan App Service en cours d’exécution sur le calcul d’une ressource.
  • Cinq applications mid à faible volume utilisent un second Plan App Service en cours d’exécution sur une ressource de calcul.
  • Les autres cinq applications sont établies que l’utilisation élevée. Chaque application est déployée sur un Plan de Service application distincte.  Une règle à l’échelle automatique est définie sur chaque Plan App Service à utiliser au moins une ressource de calcul, avec des règles de mise à l’échelle d’entrée/sortie en fonction du processeur et l’utilisation de la mémoire.

Le résultat de cette approche est que les 50 applications utilisent des ressources de calcul sept au minimum, avec les cinq applications élevées ayant chacune l’espace nécessaire pour faire évoluer indépendamment de la demande selon la charge.

Mise à l’échelle par application

Une autre solution pour l’exécution d’un grand nombre d’applications de façon plus efficace consiste à utiliser la fonctionnalité de mise à l’échelle par application de Service d’application Azure. Le document à bit.ly/2iQUm1S couvre la mise à l’échelle en détail par l’application. Mise à l’échelle par application vous permet de contrôler le nombre maximal de serveurs allouées à une application donnée, et vous pouvez le faire par application. Dans ce cas, une application s’exécutera sur le nombre maximal défini de serveurs et non sur tous les serveurs disponibles.

À l’aide de 50 antérieures exemple d’application, par l’application mise à l’échelle est activé pour le Plan App Service, 50 toutes les applications peuvent être affectées à la même Plan App Service. Ensuite, les caractéristiques de mise à l’échelle des applications individuelles peuvent être modifiées :

  • 40 applications faible volume définies pour s’exécuter sur un maximum d’un seul serveur.
  • Cinq applications moyenne et faible volume définies pour s’exécuter sur un maximum de deux serveurs.
  • Cinq applications élevées restantes définissent pour s’exécuter sur un maximum de 10 serveurs.

Le Plan de Service application sous-jacente peut commencer avec un minimum de cinq serveurs. Et puis les règles à l’échelle automatique peuvent être définies à monter en charge en tant que vs pression de mémoire selon nécessaire. Processeur :

Service d’application Azure gère automatiquement l’attribution d’applications pour les ressources de calcul. Le service gérera également limiter le nombre maximal d’instances de l’application en fonction du nombre de threads de travail en cours d’exécution définissant pour chaque application. Par conséquent, le nombre croissant de threads de travail dans le Plan App Service entraîne pas 50 instances de l’application sera exécutée sur chaque machine virtuelle disponible. 

Pour résumer, mise à l’échelle par l’application « packs de « applications sur les serveurs sous-jacent associés à un Plan App Service. Mise à l’échelle par l’application n’entraîne pas de toutes les applications en cours d’exécution sur chaque ressource de calcul associé à un Plan de Service d’application comme décrit précédemment.

Emplacements d’application

Service d’application dispose d’une fonctionnalité appelée « emplacements de déploiement » (bit.ly/2iJzv3f). En bref, un emplacement de déploiement vous permet d’utiliser une autre application (emplacement) que votre application de production. C’est une autre application que vous pouvez utiliser pour tester le nouveau code avant de basculer en production.

Emplacements d’application fait partie de la fonctionnalité la plus utilisée dans le Service d’application. Toutefois, il est important de comprendre que chaque emplacement de l’application est également une application à part entière. Cela signifie que les emplacements de l’application peuvent avoir des domaines personnalisés associés avec les différents certificats SSL, les paramètres d’application et des. Cela signifie également que l’attribution d’un emplacement de l’application à un Plan de Service d’application peut être gérée séparément à partir du Plan App Service associé à l’emplacement de production principal.

Par défaut, l’emplacement de chaque application est créé dans le même Plan App Service en tant que l’emplacement de production. Pour les applications de faible volume et/ou les applications avec une faible utilisation du processeur, mémoire, cette approche consiste.

Toutefois, toutes les applications dans un Plan App Service s’exécutant sur les mêmes serveurs, cela signifie par défaut, que tous les emplacements d’une Application sont en cours d’exécution sur le même serveur sous-jacent exact en production. Cela peut entraîner des problèmes telles que les contraintes de processeur ou la mémoire si vous décidez d’exécuter des tests de stress par rapport à des emplacements autres que de production, qui s’exécutent sur le même serveur que votre application de production.

Si la compétition de ressources est limitée uniquement à des scénarios tels que l’exécution des tests de charge, puis déplaçant temporairement un emplacement vers un autre Plan App Service, avec son propre ensemble de serveurs, effectue les opérations suivantes :

  • Créez plus Plan App Service pour les emplacements. Remarque importante : Chaque Plan App Service doit se trouver dans le même groupe de ressources et de la même région que le Plan de Service d’application de l’emplacement de production.
  • Déplacer un emplacement hors production vers un autre Plan App Service et, par conséquent, un pool de ressources de calcul distinct.
  • Effectuer des tâches gourmandes en ressources (ou risquées) lors de l’exécution dans le Plan de Service application distincte. Par exemple, les tests de charge peuvent être exécutés par rapport à un emplacement hors production sans effets négatifs sur l’emplacement de production car il ne seront pas tout conflit de ressources.
  • Lorsque l’emplacement hors production est prête à être basculées en production, déplacez-le vers le même Plan App Service en cours d’exécution l’emplacement de production. Puis l’opération d’échange emplacement peut être effectuée.

Déploiement en Production sans interruption de service

Vous avez une application réussie s’exécutant sur un Plan App Service et une grande équipe à mettre à jour votre application sur une base quotidienne. Dans ce cas, vous ne souhaitez pas déployer les bits directement en production. Vous souhaitez contrôler le déploiement et de réduire le temps mort. Pour cela, vous pouvez utiliser les emplacements de votre application. Définir votre déploiement à l’emplacement « Pre-production », qui peut être configuré avec l’environnement de production et de déployer votre code le plus récent. Vous pouvez tester en toute sécurité votre application. Une fois que vous êtes satisfait, vous pouvez basculer les nouveaux éléments en production. L’opération d’échange ne redémarre pas votre application et en retour le contrôleur notifie l’équilibrage de charge de front à rediriger le trafic vers les emplacements plus récente.

Certaines applications ont besoin pour le préchauffage avant qu’ils puissent gérer en toute sécurité la charge de production, par exemple, si votre application a besoin charger des données dans le cache, ou pour une application .NET pour permettre au runtime .NET JIT vos assemblys. Dans ce cas, vous allez également d’utiliser les emplacements de l’application à votre application avant de basculer en production de préchauffage.

Nous le constatons souvent les clients ayant un emplacement de pré-production qui sert à tester et à chaud de l’application. Vous pouvez utiliser les outils de déploiement en continu telles que le Gestionnaire de version de Visual Studio pour configurer un pipeline pour que votre code déployé en production avant emplacements, exécuter de test pour la vérification et à chaud de tous les chemins d’accès requis dans votre application avant de basculer en production.

Configuration de réseau unité de mise à l’échelle

L’unité d’échelle App Service est déployée sur un Service Cloud. Par conséquent, elle implique certaines fonctionnalités que vous pouvez vous familiariser avec afin de mieux comprendre les effets de réseau sur vos applications et la configuration de réseau.

L’unité d’échelle a une seule adresse IP virtuelle (VIP) exposée au monde. Toutes les applications sont allouées à une unité d’échelle donnée sont traitées via cette adresse IP virtuelle. L’adresse IP virtuelle est la représentation sous forme de Service Cloud sur lequel l’unité d’échelle App Service est déployée.

Les applications de Service d’application servent uniquement HTTP (port 80) et le trafic HTTPS (port 443). Chaque application de Service de l’application a la valeur par défaut de la que prise en charge de HTTPS intégrés pour le nom de domaine azurewebsites.net. App Service prend en charge les certificats basés sur IP couche SSL (Secure Sockets) et d’Indication de nom de serveur (SNI). Dans le cas de SSL basé sur IP, une application donnée est allouée à une adresse IP dédiée pour que le trafic entrant, qui est associé au déploiement de Service Cloud. Veuillez noter que Frontaux terminer la connexion SSL pour toutes les demandes HTTPS pour toutes les applications et n’importe quel type de certificat. Le serveur frontal transfère ensuite la demande au traitement désigné pour une application donnée.

Adresse IP virtuelle publique

Par défaut, il existe une adresse VIP unique pour tout le trafic HTTP entrant. N’importe quelle application est dédiée à une adresse IP virtuelle unique. Si vous avez une application App service, exécutez la commande nslookup (à partir de la console Windows ou PowerShell) et afficher le résultat. Voici un exemple :

#1 PS C:\> nslookup awesomewebapp.azurewebsites.net
#2 Server:  UnKnown
#3 Address:  10.221.0.3
#4 Non-authoritative answer:
#5 Name:    waws-prod-bay-001.cloudapp.net
#6 Address:  168.62.20.37
#7 Aliases:  awesomewebapp.azurewebsites.net

Voici un examen de la sortie de awesomewebapp.azurewebsites.net :

  • Ligne #1 exécute un nslookup interrogation résolution pour awseomwebapp.azurewebsites.net.
  • Ligne #5 indique le nom de domaine de l’unité d’échelle awseomwebapp application en cours d’exécution. Vous remarquerez qu’une unité d’échelle App Service est déployée sur Azure Cloud Service (par le suffixe cloudapp.net). WAWS est l’abréviation de Windows Azure (lorsque Azure a été appelé toujours Windows) des sites Web (le nom d’origine du Service d’application).
  • Ligne #6 indique l’adresse VIP de l’unité d’échelle. Toutes les applications qui sont hébergés et s’exécute sur Azure Web sites-prod-bay-001 (ligne n ° 5) sont adressables à l’adresse IP virtuelle publique désigné.
  • Ligne #7 affiche tous les alias de domaine mappés à la même adresse IP.

Adresses IP virtuelles sortants

Votre application est probablement connectée à d’autres Azure et les services non-Azure. Par conséquent, votre application effectue des appels réseau sortants aux points de terminaison pas sur l’unité d’échelle de votre application. Cela inclut l’appel aux services Azure comme base de données SQL et le stockage Azure. Il existe jusqu'à cinq adresses (une adresse VIP et quatre adresses IP virtuelles dédiés sortants) utilisés pour la communication sortante. Vous ne pouvez pas choisir dont votre application utilise l’adresse IP virtuelle et tous les appels sortants à partir de toutes les applications dans l’unité d’échelle qui utilisent les cinq adresses IP virtuelles allouées. Si votre application utilise un service qui requiert une liste blanche d’adresses IP qui sont autorisés à effectuer des appels d’API dans un tel service, vous devez inscrire toutes les adresses IP cinq virtuelles de l’unité d’échelle. Pour afficher l’adresses IP sont des adresses IP virtuelles allouées à la sortie d’une unité d’échelle donnée (ou de votre application à partir de votre point de vue), accédez au portail, comme illustré dans Figure 3.

Affichage des adresses IP sortante Application app Service dans le portail Azure
Affichage des adresses IP sortante figure 3 App Service Application dans Azure Portal

Si vous recherchez un ensemble dédié de fournisseurs d’identité entrante et sortante, vous pouvez Explorer cela à l’aide d’un environnement de Service d’application totalement isolé et dédié à bit.ly/2hVRSlR.

Adresse IP et SSL SNI

App Service prend en charge les certificats SSL basés sur IP. Lorsque vous utilisez SSL IP, App Service alloue à votre application une adresse IP dédiée pour le trafic HTTP entrant uniquement.

Contrairement au reste des adresses IP dédiées Azure, l’adresse IP avec le Service d’application via SSL IP est allouée, que vous choisissez pour l’utiliser. Vous ne possédez pas l’adresse IP et lorsque vous supprimez votre SSL IP, vous risquez de perdre l’adresse IP (comme il peut être attribué à une autre application).

Service de l’application prend également en charge SSL SNI, qui ne nécessite pas une adresse IP dédiée et est pris en charge par les navigateurs modernes. 

Capacité de Port réseau pour les appels réseau sortants

Une exigence courante pour les applications est la possibilité d’effectuer des appels réseau sortants aux autres points de terminaison réseau. Cela inclut l’appelant Azure services internes tels que la base de données SQL et le stockage Azure. Il inclut également des cas où les applications appeler des points de terminaison HTTP/HTTPS API — par exemple, appeler une API de recherche Bing ou appeler une API « application » qui implémente la logique métier de back-end pour une application Web.

Dans presque tous les cas, l’application appelante s’exécutant sur Azure App Service est implicitement ouverture d’un socket réseau et effectue des appels sortants vers les points de terminaison qui sont considérées comme « distants » à partir d’un point de vue de la mise en réseau Azure. Il s’agit d’un point important, car les appels effectués à partir d’une application qui s’exécute sur Azure App Service à un point de terminaison distant s’appuient sur le réseau Azure pour configurer et gérer une table de mappages de traduction d’adresses réseau (NAT).

Création de nouvelles entrées dans ce mappage NAT prend du temps et il est finalement une limite finie sur le nombre total de mappages NAT qui peuvent être établies pour une seule unité d’échelle Azure App Service. Pour cette raison, App Service impose des limites sur le nombre de connexions sortantes qui peuvent être en attente à un moment donné dans le temps.

La limite maximale de connexions est les suivants :

  • 1 920 connexions par instance de B1/S1/P1
  • 3,968 connexions par instance de B2/S2/P2
  • 8,064 connexions par instance de B3/S3/P3
  • Limite supérieure maximale de 64 Ko par environnement App Service

Applications « fuite de « connexions invariablement exécutées dans ces limites de connexion. Applications démarrent intermittent, car les appels vers les points de terminaison distants échouent, avec les échecs parfois corrélation étroitement aux périodes de charge d’application supérieure. Vous rencontrerez souvent des erreurs comme suit : « Une tentative a été effectuée pour accéder à un socket de manière interdite par ses aaa.bbb.ccc.ddd d’autorisations accès ».

La probabilité de ce problème peut être considérablement atténuée avec quelques meilleures pratiques :

  • Pour les applications .NET à l’aide de ADO.NET/EF, utilisez le regroupement de connexions de base de données.
  • Pour php/mySql, utilisent des connexions de base de données persistante.
  • Pour les applications Node.js effectue des appels HTTP/HTTPS sortantes, configurer des connexions persistantes afin que les connexions sortantes sont réutilisées. Cette configuration est décrite au bit.ly/2iGrcoo.
  • Pour les applications .NET qui effectue des appels HTTP/HTTPS sortants du pool et réutiliser des instances de System.Net.Http.HttpClient ou utiliser des connexions persistantes avec System.Net.HttpWebRequest. Remarque : Pensez à augmenter la System.Net.ServicePointManager.DefaultConnectionLimit, car sinon sera limité à deux connexions sortantes simultanées au même point de terminaison.

Il existe des limitations supplémentaires imposées par le Sandbox de services d’application. Il s’agit des limites de niveau inférieur et contraintes pour Azure App Service et vous pouvez consulter les plus en détail à bit.ly/2hXJ6lL.

Pour résumer

Azure App Service fournit une offre PaaS riche pour le Web, les applications d’API et mobiles. Alors que le service a un grand nombre de déplacement des composants internes, ils sont extraits afin que les développeurs peuvent se concentrer sur l’écriture des applications pendant que le service gère les complexités de l’exécution de ces applications à l’échelle mondiale. 

La plupart des méthodes conseillées pour le Service d’application sont axés sur la mise à l’échelle de l’application. Une bonne compréhension du mappent des applications aux traitements Web dans un Plan App Service est important lorsque vous augmentez le nombre de vos applications en cours d’exécution sur le service, tout en conservant une configuration de mise à l’échelle optimale.

Étant donné l’univers de cloud d’abord nous dans, Azure et Azure App Service sont toujours en constante évolution à un rythme rapide. Nombre de nouvelles innovations sont attendues dans 2017.

Composants d’unité de mise à l’échelle

Il peut sembler comme si l’échelle unité composants dépendent largement mutuellement. Toutefois, par défaut, ils sont faiblement couplées. Une application en cours d’exécution (activement le trafic HTTP service) dans un traitement Web donné peut continuer à traiter le trafic HTTP, même si d’autres rôles dans l’unité d’échelle ne fonctionnent pas correctement.

Par exemple, un serveur de publication ne fonctionne ne pas correctement peut gêner l’accès FTP, mais qui n’affecte pas le trafic HTTP d’une application ou autres options de déploiement. Si le contrôleur a un bogue qui empêche la création de nouvelles applications, cela ne signifie pas déjà affectées à l’unité d’échelle des applications cessent de fonctionner.

Yochay Kiriatyest responsable de programme principal dans l’équipe Microsoft Azure, en particulier de commande Web, mobiles, API et fonctions dans le cadre de la plate-forme de services d’application Azure.  Kiriaty travaille avec les technologies Web depuis les années 90 en retard et est passionné par l’évolutivité et de performances. Vous pouvez le contacter à l’adresse yochay@microsoft.com et le suivre sur Twitter : @yochayk.

Stefan Schackowest responsable de programme de l’équipe de Services d’application Azure qui a travaillé sur le cloud d’application Web offre depuis ses jours plus tôt.  Dans Azure, il dirige une équipe de responsables de programmes qui travaillent sur le développement et déploiement d’Azure App Service, ainsi que le développement de produits de locale/cloud hybride de Microsoft (Azure Pack et Azure pile). Vous pouvez le contacter à stefsch@microsoft.com.

Merci aux experts techniques Microsoft suivants d'avoir relu cet article : Eduardo Laureano et Nir Mashkowski