Udostępnij za pośrednictwem

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.

Składniki używane w bramie aplikacji

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 bramy aplikacyjnej Azure w wersji 2 można skonfigurować tak, aby obsługiwała zarówno statyczny adres IP wewnętrzny, jak i statyczny adres IP publiczny lub tylko statyczny adres IP publiczny. Nie można go skonfigurować tak, aby obsługiwał tylko statyczny wewnętrzny adres IP.

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. Porty dla jednostek SKU w wersji 1 i 2 można skonfigurować jak poniżej.

jednostka magazynowa (SKU) Obsługiwany zakres portów Wyjątki
Wersja 2 Od 1 do 64999 22, 53
W1 Od 1 do 65502 3389

Protokoły

Usługa Application Gateway zapewnia obsługę protokołów internetowych HTTP, HTTPS, HTTP/2 i WebSocket za pośrednictwem serwera proxy warstwy 7. Ponadto obsługuje protokoły TLS i TCP za pośrednictwem serwera proxy warstwy 4 w wersji zapoznawczej, które można skonfigurować na tym samym zasobie.

  • Wybierz między protokołami HTTP, HTTPS, TLS lub TCP w konfiguracji odbiornika.
  • Do kończenia żądań protokołu TLS można użyć odbiornika HTTPS lub TLS. Odbiornik HTTPS/TLS przenosi zadanie szyfrowania i odszyfrowywania na bramę aplikacji, dzięki czemu serwery nie są obciążone przetwarzaniem TLS.
  • Obsługa protokołów WebSocket i HTTP/2 jest zapewniana natywnie, a obsługa protokołu WebSocket jest domyślnie włączona. 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.

Uwaga

Obsługa protokołu HTTP/2 jest dostępna tylko dla klientów łączących się z odbiornikami bramy aplikacji. Komunikacja z pulami serwerów zaplecza jest zawsze za pośrednictwem protokołu HTTP/1.1. Domyślnie obsługa protokołu HTTP/2 jest wyłączona. Możesz ją włączyć.

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 znakowania firmowego i układu za pomocą niestandardowej strony błędu. 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. Ta konfiguracja nasłuchująca jest wymagana w przypadku hostowania pojedynczej witryny za bramą aplikacji.

  • Wiele witryn. Ta konfiguracja odbiornika jest wymagana, jeśli chcesz skonfigurować routing na podstawie nazwy hosta lub nazwy domeny dla więcej niż jednej aplikacji internetowej w tej samej bramie aplikacji. 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 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 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 nasłuchiwaczu.

    Aby uzyskać więcej informacji na temat konfigurowania odbiornika z wieloma lokacjami, zobacz Hostowanie wielu witryn 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 kierowania żądań zawiera również pulę serwerów zaplecza, do której ma być kierowana, oraz ustawienia HTTP, w którym wymieniono port zaplecza, protokół itp.

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

  • Oparte na ścieżkach. Ta reguła routingu umożliwia kierowanie żądań do skojarzonego odbiornika do określonej puli zaplecza na podstawie adresu URL w żądaniu. Jeśli ścieżka adresu URL w żądaniu jest zgodna ze wzorcem ścieżki w regule opartej na ścieżkach, reguła kieruje to żądanie. Stosuje on wzorzec ścieżki tylko do ścieżki adresu URL, a nie do parametrów zapytania. Jeśli ścieżka adresu URL żądania odbiornika nie jest zgodna z żadną regułą opartą na ścieżkach, kieruje żądanie do domyślnej puli zaplecza i ustawień PROTOKOŁU HTTP.

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. Jest to ogólny mechanizm przekierowywania, dzięki czemu można przekierować do i z dowolnego portu zdefiniowanego przy użyciu reguł.

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

Za pomocą reguł ponownego zapisywania można dodawać, usuwać lub aktualizować nagłówki żądań HTTP(S) i odpowiedzi, a także ścieżki adresu URL i parametrów ciągu zapytania, ponieważ pakiety żądań i odpowiedzi są przenoszone między pulami klienta i zaplecza za pośrednictwem bramy aplikacji.

Nagłówki i parametry adresu URL można ustawić na wartości statyczne, inne nagłówki lub zmienne serwera. Pomaga to w ważnych przypadkach użycia, takich jak wyodrębnianie adresów IP klienta, usuwanie poufnych informacji o zapleczu, dodawanie większej liczby zabezpieczeń itd.

Aby uzyskać więcej informacji, zobacz Ponowne zapisywanie nagłówków HTTP i adresów URL w bramie aplikacji.

Ustawienia protokołu HTTP

Brama aplikacji kieruje ruch do serwerów zaplecza (określonych w regule routingu żądań zawierającej ustawienia PROTOKOŁU HTTP) przy użyciu numeru portu, protokołu i innych ustawień opisanych w tym składniku.

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.

Ten składnik jest również używany do:

  • Ustal, czy sesja użytkownika ma być przechowywana na tym samym serwerze przy użyciu koligacji 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 serwerów backendowych kieruje żądania do serwerów, które je obsługują. Grupy zaplecza mogą zawierać:

  • Karty sieciowe
  • Zestawy do skalowania maszyn wirtualnych
  • Publiczne adresy IP
  • Wewnętrzne adresy IP
  • FQDN (Pełna nazwa domeny)
  • Systemy zaplecza wielodostępne (takie jak usługa App Service)

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 uaktualnisz wystąpień zestawów skalowania, zaplecze będzie w złej kondycji.

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. W przypadku korzystania z sond niestandardowych można skonfigurować niestandardową nazwę hosta, ścieżkę adresu URL, interwał sondy, a także liczbę nieudanych odpowiedzi, które można zaakceptować przed oznaczeniem instancji puli zaplecza jako niezdrowej, niestandardowe kody stanu oraz dopasowanie treści odpowiedzi, itp. Zalecamy skonfigurowanie sond niestandardowych, aby monitorować stan każdej puli zaplecza.

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

Następne kroki

Tworzenie bramy aplikacji: