Betriebssystemfunktionen für Azure App Service

In diesem Artikel werden allgemeine, grundlegende Betriebssystemfunktionen beschrieben, die für alle Windows-Apps zur Verfügung stehen, die in Azure App Service ausgeführt werden. Diese Funktionen umfassen Zugriff auf Dateien, Netzwerke und Registrierung sowie Diagnoseprotokolle und Ereignisse.

Hinweis

Linux-Apps in App Service werden in eigenen Containern ausgeführt. Sie erhalten Rootzugriff auf den Container, aber es wird kein Zugriff auf das Hostbetriebssystem gewährt. Ebenso erhalten Sie für in Windows-Containern ausgeführte Apps Verwaltungszugriff auf die Container, aber keinen Zugriff auf das Hostbetriebssystem.

App Service-Planstufen

App Service führt Kunden-Apps in einer mandantenfähigen Hostingumgebung aus. Apps mit Bereitstellung in den Tarifen Free und Shared werden mit Workerprozessen auf gemeinsamen virtuellen Computern ausgeführt. Apps mit Bereitstellung in den Tarifen Standard und Premium werden hingegen auf virtuellen Computern ausgeführt, die nur für die Apps eines einzelnen Kunden bestimmt sind.

Hinweis

Die App Service-Dienstpläne „Free“ und „Shared“ (Vorschauversion) sind Basistarife, die auf denselben virtuellen Azure-Computern ausgeführt werden wie andere App Service-Apps. Einige Apps gehören möglicherweise anderen Kunden. Diese Tarife sind nur für Entwicklungs- und Testzwecke gedacht.

Da App Service eine nahtlose Skalierung zwischen unterschiedlichen Tarifen unterstützt, bleibt die durchgeführte Sicherheitskonfiguration für App Service Apps gleich. So wird gewährleistet, dass sich Apps nicht plötzlich anders verhalten und unerwartet ausfallen, wenn bei einem App Service-Plan die Dienstebene gewechselt wird.

Entwicklungsframeworks

App Service-Tarife steuern die Rechnerressourcen (CPU, Datenspeicher, Arbeitsspeicher und Netzwerkausgang), die Apps zur Verfügung stehen. Unabhängig von den gewählten Tarifen bleibt der Umfang verfügbarer Frameworkfunktionen für Apps jedoch gleich.

App Service unterstützt eine Vielzahl von Entwicklungsframeworks, einschließlich ASP.NET, klassischem ASP, Node.js, PHP und Python. App Service Apps führen die verschiedenen Entwicklungsframeworks mit deren Standardeinstellungen aus, um die Sicherheitskonfiguration zu vereinfachen und zu normalisieren. Die von der Plattform bereitgestellten Frameworks und Runtimekomponenten werden regelmäßig aktualisiert, um Sicherheits- und Complianceanforderungen zu erfüllen. Aus diesem Grund garantieren wir keine bestimmten Neben- bzw. Patchversionen und empfehlen Kund*innen, bei Bedarf die Hauptversion als Ziel zu verwenden.

In den folgenden Abschnitten werden die allgemeinen Betriebssystemfunktionen für App Service-Apps zusammengefasst.

Dateizugriff

In App Service gibt es viele Laufwerke, einschließlich lokaler Laufwerke und Netzwerklaufwerke.

Lokale Laufwerke

Im Grunde ist App Service ein Dienst, der auf der Azure-PaaS-Infrastruktur (Platform-as-a-Service) ausgeführt wird. Daher sind die lokalen Laufwerke, die an einen virtuellen Computer "angehängt" sind, die gleichen Laufwerkstypen wie die für jede in Azure ausgeführte Workerrolle verfügbaren Typen. Dies schließt Folgendes ein:

• Ein Betriebssystemlaufwerk (%SystemDrive%), dessen Größe je nach Größe der VM variiert
• Ein Ressourcenlaufwerk (%ResourceDrive%), das intern von App Service verwendet wird

Die Überwachung der Datenträgerauslastung ist wichtig, wenn Ihre Anwendung wächst. Wenn das Datenträgerkontingent erreicht ist, kann sich das negativ auf Ihre Anwendung auswirken. Beispiel:

• Die App gibt möglicherweise eine Fehlermeldung zurück, dass nicht genug Speicherplatz auf dem Datenträger vorhanden ist.
• Wenn Sie die Kudu-Konsole durchsuchen, werden Ihnen möglicherweise Datenträgerfehler angezeigt.
• Die Bereitstellung über Azure DevOps oder Visual Studio funktioniert möglicherweise mit ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk) nicht.
• Ihrer App wird möglicherweise langsam ausgeführt.

Netzwerklaufwerke (UNC-Freigaben)

Ein Alleinstellungsmerkmal von App Service, das die Webanwendungsbereitstellung und -wartung so unkompliziert macht, ist die Tatsache, dass alle Inhaltsfreigaben in einer Gruppe von UNC-Freigaben gespeichert werden. Dieses Modell passt gut zum allgemeinen Muster der Inhaltsspeicherung, das von lokalen Webhostingumgebungen verwendet wird, die über mehrere Server mit Lastenausgleich verfügen.

In App Service werden in jedem Rechenzentrum mehrere UNC-Freigaben erstellt. Ein Prozentsatz der Benutzerinhalte aller Kunden in jedem Rechenzentrum wird auf alle UNC-Freigaben verteilt. Jedes Abonnement eines Kunden verfügt über eine reservierte Verzeichnisstruktur auf einer bestimmten UNC-Freigabe innerhalb eines Rechenzentrums. Ein Kunde kann über mehrere Apps verfügen, die in einem bestimmten Rechenzentrum erstellt werden. Alle Verzeichnisse, die zu einem Abonnement eines Kunden gehören, werden daher auf derselben UNC-Freigabe erstellt.

Aufgrund der Funktionsweise von Azure-Diensten ändert sich der spezifische virtuelle Computer, der die UNC-Freigabe hostet, im Lauf der Zeit. Es wird gewährleistet, dass UNC-Freigaben von unterschiedlichen virtuellen Computern eingebunden werden, da diese während des normalen Verlaufs von Azure-Vorgängen ein- und ausgeschaltet werden. Aus diesem Grund sollten Apps nicht hartcodiert annehmen, dass die Computerinformationen in einem UNC-Dateipfad immer stabil bleiben. Stattdessen muss der praktische pseudoabsolute Pfad %HOME%\site verwendet werden, den App Service zur Verfügung stellt. Dieser pseudoabsolute Pfad bietet eine portable, Web-App- und benutzeragnostische Methode für die Verknüpfung zur eigenen App. Wenn Sie %HOME%\site verwenden, können Sie freigegebene Dateien von App zu App übertragen, ohne für jede Übertragung einen neuen absoluten Pfad konfigurieren zu müssen.

Dateizugriffsarten für eine Webanwendung

Das %HOME%-Verzeichnis in einer App wird einer Inhaltsfreigabe in Azure Storage zugeordnet, die für diese App dediziert ist, und ihre Größe wird durch Ihren Tarif definiert. In der Freigabe können Verzeichnisse für Inhalt, Fehler- und Diagnoseprotokolle und frühere Versionen der App enthalten sein, die von der Quellcodeverwaltung erstellt wurden. Diese Verzeichnisse stehen dem Anwendungscode der App zur Laufzeit für Lese- und Schreibzugriff zur Verfügung. Da die Dateien nicht lokal gespeichert werden, sind sie bei App-Neustarts persistent.

App Service reserviert %SystemDrive%\local auf dem Systemlaufwerk für App-spezifischen, temporären lokalen Speicher. Änderungen an Dateien in diesem Verzeichnis sind bei App-Neustarts nicht persistent. Obwohl eine App vollständigen Lese- und Schreibzugriff für den eigenen temporären lokalen Speicher besitzt, ist dieser Speicherplatz nicht dazu gedacht, direkt vom Anwendungscode verwendet zu werden. Stattdessen dient er dem Zweck, temporären Dateispeicher für IIS und Webanwendungsframeworks bereitzustellen. App Service beschränkt außerdem den Speicherplatz in %SystemDrive%\local für jede App, damit einzelne Apps nicht übermäßig viel lokalen Speicherplatz verbrauchen können. Für die Tarife Free, Shared und Consumption (Azure Functions) beträgt der Grenzwert 500 MB. In der folgenden Tabelle finden Sie weitere Tarife:

SKU-Familie	B1/S1/etc.	B2/S2/etc.	B3/S3/etc.
Basic, Standard und Premium	11 GB	15 GB	58 GB
PremiumV2, PremiumV3, isoliert	21 GB	61 GB	140 GB

Zwei Beispiele dazu, wie App Service temporären lokalen Speicherplatz verwendet, sind das Verzeichnis für ASP.NET-Dateien und das Verzeichnis für komprimierte IIS-Dateien. Das Kompilierungssystem von ASP.NET verwendet das Verzeichnis %SystemDrive%\local\Temporary ASP.NET Files als temporären Speicherort für den Kompilierungscache. IIS verwenden das Verzeichnis %SystemDrive%\local\IIS Temporary Compressed Files zum Speichern komprimierter Antwortausgaben. Diese beiden Arten der Dateinutzung (und weitere) werden in App Service über temporären lokalen Speicherplatz pro App neu zugewiesen. Durch diese Neuzuweisung wird eine durchgängige Funktionalität gewährleistet.

