Betriebssystemfunktionen in Azure App Service

In diesem Artikel werden die grundlegenden Betriebssystemfunktionen beschrieben, die für alle Windows-Apps verfügbar sind, die in Azure App Service ausgeführt werden. Diese Funktionalität umfasst Datei-, Netzwerk- und Registrierungszugriff sowie Diagnoseprotokolle und Ereignisse.

Hinweis

Linux-Apps in App Service werden in ihren eigenen Containern ausgeführt. Sie haben Stammzugriff auf den Container, aber keinen Zugriff auf das Hostbetriebssystem. Ebenso haben Sie für Apps, die in Windows-Containern ausgeführt werden, administrativen Zugriff auf den Container, aber keinen Zugriff auf das Hostbetriebssystem.

App Service-Planebenen

App Service führt Kunden-Apps in einer mehrinstanzenübergreifenden Hostingumgebung aus.

• In den Ebenen "Frei" und "Freigegeben" bereitgestellte Apps werden in Arbeitsprozessen auf gemeinsam genutzten virtuellen Computern (VMs) ausgeführt.
• Apps, die in den Stufen "Standard" und "Premium" bereitgestellt werden, werden speziell für die Apps ausgeführt, die einem einzelnen Kunden zugeordnet 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 zu anderen Kunden. Diese Tarife sind nur für Entwicklungs- und Testzwecke gedacht.

Da App Service eine nahtlose Skalierung zwischen Ebenen unterstützt, bleibt die für App Service-Apps erzwungene Sicherheitskonfiguration identisch. Diese Konfiguration stellt sicher, dass sich Apps nicht plötzlich anders verhalten und unerwartet fehlschlagen, wenn ein App Service-Plan von einer Ebene zu einer anderen wechselt.

Frameworks für die Entwicklung

App Service-Preisstufen steuern die Menge der Computeressourcen (CPU, Datenträgerspeicher, Arbeitsspeicher und Netzwerkausgang), die für Apps verfügbar sind. Die Breite der framework-Funktionalität, die für Apps verfügbar ist, bleibt jedoch unabhängig von den Skalierungsstufen gleich.

Der App-Dienst unterstützt verschiedene Entwicklungsframeworks, darunter ASP.NET, klassische ASP, Node.js, PHP und Python. Um die Sicherheitskonfiguration zu vereinfachen und zu normalisieren, führen App Service-Apps in der Regel die Entwicklungsframeworks mit ihren Standardeinstellungen aus. Die von der Plattform bereitgestellten Frameworks und Laufzeitkomponenten werden regelmäßig aktualisiert, um Sicherheits- und Complianceanforderungen zu erfüllen. Aus diesem Grund garantieren wir keine spezifischen Neben- oder Patchversionen. Es wird empfohlen, dass Kunden bei Bedarf auf Hauptversionen abzielen.

In den folgenden Abschnitten werden die allgemeinen Arten von Betriebssystemfunktionen zusammengefasst, die für App Service-Apps verfügbar sind.

Zugriff auf Dateien

Es gibt verschiedene Laufwerke innerhalb des App-Diensts, einschließlich lokaler Laufwerke und Netzwerklaufwerke.

Lokale Laufwerke

Im Kern ist App Service ein Dienst, der auf der Azure-Plattform als Dienstinfrastruktur (PaaS) ausgeführt wird. Daher sind die lokalen Laufwerke, die einem virtuellen Computer zugeordnet sind, die gleichen Laufwerkstypen, die für jede In Azure ausgeführte Workerrolle verfügbar sind. Dazu gehören:

• Ein Betriebssystemlaufwerk (%SystemDrive%), dessen Größe von der Größe des virtuellen Computers abhängt.
• Ein Ressourcenlaufwerk (%ResourceDrive%), das der App-Dienst intern verwendet.

Es ist bewährte Praxis, immer die Umgebungsvariablen %SystemDrive% und %ResourceDrive% anstelle von hartcodierten Dateipfaden zu verwenden. Der Stammpfad, der von diesen beiden Umgebungsvariablen zurückgegeben wird, hat sich im Laufe der Zeit von d:\ zu c:\ verschoben. Ältere Anwendungen, die mit Dateipfadverweisen auf d:\ hartcodiert sind, funktionieren jedoch weiterhin, da App Service d:\ automatisch neu zuordnet, um auf c:\ zu verweisen. Wie bereits erwähnt, wird dringend empfohlen, beim Erstellen von Dateipfaden immer die Umgebungsvariablen zu verwenden und Verwechslungen gegenüber Plattformänderungen am Standardstammdateipfad zu vermeiden.

