Fonctionnalités du système d’exploitation dans Azure App Service

Cet article décrit la fonctionnalité de système d’exploitation de référence disponible pour toutes les applications Windows s’exécutant dans Azure App Service. Cette fonctionnalité inclut l’accès aux fichiers, au réseau et au Registre, ainsi qu’aux journaux de diagnostic et aux événements.

Remarque

Les applications Linux dans App Service s’exécutent dans leurs propres conteneurs. Vous disposez d’un accès racine au conteneur, mais aucun accès au système d’exploitation hôte. De même, pour les applications s’exécutant dans des conteneurs Windows, vous disposez d’un accès administratif au conteneur, mais aucun accès au système d’exploitation hôte.

Niveaux des plans App Service

App Service exécute des applications client dans un environnement d’hébergement mutualisé.

• Les applications déployées dans les niveaux Gratuit et Partagé s’exécutent dans des processus de travail sur des machines virtuelles partagées.
• Les applications déployées dans les niveaux Standard et Premium s’exécutent sur des machines virtuelles dédiées spécifiquement aux applications associées à un seul client.

Remarque

Les plans de service Gratuit et Partagé (préversion) d’App Service sont des niveaux de base qui s’exécutent sur les mêmes machines virtuelles Azure que les autres applications App Service. Certaines applications peuvent appartenir à d’autres clients. Ces niveaux sont destinés uniquement à des fins de test et de développement.

Étant donné que App Service prend en charge une expérience de mise à l’échelle transparente entre les niveaux, la configuration de sécurité appliquée pour les applications App Service reste la même. Cette configuration garantit que les applications ne se comportent pas soudainement différemment et échouent de manière inattendue lorsqu’un plan App Service passe d’un niveau à un autre.

Infrastructures de développement

Les niveaux tarifaires App Service contrôlent la quantité de ressources de calcul (processeur, stockage sur disque, mémoire et sortie réseau) disponibles pour les applications. Toutefois, l’étendue des fonctionnalités d’infrastructure disponibles pour les applications reste la même, quel que soit le niveau de mise à l’échelle.

App Service prend en charge diverses infrastructures de développement, notamment ASP.NET, ASP classique, Node.js, PHP et Python. Pour simplifier et normaliser la configuration de la sécurité, les applications App Service exécutent généralement les frameworks de développement avec leurs paramètres par défaut. Les frameworks et composants d’exécution que la plateforme fournit sont mis à jour régulièrement pour répondre aux exigences de sécurité et de conformité. Pour cette raison, nous ne garantissons pas de versions mineures ou correctives spécifiques. Nous recommandons aux clients de cibler les versions principales en fonction des besoins.

Les sections suivantes résument les types généraux de fonctionnalités du système d’exploitation disponibles pour les applications App Service.

Accès aux fichiers

Différents lecteurs existent dans App Service, notamment les lecteurs locaux et les lecteurs réseau.

Lecteurs locaux

Au cœur, App Service est un service qui s’exécute sur l’infrastructure PaaS (Platform as a Service) Azure. Par conséquent, les lecteurs locaux associés à une machine virtuelle sont les mêmes types de lecteurs disponibles pour n’importe quel rôle de travail s’exécutant dans Azure. Il s’agit notamment des éléments suivants :

• Lecteur de système d’exploitation (%SystemDrive%) dont la taille dépend de la taille de la machine virtuelle.
• Un lecteur de ressources (%ResourceDrive%) qu’App Service utilise en interne.

Une bonne pratique consiste à toujours utiliser les variables %SystemDrive% d’environnement et %ResourceDrive% au lieu de chemins de fichiers codés en dur. Le chemin racine retourné à partir de ces deux variables d'environnement a changé au fil du temps de d:\ à c:\. Toutefois, les applications plus anciennes codées en dur avec des références de chemin d’accès de fichier vers d:\ continuent à fonctionner, car App Service remappe automatiquement d:\ pour qu'il pointe vers c:\. Comme indiqué précédemment, nous vous recommandons vivement d’utiliser toujours les variables d’environnement lors de la création de chemins de fichier et d’éviter toute confusion sur les modifications de plateforme apportées au chemin d’accès du fichier racine par défaut.

