Anwendungsgateway – Hosten mehrerer Websites

Das Hosten mehrerer Websites ermöglicht es Ihnen, mithilfe von öffentlichen Listenern mehrere Webanwendungen am selben Port eines Anwendungsgateways zu konfigurieren. Sie können eine effizientere Topologie für Ihre Bereitstellungen konfigurieren, indem Sie einem Anwendungsgateway bis zu 100 Websites hinzufügen. Jede Website kann an ihren eigenen Back-End-Pool weitergeleitet werden. Beispielsweise können die drei Domänen „contoso.com“, „fabrikam.com“ und „adatum.com“ auf die IP-Adresse des Anwendungsgateways verweisen. Sie erstellen drei Listener vom Typ „Mehrere Websites“ und konfigurieren jeden Listener für den jeweiligen Port und die jeweilige Protokolleinstellung.

Sie können auch Platzhalterhostnamen in einem Listener für mehrere Standorte und bis zu fünf Hostnamen pro Listener definieren. Weitere Informationen finden Sie unter Wildcard-Hostnamen in Listenern.

Wichtig

Regeln werden in der Reihenfolge verarbeitet, in der sie im Portal für die v1-SKU aufgeführt werden. Verwenden Sie für die v2-SKU die Regelpriorität, um die Verarbeitungsreihenfolge festzulegen. Es wird dringend empfohlen, vor dem Konfigurieren eines einfachen Listeners zuerst Listener für mehrere Standorte zu konfigurieren. So wird sichergestellt, dass der Datenverkehr an das richtige Back-End geleitet wird. Wenn ein einfacher Listener an erster Stelle aufgeführt ist und mit einer eingehenden Anfrage übereinstimmt, wird sie von diesem Listener verarbeitet.

Anforderungen für http://contoso.com werden an „ContosoServerPool“ und Anforderungen für http://fabrikam.com an „FabrikamServerPool“ weitergeleitet.

Analog dazu können Sie mehrere Unterdomänen derselben übergeordneten Domäne in derselben Application Gateway-Bereitstellung hosten. Beispielsweise können Sie http://blog.contoso.com und http://app.contoso.com in einer einzelnen Application Gateway-Bereitstellung hosten.

Anfordern eines Auswertungsauftrags für Routingregeln

Wenn Sie mehrere Listener verwenden, um sicherzustellen, dass der Client-Datenverkehr an das richtige Backend weitergeleitet wird, ist es wichtig, dass die Regeln für die Weiterleitung von Anforderungen in der richtigen Reihenfolge vorhanden sind. Wenn Sie beispielsweise 2 Listener mit zugehörigen Hostnamen *.contoso.com und shop.contoso.com haben, muss der Listener mit dem shop.contoso.com-Hostnamen vor dem Listener mit *.contoso.com bearbeitet werden. Wenn der Listener mit dem Hostnamen *.contoso.com zuerst bearbeitet wird, wird kein Clientdatenverkehr von dem spezifischeren shop.contoso.com-Listener empfangen.

Die Reihenfolge der Regeln kann festgelegt werden, indem den Regeln für die Weiterleitung von Anforderungen, die den Listenern zugeordnet sind, ein Wert für das Feld Priorität zugewiesen wird. Sie können eine Integerwert von 1 bis 20000 angeben. Dabei ist 1 die höchste Priorität und 20000 die niedrigste Priorität. Wenn eingehender Clientdatenverkehr mit mehreren Listenern übereinstimmt, wird die Anforderungsroutingregel mit der höchsten Priorität für die Anforderung verwendet. Jede Anforderungsroutingregel muss einen eindeutigen Prioritätswert haben.

Das Prioritätsfeld wirkt sich nur auf die Reihenfolge der Auswertung einer Anforderungsroutingregel aus. Dadurch wird die Reihenfolge der Auswertung von pfadbasierten Regeln innerhalb einer PathBasedRouting Anforderungsweiterleitungsregel nicht geändert.

Hinweis

Wenn Sie die Regelpriorität verwenden möchten, müssen Sie für alle vorhandenen Anforderungsroutingregeln Feldwerte mit Regelpriorität angeben. Sobald das Regelprioritätsfeld verwendet wird, benötigt jede neu erstellte Routingregel auch einen Regelprioritäts-Feldwert als Teil der Konfiguration.

Wichtig

Ab API-Version 2021-08-01 ist das Regelprioritätsfeld ein Pflichtfeld in den Anforderungsroutingregeln. Die Feldwerte für die Regelpriorität bestehender Anforderungsroutingregeln, die auf der aktuellen Reihenfolge der Bewertung als Teil des ersten PUT-Aufrufs basieren, werden automatisch ausgefüllt, wenn Konfigurationsaktualisierungen mit API-Version 2021-08-01 und höher, Portal, Azure PowerShell und Azure CLI angewendet werden. Zukünftige Updates von Anforderungsroutingregeln müssten über das Regelprioritätsfeld verfügen, das als Teil der Konfiguration bereitgestellt wird.

Wildcard-Hostnamen für Listener

Application Gateway ermöglicht mithilfe von HTTP(S)-Listenern für mehrere Standorte das hostbasierte Routing. So können Sie nun im Hostnamen Platzhalterzeichen wie Sternchen (*) und Fragezeichen (?) und bis zu fünf Hostnamen pro HTTP(S)-Listener für mehrere Standorte verwenden. Beispielsweise *.contoso.com.

Durch ein Platzhalterzeichen im Hostnamen können Sie mehrere Hostnamen einem einzigen Listener zuordnen. So kann *.contoso.com beispielsweise mit ecom.contoso.com, b2b.contoso.com, customer1.b2b.contoso.com usw. übereinstimmen. Mithilfe eines Arrays von Hostnamen können Sie für einen Listener mehrere Hostnamen konfigurieren, um Anforderungen an einen Back-End-Pool weiterzuleiten. So kann ein Listener beispielsweise contoso.com, fabrikam.com enthalten und so Anforderungen für beide Hostnamen akzeptieren.

Hinweis

Dieses Feature ist nur für die Application Gateway-SKUs Standard_v2 und WAF_v2 verfügbar.

In Azure PowerShell müssen Sie -HostNames anstelle von -HostName verwenden. Wenn Sie „HostNames“ verwenden, können Sie bis zu fünf Hostnamen als durch Trennzeichen getrennte Werte angeben sowie Platzhalterzeichen verwenden. Beispielsweise -HostNames "*.contoso.com","*.fabrikam.com".

In Azure CLI müssen Sie --host-names anstelle von --host-name verwenden. Wenn Sie „host-names“ verwenden, können Sie bis zu fünf Hostnamen als durch Trennzeichen getrennte Werte angeben sowie Platzhalterzeichen verwenden. Beispielsweise --host-names "*.contoso.com,*.fabrikam.com".

Im Azure-Portal müssen Sie unter dem Listener für mehrere Standorte den Hosttyp Mehrere/Platzhalter auswählen, um bis zu fünf Hostnamen mit zulässigen Platzhalterzeichen zu erwähnen.

Zulässige Zeichen im Hostnamenfeld

• (A-Z,a-z,0-9): alphanumerische Zeichen
• -: Bindestrich oder Minus
• . - Punkt als Trennzeichen
• * - kann mit mehreren Zeichen im zulässigen Bereich übereinstimmen
• ? - kann mit einem einzelnen Zeichen im zulässigen Bereich übereinstimmen

Bedingungen für die Verwendung von Platzhalterzeichen und von mehreren Hostnamen in einem Listener

Die folgenden Bedingungen gelten, wenn Sie Wildcard-Charaktere oder mehrere Hostnamen in einem Listener verwenden.

Constraint	Limit	Example
Hostnamen in einem einzigen Hörer	Bis zu 5	Nicht anwendbar
Asterisk (*) in einer Komponente eines Domain-Stil- oder Hostnamens	Kann nur einmal erwähnt werden	component1*.component2*.component3. (*.contoso-*.com) ist gültig.
Asterisken (*) in einem Wirtsnamen	Bis zu zwei	*.contoso.* ist gültig und *.contoso.*.*.com ist ungültig.
Wildcard-Charaktere in einem Wirtsnamen	Höchstens 4	????.contoso.com und w??.contoso*.edu.* gültig sind, aber ????.contoso.* ungültig.
Asterisk (*) und Fragezeichen (?) zusammen in einem Bestandteil eines Hostnamens (*? oder ?* oder **)	Ungültig	*?.contoso.com und **.contoso.com ungültig sind.
Abgleichverhalten von *.contoso.com	Stimmt nicht überein contoso.com	*.contoso.com gibt an, dass ein Punkt vor Contoso vorhanden ist, also contoso.com passt nicht überein.

Überlegungen und Einschränkungen bei der Verwendung von Platzhaltern oder mehreren Hostnamen in einem Listener

• Für SSL-Terminierung und End-to-End-SSL müssen Sie das Protokoll als HTTPS konfigurieren und ein Zertifikat hochladen, das in der Listenerkonfiguration verwendet werden soll. Wenn es sich um einen Multisite-Listener handelt, können Sie zusätzlich den Hostnamen eingeben; in der Regel ist dies der Common Name (CN) des SSL-Zertifikats. Wenn Sie im Listener mehrere Hostnamen angeben oder Platzhalterzeichen verwenden, müssen Sie Folgendes beachten:
  • Wenn es sich um einen Wildcard-Hostnamen wie „*.contoso.com“ handelt, müssen Sie ein Wildcard-Zertifikat mit einem CN wie „*.contoso.com“ hochladen.
  • Wenn in demselben Listener mehrere Hostnamen angegeben sind, müssen Sie ein SAN-Zertifikat (Subject Alternative Names) hochladen, dessen CNs mit den angegebenen Hostnamen übereinstimmen.
• Zur Angabe des Hostnamens kann kein regulärer Ausdruck verwendet werden. Das Muster des Hostnamens kann nur mithilfe von Platzhalterzeichen wie Sternchen (*) und Fragezeichen (?) gebildet werden.
• Für die Back-End-Integritätsprüfung können pro HTTP-Einstellung nicht mehrere benutzerdefinierte Sonden zugeordnet werden. Testen Sie stattdessen eine der Websites am Back-End, oder überprüfen Sie mit „127.0.0.1“ den lokalen Host auf dem Back-End-Server. Wenn Sie jedoch in einem Listener Platzhalter oder mehrere Hostnamen verwenden, werden die Anforderungen für alle angegebenen Domänenmuster je nach Regeltyp (einfach oder pfadbasiert) an den Back-End-Pool weitergeleitet.
• Die Eigenschaft „hostname“ erwartet als Eingabe eine Zeichenfolge, wobei nur ein Domänenname ohne Platzhalter angegeben werden kann. Die Eigenschaft „hostnames“ akzeptiert als Eingabe ein Array von Zeichenfolgen, in dem Sie bis zu 5 Platzhalter-Domänennamen angeben können. Beide Eigenschaften können nicht gleichzeitig verwendet werden.

Eine Schritt-für-Schritt-Anleitung zum Konfigurieren von Hostnamen mit Platzhaltern in einem Multisite-Listener finden Sie unter Erstellen von mehreren Standorten mit Azure PowerShell oder mit Azure CLI.

Multisite-Listener für TLS- und TCP-Protokolllistener

Das Feature für mehrere Websites ist auch für Layer4-Proxy verfügbar, aber nur für seine TLS-Listener. Sie können den Datenverkehr für jede Anwendung an den Back-End-Pool weiterleiten, indem Sie Domänennamen im TLS-Listener angeben. Damit das Feature für mehrere Websites auf TLS-Listenern funktioniert, verwendet der Anwendungsgateway den SNI-Wert (Server Name Indication) (die Clients präsentieren hauptsächlich die SNI-Erweiterung, um das richtige TLS-Zertifikat abzurufen). Ein TLS-Listener für mehrere Websites würde diesen SNI-Wert aus den TLS-Handshakedaten einer eingehenden Verbindung auswählen und diese Verbindung an den entsprechenden Back-End-Pool weiterleiten. Die TCP-Verbindung hat inhärent kein Konzept des Hostnamens oder des Domänennamens, weshalb dies für TCP-Listener nicht verfügbar ist.

Host-Header und Servernamenanzeige (SNI)

Es gibt drei allgemeine Mechanismen, um das Hosten mehrerer Websites in der gleichen Infrastruktur zu ermöglichen.

1. Hosten von mehreren Webanwendungen, jeweils mit einer eindeutigen IP-Adresse.
2. Verwenden Sie Hostnamen, um mehrere Webanwendungen unter derselben IP-Adresse zu hosten.
3. Verwenden verschiedener Ports zum Hosten mehrerer Webanwendungen mit der gleichen IP-Adresse.

Derzeit unterstützt Application Gateway eine einzelne öffentliche IP-Adresse, an der es auf Datenverkehr lauscht. Daher werden mehrere Anwendungen mit eigenen IP-Adressen zurzeit nicht unterstützt.

Application Gateway unterstützt mehrere Anwendungen, die jeweils an verschiedenen Ports lauschen, für dieses Szenario müssen die Anwendungen jedoch Datenverkehr über nicht standardmäßige Ports akzeptieren.

Application Gateway verwendet HTTP 1.1-Hostheader, um mehrere Websites an der gleichen öffentlichen IP-Adresse und dem gleichen Port zu hosten. Die auf Application Gateway gehosteten Websites können auch TLS-Offload mit der TLS-Erweiterung Server Name Indication (SNI) unterstützen. Das bedeutet, dass der Clientbrowser und die Back-End-Webfarm HTTP/1.1- und TLS-Erweiterungen unterstützen müssen, wie in RFC 6066 definiert.

Nächste Schritte

Hier erfahren Sie, wie Sie Multisitehosting in Application Gateway konfigurieren.

• Verwenden des Azure-Portals
• Verwenden von Azure PowerShell
• Verwenden der Azure-Befehlszeilenschnittstelle

Eine vollständige vorlagenbasierte Bereitstellung finden Sie unter Resource Manager-Vorlage mit Hosting mehrerer Websites.