Verwalten einer App Service-Umgebung

Wichtig

In diesem Artikel wird die App Service-Umgebung v2 beschrieben, die mit Plänen vom Typ „App Service (isoliert)“ verwendet wird. App Service-Umgebung v1 und v2 wurden 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 v1 verwenden, führen Sie die Schritte in diesem Artikel aus, um zur neuen Version zu migrieren.

Die Vereinbarung zum Servicelevel (Service Level Agreement, SLA) und Dienstguthaben gelten seit dem 31. August 2024 nicht mehr für Workloads von App Service-Umgebung v1 und v2, da es sich um eingestellte Produkte handelt. Die Außerbetriebnahme der Hardware für App Service-Umgebung v1 und v2 hat begonnen. Dies kann sich auf die Verfügbarkeit und Leistung Ihrer Apps und Daten auswirken.

Sie müssen die Migration zur App Service-Umgebung v3 sofort abschließen. Andernfalls werden Ihre Apps und Ressourcen möglicherweise gelöscht. Es wird versucht, alle verbleibenden App Service-Umgebungen v1 und v2 bestmöglich mithilfe des Features für die direkte Migration automatisch zu migrieren, doch Microsoft garantiert die Anwendungsverfügbarkeit nach der automatischen Migration nicht. Möglicherweise müssen Sie eine manuelle Konfiguration durchführen, um die Migration abzuschließen und Ihre SKU-Auswahl für den App Service-Plan auf Basis Ihrer Anforderungen zu optimieren. Wenn die automatische Migration nicht möglich ist, werden Ihre Ressourcen und zugehörigen App-Daten gelöscht. Sie sollten schnell handeln, um diese Szenarien zu vermeiden.

Wenn Sie mehr Zeit benötigen, können wir Ihnen eine einmalige Karenzzeit von 30 Tagen anbieten, damit Sie Ihre Migration abschließen können. Weitere Informationen auch zum Anfordern dieser Karenzzeit finden Sie in der Übersicht über die Karenzzeit. Navigieren Sie anschließend im Azure-Portal zum Bereich „Migration“ für jede Ihrer App Service-Umgebungen.

Die aktuellsten Informationen zur Einstellung der App Service Environment v1/v2 finden Sie im Update zur Einstellung der App Service Environment v1 und v2.

Eine App Service-Umgebung (ASE) ist eine Bereitstellung des Azure App Service in einem Subnetz in der Azure Virtual Network-Instanz eines Kunden. Eine ASE besteht aus den folgenden Komponenten:

• Front-Ends: Der Ort, an dem HTTP oder HTTPS in einer App Service-Umgebung endet.
• Worker: Die Ressourcen, die Ihre Apps hosten.
• Datenbank: Enthält Informationen, durch die die Umgebung definiert wird.
• Storage: Wird zum Hosten der vom Kunden veröffentlichten Apps verwendet.

Sie können eine ASE mit einer externen oder internen virtuellen IP (VIP) für den App-Zugriff bereitstellen. Eine Bereitstellung mit einer externen VIP wird im Allgemeinen als externe ASE bezeichnet. Eine Bereitstellung mit einer internen VIP wird als ILB-ASE bezeichnet, da ein interner Load Balancer (ILB) verwendet wird. Weitere Informationen zur ILB-ASE finden Sie unter Erstellen und Verwenden einer ILB-ASE.

Erstellen einer App in einer ASE

Um eine App in einer ASE zu erstellen, verwenden Sie denselben Prozess wie bei der normalen Erstellung einer App, jedoch mit einigen kleinen Unterschieden. Beim Erstellen eines neuen App Service-Plans gilt:

• Anstatt einen geografischen Standort auszuwählen, an dem Sie Ihre App bereitstellen, wählen Sie eine ASE als Ihren Standort aus.
• Alle in einer ASE erstellten App Service-Pläne können nur den Tarif „Isoliert“ aufweisen.

Wenn Sie über keine ASE verfügen, können Sie eine erstellen. Folgen Sie hierzu den Anweisungen in Erstellen einer App Service-Umgebung.

So erstellen Sie eine App in einer ASE

1. Wählen Sie Ressource erstellen>Web + Mobil>Web-Apps aus.

2. Geben Sie einen Namen für die App ein. Wenn Sie bereits einen App Service-Plan in einer ASE ausgewählt haben, entspricht der Domänenname der App dem Domänenname der ASE:

   

3. Wählen Sie ein Abonnement aus.

4. Geben Sie einen Namen für eine neue Ressourcengruppe ein, oder wählen Sie Vorhandene verwenden aus, und wählen Sie in der Dropdownliste eine Ressourcengruppe aus.

5. Wählen Sie Ihr Betriebssystem aus.

6. Wählen Sie einen in Ihrer ASE vorhandenen App Service-Plan aus, oder erstellen Sie mit den folgenden Schritten einen neuen:

   a. Wählen Sie im Azure-Portal im Menü auf der linken Seite die Option Ressource erstellen > Web-App aus.

   b. Wählen Sie das Abonnement aus.

   c. Wählen Sie die Ressourcengruppe aus bzw. erstellen Sie sie.

   d. Geben Sie den Namen Ihrer Web-App ein.

   e. Wählen Sie Code oder DockerContainer aus.

   f. Wählen Sie einen Runtimestapel aus.

   g. Wählen Sie zwischen Linux und Windows aus.

   h. Wählen Sie Ihre ASE in der Dropdownliste Region aus.

   i. Wählen Sie einen neuen App Service-Plan aus, oder erstellen Sie ihn. Wählen Sie beim Erstellen eines neuen App Service-Plans die entsprechende SKU-Größe Isoliert aus.

   

   Hinweis

   Linux-Apps und Windows-Apps können sich nicht im selben App Service-Plan befinden, jedoch in derselben App Service-Umgebung.

7. Wählen Sie Bewerten + erstellen aus, stellen Sie sicher, dass die Informationen richtig sind, und wählen Sie dann Erstellen aus.

Skalieren

Jede App Service-App wird in einem App Service-Plan ausgeführt. App Service-Umgebungen enthalten App Service-Pläne, und App Service-Pläne enthalten Apps. Wenn Sie eine App skalieren, skalieren Sie auch den App Service-Plan und damit alle Apps in diesem Plan.

Wenn Sie einen App Service-Plan skalieren, wird die erforderliche Infrastruktur automatisch hinzugefügt. Bei der Skalierung von Vorgängen kommt es zu einer Zeitverzögerung, während die Infrastruktur hinzugefügt wird. Wenn Sie mehrere Skalierungsvorgänge nacheinander durchführen, wird die erste Skalierungsanforderung für die Infrastruktur verarbeitet, und die anderen werden in die Warteschlange eingereiht. Nachdem der erste Skalierungsvorgang abgeschlossen ist, werden die anderen Infrastrukturanforderungen zusammen ausgeführt. Und nach dem Hinzufügen der Infrastruktur werden die App Service-Pläne entsprechend zugewiesen. Auch die Erstellung eines neuen App Service-Plans selbst ist ein Skalierungsvorgang, weil zusätzliche Hardware angefordert wird. Ein Skalierungsvorgang dauert in der Regel 30–60 Minuten, bis er abgeschlossen ist. Upgrades sind auch Vorgänge, die die Skalierung während der Bearbeitung blockieren.

Bei einer mehrinstanzenfähigen App Service-Instanz erfolgt die Skalierung unmittelbar, da sofort ein Ressourcenpool für die Unterstützung verfügbar ist. In einer ASE gibt es keinen solchen Puffer. Die Ressourcen werden nach Bedarf zugeordnet.

In einer ASE können Sie einen App Service-Plan auf bis zu 100 Instanzen zentral hochskalieren. Eine ASE kann übergreifend für alle App Service-Pläne in dieser ASE eine Gesamtmenge von bis zu 201 Instanzen enthalten.

IP-Adressen

App Service kann eine dedizierte IP-Adresse an eine App vergeben. Diese Funktion ist nach dem Konfigurieren einer IP-basiertem TLS/SSL-Bindung verfügbar, wie unter Binden eines vorhandenen benutzerdefinierten TLS/SSL-Zertifikats an Azure App Service beschrieben. In einer ILB-ASE können Sie keine weiteren IP-Adressen hinzufügen, die für die IP-basierte TLS/SSL-Bindung verwendet werden sollen.

Bei einer externen ASE können Sie eine IP-basierte TLS/SSL-Bindung für Ihre App genauso wie für den mehrinstanzenfähigen App Service konfigurieren. In der ASE ist immer eine freie Adresse vorhanden (bis zu 30 IP-Adressen). Bei jeder Verwendung einer IP-Adresse wird eine weitere hinzugefügt, sodass immer sofort eine Adresse zur Verfügung steht. Bei der Vergabe einer weiteren IP-Adresse ist eine zeitliche Verzögerung erforderlich. Diese Verzögerung verhindert das Hinzufügen von IP-Adressen in schneller Abfolge.

