Udostępnij za pośrednictwem

Ruch przychodzący w usłudze Azure Container Apps

  • Artykuł

Usługa Azure Container Apps umożliwia uwidocznienie aplikacji kontenera w publicznej sieci Web, sieci wirtualnej i innych aplikacji kontenerów w środowisku przez włączenie ruchu przychodzącego. Ustawienia ruchu przychodzącego są wymuszane za pomocą zestawu reguł kontrolujących routing ruchu zewnętrznego i wewnętrznego do aplikacji kontenera. Po włączeniu ruchu przychodzącego nie musisz tworzyć usługi Azure Load Balancer, publicznego adresu IP ani żadnych innych zasobów platformy Azure w celu włączenia przychodzących żądań HTTP lub ruchu TCP.

Ruch przychodzący obsługuje:

Przykładowa konfiguracja ruchu przychodzącego przedstawiająca podział ruchu przychodzącego między dwie poprawki:

Diagram przedstawiający konfigurację ruchu przychodzącego dzielącą ruch między dwie poprawki.

Aby uzyskać szczegółowe informacje o konfiguracji, zobacz Konfigurowanie ruchu przychodzącego.

Ruch przychodzący zewnętrzny i wewnętrzny

Po włączeniu ruchu przychodzącego można wybrać między dwoma typami ruchu przychodzącego:

  • Zewnętrzne: akceptuje ruch zarówno z publicznego Internetu, jak i środowiska wewnętrznego aplikacji kontenera.
  • Wewnętrzne: zezwala tylko na dostęp wewnętrzny z poziomu środowiska aplikacji kontenera.

Każda aplikacja kontenera w środowisku może być skonfigurowana przy użyciu różnych ustawień ruchu przychodzącego. Na przykład w scenariuszu z wieloma aplikacjami mikrousług w celu zwiększenia bezpieczeństwa może istnieć jedna aplikacja kontenera, która odbiera żądania publiczne i przekazuje żądania do usługi w tle. W tym scenariuszu skonfigurujesz publiczną aplikację kontenera z zewnętrznymi ruchami przychodzącymi i wewnętrzną aplikacją kontenera z wewnętrznymi ruchami przychodzącymi.

Typy protokołów

Usługa Container Apps obsługuje dwa protokoły dla ruchu przychodzącego: HTTP i TCP.

HTTP

Po włączeniu ruchu przychodzącego HTTP aplikacja kontenera ma:

  • Obsługa kończenia żądań protokołu TLS
  • Obsługa protokołów HTTP/1.1 i HTTP/2
  • Obsługa protokołu WebSocket i gRPC
  • Punkty końcowe HTTPS, które zawsze używają protokołu TLS 1.2 lub 1.3, zakończone w punkcie ruchu przychodzącego
  • Punkty końcowe, które uwidaczniają porty 80 (dla protokołu HTTP) i 443 (dla protokołu HTTPS)
    • Domyślnie żądania HTTP do portu 80 są automatycznie przekierowywane do protokołu HTTPS na 443
  • W pełni kwalifikowana nazwa domeny (FQDN)
  • Limit czasu żądania wynosi 240 sekund

Nagłówki HTTP

Ruch przychodzący HTTP dodaje nagłówki w celu przekazania metadanych dotyczących żądania klienta do aplikacji kontenera. Na przykład X-Forwarded-Proto nagłówek służy do identyfikowania protokołu używanego przez klienta do nawiązywania połączenia z usługą Container Apps. W poniższej tabeli wymieniono nagłówki HTTP, które są istotne dla ruchu przychodzącego w usłudze Container Apps:

Nagłówek opis Wartości
X-Forwarded-Proto Protokół używany przez klienta do nawiązywania połączenia z usługą Container Apps. http lub https
X-Forwarded-For Adres IP klienta, który wysłał żądanie.
X-Forwarded-Host Nazwa hosta używanego do nawiązywania połączenia z usługą Container Apps.
X-Forwarded-Client-Cert Certyfikat klienta, jeśli clientCertificateMode został ustawiony. Rozdzielana średnikami lista skrótów, certyfikatów i łańcuchów. Na przykład: Hash=....;Cert="...";Chain="...";.

TCP

Usługa Container Apps obsługuje protokoły oparte na protokole TCP inne niż HTTP lub HTTPS. Na przykład możesz użyć ruchu przychodzącego TCP, aby uwidocznić aplikację kontenera korzystającą z protokołu Redis.

Uwaga

Zewnętrzny ruch przychodzący TCP jest obsługiwany tylko w środowiskach usługi Container Apps korzystających z niestandardowej sieci wirtualnej. Ruch przychodzący TCP nie jest obsługiwany w przypadku aplikacji, które akceptują ruch przychodzący za pośrednictwem prywatnego punktu końcowego.

Po włączeniu ruchu przychodzącego TCP aplikacja kontenera:

  • Jest dostępny dla innych aplikacji kontenerów w tym samym środowisku za pośrednictwem jego nazwy (zdefiniowanej name przez właściwość w zasobie usługi Container Apps) i uwidocznionego numeru portu.
  • Jest dostępny zewnętrznie za pośrednictwem w pełni kwalifikowanej nazwy domeny (FQDN) i uwidoczniony numer portu, jeśli dla ruchu przychodzącego ustawiono wartość external.

Dodatkowe porty TCP

Oprócz głównego portu HTTP/TCP dla aplikacji kontenera można uwidocznić dodatkowe porty TCP, aby umożliwić aplikacjom akceptowanie połączeń TCP na wielu portach.

Uwaga

Aby korzystać z tej funkcji, musisz mieć rozszerzenie interfejsu wiersza polecenia aplikacji kontenera. Uruchom polecenie az extension add -n containerapp , aby zainstalować najnowszą wersję rozszerzenia interfejsu wiersza polecenia aplikacji kontenera.

Następujące elementy dotyczą dodatkowych portów TCP:

  • Dodatkowe porty TCP mogą być zewnętrzne tylko wtedy, gdy sama aplikacja jest ustawiona jako zewnętrzna, a aplikacja kontenera używa niestandardowej sieci wirtualnej.
  • Wszystkie zewnętrzne uwidocznione dodatkowe porty TCP muszą być unikatowe w całym środowisku usługi Container Apps. Obejmuje to wszystkie zewnętrzne dodatkowe porty TCP, zewnętrzne główne porty TCP i porty 80/443 używane przez wbudowany ruch przychodzący HTTP. Jeśli dodatkowe porty są wewnętrzne, ten sam port może być współużytkowany przez wiele aplikacji.
  • Jeśli nie podano uwidocznionego portu, uwidoczniony port będzie domyślnie zgodny z portem docelowym.
  • Każdy port docelowy musi być unikatowy, a ten sam port docelowy nie może być uwidoczniony na różnych uwidocznionych portach.
  • Istnieje maksymalnie pięć dodatkowych portów na aplikację. Jeśli wymagane są dodatkowe porty, otwórz wniosek o pomoc techniczną.
  • Tylko główny port przychodzący obsługuje wbudowane funkcje HTTP, takie jak CORS i koligacja sesji. W przypadku uruchamiania protokołu HTTP na dodatkowych portach TCP te wbudowane funkcje nie są obsługiwane.

Zapoznaj się z artykułem dotyczącym ruchu przychodzącego , aby uzyskać więcej informacji na temat włączania dodatkowych portów dla aplikacji kontenerów.

Nazwy domen

Dostęp do aplikacji można uzyskać w następujący sposób:

  • Domyślna w pełni kwalifikowana nazwa domeny (FQDN): każda aplikacja w środowisku usługi Container Apps jest automatycznie przypisywana nazwa FQDN na podstawie sufiksu DNS środowiska. Aby dostosować sufiks DNS środowiska, zobacz Niestandardowy sufiks DNS środowiska.
  • Niestandardowa nazwa domeny: możesz skonfigurować niestandardową domenę DNS dla środowiska usługi Container Apps. Aby uzyskać więcej informacji, zobacz Niestandardowe nazwy domen i certyfikaty.
  • Nazwa aplikacji: możesz użyć nazwy aplikacji do komunikacji między aplikacjami w tym samym środowisku.

Aby uzyskać nazwę FQDN aplikacji, zobacz Lokalizacja.

Ograniczenia adresów IP

Usługa Container Apps obsługuje ograniczenia adresów IP dla ruchu przychodzącego. Możesz utworzyć reguły, aby skonfigurować adresy IP, które są dozwolone lub blokowane dostęp do aplikacji kontenera. Aby uzyskać więcej informacji, zobacz Konfigurowanie ograniczeń adresów IP.

Uwierzytelnianie

Usługa Azure Container Apps udostępnia wbudowane funkcje uwierzytelniania i autoryzacji w celu zabezpieczenia zewnętrznej aplikacji kontenera z obsługą ruchu przychodzącego. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie i autoryzacja w usłudze Azure Container Apps.

Aplikację można skonfigurować tak, aby obsługiwała certyfikaty klienta (mTLS) na potrzeby uwierzytelniania i szyfrowania ruchu. Aby uzyskać więcej informacji, zobacz Konfigurowanie certyfikatów klienta.

Aby uzyskać szczegółowe informacje na temat korzystania z szyfrowania sieci na poziomie środowiska równorzędnego, zobacz omówienie sieci.

Dzielenie ruchu

Usługa Containers Apps umożliwia podzielenie ruchu przychodzącego między aktywne poprawki. Podczas definiowania reguły dzielenia przypisuje się procent ruchu przychodzącego, aby przejść do różnych poprawek. Aby uzyskać więcej informacji, zobacz Podział ruchu.

Koligacja sesji

Koligacja sesji, znana również jako sesje sticky, to funkcja, która umożliwia kierowanie wszystkich żądań HTTP od klienta do tej samej repliki aplikacji kontenera. Ta funkcja jest przydatna w przypadku aplikacji stanowych, które wymagają spójnego połączenia z tą samą repliką. Aby uzyskać więcej informacji, zobacz Koligacja sesji.

Współużytkowanie zasobów między źródłami (CORS)

Domyślnie wszystkie żądania wysyłane za pośrednictwem przeglądarki ze strony do domeny, która nie jest zgodna z domeną pochodzenia strony, są blokowane. Aby uniknąć tego ograniczenia dla usług wdrożonych w usłudze Container Apps, możesz włączyć współużytkowanie zasobów między źródłami (CORS).

Aby uzyskać więcej informacji, zobacz Konfigurowanie mechanizmu CORS w usłudze Azure Container Apps.

Następne kroki

Konfigurowanie ruchu przychodzącego