Sieć w środowisku App Service Environment

App Service Environment to jednodostępne wdrożenie usługi aplikacja systemu Azure, która hostuje kontenery systemu Windows i Linux, aplikacje internetowe, aplikacje interfejsu API, aplikacje logiki i aplikacje funkcji. Po zainstalowaniu środowiska App Service Environment należy wybrać sieć wirtualną platformy Azure, w której ma zostać wdrożona. Cały ruch przychodzący i wychodzący aplikacji znajduje się w określonej sieci wirtualnej. Możesz wdrożyć się tylko w jedną podsieć w swojej sieci wirtualnej, a nic innego nie można wdrożyć w tej podsieci.

Wymagania dotyczące podsieci

Poniżej przedstawiono minimalny zestaw wymagań dla podsieci, w których znajduje się środowisko App Service Environment.

• Podsieć musi być delegowana do Microsoft.Web/hostingEnvironments.
• Podsieć musi być pusta.
• Właściwość podsieci addressPrefix musi być sformatowana jako ciąg, a nie tablica.

Rozmiar podsieci może mieć wpływ na limity skalowania wystąpień planu usługi App Service w środowisku App Service Environment. W przypadku skali produkcyjnej zalecamy przestrzeń adresową /24 (256 adresów) dla podsieci. Jeśli planujesz skalowanie niemal maksymalnej pojemności 200 wystąpień w naszym środowisku App Service Environment i planujesz częste operacje skalowania w górę/w dół, zalecamy przestrzeń adresową /23 (512 adresów) dla podsieci.

Jeśli używasz mniejszej podsieci, pamiętaj o następujących ograniczeniach:

• Każda określona podsieć ma pięć adresów zarezerwowanych do celów zarządzania. Oprócz adresów zarządzających środowisko App Service Environment dynamicznie skaluje infrastrukturę pomocniczą i używa od 7 do 27 adresów w zależności od konfiguracji i obciążenia. Pozostałe adresy można używać dla wystąpień w planie usługi App Service. Minimalny rozmiar podsieci to przestrzeń adresowa /27 (32 adresy).
• W przypadku dowolnej kombinacji systemu operacyjnego/jednostki SKU planu usługi App Service używanej w środowisku App Service Environment, takiej jak I1v2 Windows, na każde 20 aktywnych wystąpień jest tworzone jedno wystąpienie rezerwowe. Wystąpienia rezerwowe wymagają również adresów IP.
• Gdy skaluje się plany usługi App Service w środowisku App Service Environment w górę lub w dół, liczba adresów IP używanych przez plan usługi App Service jest tymczasowo podwojona w trakcie realizacji operacji skalowania. Nowe wystąpienia muszą być w pełni funkcjonalne, zanim istniejące wystąpienia zostaną zdezaktywowane.
• Uaktualnienia platformy wymagają bezpłatnych adresów IP, aby zapewnić, że uaktualnienia mogą wystąpić bez przerw w ruchu wychodzącym.
• Po zakończeniu operacji skalowania w górę, w dół lub do środka, może upłynąć krótki okres czasu przed zwolnieniem adresów IP. W rzadkich przypadkach ta operacja może potrwać do 12 godzin.
• Jeśli zabraknie adresów w podsieci, możesz ograniczyć skalowanie planów usługi App Service w środowisku App Service Environment. Inną możliwością jest zwiększenie opóźnienia podczas intensywnego obciążenia ruchem, jeśli firma Microsoft nie może skalować infrastruktury pomocniczej.

Uwaga

Kontenery Windows używają dodatkowego adresu IP dla każdej aplikacji w każdym wystąpieniu planu usługi App Service, i trzeba odpowiednio dobrać rozmiar podsieci. Jeśli twoje Środowisko usługi App Service ma na przykład 2 plany usługi App Service dla kontenerów Windows, każdy z 25 instancjami i 5 działającymi aplikacjami, będziesz potrzebować 300 adresów IP i dodatkowe adresy do obsługi poziomej skali.

Przykładowe obliczenie:

Dla każdego wystąpienia planu usługi App Service potrzebne są: 5 aplikacji kontenera systemu Windows = 5 adresów IP 1 adres IP na wystąpienie planu usługi App Service 5 + 1 = 6 adresów IP

W przypadku 25 instancji: 6 x 25 = 150 adresów IP na każdą usługę planu App Service

Ponieważ masz 2 plany usługi App Service, 2 x 150 = 300 adresów IP.

Adresy

Środowisko App Service Environment zawiera następujące informacje o sieci podczas tworzenia:

