Hostowanie wielu witryn w usłudze Application Gateway

Dzięki hostingowi wielu witryn możesz skonfigurować więcej niż jedną aplikację webową na tym samym porcie bram aplikacji, korzystając z publicznych listenerów. Możesz dodać ponad 100 stron internetowych do jednego Application Gateway. Możesz skierować każdą witrynę do własnej puli backendowej. Na przykład trzy domeny — contoso.com, fabrikam.com i adatum.com — wskazują adres IP bramy aplikacji. Tworzysz trzy wielolokalizacyjne odbiorniki nasłuchujące i konfigurujesz każdy z nich pod odpowiedni port oraz ustawienia protokołu.

Możesz także zdefiniować nazwy hostów z symbolami wieloznacznymi w nasłuchiwaczu wielowitrynowym oraz do pięciu nazw hostów na nasłuchiwacz. Aby dowiedzieć się więcej, zobacz nazwy hostów z symbolami wieloznacznymi w listenerze.

Zrzut ekranu routingu wielowitrynowego Application Gateway dla pul serwerów backendowych Contoso i Fabrikam.

Żądania dotyczące adresu http://contoso.com są kierowane do puli ContosoServerPool, a żądania dotyczące adresu http://fabrikam.com — do puli FabrikamServerPool.

Podobnie można hostować wiele poddomen tej samej domeny nadrzędnej w tym samym wdrożeniu bramy aplikacji. Na przykład można hostować http://blog.contoso.com i http://app.contoso.com w jednym wdrożeniu bramy aplikacji.

Uwaga

Zaawansowane zasady routingu nie są obsługiwane dla odbiorników wielowitrynowych.

Kolejność oceny reguł routingu żądań

Jeśli używasz nasłuchiwaczy wielowitrynowych, aby upewnić się, że ruch klienta jest kierowany do właściwego zaplecza, ważne jest, aby reguły routingu żądań były obecne we właściwej kolejności. Jeśli na przykład masz 2 listenery ze skojarzonymi nazwami hostów *.contoso.com i shop.contoso.com, listener z nazwą hosta shop.contoso.com musi zostać przetworzony przed listenerem z nazwą hosta *.contoso.com. Jeśli listener z *.contoso.com jest przetwarzany jako pierwszy, żaden ruch klienta nie jest odbierany przez bardziej konkretny listener shop.contoso.com.

Kolejność reguł można ustanowić, podając wartość pola Priorytet dla reguł routingu żądań skojarzonych z odbiornikami. Można określić wartość całkowitą z zakresu od 1 do 20000, gdzie 1 ma najwyższy priorytet, a 20000 ma najniższy priorytet. Jeśli przychodzący ruch klienta jest zgodny z wieloma detektorami nasłuchiwania, reguła routingu żądań o najwyższym priorytecie jest używana do obsługi żądania. Każda reguła routingu żądań musi mieć unikatową wartość priorytetu.

Pole priorytetu ma wpływ tylko na kolejność oceny reguły routingu żądań. Nie spowoduje to zmiany kolejności obliczania reguł opartych na ścieżkach w PathBasedRouting ramach reguły routingu żądań.

Uwaga

Aby użyć priorytetu reguły, należy określić wartości pól priorytetu reguły dla wszystkich istniejących reguł routingu żądań. Gdy pole priorytetu reguły jest używane, każda nowa utworzona reguła rozsyłania musi mieć wartość pola priorytetu reguły w ramach konfiguracji.

Ważne

  • Począwszy od wersji interfejsu API 2021-08-01, pole priorytetu reguły jest polem obowiązkowym w regułach routingu żądań. Wartości pola priorytetu reguły dla istniejących reguł routingu żądań są automatycznie uzupełniane na podstawie bieżącej kolejności oceniania podczas pierwszego wywołania PUT, jeśli jakiekolwiek aktualizacje konfiguracji są stosowane przy użyciu interfejsu API w wersji 2021-08-01 lub nowszej, portalu, programu Azure PowerShell i interfejsu wiersza polecenia platformy Azure. Przyszłe aktualizacje reguł routingu muszą mieć pole priorytetu reguły podane w ramach konfiguracji.
  • Reguły są przetwarzane w kolejności, w jakiej są wymienione w portalu dla SKU v1. W przypadku jednostki SKU v2 użyj priorytetu reguł, aby określić kolejność przetwarzania. Zdecydowanie zaleca się skonfigurowanie detektorów nasłuchu obejmujących wiele lokacji przed skonfigurowaniem podstawowego detektora nasłuchu. Zapewnia to skierowanie ruchu do odpowiedniego backendu. Jeśli podstawowy listener znajduje się na początku listy i odpowiada żądaniu przychodzącemu, jest ono przetwarzane przez ten listener.

