Betriebssystemfunktionalität in Azure-App Dienst
In diesem Artikel werden die grundlegenden Betriebssystemfunktionen beschrieben, die für alle Windows-Apps verfügbar sind, die in Azure-App Dienst ausgeführt werden. Diese Funktionalität umfasst Datei-, Netzwerk- und Registrierungszugriff sowie Diagnose Protokolle und Ereignisse.
Hinweis
Linux-Apps in App Service werden in eigenen Containern ausgeführt. Sie haben Stammzugriff auf den Container, aber keinen Zugriff auf das Hostbetriebssystem. 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 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 anderen Kunden. Diese Ebenen sind nur für Entwicklungs- und Testzwecke vorgesehen.
Da App Service eine nahtlose Skalierung zwischen Ebenen unterstützt, wird die für App Service-Apps erzwungene Sicherheitskonfiguration erneut Standard 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.
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.
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-/Patchversionen. Es wird empfohlen, dass Kunden bei Bedarf auf Hauptversionen abzielen.
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 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 Arbeitsrolle 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.
Eine bewährte Methode besteht darin, immer die Umgebungsvariablen %SystemDrive% und %ResourceDrive% anstelle hartcodierter Dateipfade zu verwenden. Der von diesen beiden Umgebungsvariablen zurückgegebene Stammpfad wurde im Laufe der Zeit von d:\ in c:\ verschoben. Ältere Anwendungen sind jedoch hartcodiert mit Dateipfadverweise, um weiterhin funktionsfähig zu d:\ sein, da Der App-Dienst automatisch neu zugeordnet d:\ wird, um auf c:\den Punkt 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, Ihre 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 fehl.
ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk) - Ihre App hat möglicherweise eine langsame Leistung.
Netzwerklaufwerke (UNC-Freigaben)
Einer der einzigartigen Aspekte des App-Diensts, die die Bereitstellung der App und Standard Tenance vereinfachen, besteht darin, dass alle Inhaltsfreigaben in einer Reihe 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 UNC-Freigaben in jedem Rechenzentrum erstellt. Ein Prozentsatz der Benutzerinhalte für alle Kunden in jedem Rechenzentrum wird jeder UNC-Freigabe zugeordnet. Jedes Abonnement eines Kunden verfügt über eine reservierte Verzeichnisstruktur auf 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 der spezifische virtuelle Computer, der für das Hosten einer UNC-Freigabe verantwortlich ist. UNC-Freigaben werden von verschiedenen virtuellen Computern bereitgestellt, da sie während des normalen Verlaufs von Azure-Vorgängen auf- und heruntergezogen 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.
Der faux absolute Pfad ist eine tragbare Methode zum Verweisen auf Ihre eigene App. Es ist nicht spezifisch für jede App oder einen Benutzer. Mithilfe der Verwendung %HOME%\sitekönnen Sie freigegebene Dateien von der App in die 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 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 stehen dem Anwendungscode der App zur Laufzeit für Lese- und Schreibzugriff zur Verfügung. Da die Dateien nicht lokal gespeichert werden, sind 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 sind bei App-Neustarts nicht 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 dient er dem Zweck, temporären Dateispeicher für IIS und Webanwendungsframeworks bereitzustellen.
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 Tarife Free, Shared und Consumption (Azure Functions) beträgt der Grenzwert 500 MB. In der folgenden Tabelle sind weitere Ebenen aufgeführt:
| Tarif | Lokaler Dateispeicher |
|---|---|
| B1/S1/P1 | 11 GB |
| B2/S2/P2 | 15 GB |
| B3/S3/P3 | 58 GB |
| P0v3 | 11 GB |
| P1v2/P1v3/P1mv3/Isolated1/Isolated1v2 | 21 GB |
| P2v2/P2v3/P2mv3/Isolated2/Isolated2v2 | 61 GB |
| P3v2/P3v3/P3mv3/Isolated3/Isolated3v2 | 140 GB |
| Isolated4v2 | 276 GB |
| P4mv3 | 280 GB |
| Isolated5v2 | 552 GB |
| P5mv3 | 560 GB |
| Isolated6v2 | 1.104 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. Beide Arten der Dateiverwendung (zusammen mit anderen) werden im App-Dienst auf 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, low-privileged-Workerprozessidentität ausgeführt, die als Anwendungspoolidentität bezeichnet wird. Anwendungscode nutzt diese Identität für grundlegenden 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
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 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. Sie wird auch nicht zwischen der App und der 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 diese Protokolle verwenden, um eine Verbindung mit Diensten in Azure herzustellen, z. B. durch Einrichten von HTTPS-Verbindungen zu Azure SQL-Datenbank.
Es gibt auch eine eingeschränkte Funktion für Apps, eine lokale Loopbackverbindung einzurichten und eine App auf diesen lokalen Loopbacksocket lauschen zu lassen. Dieses Feature ermöglicht Apps, die im Rahmen ihrer Funktionalität lokale Loopbacksockets überwachen. 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 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 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 Arbeitsspeicherbereich, der dem Arbeitsprozess zugeordnet ist, sowie alle untergeordneten Prozesse, die CGI-Prozesse oder andere Anwendungen speichern 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 Webanwendungsframeworks erstellt wurden. App Service konfiguriert die Einstellungen von Webanwendungsframeworks nicht auf eingeschränktere Modi. Beispielsweise werden ASP.NET Apps, die im App-Dienst ausgeführt werden, voll vertrauenswürdig ausgeführt, im Gegensatz zu einem 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. Webframeworks können keine out-of-process COM-Komponenten 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 Ausfü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 im App-Dienst ausgeführt wird, gehören Diagnose- und Protokollinformationen, die von einer App generiert werden, und können problemlos darauf zugreifen.
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 BLOB-Speicher, wenn Sie die W3C-Protokollierung für den 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 Echtzeit-Diagnose Informationen aus .NET-Apps über die .NET-Ablaufverfolgung und Diagnose-Infrastruktur protokolliert werden. Anschließend können Sie die Ablaufverfolgungsinformationen entweder in die Netzwerkfreigabe der App oder in einen BLOB-Speicherort schreiben.
Bereiche der Diagnose Protokollierung und Ablaufverfolgung, die für Apps nicht verfügbar sind, sind Windows-Ereignisablaufverfolgungsereignisse für Windows (ETW)-Ereignisse und allgemeine Windows-Ereignisprotokolle (z. B. System-, Anwendungs- und Sicherheitsereignisprotokolle). Da ETW-Ablaufverfolgungsinformationen möglicherweise auf einem Computer angezeigt werden können (mit den richtigen Zugriffssteuerungslisten), 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 viele (aber nicht alle) der Registrierung des virtuellen Computers, auf dem 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 die HKEY\_CURRENT\_USER Struktur.
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 auf virtuellen Computern 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
App Service stellt keinen Remotedesktopzugriff auf die VM-Instanzen bereit.
Weitere Informationen
Die aktuellsten Informationen zur Ausführungsumgebung von App Service finden Sie im Azure-App Service-Sandkasten. Das App Service-Entwicklungsteam Standard diese Seite enthält.