Hostowanie wielu witryn w usłudze Application Gateway

  • Artykuł

Hostowanie wielu witryn umożliwia skonfigurowanie więcej niż jednej aplikacji internetowej na tym samym porcie bram aplikacji przy użyciu odbiorników publicznych. Ta funkcja umożliwia skonfigurowanie bardziej wydajnej topologii dla wdrożeń przez dodanie nawet ponad 100 witryn internetowych do jednej bramy aplikacji. Każdą witrynę sieci Web można skierować do jej puli zaplecza. Na przykład trzy domeny — contoso.com, fabrikam.com i adatum.com — wskazują adres IP bramy aplikacji. Utworzysz trzy odbiorniki obejmujące wiele witryn i skonfigurujesz każdy odbiornik dla odpowiedniego portu i ustawienia protokołu.

Możesz również określić nazwy hosta z symbolami wieloznacznymi w odbiorniku obejmującym wiele witryn, z maksymalnie pięcioma nazwami hostów na odbiornik. Aby dowiedzieć się więcej, zobacz nazwy hostów z symbolami wieloznacznymi w odbiorniku.

Multi-site Application Gateway

Ważne

Reguły są przetwarzane w kolejności, w której są wyświetlane w portalu dla jednostki SKU w wersji 1. W przypadku jednostki SKU w wersji 2 użyj priorytetu reguły, aby określić kolejność przetwarzania. Zdecydowanie zaleca się skonfigurowanie odbiorników obejmujących wiele lokacji przed skonfigurowaniem podstawowego odbiornika. Zapewnia to skierowanie ruchu do odpowiedniego zaplecza. Jeśli podstawowy odbiornik znajduje się na początku listy i jest zgodny z żądaniem przychodzącym, jest ono przetwarzane przez ten odbiornik.

Żą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.

Kolejność oceny reguł routingu żądań

Jeśli używasz odbiorników z wieloma lokacjami, aby upewnić się, że ruch klienta jest kierowany do dokładnego zaplecza, ważne jest, aby reguły routingu żądań były obecne w prawidłowej kolejności. Jeśli na przykład masz 2 odbiorniki ze skojarzonymi nazwami hostów *.contoso.com i shop.contoso.com, odbiornik o shop.contoso.com nazwie hosta musi zostać przetworzony przed odbiornikiem za pomocą *.contoso.compolecenia . Jeśli odbiornik z *.contoso.com programem jest przetwarzany jako pierwszy, żaden ruch klienta nie jest odbierany przez bardziej konkretny shop.contoso.com odbiornik.

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 odbiornikami, 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ń. Spowoduje to zmianę kolejności oceny 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 interfejsu API w wersji 2021-08-01, pole priorytetu reguły jest polem obowiązkowym w regułach routingu żądań. Wartości pól priorytetu reguły dla istniejących reguł routingu żądań na podstawie bieżącej kolejności oceny w ramach pierwszego wywołania PUT są wypełniane automatycznie, 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.

Nazwy hostów z symbolami wieloznacznymi w odbiorniku

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

Używając symbolu wieloznacznych w nazwie hosta, można dopasować wiele nazw hostów w jednym odbiorniku. Na przykład *.contoso.com może być zgodny z parametrami ecom.contoso.comi b2b.contoso.comcustomer1.b2b.contoso.com itd. Za pomocą tablicy nazw hostów można skonfigurować więcej niż jedną nazwę hosta dla odbiornika, aby kierować żądania do puli zaplecza. Na przykład odbiornik może zawierać contoso.com, fabrikam.com żądania dotyczące obu nazw hostów.

Wildcard Listener

Uwaga

Ta funkcja jest dostępna tylko dla Standard_v2 i WAF_v2 jednostki SKU 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 --host-nameAzure należy użyć polecenia --host-names zamiast . 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 wspomnieć o maksymalnie pięciu nazwach hostów z dozwolonymi znakami wieloznacznymi .

Wildcard Listener UI

Dozwolone znaki w polu nazwy hostów

  • (A-Z,a-z,0-9) - znaki alfanumeryczne
  • - - łącznik lub minus
  • . - kropka jako ogranicznik
  • * — może być zgodny z wieloma znakami w dozwolonym zakresie
  • ? - może być zgodny z pojedynczym znakiem w dozwolonym zakresie

