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 zaplecza, w tym maszyn wirtualnych platformy Azure, zestawów skalowania maszyn wirtualnych, aplikacja systemu Azure 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 utworzeniu adres IP frontonu jest skojarzony z odbiornikiem.
Statyczny i dynamiczny publiczny adres IP
Jednostkę SKU bramy aplikacja systemu Azure w wersji 2 można skonfigurować tak, aby obsługiwała zarówno statyczny wewnętrzny adres IP, jak i statyczny publiczny adres IP lub tylko statyczny publiczny adres IP. 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ę w uruchomionej bramie. Może ona ulec zmianie tylko po zatrzymaniu lub uruchomieniu bramy. 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 wykryciu przez odbiornik żądań przychodzących od klientów brama aplikacji kieruje te żądania do członków w puli zaplecza skonfigurowanej w regule.
Odbiorniki obsługują następujące porty i protokoły.
Porty
Port to miejsce, w którym odbiornik nasłuchuje żądania klienta. Porty dla jednostek SKU w wersji 1 i 2 można skonfigurować zgodnie z poniższymi wymaganiami.
| SKU | Obsługiwany zakres portów | Wyjątki |
|---|---|---|
| Wersja 2 | Od 1 do 64999 | 22 |
| Wersja 1 | Od 1 do 65502 | 3389 |
Protokoły
Usługa Application Gateway obsługuje protokoły internetowe HTTP, HTTPS, HTTP/2 i WebSocket z serwerem proxy warstwy 7. Protokoły TLS i TCP są obsługiwane przy użyciu serwera proxy warstwy 4 (wersja zapoznawcza) i można je skonfigurować na tym samym zasobie.
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ć.
- Wybierz między protokołami HTTP, HTTPS, TLS lub TCP w konfiguracji odbiornika.
- 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 obiektów WebSocket zarówno z odbiornikami HTTP, jak i HTTPS.
Użyj odbiornika HTTPS lub TLS na potrzeby kończenia żądań protokołu TLS. Odbiornik HTTPS/TLS odciąża szyfrowanie i odszyfrowywanie do bramy aplikacji, więc serwery nie są obciążone obciążeniem obliczeń.
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. W przypadku niestandardowych stron błędów możesz użyć własnych oznakowań i układu. 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:
Basic. Ten typ odbiornika nasłuchuje pojedynczej lokacji domeny, gdzie ma pojedyncze mapowanie DNS na adres IP bramy aplikacji. Ta konfiguracja odbiornika jest wymagana w przypadku hostowania pojedynczej lokacji 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 zaplecza. Na przykład trzy domeny — contoso.com, fabrikam.com i adatum.com — wskazują adres IP bramy aplikacji. Utworzysz trzy odbiorniki z wieloma lokacjami i skonfigurujesz każdy odbiornik dla odpowiedniego 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 odbiorniku.
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 routingu żądań zawiera również pulę zaplecza, do której ma być kierowana, oraz ustawienie HTTP, do którego wymieniono port zaplecza, protokół itp.
Żądanie reguł rozsyłania
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 odbiornik może być dołączony do jednej reguły.
Istnieją dwa typy reguł routingu żądań:
Basic. 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 w 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 lub inne nagłówki i 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.
Bezpiecznie usuń elementy członkowskie puli zaplecza przy użyciu 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.
Pule zaplecza
Pula zaplecza kieruje żądania do serwerów zaplecza, które obsługują żądanie. Pule zaplecza mogą zawierać:
- Karty sieciowe NIC
- Zestawy skalowania maszyn wirtualnych
- Publiczne adresy IP
- Wewnętrzne adresy IP
- Nazwa FQDN
- Wielodostępne zaplecza (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órych 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ć komunikacji równorzędnej sieci wirtualnej lub bramy sieci VPN. Komunikacja równorzędna sieci wirtualnych jest obsługiwana i korzystna dla ruchu równoważenia obciążenia w innych sieciach wirtualnych.
Brama aplikacji może również komunikować się z serwerami lokalnymi, gdy są połączone przez tunele usługi Azure ExpressRoute lub VPN, jeśli ruch jest dozwolony.
Możesz utworzyć różne pule zaplecza 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 elementu członkowskiego puli zaplecza należy uaktualnić 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 wystąpienia w złej kondycji i dodaje je z powrotem do puli zaplecza w dobrej kondycji, gdy staną się dostępne i reagują na sondy kondycji.
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 i liczbę nieudanych odpowiedzi do zaakceptowania przed oznaczeniem wystąpienia puli zaplecza jako w złej kondycji, niestandardowych kodów stanu i dopasowania treści odpowiedzi itp. Zalecamy skonfigurowanie sond niestandardowych w celu monitorowania kondycji każdej puli zaplecza.
Aby uzyskać więcej informacji, zobacz Monitorowanie kondycji bramy aplikacji.
Następne kroki
Tworzenie bramy aplikacji: