Sieć środowiska 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. Wdrożenie w jednej podsieci w sieci wirtualnej i nic innego nie można wdrożyć w tej podsieci.
Uwaga
Ten artykuł dotyczy środowiska App Service Environment w wersji 3, który jest używany z planami izolowanej usługi App Service w wersji 2.
Wymagania dotyczące podsieci
Musisz delegować podsieć do Microsoft.Web/hostingEnvironments, a podsieć musi być pusta.
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ądzania środowisko App Service Environment dynamicznie skaluje infrastrukturę pomocniczą i używa między adresami 7 i 27 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, dla każdego 20 aktywnych wystąpień jest tworzone jedno wystąpienie rezerwowe. Wystąpienia rezerwowe wymagają również adresów IP.
- Podczas skalowania planów usługi App Service w środowisku App Service Environment w górę/w dół ilość adresów IP używanych przez plan usługi App Service jest tymczasowo podwoina podczas wykonywania operacji skalowania. Nowe wystąpienia muszą być w pełni funkcjonalne, zanim istniejące wystąpienia zostaną anulowane.
- Uaktualnienia platformy wymagają bezpłatnych adresów IP, aby zapewnić, że uaktualnienia mogą wystąpić bez przerw w ruchu wychodzącym.
- Po zakończeniu skalowania w górę, w dół lub w dół 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 systemu Windows używają dodatkowego adresu IP na aplikację dla każdego wystąpienia planu usługi App Service i należy odpowiednio rozmiesić podsieć. Jeśli środowisko App Service Environment ma na przykład 2 plany usługi App Service kontenera systemu Windows z 25 wystąpieniami i każdy z 5 uruchomionymi aplikacjami, będzie potrzebnych 300 adresów IP i dodatkowych adresów do obsługi skali poziomej (w poziomie/w poziomie).
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 wystąpień: 6 x 25 = 150 adresów IP na plan usługi 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 wdrożona w programie . |
| Podsieć środowiska App Service Environment | Podsieć wdrożona w. |
| Sufiks domeny | Sufiks domeny używany przez aplikacje. |
| Wirtualny adres IP (VIP) | Używany typ adresu 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. |
| Domyślne adresy wychodzące | Aplikacje używają tego adresu domyślnie podczas wykonywania wywołań wychodzących do Internetu. |
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 i liczby wystąpień dostępnych w usłudze App Service oraz liczby wystąpień ruchu. 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.
Korzystanie z własnego adresu przychodzącego
Możesz przenieść własny adres przychodzący 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 przychodzącego po utworzeniu środowiska App Service Environment.
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 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.
Dobrym pomysłem jest skonfigurowanie następującej reguły sieciowej grupy zabezpieczeń dla ruchu przychodzącego:
| Porty źródłowe/docelowe | Kierunek | Element źródłowy | Element docelowy | Purpose |
|---|---|---|---|---|
| * / 80,443 | Przychodzący | VirtualNetwork | Zakres podsieci środowiska App Service Environment | Zezwalaj na ruch w aplikacji i ruch ping kondycji wewnętrznej |
Minimalnym wymaganiem, aby środowisko App Service Environment działało, jest:
| Porty źródłowe/docelowe | Kierunek | Element źródłowy | Element docelowy | Purpose |
|---|---|---|---|---|
| * / 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żywanie | 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 modułu LoadBalancer do zakresu podsieci środowiska App Service Environment na porcie 21, ponieważ jest on używany do wewnętrznego ruchu ping kondycji dla usługi FTP specjalnie.
Routing sieciowy
Tabele tras można ustawić bez ograniczeń. Możesz tunelować cały ruch aplikacji wychodzącej ze środowiska App Service Environment do urządzenia zapory ruchu wychodzącego, takiego jak usługa 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, które wywołuje aplikacja, zależności mogą być również punktami końcowymi pochodnymi, takimi jak lista odwołania certyfikatów (CRL), sprawdzanie punktów końcowych i punktów końcowych tożsamości/uwierzytelniania, na przykład identyfikator entra firmy Microsoft. 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 internetowej, takie jak aplikacja systemu Azure 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 środowisku App Service Environment, możesz dodać bramę translatora adresów sieciowych 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 jest wdrażana 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ć dodanie tymczasowej podsieci, tymczasowe skojarzenie/skojarzenie sieciowej grupy zabezpieczeń lub tymczasowe skonfigurowanie 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 Konfiguracja środowiska App Service Environment włącz ustawienie Allow new private endpoints.
Alternatywnie można włączyć następujący 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 o 40 znaków z powodu limitów DNS. Jeśli masz miejsce, nazwa miejsca jest obcięta o 19 znaków.
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, 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:
- Utwórz strefę dla elementu
<App Service Environment-name>.appserviceenvironment.net. - Utwórz rekord A w tej strefie, który wskazuje * na przychodzący adres IP używany przez środowisko App Service Environment.
- Utwórz rekord A w tej strefie, który wskazuje znak @ na przychodzący adres IP używany przez środowisko App Service Environment.
- Utwórz strefę o
<App Service Environment-name>.appserviceenvironment.netnazwiescm. - Utwórz rekord A w
scmstrefie, która 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:
- Utwórz strefę prywatną usługi Azure DNS o nazwie
<App Service Environment-name>.appserviceenvironment.net. - Utwórz rekord A w tej strefie, który wskazuje * na przychodzący adres IP.
- Utwórz rekord A w tej strefie, który wskazuje znak @ na przychodzący adres IP.
- 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 <adresem appname.scm>.<asename.appserviceenvironment.net>.
Konfiguracja DNS na potrzeby dostępu ftp
Aby dostęp FTP do wewnętrznego modułu równoważenia obciążenia (ILB) 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ń:
- Utwórz strefę prywatną usługi Azure DNS o nazwie
ftp.appserviceenvironment.net. - Utwórz rekord A w tej strefie, który wskazuje
<App Service Environment-name>przychodzący adres IP.
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ą systemu DNS skonfigurowanego przez sieć wirtualną. 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.