Omówienie architektury sieciowej środowisk usługi App Service

Ważne

Ten artykuł dotyczy środowiska App Service Environment w wersji 1. Środowisko App Service Environment w wersji 1 zostanie wycofane 31 sierpnia 2024 r. Jest dostępna nowa wersja środowiska App Service Environment, która jest łatwiejsza do użycia i działa w bardziej wydajnej infrastrukturze. Aby dowiedzieć się więcej o nowej wersji, zacznij od wprowadzenia do środowiska App Service Environment. Jeśli obecnie używasz środowiska App Service Environment w wersji 1, wykonaj kroki opisane w tym artykule , aby przeprowadzić migrację do nowej wersji.

Od 29 stycznia 2024 r. nie można już tworzyć nowych zasobów środowiska App Service Environment w wersji 1 przy użyciu dowolnej z dostępnych metod, w tym szablonów usługi ARM/Bicep, witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST. Aby zapobiec usunięciu zasobów i utracie danych, musisz przeprowadzić migrację do środowiska App Service Environment w wersji 3 przed 31 sierpnia 2024 r.

Środowiska App Service Environment są zawsze tworzone w podsieci sieci wirtualnej — aplikacje działające w środowisku App Service Environment mogą komunikować się z prywatnymi punktami końcowymi znajdującymi się w tej samej topologii sieci wirtualnej. Ponieważ klienci mogą blokować części infrastruktury sieci wirtualnej, ważne jest, aby zrozumieć typy przepływów komunikacji sieciowej występujących w środowisku App Service Environment.

Ogólny przepływ sieci

Gdy środowisko App Service Environment (ASE) używa publicznego wirtualnego adresu IP (VIP) dla aplikacji, cały ruch przychodzący dociera do tego publicznego adresu VIP. Obejmuje to ruch HTTP i HTTPS dla aplikacji oraz inny ruch dla protokołu FTP, funkcje zdalnego debugowania i operacje zarządzania platformy Azure. Aby uzyskać pełną listę określonych portów (wymaganych i opcjonalnych), które są dostępne na publicznym adresie VIP, zobacz artykuł dotyczący kontrolowania ruchu przychodzącego do środowiska App Service Environment.

Środowiska App Service Environment obsługują również uruchamianie aplikacji powiązanych tylko z adresem wewnętrznym sieci wirtualnej, nazywanym również adresem wewnętrznego modułu równoważenia obciążenia (wewnętrznego modułu równoważenia obciążenia). W przypadku środowiska ASE z włączonym wewnętrznym modułem równoważenia obciążenia, ruchem HTTP i HTTPS dla aplikacji i wywołań zdalnego debugowania są odbierane na adres wewnętrznym modułu równoważenia obciążenia. W przypadku najpopularniejszych konfiguracji środowiska ILB-ASE ruch FTP/FTPS również zostanie dostarczony na adres ILB. Jednak operacje zarządzania platformy Azure nadal będą przepływać do portów 454/455 na publicznym adresie VIP środowiska ASE z włączonym wewnętrznym modułem równoważenia obciążenia.

Na poniższym diagramie przedstawiono przegląd różnych przepływów sieci przychodzących i wychodzących dla środowiska App Service Environment, w którym aplikacje są powiązane z publicznym wirtualnym adresem IP:

Środowisko App Service Environment może komunikować się z prywatnymi punktami końcowymi klienta. Na przykład aplikacje uruchomione w środowisku App Service Environment mogą łączyć się z serwerami baz danych uruchomionymi na maszynach wirtualnych IaaS w tej samej topologii sieci wirtualnej.

Ważne

Patrząc na diagram sieci, "Inne zasoby obliczeniowe" są wdrażane w innej podsieci od środowiska App Service Environment. Wdrażanie zasobów w tej samej podsieci przy użyciu środowiska ASE spowoduje zablokowanie łączności ze środowiska ASE z tymi zasobami (z wyjątkiem określonego routingu wewnątrz środowiska ASE). Wdróż w innej podsieci (w tej samej sieci wirtualnej). Następnie środowisko App Service Environment będzie mogło nawiązać połączenie. Nie jest wymagana żadna dodatkowa konfiguracja.

Środowiska App Service Environment komunikują się również z zasobami usługi Sql DB i Azure Storage niezbędnymi do zarządzania środowiskiem App Service Environment i zarządzania nim. Niektóre zasoby sql i storage, z którymi komunikuje się środowisko App Service Environment, znajdują się w tym samym regionie co środowisko App Service Environment, a inne znajdują się w zdalnych regionach świadczenia usługi Azure. W związku z tym łączność wychodząca z Internetem jest zawsze wymagana, aby środowisko App Service Environment działało prawidłowo.

Ponieważ środowisko App Service Environment jest wdrażane w podsieci, sieciowe grupy zabezpieczeń mogą służyć do kontrolowania ruchu przychodzącego do podsieci. Aby uzyskać szczegółowe informacje na temat kontrolowania ruchu przychodzącego do środowiska App Service Environment, zobacz następujący artykuł.

Aby uzyskać szczegółowe informacje na temat zezwalania na wychodzącą łączność internetową ze środowiska App Service Environment, zobacz następujący artykuł dotyczący pracy z usługą Express Route. To samo podejście opisane w artykule ma zastosowanie podczas pracy z łącznością typu lokacja-lokacja i korzystania z wymuszonego tunelowania.