Jede App in App Service wird als zufällige, eindeutige Workerprozessidentität mit geringen Berechtigungen ausgeführt. Weitere Informationen zu dieser als „Anwendungspoolidentität“ bezeichneten Identität finden Sie in der Dokumentation zu Anwendungspoolidentitäten. Anwendungscode nutzt diese Identität für grundlegenden schreibgeschützten Zugriff auf das Betriebssystemlaufwerk. Das bedeutet, Anwendungscode kann allgemeine Verzeichnisstrukturen auflisten und allgemeine Dateien auf dem Betriebssystemlaufwerk lesen. Dies erscheint zwar wie ein sehr umfassender Zugriff, dieselben Verzeichnisse und Dateien sind jedoch zugänglich, wenn Sie in einem von Azure gehosteten Dienst eine Workerrolle bereitstellen und die Laufwerksinhalte lesen.

Dateizugriff über mehrere Instanzen

Das Inhaltsfreigabeverzeichnis (%HOME%) enthält den Inhalt einer App, und Anwendungscode kann darin schreiben. Wenn eine App auf mehreren Instanzen ausgeführt wird, wird das Verzeichnis %HOME% auf alle Instanzen verteilt, sodass für alle Instanzen das gleiche Verzeichnis angezeigt wird. Wenn also beispielsweise eine App hochgeladene Dateien im Verzeichnis %HOME% speichert, sind diese Dateien sofort für alle Instanzen verfügbar.

Das Verzeichnis für temporären Speicher (%SystemDrive%\local) wird weder zwischen Instanzen noch zwischen der App und der zugehörigen Kudu-App freigegeben.

Netzwerkzugriff

Anwendungscode kann TCP/IP- und UDP-basierte Protokolle verwenden, um ausgehende Verbindungen zu zugänglichen Endpunkten im Internet herzustellen, die externe Dienste bereitstellen. Apps können die gleichen Protokolle für eine Verbindung mit Diensten innerhalb von Azure verwenden, z.B. durch Herstellen von HTTPS-Verbindungen mit SQL-Datenbank.

Es ist außerdem eine eingeschränkte Funktion für Apps zur Erstellung einer lokalen Loopbackverbindung vorhanden, deren lokaler Loopbacksocket von Apps überwachtwerden kann. Diese Funktion dient vor allem dazu, Apps zu ermöglichen, als Teil ihrer Funktionalität lokale Loopbacksockets zu überwachen. Jede App sieht eine „private“ Loopbackverbindung. Die App „A“ kann nicht an einem lokalen Loopbacksocket lauschen, der durch die App „B“ eingerichtet wurde.

Named Pipes werden auch als Mechanismus für die Kommunikation zwischen Prozessen (IPC) unterstützt. Dies umfasst unterschiedliche Prozesse, die zusammen eine App ausführen. Beispielsweise nutzt das IIS FastCGI-Modul Named Pipes für die Koordinierung der individuellen Prozesse, die PHP-Websites ausführen.

Codeausführung, Prozesse und Speicher

Wie bereits zuvor erwähnt, werden Apps innerhalb von Workerprozessen mit geringen Berechtigungen und mit einer zufälligen Anwendungspoolidentität ausgeführt. Anwendungscode besitzt Zugriff auf den Speicherplatz, der zum Workerprozess gehört, sowie alle untergeordneten Prozesse, die aus CGI-Prozessen oder anderen Anwendungen stammen. Eine App kann jedoch nicht auf den Speicher oder die Daten einer anderen App zugreifen, selbst wenn diese auf demselben virtuellen Computer ausgeführt wird.

Apps können Skripts oder Seiten ausführen, die mit unterstützten Webanwendungsframeworks erstellt wurden. App Service konfiguriert die Einstellungen von Webanwendungsframeworks nicht auf eingeschränktere Modi. Beispielsweise werden ASP.NET-Apps, die in App Service ausgeführt werden, als „voll“ vertrauenswürdig statt auf eingeschränkter Vertrauensebene ausgeführt. Webframeworks, einschließlich klassischem ASP und ASP.NET, können prozessinterne COM-Komponenten aufrufen (jedoch keine prozessexternen COM-Komponenten), zum Beispiel ADO (ActiveX Data Objects), die standardmäßig auf dem Windows-Betriebssystem registriert sind.