Es ist wichtig, die Datenträgerauslastung zu überwachen, wenn Ihre Anwendung wächst. Das Erreichen des Datenträgerkontingents kann nachteilige Auswirkungen auf Ihre Anwendung haben. Beispiel:

• Die App löst möglicherweise einen Fehler aus, der angibt, dass nicht genügend Speicherplatz auf dem Datenträger vorhanden ist.
• Beim Browsen zur Kudu-Konsole werden möglicherweise Datenträgerfehler angezeigt.
• Die Bereitstellung von Azure DevOps oder Visual Studio schlägt möglicherweise mit ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk) fehl.
• Ihre App hat möglicherweise eine langsame Leistung.

Netzwerklaufwerke (UNC-Freigaben)

Einer der einzigartigen Aspekte des App-Diensts, die die Bereitstellung und Wartung der App vereinfachen, besteht darin, dass alle Inhaltsfreigaben in einer Reihe von UNC-Freigaben (Universal Naming Convention) gespeichert werden. Dieses Modell entspricht dem allgemeinen Muster des Inhaltsspeichers, der von lokalen Webhostingumgebungen verwendet wird, die über mehrere Server mit Lastenausgleich verfügen.

In App Service werden UNC-Freigaben in jedem Rechenzentrum 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 in einer bestimmten UNC-Freigabe in einem Rechenzentrum. Ein Kunde hat möglicherweise mehrere Apps in einem bestimmten Rechenzentrum erstellt, sodass alle Verzeichnisse, die zu einem einzelnen Kundenabonnement gehören, auf derselben UNC-Freigabe erstellt werden.

Aufgrund der Funktionsweise von Azure-Diensten ändert sich die spezifische VM, die die UNC-Freigabe hostet, im Laufe der Zeit. UNC-Freigaben werden von unterschiedlichen VMs eingebunden, da diese während des normalen Verlaufs von Azure-Vorgängen hoch- und heruntergefahren werden. Aus diesem Grund sollten Apps niemals hartcodierte Annahmen machen, dass die Computerinformationen in einem UNC-Dateipfad im Laufe der Zeit stabil bleiben. Stattdessen sollten sie den praktischen pseudoabsoluten Pfad %HOME%\site verwenden, den App Service bereitstellt.

Der pseudoabsolute Pfad ist eine portierbare Methode zum Verweisen auf Ihre eigene App. Es ist nicht spezifisch für jede App oder einen Benutzer. Mit %HOME%\site können Sie freigegebene Dateien zwischen Apps übertragen, ohne für jede Übertragung einen neuen absoluten Pfad konfigurieren zu müssen.

Dateizugriffstypen, die einer App gewährt werden

Das %HOME% Verzeichnis in einer App ist einer Inhaltsfreigabe in Azure Storage zugeordnet, die für diese App reserviert ist. Ihr Preisniveau definiert seine Größe. Es kann Verzeichnisse wie z. B. Verzeichnisse für Inhalte, Fehler- und Diagnoseprotokolle und frühere Versionen der App enthalten, die von der Quellcodeverwaltung erstellt wurden. Diese Verzeichnisse sind zur Laufzeit für Lese- und Schreibzugriff auf den Anwendungscode der App verfügbar. Da die Dateien nicht lokal gespeichert werden, werden sie über App-Neustarts hinweg persistent.

App Service reserviert %SystemDrive%\local auf dem Systemlaufwerk für App-spezifischen, temporären lokalen Speicher. Änderungen an Dateien in diesem Verzeichnis werden nicht über App-Neustarts hinweg persistent. Obwohl eine App vollständigen Lese- und Schreibzugriff auf den eigenen temporären lokalen Speicher hat, ist dieser Speicher nicht für die direkte Verwendung durch den Anwendungscode vorgesehen. Stattdessen soll temporäre Dateispeicher für IIS- und Webanwendungsframeworks bereitgestellt werden.

Der App-Dienst schränkt die Menge des Speichers %SystemDrive%\local für jede App ein, um zu verhindern, dass einzelne Apps übermäßige Mengen lokaler Dateispeicher verbrauchen. Für die Stufen "Kostenlos", "Freigegeben" und "Verbrauch" (Azure Functions) beträgt der Grenzwert 500 MB. In der folgenden Tabelle sind weitere Ebenen aufgeführt:

Tarif	Grenzwert für lokalen Speicher
B1/S1/P1	11 GB
B2/S2/P2	15 GB
B3/S3/P3	58 GB
P0v3/P0v4	11 GB
P1v2/P1v3/P1mv3/P1mv4/Isolated1/Isolated1v2	21 GB
P2v2/P2v3/P2mv3/P2mv4/Isolated2/Isolated2v2	61 GB
P3v2/P3v3/P3mv3/P3mv4/Isolated3/Isolated3v2	140 GB
Isolated4v2	276 GB
P4mv3/P4mv4	280 GB
Isolated5v2	552 GB
P5mv3/P5mv4	560 GB
Isolated6v2	1.104 GB

Das Verzeichnis für temporäre ASP.NET Dateien und das Verzeichnis für komprimierte IIS-Dateien sind zwei Beispiele dafür, wie Der App-Dienst temporären lokalen Speicher verwendet. Das ASP.NET Kompilierungssystem verwendet das %SystemDrive%\local\Temporary ASP.NET Files Verzeichnis als temporären Kompilierungscachespeicherort. IIS verwendet das %SystemDrive%\local\IIS Temporary Compressed Files Verzeichnis zum Speichern der komprimierten Antwortausgabe. Diese beiden Arten der Dateinutzung (zusammen mit anderen) werden in App Service dem temporären lokalen Speicher pro App neu zugeordnet. Durch diese Neuzuordnung wird sichergestellt, dass die Funktionalität erwartungsgemäß fortgesetzt wird.

Jede App in App Service wird als zufällige, eindeutige Workerprozessidentität mit geringen Berechtigungen ausgeführt, die als Anwendungspoolidentität bezeichnet wird. Der Anwendungscode verwendet diese Identität für den einfachen schreibgeschützten Zugriff auf das Betriebssystemlaufwerk. Dieser Zugriff bedeutet, dass Anwendungscode allgemeine Verzeichnisstrukturen auflisten und allgemeine Dateien auf dem Betriebssystemlaufwerk lesen kann. Obwohl diese Zugriffsebene allgemein erscheinen mag, sind dieselben Verzeichnisse und Dateien zugänglich, wenn Sie eine Workerrolle in einem von Azure gehosteten Dienst bereitstellen und den Laufwerkinhalt lesen.

Dateizugriff über mehrere Instanzen hinweg

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

Das temporäre lokale Speicherverzeichnis (%SystemDrive%\local) wird nicht zwischen Instanzen freigegeben. Es wird auch nicht von der App und der zugehörigen Kudu-App gemeinsam genutzt.

Netzwerkzugriff

Anwendungscode kann TCP/IP- und UDP-basierte Protokolle verwenden, um ausgehende Netzwerkverbindungen mit internetverwendlichen Endpunkten herzustellen, die externe Dienste verfügbar machen. Apps können dieselben Protokolle verwenden, um eine Verbindung mit Diensten in Azure herzustellen, z. B. durch Einrichten von HTTPS-Verbindungen mit Azure SQL-Datenbank.

Es gibt außerdem eine eingeschränkte Funktion für Apps, eine lokale Loopback-Verbindung einzurichten und eine App zu haben, die auf diesem lokalen Loopback-Socket lauscht. Mit dieser Funktion können Sie Apps verwenden, die als Teil ihrer Funktionalität auf lokalen Loopback-Sockets lauscht. Jede App verfügt über eine private Loopbackverbindung. Eine App kann nicht auf einen lokalen Loopbacksocket lauschen, den eine andere App eingerichtet hat.

Benannte Rohre werden auch als Mechanismus für die Kommunikation zwischen Prozessen unterstützt, die eine App gemeinsam ausführen. Beispielsweise basiert das IIS FastCGI-Modul auf benannten Rohren, um die einzelnen Prozesse zu koordinieren, die PHP-Seiten ausführen.

Codeausführung, Prozesse und Arbeitsspeicher

Wie bereits erwähnt, werden Apps innerhalb von Arbeitsprozessen mit geringen Rechten ausgeführt, indem sie eine zufällige Anwendungspoolidentität verwenden. Der Anwendungscode hat Zugriff auf den Speicherbereich, der mit dem Arbeitsprozess assoziiert ist, sowie auf alle untergeordneten Prozesse, die von CGI-Prozessen oder anderen Anwendungen erzeugt werden können. Eine App kann jedoch nicht auf den Speicher oder die Daten einer anderen App zugreifen, auch wenn sie sich auf demselben virtuellen Computer befindet.

Apps können Skripts oder Seiten ausführen, die mit unterstützten Webentwicklungsframeworks geschrieben wurden. Der App-Dienst konfiguriert keine Webframeworkeinstellungen für eingeschränkte Modi. Beispielsweise werden ASP.NET Apps, die im App-Dienst ausgeführt werden, mit vollem Vertrauen ausgeführt, anstatt eines eingeschränkteren Vertrauensmodus. Webframeworks, einschließlich klassischer ASP und ASP.NET, können prozessinterne COM-Komponenten (z. B. ActiveX Data Objects) aufrufen, die standardmäßig auf dem Windows-Betriebssystem registriert sind. Web-Frameworks können keine COM-Komponenten außerhalb des Prozesses aufrufen.