Typ adresu	opis
Sieć wirtualna środowiska App Service Environment	Sieć wirtualna została wdrożona.
Podsieć środowiska „App Service Environment”	Podsieć wdrożona w.
Sufiks domeny	Domyślny sufiks domeny używany przez aplikacje.
Sufiks domeny niestandardowej	(opcjonalnie) Sufiks domeny niestandardowej używany przez aplikacje.
Wirtualny adres IP (VIP)	Używany typ VIP. Dwie możliwe wartości są wewnętrzne i zewnętrzne.
Adres przychodzący	Adres przychodzący to adres, pod którym są osiągane twoje aplikacje. Jeśli masz wewnętrzny adres VIP, jest to adres w podsieci środowiska App Service Environment. Jeśli adres jest zewnętrzny, jest to adres publiczny.
Adresy wychodzące pracownika	Aplikacje używają tego lub tych adresów podczas wykonywania wywołań wychodzących do Internetu.
Adresy wychodzące platformy	Platforma używa tego adresu podczas wykonywania wywołań wychodzących do Internetu. Przykładem jest ściąganie certyfikatów dla niestandardowego sufiksu domeny z usługi Key Vault, jeśli prywatny punkt końcowy nie jest używany.

Szczegóły można znaleźć w części Adresy IP portalu — jak pokazano na poniższym zrzucie ekranu:

Podczas skalowania planów usługi App Service w środowisku App Service Environment użyj więcej adresów poza podsiecią. Liczba używanych adresów różni się w zależności od liczby wystąpień planu usługi App Service oraz ilości ruchu sieciowego. Aplikacje w środowisku App Service Environment nie mają dedykowanych adresów w podsieci. Określone adresy używane przez aplikację w podsieci zmienią się w czasie.

Przynieś swój własny adres przychodzący

Możesz dodać własny przychodzący adres IP do środowiska App Service Environment. Jeśli utworzysz środowisko App Service Environment z wewnętrznym adresem VIP, możesz określić statyczny adres IP w podsieci. Jeśli tworzysz środowisko App Service Environment z zewnętrznym adresem VIP, możesz użyć własnego publicznego adresu IP platformy Azure, określając identyfikator zasobu publicznego adresu IP. Poniżej przedstawiono ograniczenia dotyczące wprowadzenia własnego adresu przychodzącego:

• W przypadku środowiska App Service Environment z zewnętrznym adresem VIP zasób publicznego adresu IP platformy Azure musi znajdować się w tej samej subskrypcji co środowisko App Service Environment.
• Nie można zmienić adresu wejściowego po utworzeniu środowiska usługi App Service.

Porty i ograniczenia sieci

Aby aplikacja odbierała ruch, upewnij się, że reguły sieciowej grupy zabezpieczeń dla ruchu przychodzącego zezwalają podsieci środowiska App Service Environment na odbieranie ruchu z wymaganych portów. Oprócz wszystkich portów, na których chcesz odbierać ruch, upewnij się, że usługa Azure Load Balancer może nawiązać połączenie z podsiecią na porcie 80. Ten port jest używany do sprawdzania kondycji wewnętrznej maszyny wirtualnej. Nadal można kontrolować ruch na porcie 80 z sieci wirtualnej do podsieci.

Uwaga

Wprowadzenie zmian w regułach grup zabezpieczeń sieciowych może zacząć obowiązywać dopiero po 14 dniach z powodu trwałości połączenia HTTP. Jeśli wprowadzisz zmianę blokującą ruch platformy/zarządzania, może upłynąć do 14 dni, aż wpływ będzie widoczny.

Dobrym pomysłem jest skonfigurowanie następującej reguły NSG dla ruchu przychodzącego.

Porty źródłowe/docelowe	Kierunek	Źródło	Cel	Cel
* / 80,443	Przychodzący	VirtualNetwork	Zakres podsieci środowiska App Service Environment	Zezwalaj na ruch aplikacji i ruch ping monitorowania wewnętrznego

Minimalnym wymaganiem, aby środowisko App Service Environment działało, jest:

Porty źródłowe/docelowe	Kierunek	Źródło	Cel podróży	Cel
* / 80	Przychodzący	AzureLoadBalancer	Zakres podsieci środowiska App Service Environment	Zezwalaj na wewnętrzny ruch ping kondycji

Jeśli używasz minimalnej wymaganej reguły, może być konieczne użycie co najmniej jednej reguły dla ruchu aplikacji. Jeśli używasz dowolnej z opcji wdrażania lub debugowania, musisz również zezwolić na ten ruch do podsieci Środowiska App Service Environment. Źródłem tych reguł może być sieć wirtualna lub co najmniej jeden konkretny adres IP klienta lub zakresy adresów IP. Miejsce docelowe jest zawsze zakresem podsieci środowiska App Service Environment.