Warunki używania symboli wieloznacznych i wielu nazw hostów w odbiorniku

  • W jednym odbiorniku można wymienić maksymalnie 5 nazw hostów
  • Gwiazdka * może być wymieniona tylko raz w składniku nazwy stylu domeny lub nazwy hosta. Na przykład component1*.component2*.component3. Nazwa (*.contoso-*.com) jest poprawna.
  • Nazwa hosta może zawierać maksymalnie dwie gwiazdki * . Na przykład *.contoso.* jest prawidłowy i *.contoso.*.*.com jest nieprawidłowy.
  • W nazwie hosta może istnieć maksymalnie 4 symbole wieloznaczne. Na przykład , ????.contoso.comw??.contoso*.edu.* są prawidłowe, ale ????.contoso.* są nieprawidłowe.
  • Użycie gwiazdki * i znaku ? zapytania w składniku nazwy hosta (*? lub ?***) jest nieprawidłowe. Na przykład *?.contoso.com i **.contoso.com są nieprawidłowe.

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

  • Kończenie żądań SSL i kompleksowa usługa SSL wymaga skonfigurowania protokołu jako protokołu HTTPS i przekazania certyfikatu do użycia w konfiguracji odbiornika. Jeśli jest to odbiornik z wieloma lokacjami, możesz również wprowadzić nazwę hosta, zazwyczaj jest to cn certyfikatu SSL. Podczas określania wielu nazw hostów w odbiorniku 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 przekazać certyfikat wieloznaczny z nazwą CN, na przykład *.contoso.com
    • Jeśli w tym samym odbiorniku wymieniono wiele nazw hostów, należy przekazać certyfikat SIECI SAN (alternatywne nazwy podmiotu) z nazwami hostów zgodnymi z wymienionymi nazwami hostów.
  • Nie można użyć wyrażenia regularnego, aby wspomnieć o nazwie 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 na ustawienia PROTOKOŁU HTTP. Zamiast tego można sondować jedną z witryn internetowych w zapleczu lub użyć "127.0.0.1", aby zbadać localhost serwera zaplecza. Jednak w przypadku używania symboli wieloznacznych lub wielu nazw hostów w odbiorniku żądania dotyczące wszystkich określonych wzorców domeny są kierowane do puli zaplecza w zależności od typu reguły (podstawowego lub opartego na ścieżce).
  • Właściwość "nazwa hosta" przyjmuje jeden ciąg jako dane wejściowe, gdzie można wspomnieć tylko o jednej nazwie domeny innej niż wieloznaczny. Właściwość "hostnames" przyjmuje tablicę ciągów jako dane wejściowe, gdzie można wspomnieć o maksymalnie 5 nazwach domen wieloznacznych. Oba te właściwości nie mogą być używane jednocześnie.

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

Odbiornik z wieloma lokacjami dla odbiorników protokołów TLS i TCP

Funkcja wielu lokacji jest również dostępna dla serwera proxy warstwy 4, ale tylko dla odbiorników TLS. Ruch dla każdej aplikacji można skierować do puli zaplecza, podając nazwy domen w odbiorniku TLS. W przypadku funkcjonowania funkcji wielu lokacji na odbiornikach TLS usługa Application Gateway używa wartości oznaczania nazwy serwera (SNI) (klienci przedstawiają przede wszystkim rozszerzenie SNI w celu pobrania poprawnego certyfikatu TLS). Odbiornik PROTOKOŁU TLS w wielu lokacjach wybiera tę wartość SNI z danych uzgadniania protokołu TLS połączenia przychodzącego i kieruje to połączenie do odpowiedniej puli zaplecza. 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 odbiorników TCP.

Nagłówki hosta i oznaczanie nazwy serwera (SNI, Server Name Indication)

Istnieją trzy typowe mechanizmy włączania hostowania wielu witryn w tej samej infrastrukturze.

  1. Hostowanie wielu aplikacji internetowych — każda z nich na unikatowym adresie IP.
  2. Użycie nazwy hosta do hostowania wielu aplikacji internetowych na tym samym adresie IP.
  3. Użycie 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, w którym nasłuchuje ruchu. Dlatego wiele aplikacji, z których każdy ma własny adres IP, nie jest obecnie obsługiwany.

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 bramie aplikacji mogą również obsługiwać odciążanie protokołu TLS przy użyciu rozszerzenia TLS oznaczania nazwy serwera (SNI). Ten scenariusz oznacza, że przeglądarka i farma sieci Web zaplecza klienta muszą obsługiwać protokół HTTP/1.1 i rozszerzenie TLS zgodnie ze standardem RFC 6066.

Następne kroki

Dowiedz się, jak skonfigurować hosting z wieloma lokacjami w usłudze Application Gateway

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