Il est important de surveiller l’utilisation de votre disque à mesure que votre application augmente. Atteindre le quota de disque peut avoir des effets néfastes sur votre application. Par exemple:

• L’application peut générer une erreur indiquant qu’il n’y a pas suffisamment d’espace sur le disque.
• Vous pouvez voir des erreurs de disque lors de la navigation dans la console Kudu.
• Le déploiement à partir d’Azure DevOps ou de Visual Studio peut échouer avec ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk).
• Votre application peut avoir des performances lentes.

Lecteurs réseau (partages UNC)

L’un des aspects uniques d’App Service qui simplifient le déploiement et la maintenance des applications est que tous les partages de contenu sont stockés sur un ensemble de partages UNC (Universal Naming Convention). Ce modèle correspond bien au modèle courant de stockage de contenu utilisé par les environnements d’hébergement web locaux qui ont plusieurs serveurs à charge équilibrée.

Dans App Service, les partages UNC sont créés dans chaque centre de données. Un pourcentage du contenu utilisateur pour tous les clients de chaque centre de données est attribué à chaque partage de fichiers UNC. L’abonnement de chaque client a une structure d’annuaires réservée sur un partage UNC spécifique dans un centre de données. Un client peut avoir plusieurs applications créées dans un centre de données spécifique, de sorte que tous les répertoires appartenant à un seul abonnement client sont créés sur le même partage UNC.

En raison de la façon dont fonctionnent les services Azure, la machine virtuelle spécifique responsable de l’hébergement d’un partage UNC change au fil du temps. Les partages UNC sont montés par différentes machines virtuelles à mesure qu’elles sont montées et bas pendant le cours normal des opérations Azure. Pour cette raison, les applications ne doivent jamais faire d'hypothèses prédéfinies que les informations de l’ordinateur dans un chemin de fichier UNC restent constantes dans le temps. Elles doivent utiliser le faux chemin d’accès absolu %HOME%\site fourni par App Service.

Le faux chemin absolu est une méthode portable pour faire référence à votre propre application. Elle n’est spécifique à aucune application ou utilisateur. En utilisant %HOME%\site, vous pouvez transférer des fichiers partagés de l’application à l’application sans avoir à configurer un nouveau chemin absolu pour chaque transfert.

Types d’accès aux fichiers accordés à une application

Le %HOME% répertoire d’une application est mappé à un partage de contenu dans stockage Azure dédié à cette application. Votre niveau tarifaire définit sa taille. Il peut inclure des répertoires tels que ceux pour le contenu, les journaux d’erreur et de diagnostic, ainsi que les versions antérieures de l’application créées par le contrôle de code source. Ces répertoires sont disponibles pour le code d’application de l’application au moment de l’exécution pour l’accès en lecture et en écriture. Étant donné que les fichiers ne sont pas stockés localement, ils sont persistants entre les redémarrages de l’application.

Sur le lecteur système, App Service réserve %SystemDrive%\local pour un stockage local temporaire spécifique à l’application. Les modifications apportées aux fichiers de ce répertoire ne sont pas persistantes entre les redémarrages de l’application. Bien qu’une application dispose d’un accès en lecture et en écriture complet à son propre stockage local temporaire, ce stockage n’est pas destiné à être utilisé directement par le code de l’application. Au lieu de cela, l’intention est de fournir un stockage de fichiers temporaire pour les infrastructures d’application web et IIS.

App Service limite la quantité de stockage dans %SystemDrive%\local chaque application pour empêcher les applications individuelles de consommer des quantités excessives de stockage de fichiers locaux. Pour les niveaux Gratuit, Partagé et Consommation (Azure Functions), la limite est de 500 Mo. Le tableau suivant répertorie les autres niveaux :

