Erstellen und Verwenden einer App Service-Umgebung für internen Lastenausgleich

  • Artikel

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, sonst 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 Blatt „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.

Die Azure App Service-Umgebung ist eine Bereitstellung von Azure App Service in einem Subnetz in einem virtuellen Azure-Netzwerk (VNET). Eine App Service-Umgebung (App Service Environment, ASE) kann auf zwei Arten bereitgestellt werden:

  • Mit einer VIP unter einer externen IP-Adresse, die häufig als „externe ASE“ bezeichnet wird
  • Mit einer VIP unter einer internen IP-Adresse, die häufig als „ILB-ASE“ bezeichnet wird, da der interne Endpunkt ein interner Lastenausgleich (ILB) ist.

In diesem Artikel wird veranschaulicht, wie Sie eine ILB-ASE erstellen. Eine Übersicht über die ASE finden Sie unter Einführung in App Service-Umgebungen. Informationen zum Erstellen einer externen ASE finden Sie unter [Erstellen einer externen ASE][MakeExternalASE].

Übersicht

Sie können eine ASE mit einem Endpunkt, auf den über das Internet zugegriffen werden kann, oder einer IP-Adresse in Ihrem VNET bereitstellen. Um die IP-Adresse auf eine VNET-Adresse festzulegen, muss die ASE mit einem ILB bereitgestellt werden. Beim Bereitstellen der ASE mit einem ILB müssen Sie den Namen Ihrer ASE angeben. Der Name Ihrer ASE wird im Domänensuffix für die Apps in Ihrer ASE verwendet. Das Domänensuffix für Ihre ILB-ASE lautet „<ASE-Name>.appserviceenvironment.net“. Apps, die in einer ILB-ASE erstellt werden, werden nicht im öffentlichen DNS abgelegt.

In früheren Versionen der ILB-ASE mussten Sie ein Domänensuffix und ein Standardzertifikat für HTTPS-Verbindungen bereitstellen. Das Domänensuffix wird bei der Erstellung der ILB-ASE nicht mehr erfasst, ebenso wenig wie das Standardzertifikat. Wenn Sie jetzt eine ILB-ASE erstellen, wird das Standardzertifikat von Microsoft bereitgestellt und vom Browser als vertrauenswürdig eingestuft. Sie können weiterhin benutzerdefinierte Domänennamen für Apps in Ihrer ASE sowie Zertifikate für diese benutzerdefinierten Domänennamen festlegen.

Mit einer ILB-ASE können Sie z.B. folgende Aktionen durchführen:

  • Intranetanwendungen sicher in der Cloud hosten, auf die Sie über ein Site-to-Site- oder ExpressRoute-VPN zugreifen
  • Apps mit einem WAF-Gerät schützen
  • Apps in der Cloud hosten, die nicht in öffentlichen DNS-Servern aufgeführt sind
  • Vom Internet isolierte Back-End-Apps erstellen, in die Ihre Front-End-Apps sicher integriert werden können

Deaktivierte Funktionen

Es gibt einige Dinge, die Sie mit einer ILB-ASE nicht machen können:

  • IP-basierte TLS/SSL-Bindung verwenden.
  • Bestimmten Apps IP-Adressen zuweisen
  • Ein Zertifikat mit einer App über das Azure-Portal kaufen und verwenden. Sie können Zertifikate direkt von einer Zertifizierungsstelle beziehen und mit Ihren Apps verwenden. Über das Azure-Portal können diese nicht bezogen werden.

Erstellen einer ILB-ASE

Informationen zum Erstellen einer ILB-ASE finden Sie unter Erstellen einer ASE mit einer Azure Resource Manager-Vorlage.

Hinweis

Der Name der App Service-Umgebung darf nicht mehr als 36 Zeichen umfassen.

Erstellen einer App in einer ILB-ASE

Sie erstellen eine App in einer ILB-ASE auf dieselbe Weise, wie Sie eine App normalerweise in einer ASE erstellen würden.

  1. Wählen Sie im Azure-Portal Ressource erstellen>Web>Web-App aus.

  2. Geben Sie den Namen der App ein.

  3. Wählen Sie das Abonnement aus.

  4. Wählen Sie eine Ressourcengruppe aus, oder erstellen Sie sie.

  5. Wählen Sie Veröffentlichungseinstellungen, Laufzeitstapel und Betriebssystem aus.

  6. Wählen Sie eine vorhandene ILB-ASE als Standort aus.

  7. Wählen Sie einen App Service-Plan aus, oder erstellen Sie einen.

  8. Wenn Sie bereit sind, klicken Sie auf Überprüfen und erstellen und dann auf Erstellen.

Webaufträge, Funktionen und die ILB-ASE

