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

Article
01/10/2024

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 et événements de diagnostic.

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 qui s’exécutent dans des conteneurs Windows, vous disposez d’un accès administratif au conteneur mais pas d’un 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 développement et de test.

É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 d’App Service déterminent la quantité de ressources de calcul (processeur, stockage sur disque, mémoire et sortie réseau) accessible aux applications. Toutefois, l’étendue des fonctionnalités d’infrastructure accessibles aux 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/correctives spécifiques. Nous recommandons aux clients de cibler les versions principales en fonction des besoins.

Les sections suivantes présentent brièvement les principaux types de fonctionnalités de système d’exploitation accessibles aux applications App Service.

Accès aux fichiers

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

Lecteurs locaux

À sa base, App Service est un service s’exécutant 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. Notamment :

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

Une bonne pratique consiste à toujours utiliser les variables d’environnement %SystemDrive% et %ResourceDrive% au lieu de chemins de fichiers codés en dur. Le chemin racine retourné à partir de ces deux variables d’environnement est passé 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 pour d:\ continuer à fonctionner, car App Service remapise d:\ automatiquement pour pointer 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 du disque à mesure du développement de votre application. 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. Ce modèle s’adapte bien au modèle commun de stockage de contenu utilisé par les environnements d’hébergement web locaux dotés de 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 alloué à chaque partage 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 les services Azure fonctionnent, 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 lorsqu’elles sont montées et bas pendant le cours normal des opérations Azure. C'est la raison pour laquelle les applications ne doivent jamais partir du principe que les informations machine présentes dans un chemin de fichier UNC resteront stables au fil du temps. Elles doivent utiliser le faux chemin d’accès absolu %HOME%\site fourni par App Service.

Le chemin absolu faux 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 octroyé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 accessibles au code 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 le stockage local temporaire spécifique de l’application. Les modifications apportées aux fichiers dans 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. Il a pour but de fournir un stockage de fichiers temporaire à IIS et aux infrastructures d'applications Web.

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	Stockage de fichier local
B1/S1/P1	11 Go
B2/S2/P2	15 Go
B3/S3/P3	58 Go
P0v3	11 Go
P1v2/P1v3/P1mv3/Isolated1/Isolated1v2	21 Go
P2v2/P2v3/P2mv3/Isolated2/Isolated2v2	61 Go
P3v2/P3v3/P3mv3/Isolated3/Isolated3v2	140 Go
Isolated4v2	276 Go
P4mv3	280 Go
Isolated5v2	552 Go
P5mv3	560 Go
Isolated6v2	1 104 Go

Deux exemples illustrent la façon dont App Service utilise le stockage local temporaire : le répertoire de fichiers temporaires ASP.NET et le répertoire de fichiers compressés IIS. Le système de compilation ASP.NET utilise le répertoire %SystemDrive%\local\Temporary ASP.NET Files comme emplacement de cache de compilation temporaire. IIS utilise le répertoire %SystemDrive%\local\IIS Temporary Compressed Files pour stocker les réponses compressées. 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 s’exécute sous la forme d’une identité de processus worker aléatoire, unique et à faible privilège appelée identité du pool d’applications. Le code d’application utilise cette identité pour l’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 du partage de contenu (%HOME%) comprend le contenu d’une application, et le code d’application peut y accéder en écriture. Si une application est exécutée sur plusieurs instances, le répertoire %HOME% est partagé entre toutes les instances afin que celles-ci voient toutes 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.

Il existe également une capacité limitée pour les applications d’établir une connexion de bouclage local et d’écouter une application sur ce socket de bouclage local. 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 bouclage 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 FastCGI d'IIS utilise des canaux nommés pour coordonner les processus individuels qui exécutent les pages PHP.

Exécution de code, processus et mémoire

Comme indiqué précédemment, les applications s’exécutent dans des processus worker à faible privilège en utilisant une identité de pool d’applications aléatoire. Le code d’application a accès à l’espace mémoire associé au processus de travail, ainsi que tous les processus enfants que CGI traite ou d’autres applications peuvent générer. 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 créés avec des infrastructures de développement Web prises en charge. App Service ne configure aucun paramètre d’infrastructure Web sur des 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 d’activité et événements de diagnostic

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 :

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 zones de journalisation et de suivi des diagnostics qui ne sont pas disponibles pour les applications sont des événements Suivi d’événements Windows pour Windows (ETW) et des journaux d’événements Windows courants (par exemple, les journaux d’événements système, application et sécurité). Étant donné que les informations de trace ETW peuvent être visibles sur un ordinateur (avec les 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 HKEY\_CURRENT\_USER ruche.

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 des 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 au Bureau à distance

App Service ne fournit pas l’accès au Bureau à distance aux instances de machine virtuelle.

Plus d’informations

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.