Apps können beliebigen Code erzeugen und ausführen. Es ist zulässig, dass eine App beispielsweise eine Befehlsshell erzeugt oder ein PowerShell-Skript ausführt. Obwohl beliebiger Code und beliebige Prozesse von einer App erzeugt werden können, sind ausführbare Programme und Skripts jedoch immer durch die Berechtigungen beschränkt, die der übergeordnete Anwendungspool besitzt. Beispielsweise kann eine App ein ausführbares Programm erzeugen, das einen ausgehenden HTTP-Aufruf ausführt. Dieses ausführbare Programm kann jedoch nicht versuchen, die IP-Adresse eines virtuellen Computers von deren NIC loszulösen. Die Durchführung eines ausgehenden Netzwerkaufrufes ist für Code mit geringen Berechtigungen zulässig, der Versuch, die Netzwerkeinstellungen auf einem virtuellen Computer zu konfigurieren erfordert jedoch Administratorberechtigungen.

Diagnoseprotokolle und Ereignisse

Bei Protokollinformationen handelt es sich um einen weiteren Datensatz, auf den einige Apps versuchen, zuzugreifen. Die Typen von Protokollinformationen, die für in App Service ausgeführten Code verfügbar sind, umfassen Diagnose- und Protokollinformationen, die von einer App generiert wurden, und auf welche diese einfach zugreifen kann.

Beispielsweise sind W3C-HTTP-Protokolle, die von einer aktiven App generiert werden, entweder in einem Protokollverzeichnis in der Netzwerkfreigabe, die für die App erstellt wurde, verfügbar oder im Blobspeicher, wenn ein Kunde W3C-Protokollierung in einem Speicher eingerichtet hat. Die zweite Option ermöglicht es Ihnen, große Mengen an Protokollen zu sammeln, ohne die Dateispeicherbeschränkungen der Netzwerkfreigabe zu überschreiten.

Ebenso können Echtzeitdiagnoseinformationen aus .NET-Apps protokolliert werden. Dies ist mit der Nachverfolgungs- und Diagnosestruktur von .NET möglich, wobei die Nachverfolgungsinformationen entweder auf die Netzwerkfreigabe der App oder in einen Blob-Speicherort geschrieben werden können.

Bereiche der Diagnoseprotokollierung und Nachverfolgung, die für Apps nicht verfügbar sind, sind Windows-ETW-Ereignisse und Windows-Ereignisprotokolle (z. B. System-, Anwendungs- und Sicherheitsereignisprotokolle). Da ETW-Nachverfolgungsinformationen potenziell computerweit sichtbar sind (mit den entsprechenden ACLs), sind Lese- und Schreibzugriff auf ETW-Ereignisse blockiert. Entwickler erkennen wahrscheinlich, dass API-Aufrufe für das Schreiben und Lesen von ETW-Ereignissen und allgemeinen Windows-Ereignisprotokollen scheinbar funktionieren. Dies liegt jedoch daran, dass App Service die Aufrufe „fälscht“, sodass sie scheinbar erfolgreich ausgeführt werden. Tatsächlich erhält der Anwendungscode keinen Zugriff auf diese Ereignisdaten.

Registrierungszugriff

Apps verfügen über schreibgeschützten Zugriff auf einen großen Teil der Registrierung des virtuellen Computers (jedoch nicht auf die gesamte), auf dem sie ausgeführt werden. In der Praxis bedeutet das, dass Registrierungsschlüssel, die schreibgeschützten Zugriff auf lokale Benutzergruppen gewähren, für Apps zugänglich sind. Ein Bereich der Registrierung, der aktuell nicht für Lese- oder Schreibzugriff unterstützt wird, ist die Struktur HKEY_CURRENT_USER.

Der Schreibzugriff auf die Registrierung ist blockiert, einschließlich des Zugriffs auf benutzerbezogene Registrierungsschlüssel. Aus Sicht der App sollte in einer Azure-Umgebung nie von Schreibzugriff auf eine Registrierung ausgegangen werden, da Apps über unterschiedliche virtuelle Computer migriert werden können (und dies auch geschieht). Der einzige dauerhaft beschreibbare Speicher, auf den sich eine App stützen kann, ist die Inhaltsverzeichnisstruktur jeder App, die auf UNC-Freigaben von App Service gespeichert wird.

Remotedesktopzugriff

App Service stellt keinen Remotedesktopzugriff auf die VM-Instanzen bereit.

Weitere Informationen

Azure App Service-Sandbox: Aktuelle Informationen zur Ausführungsumgebung von App Service. Diese Seite wird direkt vom App Service-Entwicklungsteam betreut.