Funktionen und Webaufträge werden auf einer ILB-ASE unterstützt. Damit das Portal jedoch mit ihnen arbeiten kann, benötigen Sie Netzwerkzugriff auf die SCM-Site. Das bedeutet, dass Ihr Browser sich auf einem Host befinden muss, der sich im virtuellen Netzwerk befindet oder mit diesem verbunden ist. Wenn Ihre ILB-ASE über einen Domänennamen verfügt, der nicht auf appserviceenvironment.net endet, müssen Sie das von Ihrer scm-Website verwendete HTTPS-Zertifikat für Ihren Browser als vertrauenswürdig kennzeichnen.

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.

Veröffentlichen mit einer ILB-ASE

Für jede erstellte App sind zwei Endpunkte vorhanden. In einer ILB-ASE befinden sich sowohl <App-Name>.<ILB-ASE-Domäne> als auch <App-Name>.scm.<ILB-ASE-Domäne> .

Über den Namen der SCM-Website gelangen Sie zur Kudu-Konsole, die im Azure-Portal als Erweitertes Portal bezeichnet wird. An der Kudu-Konsole können Sie u.a. die Umgebungsvariablen anzeigen, den Datenträger untersuchen und eine Konsole verwenden. Weitere Informationen hierzu finden Sie unter Kudu-Konsole für Azure App Service.

Internetbasierte CI-Systeme, wie GitHub und Azure DevOps, funktionieren weiterhin mit einer ILB-ASE, wenn der Build-Agent internetfähig ist und sich im selben Netzwerk wie die ILB-ASE befindet. Im Falle von Azure DevOps, wenn der Build-Agent auf dem gleichen VNET wie ILB-ASE erstellt wird (ein anderes Subnetz ist in Ordnung), kann er Code aus Azure DevOps-Git pullen und in der ILB-ASE bereitstellen. Wenn Sie keinen eigenen Build-Agent erstellen möchten, müssen Sie ein CI-System verwenden, das ein Pullmodell wie Dropbox verwendet.

Die Veröffentlichungsendpunkte für die Apps in einer ILB-ASE verwenden die Domäne, mit der die ILB-ASE erstellt wurde. Diese Domäne wird im Veröffentlichungsprofil und auf dem Portalblatt der App angezeigt (unter Übersicht>Zusammenfassung sowie unter Eigenschaften). Wenn Sie über eine ILB-ASE mit dem Domänensuffix <ASE-Name>.appserviceenvironment.net und eine App mit den Namen mytest verfügen, verwenden Sie mytest.<ASE-Name>.appserviceenvironment.net für FTP und mytest.scm.contoso.net für die MSDeploy-Bereitstellung.

Konfigurieren einer ILB-ASE mit einem WAF-Gerät

Sie können ein WAF-Gerät (Web Application Firewall) mit Ihrer ILB-ASE kombinieren, um nur die gewünschten Apps im Internet verfügbar zu machen und den Zugriff auf die übrigen Apps nur über das VNET zu ermöglichen. So können Sie unter anderem sichere mehrstufige Anwendungen erstellen.

Weitere Informationen zum Konfigurieren Ihrer ILB-ASE mit einem WAF-Gerät finden Sie unter Konfigurieren einer Web Application Firewall (WAF) für eine App Service-Umgebung. In diesem Artikel wird die Verwendung eines virtuellen Barracuda-Geräts mit Ihrer ASE erläutert. Eine weitere Möglichkeit besteht darin, Azure Application Gateway zu verwenden. Application Gateway sichert mithilfe der OWASP-Kernregeln alle dahinter platzierten Anwendungen. Weitere Informationen zu Application Gateway finden Sie unter Einführung zur Web Application Firewall (WAF) von Azure.

Vor Mai 2019 erstellte ILB-ASEs

Bei ILB-ASEs, die vor Mai 2019 erstellt wurden, mussten Sie das Domänensuffix während der ASE-Erstellung festlegen. Sie mussten auch ein Standardzertifikat hochladen, das auf diesem Domänensuffix basierte. Darüber hinaus war mit einer älteren ILB-ASE kein einmaliges Anmelden bei der Kudu-Konsole mit Apps in dieser ILB-ASE möglich. Beim Konfigurieren von DNS für eine ältere ILB-ASE müssen Sie den A-Platzhaltereintrag in einer Zone festlegen, die Ihrem Domänensuffix entspricht. Zum Erstellen oder Ändern der ILB-ASE mit benutzerdefiniertem Domänensuffix müssen Sie Azure Resource Manager-Vorlagen und eine API-Version vor 2019 verwenden. Die letzte unterstützte API-Version ist 2018-11-01.

Erste Schritte