Niveau	Limite de stockage locale
B1/S1/P1	11 Go
B2/S2/P2	15 Go
B3/S3/P3	58 Go
P0v3/P0v4	11 Go
P1v2/P1v3/P1mv3/P1v4/P1mv4/Isolated1/Isolated1v2	21 Go
P2v2/P2v3/P2mv3/P2v4/P2mv4/Isolated2/Isolated2v2v2	61 Go
P3v2/P3v3/P3mv3/P3v4/P3mv4/Isolated3/Isolated3v2	140 Go
Isolated4v2	276 GO
P4mv3/P4mv4	280 Go
Isolated5v2	552 GO
P5mv3/P5mv4	560 GO
Isolated6v2	1 104 Go

Le répertoire des fichiers de ASP.NET temporaires et le répertoire des fichiers compressés IIS sont deux exemples de la façon dont App Service utilise un stockage local temporaire. Le système de compilation ASP.NET utilise le %SystemDrive%\local\Temporary ASP.NET Files répertoire comme emplacement de cache de compilation temporaire. IIS utilise le répertoire pour stocker la %SystemDrive%\local\IIS Temporary Compressed Files sortie de réponse compressée. Ces deux types d’utilisation de fichiers (ainsi que d’autres) sont remappés dans App Service vers un stockage local temporaire par application. Ce remapping permet de s’assurer que les fonctionnalités continuent comme prévu.

Chaque application dans App Service fonctionne avec une identité de processus de travail aléatoire et unique, ayant des droits d'accès limités, appelée identité du pool d’applications. Le code d’application utilise cette identité pour un accès en lecture seule de base au lecteur du système d’exploitation. Cet accès signifie que le code de l’application peut répertorier les structures de répertoires courantes et lire les fichiers courants sur le lecteur du système d’exploitation. Bien que ce niveau d’accès semble être large, les mêmes répertoires et fichiers sont accessibles lorsque vous approvisionnez un rôle de travail dans un service hébergé par Azure et lisez le contenu du lecteur.

Accès aux fichiers sur plusieurs instances

Le répertoire de partage de contenu (%HOME%) contient le contenu d’une application, et le code de l’application peut y écrire. Si une application s’exécute sur plusieurs instances, le %HOME% répertoire est partagé entre toutes les instances afin que toutes les instances voient le même répertoire. Par exemple, si une application enregistre les fichiers chargés dans le %HOME% répertoire, ces fichiers sont immédiatement disponibles pour toutes les instances.

Le répertoire de stockage local temporaire (%SystemDrive%\local) n’est pas partagé entre les instances. Il n’est pas partagé entre l’application et son application Kudu.

Accès réseau

Le code d’application peut utiliser des protocoles TCP/IP et UDP pour établir des connexions réseau sortantes à des points de terminaison accessibles à Internet qui exposent des services externes. Les applications peuvent utiliser ces mêmes protocoles pour se connecter aux services dans Azure, par exemple en établissant des connexions HTTPS à Azure SQL Database.

La capacité des applications à établir une connexion de bouclage locale et à écouter sur le socket de bouclage local correspondant est également limitée. Cette fonctionnalité permet aux applications qui écoutent les sockets de bouclage locaux dans le cadre de leurs fonctionnalités. Chaque application dispose d'une connexion de retour privée. Une application ne peut pas écouter un socket de bouclage local établi par une autre application.

Les canaux nommés sont également pris en charge en tant que mécanisme pour la communication interprocesseur entre les processus qui exécutent collectivement une application. Par exemple, le module IIS FastCGI s’appuie sur des canaux nommés pour coordonner les processus individuels qui exécutent des pages PHP.

Exécution du code, processus et mémoire

Comme indiqué précédemment, les applications s'exécutent dans des processus de travail à faible privilège en utilisant une identité de pool d’applications aléatoire. Le code de l'application a accès à l'espace mémoire associé au processus de travail, ainsi qu'à tous les processus enfants que les processus CGI ou d'autres applications peuvent créer. Toutefois, une application ne peut pas accéder à la mémoire ou aux données d’une autre application, même si elle se trouve sur la même machine virtuelle.