Front-End-Skalierung

Beim Aufskalieren Ihrer App Service-Pläne werden die Worker zur Unterstützung der App Service-Pläne automatisch hinzugefügt. Jede ASE wird mit zwei Front-Ends erstellt. Die Front-Ends werden mit einer Rate von einem Front-End pro jeder Gruppe von 15 App Service-Planinstanzen automatisch erweitert. Wenn Sie beispielsweise drei App Service-Pläne mit jeweils fünf Instanzen verwenden, verfügen Sie insgesamt über 15 Instanzen und drei Front-Ends. Wenn Sie auf insgesamt 30 Instanzen skalieren, haben Sie vier Front-Ends. Dieses Muster wird bei der Erweiterung fortgesetzt.

Die standardmäßig zugeordnete Anzahl von Front-Ends ist gut für mittlere Auslastungen geeignet. Sie können das Verhältnis bis hin zu einem Front-End für je fünf Instanzen verringern. Darüber hinaus können Sie auch die Größe der Front-Ends ändern. Standardmäßig sind sie vom Typ „Einzelkern“. Im Azure-Portal können Sie ihre Größe stattdessen auf zwei oder vier Kerne ändern.

Für die Änderung des Verhältnisses oder der Größen von Front-Ends fällt eine Gebühr an. Weitere Informationen finden Sie unter Azure App Service – Preise. Wenn Sie die Auslastungskapazität Ihrer ASE verbessern möchten, erzielen Sie ein besseres Ergebnis, indem Sie zuerst auf Front-Ends mit zwei Kernen skalieren, bevor Sie das Skalierungsverhältnis anpassen. Das Ändern der Kerngröße Ihrer Front-Ends führt zu einem Upgrade Ihrer ASE und sollte außerhalb der regulären Geschäftszeiten durchgeführt werden.

Front-End-Ressourcen sind die HTTP/HTTPS-Endpunkte der ASE. Mit der standardmäßigen Front-End-Konfiguration beträgt der Speicherverbrauch pro Front-End konstant etwa 60 %. Der Hauptgrund für die Skalierung Ihrer Front-Ends ist die CPU-Auslastung, die vorrangig auf HTTPS-Datenverkehr basiert.

App-Zugriff

In einer externen ASE lautet das Domänensuffix für die App-Erstellung .<asename>.p.azurewebsites.net. Wenn Ihre ASE den Namen external-ase hat und Sie in dieser ASE eine App mit dem Namen contoso hosten, erreichen Sie sie über diese URLs:

• contoso.external-ase.p.azurewebsites.net
• contoso.scm.external-ase.p.azurewebsites.net

Informationen zum Erstellen einer externen ASE finden Sie unter Erstellen einer App Service-Umgebung.

In einer ILB-ASE lautet das Domänensuffix für die App-Erstellung .<asename>.appserviceenvironment.net. Wenn Ihre ASE den Namen ilb-ase hat und Sie in dieser ASE eine App mit dem Namen contoso hosten, erreichen Sie sie über diese URLs:

• contoso.ilb-ase.appserviceenvironment.net
• contoso.scm.ilb-ase.appserviceenvironment.net

Informationen zum Erstellen einer ILB-ASE finden Sie unter Erstellen und Verwenden einer ILB-ASE.

Die SCM-URL wird verwendet, um auf die Kudu-Konsole zuzugreifen oder Ihre App per Web Deploy zu veröffentlichen. Die Kudu-Konsole bietet eine Webbenutzeroberfläche für das Debuggen, Hochladen und Bearbeiten von Dateien und vieles mehr.

DNS-Konfiguration

Wenn Sie eine externe ASE verwenden, werden in ihrer ASE erstellte Apps bei Azure DNS registriert. Damit Ihre Apps öffentlich verfügbar sind, sind keine zusätzlichen Schritte in einer externen ASE erforderlich. In einer ILB-ASE müssen Sie Ihr eigenes DNS verwalten. Sie können dies entweder in Ihrem eigenen DNS-Server oder mit privaten Azure DNS-Zonen erzielen.

So konfigurieren Sie DNS in Ihrem eigenen Server mit Ihrer ILB-ASE

1. Erstellen Sie eine Zone für „<ASE-Name>.appserviceenvironment.net“.
2. Erstellen Sie einen A-Eintrag in dieser Zone, der * auf die ILB-IP-Adresse verweist.
3. Erstellen Sie einen A-Eintrag in dieser Zone, der @ auf die ILB-IP-Adresse verweist.
4. Erstellen Sie eine Zone namens „scm“ in „<ASE-Name>.appserviceenvironment.net“.
5. Erstellen Sie einen A-Eintrag in der Zone „scm“, der * auf die ILB-IP-Adresse verweist.

So konfigurieren Sie DNS in privaten Azure DNS-Zonen

1. Erstellen Sie eine private Azure DNS-Zone namens „<ASE-Name>.appserviceenvironment.net“.
2. Erstellen Sie einen A-Eintrag in dieser Zone, der * auf die ILB-IP-Adresse verweist.
3. Erstellen Sie einen A-Eintrag in dieser Zone, der @ auf die ILB-IP-Adresse verweist.
4. Erstellen Sie einen A-Eintrag in dieser Zone, der *.scm auf die ILB-IP-Adresse verweist.

Die DNS-Einstellungen für Ihr ASE-Standarddomänensuffix schränken Ihre Apps nicht dahingehend ein, dass sie nur über diese Namen zugänglich sind. Sie können einen benutzerdefinierten Domänennamen ohne jegliche Validierung für Ihre Apps in einer ILB-ASE festlegen. Wenn Sie dann eine Zone namens contoso.net erstellen möchten, können Sie dies tun und die Zone auf die ILB-IP-Adresse verweisen lassen. Der benutzerdefinierte Domänenname funktioniert für App-Anforderungen, aber nicht für die SCM-Site. Die SCM-Site ist nur unter <appname>.scm.<asename>.appserviceenvironment.net verfügbar.

Die Zone namens .<asename>.appserviceenvironment.net ist global eindeutig. Vor Mai 2019 konnten Kunden das Domänensuffix der ILB-ASE angeben. Wenn Sie .contoso.com als Domänensuffix verwenden wollten, konnten Sie dies tun, wobei dies dann die SCM-Site einschloss. Dieses Modell ging mit Herausforderungen einher. Dazu zählten u. a. das Verwalten des TLS/SSL-Standardzertifikats, fehlendes einmaliges Anmelden (Single Sign-On) bei der SCM-Site und die Anforderung, ein Platzhalterzertifikat zu verwenden. Der Upgradeprozess für das ILB-ASE-Standardzertifikat war außerdem führte außerdem zu Unterbrechungen und Neustarts von Anwendungen. Um diese Probleme zu beheben, wurde das ILB-ASE-Verhalten dahingehend geändert, dass ein Domänensuffix, das auf dem Namen der ASE basiert, zusammen mit einem Suffix, das Microsoft gehört, verwendet wird. Die Änderung des ILB-ASE-Verhaltens wirkt sich nur auf ILB-ASEs aus, die nach Mai 2019 erstellt wurden. Davor vorhandene ILB-ASEs müssen weiterhin das Standardzertifikat der ASE und seine DNS-Konfiguration verwalten. Wenn Ihr ILB ASE V2 nach Mai 2019 erstellt wurde, müssen Sie das ILB-Standardzertifikat nicht verwalten, da es von Microsoft verwaltet wird.

Veröffentlichung

Wie bei dem mehrinstanzenfähigen App Service können Sie in einer ASE mithilfe dieser Methoden veröffentlichen:

• Webbereitstellung
• FTP
• Continuous Integration (CI)
• Drag and Drop in der Kudu-Konsole
• Eine IDE wie Visual Studio, Eclipse oder IntelliJ IDEA

Mit einer externen ASE funktionieren diese Veröffentlichungsoptionen alle gleich. Weitere Informationen finden Sie unter Bereitstellen in Azure App Service.

In einer ILB-ASE sind die Veröffentlichungsendpunkte nur über die ILB verfügbar. Die ILB liegt in einer privaten IP-Adresse im ASE-Subnetz im virtuellen Netzwerk. Wenn Sie keinen Netzwerkzugriff auf die ILB haben, können Sie in der betreffenden ASE keine Apps veröffentlichen. Wie in Erstellen und Verwenden einer ILB-ASE erwähnt, müssen Sie für die Apps im System ein DNS konfigurieren. Diese Anforderung beinhaltet den SCM-Endpunkt. Wenn die Endpunkte nicht ordnungsgemäß definiert sind, ist keine Veröffentlichung möglich. Darüber hinaus müssen Ihre IDEs über Netzwerkzugriff auf den ILB verfügen, um direkt an ihn veröffentlichen zu können.

Ohne zusätzliche Änderungen lassen sich internetbasierte CI-Systeme wie GitHub oder Azure DevOps nicht standardmäßig mit einer ILB-ASE verwenden, da der Veröffentlichungsendpunkt nicht über das Internet erreichbar ist. Sie können die Veröffentlichung in einer ILB-ASE über Azure DevOps ermöglichen, indem Sie in dem virtuellen Netzwerk, das die ILB-ASE enthält, einen selbstgehosteten Release-Agent installieren. Alternativ können Sie auch ein CI-System wie Dropbox verwenden, das ein Pullmodell verwendet.

Die Veröffentlichungsendpunkte für die Apps in einer ILB-ASE verwenden die Domäne, mit der die ILB-ASE erstellt wurde. Dies wird im Veröffentlichungsprofil und im Portalbereich der App angezeigt (in Übersicht>Zusammenfassung sowie in den Eigenschaften).

Storage

Eine ASE verfügt für alle Apps in der ASE über Speicher mit einer Größe von 1 TB. Ein App Service-Plan in der SKU mit dem Tarif „Isoliert“ verfügt über ein Limit von 250 GB. In einer ASE werden 250 GB Speicherplatz pro App Service-Plan bis zu einem Limit von 1 TB hinzugefügt. Sie können mehr App Service-Pläne als nur vier haben, aber es wird kein über den Grenzwert von 1 TB hinausgehender Speicherplatz hinzugefügt.

Überwachung

Als Kund*in sollten Sie die App Service-Pläne und die einzelnen ausgeführten Apps überwachen und entsprechende Maßnahmen ergreifen. Bei der App Service-Umgebung v2 sollten Sie auch auf die Metriken rund um die Plattforminfrastruktur achten. Diese Metriken bieten Ihnen Einblicke in die Funktionsweise der Plattforminfrastruktur und der Front-End-Server (multiRole), und Sie können Maßnahmen ergreifen, wenn diese stark ausgelastet sind und Sie keinen maximalen Durchsatz erzielen.

Über das Azure-Portal und die CLI können Sie das Skalierungsverhältnis Ihrer Front-End-Server so konfigurieren, dass zwischen 5 und 15 App Service-Planinstanzen pro Front-End-Server (Standardeinstellung: 15) verwendet werden. Ein App Service-Umgebung verfügt immer über mindestens zwei Front-End-Server. Sie können auch die Größe der Front-End-Server erhöhen.

Der Metrikbereich, der zum Überwachen der Plattforminfrastruktur verwendet wird, wird als bezeichnet Microsoft.Web/hostingEnvironments/multiRolePools.

Es wird ein Bereich namens Microsoft.Web/hostingEnvironments/workerPools angezeigt. Die hier genannten Metriken gelten nur für App Service-Umgebung v1.

Protokollierung

Sie können Ihre ASE in Azure Monitor integrieren, um Protokolle zur ASE an Azure Storage, Azure Event Hubs oder Log Analytics zu senden. Diese Elemente werden heute protokolliert:

Situation	`Message`
ASE ist fehlerhaft	Die angegebene ASE ist aufgrund einer ungültigen VNET-Konfiguration fehlerhaft. Die ASE wird angehalten, falls der Fehlerzustand weiter besteht. Stellen Sie sicher, dass die hier definierten Richtlinien befolgt werden: Überlegungen zum Netzwerkbetrieb für eine App Service-Umgebung.
Speicherplatz im ASE-Subnetz ist nahezu erschöpft	Die angegebene ASE befindet sich in einem Subnetz, dessen Speicherplatz nahezu erschöpft ist. Es sind {0} verbleibende Adressen vorhanden. Wenn diese Adressen erschöpft sind, kann die ASE nicht mehr skaliert werden.
ASE nähert sich dem Limit für die Höchstmenge der Instanzen	Für die angegebene ASE wird in Kürze das Limit für die Höchstmenge der Instanzen erreicht. Derzeit sind {0} App Service-Planinstanzen bei einer maximalen Anzahl von 201 Instanzen vorhanden.
ASE kann eine Abhängigkeit nicht erreichen	Die angegebene ASE kann {0} nicht erreichen. Stellen Sie sicher, dass die hier definierten Richtlinien befolgt werden: Überlegungen zum Netzwerkbetrieb für eine App Service-Umgebung.
ASE wurde angehalten	Die angegebene ASE wurde angehalten. Der Grund für das Anhalten der ASE kann ein Kontoausfall oder eine ungültige Konfiguration des virtuellen Netzwerks sein. Beseitigen Sie die Grundursache, und setzen Sie die Ausführung der ASE fort, damit die Bereitstellung von Datenverkehr erfolgen kann.
ASE-Upgrade wurde gestartet	Ein Plattformupgrade für die angegebene ASE wurde gestartet. Es ist mit Verzögerungen bei den Skalierungsvorgängen zu rechnen.
ASE-Upgrade wurde abgeschlossen	Ein Plattformupgrade für die angegebene ASE wurde abgeschlossen.
Skalierungsvorgänge wurden gestartet	Für einen App Service-Plan ({0}) wurde die Skalierung gestartet. Gewünschter Status: {1} I{2}-Worker.
Skalierungsvorgänge wurden abgeschlossen	Die Skalierung eines App Service-Plans ({0}) wurde abgeschlossen. Aktueller Status: {1} I{2}-Worker.
Für Skalierungsvorgänge sind Fehler aufgetreten	Bei der Skalierung eines App Service-Plans ({0}) ist ein Fehler aufgetreten. Aktueller Status: {1} I{2}-Worker.

Aktivieren Sie die Protokollierung für Ihre ASE wie folgt:

1. Wechseln Sie im Portal zu Diagnoseeinstellungen.
2. Klicken Sie auf Diagnoseeinstellung hinzufügen.
3. Geben Sie einen Namen für die Protokollintegration an.
4. Wählen Sie die gewünschten Protokollziele aus, und konfigurieren Sie sie.
5. Wählen Sie AppServiceEnvironmentPlatformLogs aus.

Bei der Integration mit Log Analytics können Sie die Protokolle anzeigen, indem Sie im ASE-Portal die Option Protokolle auswählen und eine Abfrage für AppServiceEnvironmentPlatformLogs erstellen. Protokolle werden nur ausgegeben, wenn Ihre ASE über ein Ereignis verfügt, das diese auslöst. Wenn Ihre ASE nicht über ein derartiges Ereignis verfügt, stehen keine Protokolle zur Verfügung. Um sich schnell ein Beispiel für Protokolle in Ihrem Log Analytics-Arbeitsbereich anzusehen, führen Sie einen Skalierungsvorgang mit einem der App Service-Pläne in ihrer ASE aus. Anschließend können Sie eine Abfrage an AppServiceEnvironmentPlatformLogs- ausführen, um diese Protokolle anzuzeigen.

Erstellen einer Warnung

Anleitungen zum Erstellen einer Warnung für Ihre Protokolle befolgen Sie die Anleitungen unter Erstellen, Anzeigen und Verwalten von Protokollwarnungen mithilfe von Azure Monitor. Kurz gesagt:

• Öffnen Sie die Seite „Warnungen“ in Ihrem ASE-Portal.
• Wählen Sie Neue Warnungsregel aus.
• Wählen Sie Ihre Ressource aus, die Ihr Log Analytics-Arbeitsbereich sein soll.
• Legen Sie Ihre Bedingung mit einer benutzerdefinierten Protokollsuche so fest, dass eine Abfrage wie „AppServiceEnvironmentPlatformLogs | wenn ResultDescription „Skalierung hat begonnen“ enthält“, oder was Sie sonst möchten. Legen Sie den Schwellenwert entsprechend fest.
• Fügen Sie nach Wunsch eine Aktionsgruppe hinzu, oder erstellen Sie eine. Die Aktionsgruppe ist der Ort, an dem Sie die Reaktion auf die Warnung definieren, z. B. das Senden einer E-Mail oder SMS.
• Benennen Sie Ihrer Warnung, und speichern Sie sie.

Upgradeeinstellung

Bei Verwendung von mehreren ASEs kann es sein, dass einige ASEs vor anderen ASEs aktualisiert werden sollen. Dieses Verhalten kann in Ihrem ASE-Portal aktiviert werden. Unter Konfiguration können Sie die Option für die Aktualisierungseinstellung festlegen. Es gibt drei mögliche Werte:

• Keine: Azure führt das Upgrade Ihrer ASE in keinem bestimmten Batch durch. Dies ist der Standardwert.
• Early: Ihre ASE wird in der ersten Hälfte der App Service-Upgrades aktualisiert.
• Late: Ihre ASE wird in der zweiten Hälfte der App Service-Upgrades aktualisiert.

Wählen Sie den gewünschten Wert und dann Speichern aus. Der Standardwert aller Azure App Service-Umgebungen ist Keine.

Die Verwendung der Funktion upgradePreferences ist am sinnvollsten, wenn Sie mehrere ASEs besitzen, weil Ihre als „Early“ gekennzeichneten ASEs vor den mit „Late“ gekennzeichneten ASEs aktualisiert werden. Bei Verwendung von mehreren ASEs sollten Sie für Ihre Entwicklungs- und Test-ASEs die Option „Early“ und für Ihre Produktions-ASEs die Option „Late“ festlegen.

Preise

Die Preis-SKU Isoliert ist nur für die Verwendung mit ASEs gedacht. Alle App Service-Pläne, die in einer ASE gehostet werden, befinden sich in der Preis-SKU „Isoliert“. Die Gebühren für den Tarif „Isoliert“ für App Service-Pläne können sich nach Region unterscheiden.

Zusätzlich zum Preis Ihrer App Service-Pläne fällt eine Pauschalgebühr für die eigentliche ASE an. Diese Pauschalgebühr richtet sich nicht nach der Größe Ihrer ASE. Sie fällt für die ASE-Infrastruktur mit der Standardskalierungsrate mit einem zusätzlichen Front-End für jeweils 15 Instanzen des App Service-Plans an.

Wenn die Standardskalierung von einem Front-End für jeweils 15 Instanzen des App Service-Plans nicht schnell genug ist, können Sie das Verhältnis, nach dem Front-Ends hinzugefügt werden, oder die Größe der Front-Ends anpassen. Wenn Sie das Verhältnis oder die Größe anpassen, bezahlen Sie für die Front-End-Kerne, die standardmäßig nicht hinzugefügt werden würden.

Wenn Sie z.B. das Skalierungsverhältnis auf den Wert 10 anpassen, wird für je zehn Instanzen in Ihren App Service-Plänen ein Front-End hinzugefügt. Die Pauschalgebühr deckt ein Skalierungsverhältnis von einem Front-End pro 15 Instanzen ab. Mit einem Skalierungsverhältnis von 10 bezahlen Sie für das dritte Front-End, das für die 10 Instanzen des App Service-Plans hinzugefügt wird, eine Gebühr. Sie müssen nicht dafür bezahlen, wenn Sie 15 Instanzen erreichen, da es in diesem Fall automatisch hinzugefügt wurde.

Wenn Sie die Größe der Front-Ends in 2 Kerne ändern, aber das Verhältnis nicht anpassen, bezahlen Sie für die zusätzlichen Kerne. Eine ASE wird mit zwei Front-Ends erstellt. Sie würden also selbst unterhalb des Schwellenwerts für die automatische Skalierung zwei zusätzliche Kerne bezahlen, wenn Sie die Größe auf 2-Kern-Front-Ends erhöhen.

Weitere Informationen finden Sie unter Azure App Service – Preise.

Löschen einer ASE

So löschen Sie eine ASE

1. Wählen Sie Löschen am Anfang des Bereichs App Service-Umgebung aus.

2. Geben Sie den Namen Ihrer ASE ein, um zu bestätigen, dass Sie sie löschen möchten. Beim Löschen einer ASE wird auch ihr gesamter Inhalt gelöscht.

   

3. Klicken Sie auf OK.

ASE CLI

Es gibt Befehlszeilenfunktionen, die auf eine ASE angewendet werden können. Die Azure CLI-Befehle sind unten aufgeführt.

C:\>az appservice ase --help

Group
    az appservice ase : Manage App Service Environments v2.
        This command group is in preview. It may be changed/removed in a future release.
Commands:
    create         : Create app service environment.
    delete         : Delete app service environment.
    list           : List app service environments.
    list-addresses : List VIPs associated with an app service environment.
    list-plans     : List app service plans associated with an app service environment.
    show           : Show details of an app service environment.
    update         : Update app service environment.

For more specific examples, use: az find "az appservice ase"