Einführung in die App Service-Umgebung v2

  • Artikel

Wichtig

In diesem Artikel wird die App Service-Umgebung v2 beschrieben, die mit isolierten App Service-Plänen verwendet wird. App Service-Umgebung v2 wird am 31. August 2024 eingestellt. Für die App Service-Umgebung steht eine neue Version zur Verfügung. Diese ist benutzerfreundlicher und basiert auf einer leistungsfähigeren Infrastruktur. Weitere Informationen zu dieser neuen Version finden Sie unter Einführung in die App Service-Umgebung. Wenn Sie derzeit App Service-Umgebung v2 verwenden, führen Sie die Schritte in diesem Artikel aus, um zur neuen Version zu migrieren.

Ab dem 29. Januar 2024 können Sie keine neuen Ressourcen für die App Service-Umgebung v2 mehr mit einer der verfügbaren Methoden erstellen, darunter ARM-/Bicep-Vorlagen, Azure Portal, Azure CLI oder REST-API. Sie müssen vor dem 31. August 2024 zur App Service-Umgebung v3 migrieren, um die Löschung von Ressourcen und Datenverlust zu verhindern.

Überblick

Azure App Service-Umgebung v2 ist ein Feature von Azure App Service, das eine vollständig isolierte und dedizierte Umgebung zur sicheren Ausführung von App Service-Apps mit umfangreicher Skalierung bereitstellt. Über diese Funktion können folgende Elemente gehostet werden:

  • Windows-Web-Apps
  • Linux-Web-Apps
  • Docker-Container
  • Functions

Hinweis

Linux-Web-Apps und Docker-Container werden in Azure Government- und Microsoft Azure operated by 21Vianet-Regionen nicht unterstützt.

App Service-Umgebungen (App Service Environments, ASEs) sind ideal geeignet für Anwendungsworkloads mit folgenden Anforderungen:

  • Unterstützung sehr vieler Apps
  • Isolierung und sicherer Netzwerkzugriff
  • Hohe Speicherauslastung

Kunden können mehrere ASEs innerhalb einer einzelnen Azure-Region oder über mehrere Azure-Regionen verteilt einrichten. Durch diese Flexibilität eignen sich ASEs hervorragend für die horizontale Skalierung zustandsloser Anwendungsebenen zur Unterstützung von Workloads mit hohen Anforderungen pro Sekunde (Requests per Second, RPS).

ASEs hosten Anwendungen von nur einem Kunden in einem seiner VNETs. Kunden haben präzise Kontrolle über den eingehenden und ausgehenden Netzwerkdatenverkehr der Anwendung. Anwendungen können schnelle, sichere Verbindungen über VPNs mit lokalen Unternehmensressourcen einrichten.

Dedizierte Umgebung

Eine ASE ist eine dedizierte Umgebung, die ausschließlich zu einem einzelnen Kunden gehört und insgesamt 200 App Service-Planinstanzen hosten kann. Ein einzelner isolierter App Service-Plan einer SKU kann bis zu 100 Instanzen enthalten. Wenn Sie alle Instanzen aus allen App Service-Plänen in dieser ASE addieren, muss die Summe kleiner als oder gleich 200 sein.

Eine ASE besteht aus Front-Ends und Worker. Front-Ends sind für die HTTP/HTTPS-Beendigung und den automatischen Lastenausgleich von App-Anforderungen in einer ASE zuständig. Front-Ends werden automatisch hinzugefügt, wenn die App Service-Pläne in der ASE horizontal hochskaliert werden.

Worker sind Rollen, die Kunden-Apps hosten. Worker sind in drei festen Größen verfügbar:

  • Eine vCPU/3,5 GB RAM
  • Zwei vCPUs/7 GB RAM
  • Vier vCPUs/14 GB RAM

Kunden müssen keine Front-Ends und Worker verwalten. Die gesamte Infrastruktur wird automatisch hinzugefügt, wenn Kunden ihre App Service-Pläne aufskalieren. Wenn App Service-Pläne erstellt oder in einer ASE skaliert werden, wird die erforderliche Infrastruktur nach Bedarf hinzugefügt bzw. entfernt.

Es gibt eine monatliche Pauschalgebühr für eine ASE, mit der die Infrastruktur abgedeckt ist. Dies ändert sich nicht mit der Größe der ASE. Darüber hinaus fallen Kosten pro vCPU-App Service-Plan an. Alle in einer ASE gehosteten Apps befinden sich in der isolierten Preis-SKU. Um Informationen zu den Preisen für eine ASE zu erhalten, lesen Sie die Seite App Service-Preise, und überprüfen Sie die verfügbaren Optionen für ASEs.

Unterstützung für virtuelle Netzwerke

Das ASE-Feature ist eine Bereitstellung von Azure App Service direkt im virtuellen Azure Resource Manager-Netzwerk eines Kunden. Weitere Informationen zu virtuellen Azure-Netzwerken finden Sie unter Virtuelle Azure-Netzwerke – FAQs. Eine ASE befindet sich immer in einem virtuellen Netzwerk, genauer gesagt, in einem Subnetz eines virtuellen Netzwerks. Mithilfe der Sicherheitsfunktionen virtueller Netzwerke können Sie ein- und ausgehende Netzwerkkommunikation für Ihre Apps steuern.

Eine ASE kann entweder für Internetzugriff mit einer öffentlichen IP-Adresse oder für die ausschließliche interne Verwendung mit einer Azure-ILB-Adresse (Internal Load Balancer) eingerichtet werden.

Mithilfe von Netzwerksicherheitsgruppen können Sie die eingehende Netzwerkkommunikation mit dem Subnetz einschränken, das eine ASE enthält. Durch NSGs können Sie Apps hinter Upstreamgeräten und -diensten ausführen, wie WAFs und Netzwerk-SaaS-Anbietern.

Apps müssen häufig auch auf Unternehmensressourcen wie interne Datenbanken und Webdienste zugreifen. Wenn Sie die ASE in einem virtuellen Netzwerk bereitstellen, das über eine VPN-Verbindung mit dem lokalen Netzwerk verfügt, können die Apps in der ASE auf die lokalen Ressourcen zugreifen. Diese Funktion besteht unabhängig davon, ob es sich um ein Site-to-Site-VPN oder ein Azure ExpressRoute-VPN handelt.

Weitere Informationen zur Funktionsweise von ASEs mit virtuellen Netzwerken und lokalen Netzwerken finden Sie unter Überlegungen zu Netzwerken mit einer App Service-Umgebung.

App Service-Umgebung v1

Es gibt drei Versionen der App Service-Umgebung: ASEv1, ASEv2 und ASEv3. Die oben aufgeführten Informationen basieren auf ASEv2. In diesem Abschnitt werden die Unterschiede zwischen ASEv1 und ASEv2 aufgezeigt. Weitere Informationen finden Sie unter Übersicht über die App Service-Umgebung.

In ASEv1 müssen Sie alle Ressourcen manuell verwalten. Dies schließt Front-Ends, Worker und IP-Adressen ein, die für IP-basierte TLS/SSL-Bindungen verwendet werden. Bevor Sie Ihren App Service-Plan aufskalieren können, müssen Sie zunächst den Workerpool aufskalieren, den Sie zum Hosten verwenden möchten.

ASEv1 verwendet ein anderes Preismodell als ASEv2. In ASEv1 bezahlen Sie jede zugewiesene vCPU. Dazu gehören vCPUs für Front-Ends oder Worker, die keine Workloads hosten. In ASEv1 beträgt die maximale Standardskalierungsgröße einer ASE insgesamt 55 Hosts. Dazu gehören Worker und Front-Ends. ASEv1 hat den Vorteil, dass die Bereitstellung in einem klassischen virtuellen Netzwerk sowie in einem virtuellen Resource Manager-Netzwerk möglich ist. Weitere Informationen zu ASEv1 finden Sie unter Einführung in die App Service-Umgebung v1.