Składniki usługi Application Gateway

Brama aplikacji służy jako pojedynczy punkt kontaktu dla klientów. Dystrybuuje ruch przychodzący aplikacji między wiele pul zapleczowych, w tym maszyn wirtualnych Azure, zestawów skalowania maszyn wirtualnych, usług Azure App Service i lokalnych/zewnętrznych serwerów. Aby dystrybuować ruch, brama aplikacji używa kilku składników opisanych w tym artykule.

Adresy IP frontonu

Adres IP frontonu to adres IP skojarzony z bramą aplikacji. Bramę aplikacji można skonfigurować tak, aby miała publiczny adres IP, prywatny adres IP lub oba te elementy. Brama aplikacji obsługuje jeden publiczny lub prywatny adres IP. Sieć wirtualna i publiczny adres IP muszą znajdować się w tej samej lokalizacji co brama aplikacji. Po jego utworzeniu adres IP frontend jest skojarzony z listenerem.

Statyczny i dynamiczny publiczny adres IP

SKU Azure Application Gateway V2 może być skonfigurowany tak, aby obsługiwać zarówno statyczny wewnętrzny adres IP, jak i statyczny publiczny adres IP, albo tylko statyczny publiczny adres IP. Możesz też skonfigurować ją tak, aby używała statycznego wewnętrznego (prywatnego) adresu IP, tylko wtedy, gdy wdrożysz prywatny Application Gateway z networkIsolationEnabled ustawionym na True. Aby poznać obsługiwane kombinacje adresów IP frontend, zobacz Konfiguracja adresów IP frontend. Informacje o działaniu DNS we wdrożeniach wykorzystujących wyłącznie prywatny adres IP można znaleźć w sekcji Rozpoznawanie nazw DNS w usłudze Application Gateway.

Jednostkę SKU w wersji 1 można skonfigurować do obsługi statycznego lub dynamicznego wewnętrznego adresu IP i dynamicznego publicznego adresu IP. Dynamiczny adres IP usługi Application Gateway nie zmienia się dla działającej bramy. Może się zmienić tylko wtedy, gdy zatrzymasz lub uruchomisz Bramę. Nie zmienia się w przypadku awarii systemu, aktualizacji, aktualizacji hosta platformy Azure itp.

Nazwa DNS skojarzona z bramą aplikacji nie zmienia się w cyklu życia bramy. W związku z tym należy użyć aliasu CNAME i wskazać go na adres DNS bramy aplikacji.

Odbiorniki

Odbiornik to jednostka logiczna, która sprawdza żądania połączeń przychodzących. Odbiornik akceptuje żądanie, jeśli protokół, port, nazwa hosta i adres IP skojarzony z żądaniem są zgodne z tymi samymi elementami skojarzonymi z konfiguracją odbiornika.

Przed użyciem bramy aplikacji należy dodać co najmniej jeden odbiornik. Może istnieć wiele odbiorników dołączonych do bramy aplikacji i mogą być używane dla tego samego protokołu.

Po tym jak nasłuchujący wykryje żądania przychodzące od klientów, brama aplikacji kieruje te żądania do członków puli zaplecza skonfigurowanej według reguły.

Odbiorniki obsługują następujące porty i protokoły.

Porty sieciowe

Port to miejsce, w którym odbiornik nasłuchuje żądania klienta. Możesz skonfigurować porty dla SKU v1 i v2 w następujący sposób:

Protokoły

Application Gateway obsługuje protokoły sieciowe HTTP, HTTPS, HTTP/2 oraz WebSocket za pośrednictwem serwera proxy warstwy 7. Obsługuje także protokoły TLS i TCP poprzez proxy'a warstwy 4, które można skonfigurować na tym samym zasobie.

• Wybierz protokoły HTTP, HTTPS, TLS lub TCP w konfiguracji słuchacza.
• Do terminacji TLS użyj nasłuchiwacza HTTPS lub TLS. Odbiornik HTTPS/TLS przenosi zadanie szyfrowania i odszyfrowywania na bramę aplikacji, dzięki czemu serwery nie są obciążone przetwarzaniem TLS.
• Application Gateway natywnie obsługuje protokoły WebSockets i HTTP/2, a wsparcie dla WebSocket jest domyślnie włączone. Nie ma żadnych ustawień konfigurowanych przez użytkownika umożliwiających selektywne włączenie lub wyłączenie obsługi protokołu WebSocket. Używaj WebSocket zarówno z nasłuchiwaczami HTTP, jak i HTTPS.

Poniższa tabela podsumowuje, jak Application Gateway obsługuje każdy protokół.

Niestandardowe strony błędów

Usługa Application Gateway umożliwia tworzenie niestandardowych stron błędów zamiast wyświetlania domyślnych stron błędów. Możesz użyć własnego brandingu i układu, korzystając z niestandardowej strony z błędami. Usługa Application Gateway wyświetla niestandardową stronę błędu, gdy żądanie nie może nawiązać połączenia z zapleczem.

Aby uzyskać więcej informacji, zobacz Niestandardowe strony błędów dla bramy aplikacji.

Typy odbiorników

Istnieją dwa typy odbiorników:

• Podstawowa. Ten typ nasłuchiwacza nasłuchuje pojedynczej witryny domeny, gdzie ma pojedyncze mapowanie DNS na adres IP bramy aplikacyjnej. Taka konfiguracja słuchaczy jest potrzebna, gdy hostujesz jedną stronę za bramą aplikacji.

• Wiele witryn. Taka konfiguracja słuchaczy jest potrzebna, gdy chcesz skonfigurować routing na podstawie nazwy hosta lub domeny dla więcej niż jednej aplikacji webowej na tej samej bramie aplikacji. Korzystając z tego listenera, możesz skonfigurować bardziej efektywną topologię dla swoich wdrożeń, dodając do 100+ stron internetowych do jednej bramki aplikacji. Każdą witrynę sieci Web można skierować do jej puli serwerów zaplecza. Na przykład trzy domeny — contoso.com, fabrikam.com i adatum.com — wskazują adres IP bramy aplikacji. Utworzysz trzy odbiorniki wielomiejscowe i skonfigurujesz każdy z nich na odpowiednie ustawienia portu i protokołu.

  Możesz także zdefiniować nazwy hostów z symbolem wieloznacznym w nasłuchiwaczu dla wielu witryn oraz maksymalnie pięć nazw hostów na nasłuchiwacz. Aby dowiedzieć się więcej, zobacz nazwy hostów z symbolami wieloznacznymi w nasłuchiwaczu.

  Aby uzyskać więcej informacji o sposobie konfigurowania odbiornika dla wielu lokacji, zobacz Hostowanie wielu lokacji w usłudze Application Gateway przy użyciu witryny Azure Portal.

Po utworzeniu odbiornika należy skojarzyć go z regułą routingu żądań. Ta reguła określa, w jaki sposób żądanie odebrane na odbiorniku powinno być kierowane do zaplecza. Reguła routingu żądań zawiera także pulę backendową, do której należy kierować, oraz ustawienie HTTP, w którym określono port backendu, protokół i inne ustawienia.

Reguły routingu żądań

Reguła routingu żądań jest kluczowym składnikiem bramy aplikacji, ponieważ określa sposób kierowania ruchu na odbiorniku. Reguła wiąże odbiornik, pulę serwerów zaplecza i ustawienia HTTP zaplecza.

Gdy odbiornik zaakceptuje żądanie, reguła routingu żądań przekazuje żądanie do zaplecza lub przekierowuje je gdzie indziej. Jeśli żądanie jest przekazywane do zaplecza, reguła rozsyłania żądań definiuje pulę serwerów zaplecza do przekazania dalej. Reguła routingu żądań określa również, czy nagłówki w żądaniu mają zostać przepisane. Jeden nasłuchujący może być przypisany do jednej reguły.

Istnieją trzy typy reguł routingu żądań:

• Podstawowa. Wszystkie żądania skojarzonego odbiornika (na przykład blog.contoso.com/*) są przekazywane do skojarzonej puli zaplecza przy użyciu skojarzonego ustawienia HTTP.

• Zaawansowany routing. Tego typu reguła pozwala podejmować dynamiczne decyzje dotyczące routingu na podstawie atrybutów HTTP request. Ocenia przychodzące żądania względem skonfigurowanych warunków i kieruje ruch do określonych celów na podstawie wyników oceny.

Poniższa tabela porównuje trzy typy reguł.

Aby uzyskać więcej informacji, zobacz Routing oparty na adresach URL.

Obsługa przekierowania

Reguła routingu żądań umożliwia również przekierowywanie ruchu w bramie aplikacji. Ten mechanizm przekierowania jest ogólny, więc za pomocą reguł możesz przekierowywać ruch do dowolnego zdefiniowanego portu i z niego.

Możesz wybrać element docelowy przekierowania jako inny odbiornik (co może pomóc włączyć automatyczne przekierowywanie HTTP do HTTPS) lub witrynę zewnętrzną. Możesz również zdecydować, że przekierowanie ma być tymczasowe lub trwałe, albo dołączyć ścieżkę identyfikatora URI i ciąg zapytania do przekierowanego adresu URL.

Aby uzyskać więcej informacji, zobacz Przekierowywanie ruchu na swojej bramie aplikacji.

Ponowne zapisywanie nagłówków HTTP i adresów URL

Application Gateway może dodać, usuwać lub aktualizować nagłówki żądań i odpowiedzi HTTP(S), a także ścieżki URL i parametry ciągów zapytań, gdy ruch przechodzi między klientami a pulami backendowymi. Pełne wyjaśnienie i kroki konfiguracyjne znajdziesz w artykule Przepisz nagłówki HTTP i adresy URL na bramie aplikacji.

Ustawienia protokołu HTTP

Ustawienie HTTP, zwane także ustawieniem backendu, to konfiguracja decydująca o tym, jak ruch dociera do serwerów backendu. Definiuje port i protokół, którego brama aplikacji używa do łączenia się z tymi serwerami, jak zachowują się połączenia oraz jak brama monitoruje kondycję backendu. Reguła routingu żądań określa, które ustawienie HTTP należy zastosować podczas przekazywania żądania do puli backendowej.

Port i protokół używany w ustawieniach PROTOKOŁU HTTP określają, czy ruch między bramą aplikacji a serwerami zaplecza jest szyfrowany (zapewniając kompleksową obsługę protokołu TLS) lub niezaszyfrowany.

Wykorzystaj ten komponent do:

• Zdecyduj, czy utrzymać sesję użytkownika na tym samym serwerze, korzystając z afinitetu sesji opartej na plikach cookie.

• Płynnie usuń członków puli zaplecza, korzystając z mechanizmu opróżniania połączeń.

• Skojarz sondę niestandardową, aby monitorować kondycję zaplecza, ustawić interwał limitu czasu żądania, zastąpić nazwę hosta i ścieżkę w żądaniu i zapewnić łatwość klikania, aby określić ustawienia zaplecza usługi App Service.

Zasoby zaplecza

Pula backendowa kieruje żądania do serwerów backendowych, które obsługują te żądania. Grupy zaplecza mogą zawierać:

• Karty sieciowe
• Zestawy do skalowania maszyn wirtualnych
• Publiczne adresy IP
• Wewnętrzne adresy IP
• Nazwy FQDN (w pełni kwalifikowane nazwy domen) lub krótkie nazwy (nazwy domen z jedną etykietą), pod warunkiem że serwer DNS może je rozwiązać
• Wielodostępne zaplecza, takie jak Azure App Service i Azure Container Apps. Aby uzyskać wskazówki dotyczące implementacji, zobacz Ochrona aplikacji kontenerowych za pomocą usługi Application Gateway i zapory aplikacji internetowej (WAF).

Elementy członkowskie puli zaplecza usługi Application Gateway nie są powiązane z zestawem dostępności. Brama aplikacji może komunikować się z wystąpieniami spoza sieci wirtualnej, w której się znajduje. W związku z tym członkowie pul zaplecza mogą znajdować się w klastrach, w centrach danych lub poza platformą Azure, o ile istnieje łączność z adresami IP.

Jeśli używasz wewnętrznych adresów IP jako elementów członkowskich puli zaplecza, musisz użyć równorzędnego łączenia sieci wirtualnych lub bramy VPN. Peering sieci wirtualnych jest obsługiwany i korzystny dla równoważenia ruchu obciążenia w innych sieciach wirtualnych.

Brama aplikacji może również komunikować się z serwerami lokalnymi, gdy są połączone przez Azure ExpressRoute lub tunele VPN, jeśli pozwala się na ruch.

Możesz utworzyć różne pule backendowe dla różnych typów żądań. Na przykład utwórz jedną pulę zaplecza dla żądań ogólnych, a następnie drugą pulę zaplecza dla żądań do mikrousług dla aplikacji.

Po dodaniu zestawów skalowania maszyn wirtualnych jako członka puli zaplecza, należy zaktualizować wystąpienia zestawów skalowania maszyn wirtualnych. Dopóki nie zaktualizujesz wystąpień zestawów skalowania, backend jest niezdrowy.

Sondy kondycji

Domyślnie brama aplikacji monitoruje kondycję wszystkich zasobów w puli zaplecza i automatycznie usuwa te, które są w złej kondycji. Następnie monitoruje niezdrowe instancje i dodaje je z powrotem do zdrowej puli zaplecza, gdy staną się dostępne i odpowiadają na sondy diagnostyczne.

Oprócz korzystania z domyślnego monitorowania sondy kondycji można również dostosować sondę kondycji do wymagań aplikacji. Niestandardowe sondy umożliwiają bardziej szczegółową kontrolę nad monitorowaniem kondycji. Używając niestandardowych sond, możesz skonfigurować niestandardową nazwę hosta, ścieżkę URL, interwał prób oraz liczbę nieudanych odpowiedzi do zaakceptowania, zanim oznaczysz instancję puli backendowej jako niezdrową, własne kody statusu i dopasowanie ciała odpowiedzi oraz wiele więcej. Konfiguruj niestandardowe sondy do monitorowania stanu każdej puli backendowej.

Aby uzyskać więcej informacji, zobacz Monitorowanie kondycji Twojej bramy aplikacji.

Następne kroki

Tworzenie bramy aplikacji:

• W witrynie Azure Portal
• Przy użyciu programu Azure PowerShell
• Przy użyciu interfejsu wiersza polecenia platformy Azure