Wewnętrzny ruch ping kondycji na porcie 80 jest izolowany między modułem równoważenia obciążenia a serwerami wewnętrznymi. Żaden ruch zewnętrzny nie może dotrzeć do punktu końcowego ping kondycji.

Normalne porty dostępu do aplikacji dla ruchu przychodzącego są następujące:

Użyj	Porty
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Zdalne debugowanie programu Visual Studio	4022, 4024, 4026
Usługa Web Deploy	8172

Uwaga

Aby uzyskać dostęp do protokołu FTP, nawet jeśli nie chcesz zezwalać na standardowy protokół FTP na porcie 21, nadal musisz zezwolić na ruch z LoadBalancer do zakresu podsieci środowiska App Service Environment na porcie 21, ponieważ jest on używany do wewnętrznego ruchu ping dla kondycji usługi FTP.

Trasowanie sieci

Tabele tras można ustawić bez ograniczeń. Możesz tunelować cały wychodzący ruch aplikacji ze środowiska App Service do urządzenia zapory sieciowej, takiego jak Azure Firewall. W tym scenariuszu jedyną rzeczą, o którą musisz się martwić, jest zależności aplikacji.

Zależności aplikacji obejmują punkty końcowe, których aplikacja potrzebuje podczas wykonywania. Oprócz wywoływanych interfejsów API i usług, zależności mogą obejmować również pochodne punkty końcowe, takie jak punkty końcowe listy odwołań certyfikatów (CRL), punkty końcowe sprawdzania oraz punkty końcowe tożsamości/uwierzytelniania, na przykład Microsoft Entra ID. Jeśli używasz ciągłego wdrażania w usłudze App Service, może być również konieczne zezwolenie na punkty końcowe w zależności od typu i języka. W szczególności w przypadku ciągłego wdrażania systemu Linux należy zezwolić na usługę oryx-cdn.microsoft.io:443.

Urządzenia zapory aplikacji sieciowej, takie jak Azure Application Gateway, można umieścić przed ruchem przychodzącym. Dzięki temu można uwidocznić określone aplikacje w tym środowisku App Service Environment.

Aplikacja używa jednego z domyślnych adresów wychodzących dla ruchu wychodzącego do publicznych punktów końcowych. Jeśli chcesz dostosować adres wychodzący aplikacji w App Service Environment, możesz dodać bramkę NAT do podsieci.

Uwaga

Łączność wychodząca SMTP (port 25) jest obsługiwana dla środowiska App Service Environment w wersji 3. Możliwość obsługi jest określana przez ustawienie w subskrypcji, w której wdrażana jest sieć wirtualna. W przypadku sieci wirtualnych/podsieci utworzonych przed 1. W sierpniu 2022 r. należy zainicjować tymczasową zmianę konfiguracji w sieci wirtualnej/podsieci, aby ustawienie było synchronizowane z subskrypcji. Przykładem może być tymczasowe dodanie podsieci, tymczasowe powiązanie/rozłączenie sieciowej grupy zabezpieczeń lub tymczasowa konfiguracja punktu końcowego usługi. Aby uzyskać więcej informacji i rozwiązać problemy, zobacz Rozwiązywanie problemów z łącznością wychodzącą SMTP na platformie Azure.

Prywatny punkt końcowy

Aby włączyć prywatne punkty końcowe dla aplikacji hostowanych w środowisku App Service Environment, należy najpierw włączyć tę funkcję na poziomie środowiska App Service Environment.

Można ją aktywować za pośrednictwem witryny Azure Portal. W okienku konfiguracyjnym środowiska App Service Environment włącz ustawienie Allow new private endpoints. Alternatywnie można włączyć następujący CLI (interfejs wiersza polecenia):

az appservice ase update --name myasename --allow-new-private-endpoint-connections true

Aby uzyskać więcej informacji na temat prywatnego punktu końcowego i aplikacji internetowej, zobacz Prywatny punkt końcowy aplikacji internetowej platformy Azure

DNS

W poniższych sekcjach opisano zagadnienia i konfigurację systemu DNS, które dotyczą ruchu przychodzącego i wychodzącego ze środowiska App Service Environment. W przykładach użyto sufiksu appserviceenvironment.net domeny z chmury publicznej platformy Azure. Jeśli używasz innych chmur, takich jak Azure Government, musisz użyć odpowiedniego sufiksu domeny. W przypadku domen środowiska App Service Environment nazwa witryny jest obcięta na 59 znaków z powodu limitów DNS. W przypadku domen środowiska App Service Environment z slotami nazwa witryny jest skrócona do 40 znaków, a nazwa slotu do 19 znaków z powodu ograniczeń DNS.