Les applications peuvent exécuter des scripts ou des pages écrits avec des frameworks de développement web pris en charge. App Service ne configure aucun paramètre d’infrastructure web en modes plus restreints. Par exemple, ASP.NET applications s’exécutant dans App Service s’exécutent en toute confiance, par opposition à un mode d’approbation plus restreint. Les infrastructures web, y compris ASP et ASP.NET classiques, peuvent appeler des composants COM in-process (comme ActiveX Data Objects) inscrits par défaut sur le système d’exploitation Windows. Les frameworks web ne peuvent pas appeler des composants COM hors processus.

Une application peut générer et exécuter du code arbitraire, ouvrir un interpréteur de commandes ou exécuter un script PowerShell. Toutefois, les programmes exécutables et les scripts sont toujours limités aux privilèges accordés au pool d’applications parent. Par exemple, une application peut générer un programme exécutable qui effectue un appel HTTP sortant, mais ce programme exécutable ne peut pas essayer de dissocier l’adresse IP d’une machine virtuelle à partir de sa carte réseau. L’exécution d’un appel réseau sortant est autorisée pour du code à faible privilège, mais la tentative de reconfigurer les paramètres réseau sur une machine virtuelle nécessite des privilèges d’administration.

Journaux de diagnostic et événements

Les informations de journal sont un autre ensemble de données auxquelles certaines applications tentent d’accéder. Les types d’informations de journal disponibles pour le code en cours d’exécution dans App Service incluent les informations de diagnostic et de journal qu’une application génère et peut facilement accéder.

Par exemple, les journaux HTTP W3C générés par l’application sont disponibles soit :

• Dans un répertoire de journal dans l’emplacement de partage réseau que vous avez créé pour l’application.
• Dans le stockage d’objets blob si vous configurez la journalisation W3C sur le stockage.

Cette dernière option permet aux applications de collecter de grandes quantités de journaux sans dépasser les limites de stockage de fichiers associées à un partage réseau.

De même, les informations de diagnostic en temps réel des applications .NET peuvent être journalisées via l’infrastructure de suivi et de diagnostic .NET. Vous pouvez ensuite écrire les informations de trace dans le partage réseau de l’application ou dans un emplacement de stockage d’objets blob.

Les domaines de journalisation et de traçage des diagnostics qui ne sont pas accessibles aux applications incluent le Suivi d’événements pour Windows (ETW) et les journaux d’événements habituels de Windows, comme les journaux système, application et sécurité. Étant donné que les informations de trace ETW peuvent potentiellement être visibles sur un ordinateur à l’aide des listes de contrôle d’accès appropriées, l’accès en lecture et l’accès en écriture aux événements ETW sont bloqués. Les appels d’API pour lire et écrire des événements ETW et des journaux d’événements Windows courants peuvent sembler fonctionner, mais en réalité, le code de l’application n’a pas accès à ces données d’événements.

Accès au Registre

Les applications ont un accès en lecture seule à beaucoup, mais pas tous, du registre de la machine virtuelle sur laquelle elles s’exécutent. Cet accès signifie que les applications peuvent accéder aux clés de Registre qui autorisent l’accès en lecture seule au groupe Utilisateurs locaux. L’une des zones du Registre qui n’est actuellement pas prise en charge pour l’accès en lecture ou en écriture est la ruche HKEY_CURRENT_USER.

L’accès en écriture au Registre est bloqué, y compris l’accès à toutes les clés de Registre par utilisateur. Du point de vue de l’application, elle ne peut pas s’appuyer sur l’accès en écriture au Registre dans l’environnement Azure, car les applications peuvent être migrées sur plusieurs machines virtuelles. Le seul stockage pouvant être écrit persistant sur lequel une application peut dépendre est la structure de répertoires de contenu par application stockée sur les partages UNC App Service.

Accès bureau à distance

App Service ne fournit pas d’accès bureau à distance aux instances de machine virtuelle.

Contenu connexe

Pour obtenir les informations les plus à jour sur l’environnement d’exécution d’App Service, consultez le bac à sable Azure App Service. L’équipe de développement App Service gère cette page.