Eine App kann beliebigen Code spawnen und ausführen, eine Befehlsshell öffnen oder ein PowerShell-Skript ausführen. Ausführbare Programme und Skripts sind jedoch weiterhin auf die Berechtigungen beschränkt, die dem übergeordneten Anwendungspool gewährt werden. Beispielsweise kann eine App ein ausführbares Programm spawnen, das einen ausgehenden HTTP-Aufruf durchführt, aber dieses ausführbare Programm kann nicht versuchen, die IP-Adresse eines virtuellen Computers von seinem Netzwerkadapter aufzuheben. Das Durchführen eines ausgehenden Netzwerkaufrufs ist für Code mit niedriger Berechtigung zulässig, aber beim Versuch, Netzwerkeinstellungen auf einem virtuellen Computer neu zu konfigurieren, sind Administratorrechte erforderlich.

Diagnoseprotokolle und Ereignisse

Protokollinformationen sind eine weitere Datenmenge, auf die einige Apps zugreifen möchten. Zu den Protokollinformationen, die für Code verfügbar sind, der in App Service ausgeführt wird, gehören Diagnose- und Protokollinformationen, die von einer App generiert werden und auf die eine App problemlos zugreifen kann.

Beispielsweise sind von der App generierte W3C-HTTP-Protokolle verfügbar:

• In einem Protokollverzeichnis am Speicherort der Netzwerkfreigabe, den Sie für die App erstellt haben
• Im Blobspeicher, wenn Sie die W3C-Protokollierung im Speicher einrichten

Mit dieser Option können Apps große Mengen von Protokollen sammeln, ohne die Mit einer Netzwerkfreigabe verbundenen Dateispeichergrenzwerte zu überschreiten.

Ebenso können Echtzeitdiagnoseinformationen aus .NET-Apps über die .NET-Ablaufverfolgungs- und Diagnoseinfrastruktur protokolliert werden. Anschließend können Sie die Ablaufverfolgungsinformationen entweder in die Netzwerkfreigabe der App oder in einen Blob-Speicherort schreiben.

Bereiche der Diagnoseprotokollierung und -ablaufverfolgung, die für Apps nicht verfügbar sind, umfassen ETW-Ereignisse und allgemeine Windows-Ereignisprotokolle (z. B. System-, Anwendungs- und Sicherheitsereignisprotokolle). Da ETW-Ablaufverfolgungsinformationen potenziell auf einem Computer angezeigt werden können, indem die richtigen Zugriffssteuerungslisten verwendet werden, werden Lesezugriff und Schreibzugriff auf ETW-Ereignisse blockiert. API-Aufrufe zum Lesen und Schreiben von ETW-Ereignissen und allgemeinen Windows-Ereignisprotokollen scheinen möglicherweise zu funktionieren, aber in Wirklichkeit hat der Anwendungscode keinen Zugriff auf diese Ereignisdaten.

Registrierungszugriff

Apps haben schreibgeschützten Zugriff auf einen Großteil, jedoch nicht auf alle Registrierungseinträge der VM, auf der sie ausgeführt werden. Dieser Zugriff bedeutet, dass Apps auf Registrierungsschlüssel zugreifen können, die schreibgeschützten Zugriff auf die Gruppe "Lokale Benutzer" ermöglichen. Ein Bereich der Registrierung, der derzeit für den Lese- oder Schreibzugriff nicht unterstützt wird, ist der HKEY_CURRENT_USER Hive.

Schreibzugriff auf die Registrierung wird blockiert, einschließlich des Zugriffs auf benutzerspezifische Registrierungsschlüssel. Aus Sicht der App kann sie sich nicht auf den Schreibzugriff auf die Registrierung in der Azure-Umgebung verlassen, da Apps über virtuelle Computer migriert werden können. Der einzige dauerhafte schreibbare Speicher, von dem eine App abhängig sein kann, ist die Inhaltsverzeichnisstruktur pro App, die auf den App Service UNC-Freigaben gespeichert ist.

Remotedesktopzugriff

Der App-Dienst bietet keinen Remotedesktopzugriff auf die VM-Instanzen.

Verwandte Inhalte

Die aktuellsten Informationen zur Ausführungsumgebung von App Service finden Sie unter Azure App Service-Sandbox. Das App Service-Entwicklungsteam verwaltet diese Seite.