Konfiguracja DNS w środowisku App Service Environment

Jeśli środowisko App Service Environment jest tworzone przy użyciu zewnętrznego adresu VIP, aplikacje są automatycznie umieszczane w publicznym systemie DNS. Jeśli środowisko App Service Environment jest tworzone przy użyciu wewnętrznego adresu VIP, masz dwie opcje podczas tworzenia środowiska App Service Environment. Jeśli wybierzesz automatyczne skonfigurowanie stref prywatnych usługi Azure DNS, usługa DNS zostanie skonfigurowana w sieci wirtualnej. Jeśli zdecydujesz się skonfigurować usługę DNS ręcznie, musisz użyć własnego serwera DNS lub skonfigurować strefy prywatne usługi Azure DNS. Aby znaleźć adres przychodzący, przejdź do portalu środowiska App Service Environment i wybierz pozycję Adresy IP.

Jeśli chcesz użyć własnego serwera DNS, dodaj następujące rekordy:

1. Utwórz strefę dla elementu <App Service Environment-name>.appserviceenvironment.net.
2. Utwórz rekord A w tej strefie, który wskazuje na przychodzący adres IP używany przez twoje środowisko App Service.
3. Utwórz rekord A w tej strefie, który wskazuje znak @ na przychodzący adres IP używany przez środowisko App Service Environment.
4. Utwórz strefę pod <App Service Environment-name>.appserviceenvironment.net, nazwaną scm.
5. Utwórz rekord A w strefie scm, który wskazuje na adres IP używany przez prywatny punkt końcowy środowiska App Service Environment.

Aby skonfigurować usługę DNS w strefach prywatnych usługi Azure DNS:

1. Utwórz strefę prywatną usługi Azure DNS o nazwie <App Service Environment-name>.appserviceenvironment.net.
2. Utwórz rekord A w tej strefie, który wskazuje * na przychodzący adres IP.
3. Utwórz rekord A w tej strefie, który wskazuje znak @ na przychodzący adres IP.
4. Utwórz rekord A w tej strefie, który wskazuje *.scm na przychodzący adres IP.

Oprócz domeny domyślnej udostępnianej podczas tworzenia aplikacji można również dodać domenę niestandardową do aplikacji. Możesz ustawić niestandardową nazwę domeny bez sprawdzania poprawności w aplikacjach. Jeśli używasz domen niestandardowych, musisz upewnić się, że mają skonfigurowane rekordy DNS. Możesz postępować zgodnie z powyższymi wskazówkami, aby skonfigurować strefy DNS i rekordy dla niestandardowej nazwy domeny (zastąp domyślną nazwę domeny niestandardową nazwą domeny). Nazwa domeny niestandardowej działa dla żądań aplikacji, ale nie działa dla scm witryny. Witryna scm jest dostępna tylko pod <appname>.scm.<asename>.appserviceenvironment.net.

Konfiguracja DNS na potrzeby dostępu ftp

Aby uzyskać dostęp FTP do wewnętrznego mechanizmu równoważenia obciążenia (ILB) w środowisku App Service Environment w wersji 3, należy upewnić się, że system DNS jest skonfigurowany. Skonfiguruj strefę prywatną usługi Azure DNS lub równoważną niestandardową usługę DNS przy użyciu następujących ustawień:

1. Utwórz strefę prywatną usługi Azure DNS o nazwie ftp.appserviceenvironment.net.
2. Utwórz rekord A w tej strefie, który wskazuje <App Service Environment-name> na adres IP wejściowy.

Oprócz konfigurowania systemu DNS należy ją również włączyć w konfiguracji środowiska App Service Environment i na poziomie aplikacji.

Konfiguracja DNS ze środowiska App Service Environment

Aplikacje w środowisku App Service Environment używają DNS skonfigurowanego w twojej sieci wirtualnej. Jeśli chcesz, aby niektóre aplikacje używały innego serwera DNS, możesz ręcznie ustawić je dla poszczególnych aplikacji przy użyciu ustawień WEBSITE_DNS_SERVER aplikacji i WEBSITE_DNS_ALT_SERVER. WEBSITE_DNS_ALT_SERVER Konfiguruje pomocniczy serwer DNS. Pomocniczy serwer DNS jest używany tylko wtedy, gdy nie ma odpowiedzi z podstawowego serwera DNS.

Więcej zasobów

• Dokumentacja zmiennych środowiskowych i ustawień aplikacji