Wychodzące adresy sieciowe

Gdy środowisko App Service Environment wykonuje wywołania wychodzące, adres IP jest zawsze skojarzony z wywołaniami wychodzącymi. Określony używany adres IP zależy od tego, czy wywoływany punkt końcowy znajduje się w topologii sieci wirtualnej, czy poza topologią sieci wirtualnej.

Jeśli wywoływany punkt końcowy znajduje się poza topologią sieci wirtualnej, adres wychodzący (znany również jako adres NAT ruchu wychodzącego), który jest używany, jest publicznym adresem VIP środowiska App Service Environment. Ten adres można znaleźć w interfejsie użytkownika portalu dla środowiska App Service Environment w sekcji Właściwości.

Ten adres można również określić dla środowisk ASE, które mają tylko publiczny adres VIP, tworząc aplikację w środowisku App Service Environment, a następnie wykonując polecenie nslookup na adresie aplikacji. Wynikowy adres IP jest zarówno publicznym adresem VIP, jak i wychodzącym adresem NAT środowiska App Service Environment.

Jeśli wywoływany punkt końcowy znajduje się wewnątrz topologii sieci wirtualnej, adres wychodzący aplikacji wywołującej będzie wewnętrznym adresem IP pojedynczego zasobu obliczeniowego, na którym działa aplikacja. Nie ma jednak trwałego mapowania wewnętrznych adresów IP sieci wirtualnej na aplikacje. Aplikacje mogą poruszać się między różnymi zasobami obliczeniowymi, a pula dostępnych zasobów obliczeniowych w środowisku App Service Environment może ulec zmianie z powodu operacji skalowania.

Jednak ponieważ środowisko App Service Environment zawsze znajduje się w podsieci, gwarantowane jest, że wewnętrzny adres IP zasobu obliczeniowego, na którym działa aplikacja, będzie zawsze znajdować się w zakresie CIDR podsieci. W związku z tym, gdy szczegółowe listy ACL lub sieciowe grupy zabezpieczeń są używane do zabezpieczania dostępu do innych punktów końcowych w sieci wirtualnej, zakres podsieci zawierający środowisko App Service Environment musi mieć dostęp.

Na poniższym diagramie przedstawiono te pojęcia bardziej szczegółowo:

Na powyższym diagramie:

• Ponieważ publiczny adres VIP środowiska App Service Environment to 192.23.1.2, jest to adres IP ruchu wychodzącego używany podczas wykonywania wywołań do punktów końcowych "Internet".
• Zakres CIDR zawierającej podsieć dla środowiska App Service Environment to 10.0.1.0/26. Inne punkty końcowe w ramach tej samej infrastruktury sieci wirtualnej będą widzieć wywołania z aplikacji pochodzące z gdzieś w tym zakresie adresów.

Wywołania między środowiskami usługi App Service

Bardziej złożony scenariusz może wystąpić, jeśli wdrożysz wiele środowisk App Service Environment w tej samej sieci wirtualnej i wykonasz wywołania wychodzące z jednego środowiska App Service Environment do innego środowiska App Service Environment. Te typy wywołań środowiska App Service Environment będą również traktowane jako wywołania "Internet".

Na poniższym diagramie przedstawiono przykład architektury warstwowej z aplikacjami w jednym środowisku App Service Environment (na przykład "Front door" web apps) wywołującym aplikacje w drugim środowisku App Service Environment (na przykład wewnętrzne aplikacje interfejsu API zaplecza, które nie mają być dostępne z Internetu).

W powyższym przykładzie środowisko App Service Environment "ASE One" ma wychodzący adres IP 192.23.1.2. Jeśli aplikacja uruchomiona w tym środowisku App Service Environment wykonuje wywołanie wychodzące do aplikacji uruchomionej w drugim środowisku App Service Environment ("ASE Two") znajdującym się w tej samej sieci wirtualnej, wywołanie ruchu wychodzącego będzie traktowane jako wywołanie "Internet". W rezultacie ruch sieciowy przychodzący do drugiego środowiska App Service Environment będzie wyświetlany jako pochodzący z wersji 192.23.1.2 (czyli nie zakres adresów podsieci pierwszego środowiska App Service Environment).

Mimo że wywołania między różnymi środowiskami App Service Environment są traktowane jako wywołania "Internet", gdy oba środowiska App Service Environment znajdują się w tym samym regionie świadczenia usługi Azure, ruch sieciowy pozostanie w regionalnej sieci platformy Azure i nie będzie fizycznie przepływać przez publiczny Internet. W rezultacie można użyć sieciowej grupy zabezpieczeń w podsieci drugiego środowiska App Service Environment, aby zezwolić tylko na połączenia przychodzące z pierwszego środowiska App Service Environment (którego wychodzący adres IP to 192.23.1.2), zapewniając w ten sposób bezpieczną komunikację między środowiskami App Service Environment.

Dodatkowe linki i informacje

Szczegółowe informacje na temat portów przychodzących używanych przez środowiska App Service Environment i używania sieciowych grup zabezpieczeń do kontrolowania ruchu przychodzącego są dostępne tutaj.

Szczegółowe informacje na temat używania tras zdefiniowanych przez użytkownika w celu udzielenia wychodzącego dostępu do Internetu w środowiskach App Service Environment są dostępne w tym artykule.