Nazwy hostów z symbolami wieloznacznymi w listenerze

Usługa Application Gateway umożliwia routing oparty na hoście przy użyciu wielowitrynowego odbiornika HTTP(S). Teraz można używać symboli wieloznacznych, takich jak gwiazdka (*) i znak zapytania (?) w nazwie hosta, oraz maksymalnie 5 nazw hostów w nasłuchiwaczu HTTP(S) dla wielu witryn. Na przykład *.contoso.com.

Używając symbolu wieloznacznego w nazwie hosta, można dopasować wiele nazw hostów w jednym nasłuchu. Na przykład *.contoso.com może pasować do ecom.contoso.com, b2b.contoso.com i customer1.b2b.contoso.com itd. Za pomocą tablicy nazw hostów można skonfigurować więcej niż jedną nazwę hosta dla detektora nasłuchującego, aby kierować żądania do puli zaplecza. Na przykład odbiornik może zawierać contoso.com, fabrikam.com, który przyjmuje żądania dla obu nazw hostów.

Zrzut ekranu słuchacza z dziką kartą, który kieruje wiele nazw hostów do puli backendowej.

Uwaga

Ta funkcja jest dostępna tylko dla jednostek SKU Standard_v2 i WAF_v2 usługi Application Gateway.

W programie Azure PowerShell należy użyć polecenia -HostNames zamiast -HostName. W przypadku nazw hostów można wymieniać maksymalnie 5 nazw hostów jako wartości rozdzielane przecinkami i używać symboli wieloznacznych. Na przykład -HostNames "*.contoso.com","*.fabrikam.com".

W interfejsie wiersza polecenia platformy Azure należy użyć polecenia --host-names zamiast --host-name. W przypadku nazw hostów można wymieniać maksymalnie 5 nazw hostów jako wartości rozdzielane przecinkami i używać symboli wieloznacznych. Na przykład --host-names "*.contoso.com,*.fabrikam.com".

W witrynie Azure Portal w obszarze odbiornika z wieloma witrynami należy wybrać typ hosta Wiele/symbol wieloznaczny, aby podać maksymalnie pięć nazw hostów z dozwolonymi znakami wieloznacznymi.

Zrzut ekranu interfejsu konfiguracji nasłuchiwacza wieloznacznego w portalu Azure.

Dozwolone znaki w polu nazw hostów

  • (A-Z,a-z,0-9) - znaki alfanumeryczne
  • - - łącznik lub minus
  • . - kropka jako separator
  • * — może pasować do wielu znaków w dozwolonym zakresie
  • ? - może pasować do pojedynczego znaku w dozwolonym zakresie

Warunki używania symboli wieloznacznych i wielu nazw hostów w nasłuchiwaczu

Następujące warunki obowiązują, gdy używasz znaków wieloznacznych lub wielu nazw hostów w listenerze.

Ograniczenie Limit Example
Nazwy hostów w jednym listenerze Maksymalnie 5 Nie dotyczy
Gwiazdka (*) w składniku nazwy domeny lub nazwy hosta Można o tym wspomnieć tylko raz component1*.component2*.component3. (*.contoso-*.com) jest poprawne.
Gwiazdki (*) w nazwie hosta Do dwóch *.contoso.* jest ważna i *.contoso.*.*.com jest nieważna.
Znaki wieloznaczne w nazwie hosta Maksymalnie 4 ????.contoso.com i w??.contoso*.edu.* są ważne, ale ????.contoso.* jest nieważne.
Gwiazdka (*) i znak zapytania (?) razem w części nazwy hosta (*? lub ?* lub **) Nieprawidłowy *?.contoso.com i **.contoso.com są nieprawidłowe.
Dopasuj zachowanie elementu *.contoso.com Nie pasuje contoso.com *.contoso.com Określa, że kropka jest obecna przed Contoso, więc contoso.com nie pasuje.

Zagadnienia i ograniczenia dotyczące używania symboli wieloznacznych lub wielu nazw hostów w nasłuchu

  • Terminacja SSL i SSL end-to-end wymaga skonfigurowania protokołu jako HTTPS i przekazania certyfikatu do użycia w konfiguracji nasłuchu. Jeśli jest to listener wielowitrynowy, możesz również wprowadzić nazwę hosta, zazwyczaj jest to CN certyfikatu SSL. Podczas określania wielu nazw hostów w listenerze lub używania symboli wieloznacznych należy wziąć pod uwagę następujące kwestie:
    • Jeśli jest to nazwa hosta z symbolami wieloznacznymi, na przykład *.contoso.com, musisz przesłać certyfikat wieloznaczny z nazwą CN, na przykład *.contoso.com
    • Jeśli w tym samym listenerze wymieniono wiele nazw hostów, należy przekazać certyfikat SAN (alternatywne nazwy podmiotu) z nazwami CN zgodnymi z wymienionymi nazwami hostów.
  • Nie można użyć wyrażenia regularnego, aby określić nazwę hosta. Można używać symboli wieloznacznych, takich jak gwiazdka (*) i znak zapytania (?), aby utworzyć wzorzec nazwy hosta.
  • W przypadku sprawdzania kondycji zaplecza nie można skojarzyć wielu niestandardowych sond dla jednego ustawienia HTTP. Zamiast tego można sprawdzić jedną z witryn internetowych po stronie backendu lub użyć "127.0.0.1", aby sprawdzić localhost serwera backendu. Jednak w przypadku używania symboli wieloznacznych lub wielu nazw hostów w nasłuchu żądania dotyczące wszystkich określonych wzorców domeny są kierowane do puli serwerów zaplecza w zależności od typu reguły (podstawowego lub opartego na ścieżce).
  • Właściwość "hostname" przyjmuje jeden ciąg jako dane wejściowe, w którym można podać tylko jedną nazwę domeny bez symboli wieloznacznych. Właściwość "hostnames" przyjmuje tablicę ciągów jako dane wejściowe, gdzie można wspomnieć o maksymalnie 5 nazwach domen z symbolami wieloznacznymi. Obie te właściwości nie mogą być używane jednocześnie.

Zobacz tworzenie wielu witryn przy użyciu programu Azure PowerShell lub przy użyciu interfejsu wiersza polecenia platformy Azure, aby zapoznać się z przewodnikiem krok po kroku dotyczącym konfigurowania nazw hostów z symbolami wieloznacznymi w nasłuchiwaczu z wieloma witrynami.

Wielowitrynowy listener dla listenerów protokołów TLS i TCP

Funkcja wielowitrynowa jest również dostępna dla serwera proxy warstwy 4, ale tylko dla jego nasłuchiwaczy TLS. Ruch dla każdej aplikacji można skierować do jej puli zaplecza, podając nazwy domen w nasłuchiwaczu TLS. W przypadku działania funkcji obsługi wielu witryn na detektorach TLS usługa Application Gateway używa wartości wskazania nazwy serwera (SNI) (klienci przedstawiają przede wszystkim rozszerzenie SNI w celu pobrania poprawnego certyfikatu TLS). Wielowitrynowy nasłuchiwacz TLS wybiera tę wartość SNI z danych uzgadniania TLS połączenia przychodzącego i kieruje to połączenie do odpowiedniej puli zaplecza aplikacji. Połączenie TCP z natury nie ma pojęcia nazwy hosta ani nazwy domeny; w związku z tym nie jest to dostępne dla nasłuchów TCP.

Nagłówki hosta i wskazanie nazwy serwera (SNI)

Istnieją trzy typowe mechanizmy umożliwiające hostowanie wielu witryn w tej samej infrastrukturze.

  • Hostowanie wielu aplikacji internetowych — każda z nich na unikatowym adresie IP.
  • Użyj nazwy hosta do hostowania wielu aplikacji internetowych na tym samym adresie IP.
  • Użyj różnych portów do hostowania wielu aplikacji internetowych na tym samym adresie IP.

Obecnie usługa Application Gateway obsługuje pojedynczy publiczny adres IP, na którym nasłuchuje ruchu. Wiele aplikacji, z których każda ma własny adres IP, nie są obecnie obsługiwane.

Usługa Application Gateway obsługuje wiele aplikacji nasłuchujących na różnych portach, ale ten scenariusz wymaga, aby aplikacje akceptowały ruch na niestandardowych portach.

Usługa Application Gateway bazuje na nagłówkach hosta HTTP 1.1 w celu hostowania więcej niż jednej witryny sieci Web na tym samym publicznym adresie IP i porcie. Witryny hostowane w usłudze Application Gateway mogą również obsługiwać odciążanie protokołu TLS przy użyciu rozszerzenia TLS Server Name Indication (SNI). Ten scenariusz oznacza, że przeglądarka klienta i farma serwerów WWW zaplecza muszą obsługiwać protokół HTTP/1.1 i rozszerzenie TLS zgodnie ze standardem RFC 6066.

Następne kroki

Dowiedz się, jak skonfigurować hosting wielu witryn w usłudze Application Gateway

Zobacz szablon usługi Resource Manager korzystający z hostingu wielu witryn, aby uzyskać kompleksowe wdrożenie oparte na szablonach.

  • Ostatnia aktualizacja o