Sieć w środowisku usługi Azure Container Apps

Usługa Azure Container Apps działa w kontekście środowiska z własną siecią wirtualną.

Domyślnie środowisko aplikacji kontenera jest tworzone przy użyciu sieci wirtualnej, która jest automatycznie generowana. W przypadku precyzyjnej kontroli nad siecią można podać istniejącą sieć wirtualną podczas tworzenia środowiska. Po utworzeniu środowiska z wygenerowaną lub istniejącą siecią wirtualną nie można zmienić typu sieci.

Wygenerowane sieci wirtualne przyjmują następujące cechy.

Są to:

• niedostępny dla Ciebie podczas tworzenia ich w dzierżawie firmy Microsoft
• publicznie dostępny za pośrednictwem Internetu
• tylko dostęp do punktów końcowych z dostępem do Internetu

Ponadto obsługują tylko ograniczony podzestaw funkcji sieciowych, takich jak ograniczenia adresów IP ruchu przychodzącego i kontrolki ruchu przychodzącego na poziomie aplikacji kontenera.

Użyj istniejącej sieci wirtualnej, jeśli potrzebujesz większej liczby funkcji sieciowych platformy Azure, takich jak:

• Integracja z usługą Application Gateway
• Grupy zabezpieczeń sieci
• Komunikacja z zasobami za prywatnymi punktami końcowymi w sieci wirtualnej

Dostępne funkcje sieci wirtualnej zależą od wybranego środowiska.

Wybór środowiska

Usługa Container Apps ma dwa różne typy środowisk, które mają wiele takich samych właściwości sieciowych z pewnymi kluczowymi różnicami.

Typ środowiska	opis	Obsługiwane typy planów
Profile obciążeń	Obsługuje trasy zdefiniowane przez użytkownika (UDR) i ruch wychodzący za pośrednictwem bramy translatora adresów sieciowych. Minimalny wymagany rozmiar podsieci to /27.	Zużycie, dedykowane
Tylko zużycie	Nie obsługuje tras zdefiniowanych przez użytkownika (UDR), wychodzących za pośrednictwem bramy translatora adresów sieciowych, komunikacji równorzędnej za pośrednictwem bramy zdalnej ani innego niestandardowego ruchu wychodzącego. Minimalny wymagany rozmiar podsieci to /23.	Zużycie

Poziomy ułatwień dostępu

Możesz skonfigurować, czy aplikacja kontenera zezwala na publiczny ruch przychodzący lub przychodzący tylko z poziomu sieci wirtualnej na poziomie środowiska.

Poziom ułatwień dostępu	opis
Zewnętrzne	Umożliwia aplikacji kontenera akceptowanie publicznych żądań. Środowiska zewnętrzne są wdrażane przy użyciu wirtualnego adresu IP na zewnętrznym, publicznym adresie IP.
Wewnętrzny	Środowiska wewnętrzne nie mają publicznych punktów końcowych i są wdrażane przy użyciu wirtualnego adresu IP (VIP) zamapowanego na wewnętrzny adres IP. Wewnętrzny punkt końcowy jest wewnętrznym modułem równoważenia obciążenia (ILB) platformy Azure, a adresy IP są wystawiane z listy prywatnych adresów IP niestandardowej sieci wirtualnej.

Niestandardowa konfiguracja sieci wirtualnej

Podczas tworzenia niestandardowej sieci wirtualnej należy pamiętać o następujących sytuacjach:

• Jeśli chcesz, aby aplikacja kontenera ograniczyła cały dostęp zewnętrzny, utwórz wewnętrzne środowisko usługi Container Apps.

• Jeśli używasz własnej sieci wirtualnej, musisz podać podsieć przeznaczoną wyłącznie dla wdrażanego środowiska aplikacji kontenera. Ta podsieć nie jest dostępna dla innych usług.

• Adresy sieciowe są przypisywane z zakresu podsieci zdefiniowanego podczas tworzenia środowiska.

  • Zakres podsieci używany przez środowisko Container Apps można zdefiniować.

  • Możesz ograniczyć żądania przychodzące do środowiska wyłącznie do sieci wirtualnej, wdrażając środowisko jako wewnętrzne.

Uwaga

Po podaniu własnej sieci wirtualnej tworzone są dodatkowe zasoby zarządzane. Te zasoby generują koszty według powiązanych stawek.

Podczas projektowania sieci wokół aplikacji kontenera zapoznaj się z tematem Planowanie sieci wirtualnych.

Uwaga

Przenoszenie sieci wirtualnych między różnymi grupami zasobów lub subskrypcjami nie jest dozwolone, jeśli sieć wirtualna jest używana przez środowisko usługi Container Apps.

Zachowanie serwera proxy usługi HTTP Edge

Usługa Azure Container Apps używa serwera proxy usługi Envoy jako brzegowego serwera proxy HTTP. Protokół Transport Layer Security (TLS) jest przerywany na krawędzi, a żądania są kierowane na podstawie reguł podziału ruchu i kierowania ruchu do właściwej aplikacji.

Aplikacje HTTP są skalowane na podstawie liczby żądań i połączeń HTTP. Usługa Envoy kieruje ruch wewnętrzny wewnątrz klastrów.

Połączenia podrzędne obsługują połączenia HTTP1.1 i HTTP2 i Envoy automatycznie wykrywa i uaktualnia połączenia, jeśli połączenie klienta wymaga uaktualnienia.

Połączenia nadrzędne są definiowane przez ustawienie transport właściwości obiektu przychodzącego.

Konfiguracja ruchu przychodzącego

W sekcji ruchu przychodzącego można skonfigurować następujące ustawienia:

• Poziom ułatwień dostępu: możesz ustawić aplikację kontenera jako zewnętrznie lub wewnętrznie dostępną w środowisku. Zmienna środowiskowa CONTAINER_APP_ENV_DNS_SUFFIX służy do automatycznego rozpoznawania sufiksu w pełni kwalifikowanej nazwy domeny (FQDN) dla danego środowiska. Podczas komunikacji między aplikacjami kontenerów w tym samym środowisku możesz również użyć nazwy aplikacji. Aby uzyskać więcej informacji na temat uzyskiwania dostępu do aplikacji, zobacz Ruch przychodzący w usłudze Azure Container Apps.

• Reguły podziału ruchu: można zdefiniować reguły podziału ruchu między różnymi wersjami aplikacji. Aby uzyskać więcej informacji, zobacz Podział ruchu.

Aby uzyskać więcej informacji na temat różnych scenariuszy sieciowych, zobacz Ruch przychodzący w usłudze Azure Container Apps.

Zależności portalu

Dla każdej aplikacji w usłudze Azure Container Apps istnieją dwa adresy URL.

Środowisko uruchomieniowe usługi Container Apps początkowo generuje w pełni kwalifikowaną nazwę domeny (FQDN) używaną do uzyskiwania dostępu do aplikacji. Zobacz adres URL aplikacji w oknie Przegląd aplikacji kontenera w witrynie Azure Portal, aby uzyskać nazwę FQDN aplikacji kontenera.

Drugi adres URL jest również generowany dla Ciebie. Ta lokalizacja udziela dostępu do usługi przesyłania strumieniowego dzienników i konsoli. W razie potrzeby może być konieczne dodanie https://azurecontainerapps.dev/ do listy dozwolonych zapory lub serwera proxy.

Porty i adresy IP

Następujące porty są uwidocznione dla połączeń przychodzących.

Protokół	Porty
HTTP/HTTPS	80, 443

Adresy IP są podzielone na następujące typy:

Type	Opis
Publiczny adres IP dla ruchu przychodzącego	Służy do obsługi ruchu aplikacji we wdrożeniu zewnętrznym i ruchu zarządzania zarówno we wdrożeniach wewnętrznych, jak i zewnętrznych.
Wychodzący publiczny adres IP	Używany jako adres IP "from" dla połączeń wychodzących, które opuszczają sieć wirtualną. Te połączenia nie są kierowane w dół sieci VPN. Adresy IP ruchu wychodzącego mogą ulec zmianie w czasie. Używanie bramy translatora adresów sieciowych lub innego serwera proxy dla ruchu wychodzącego ze środowiska usługi Container Apps jest obsługiwane tylko w środowisku profilów obciążeń.
Wewnętrzny adres IP modułu równoważenia obciążenia	Ten adres istnieje tylko w środowisku wewnętrznym.

Podsieć

Integracja sieci wirtualnej zależy od dedykowanej podsieci. Sposób przydzielania adresów IP w podsieci i obsługiwanych rozmiarów podsieci zależy od tego, który plan jest używany w usłudze Azure Container Apps.

Starannie wybierz rozmiar podsieci. Nie można modyfikować rozmiarów podsieci po utworzeniu środowiska usługi Container Apps.

Różne typy środowisk mają różne wymagania dotyczące podsieci:

Środowisko profilów obciążeń

• /27 to minimalny rozmiar podsieci wymagany do integracji sieci wirtualnej.

• Podsieć musi być delegowana do .Microsoft.App/environments

• W przypadku korzystania ze środowiska zewnętrznego z zewnętrznymi ruchami przychodzącymi kieruje ruch przychodzący za pośrednictwem publicznego adresu IP infrastruktury, a nie za pośrednictwem podsieci.

• Usługa Container Apps automatycznie rezerwuje 12 adresów IP na potrzeby integracji z podsiecią. Liczba adresów IP wymaganych do integracji infrastruktury nie różni się w zależności od wymagań skalowania środowiska. Dodatkowe adresy IP są przydzielane zgodnie z następującymi regułami w zależności od typu profilu obciążenia, który używasz więcej adresów IP, są przydzielane w zależności od profilu obciążenia środowiska:

  • Profil dedykowanego obciążenia: w miarę skalowania aplikacji kontenera w poziomie każdy węzeł ma przypisany jeden adres IP.

  • Profil obciążenia zużycie: każdy adres IP może być współużytkowany między wieloma replikami. Podczas planowania liczby adresów IP wymaganych dla aplikacji zaplanuj 1 adres IP na 10 replik.

• Jeśli wprowadzisz zmianę w trybie pojedynczej poprawki , wymagana przestrzeń adresowa zostanie podwoina przez krótki czas w celu zapewnienia obsługi wdrożeń bez przestojów. Ma to wpływ na rzeczywiste, dostępne obsługiwane repliki lub węzły dla danego rozmiaru podsieci. W poniższej tabeli przedstawiono zarówno maksymalne dostępne adresy na blok CIDR, jak i wpływ na skalę poziomą.

  Rozmiar podsieci	Dostępne adresyIP 1	Maksymalna liczba węzłów (profil dedykowanego obciążenia)2	Maksymalna liczba replik (profil obciążenia zużycie)2
  /23	500	250	2500
  /24	244	122	1,220
  /25	116	58	580
  /26	52	26	260
  /27	20	10	100

  ¹ Dostępne adresy IP to rozmiar podsieci minus 12 adresów IP wymaganych dla infrastruktury usługi Azure Container Apps.
  ² Dotyczy to aplikacji w trybie pojedynczej poprawki.

Środowisko tylko do użycia

• /23 to minimalny rozmiar podsieci wymagany do integracji sieci wirtualnej.

• Środowisko uruchomieniowe usługi Container Apps rezerwuje co najmniej 60 adresów IP dla infrastruktury w sieci wirtualnej. Kwota zarezerwowana może wzrosnąć do 256 adresów w miarę skalowania środowiska.

• W miarę skalowania aplikacji nowy adres IP jest przydzielany dla każdej nowej repliki.

• Jeśli wprowadzisz zmianę w trybie pojedynczej poprawki , wymagana przestrzeń adresowa zostanie podwoina przez krótki czas w celu zapewnienia obsługi wdrożeń bez przestojów. Ma to wpływ na rzeczywiste, dostępne obsługiwane repliki dla danego rozmiaru podsieci.

Ograniczenia zakresu adresów podsieci

Środowisko profilów obciążeń

Zakresy adresów podsieci nie mogą nakładać się na następujące zakresy zarezerwowane przez usługi Azure Kubernetes Services:

• 169.254.0.0/16
• 172.30.0.0/16
• 172.31.0.0/16
• 192.0.2.0/24

Ponadto środowisko profilów obciążeń rezerwuje następujące adresy:

• 100.100.0.0/17
• 100.100.128.0/19
• 100.100.160.0/19
• 100.100.192.0/19

Środowisko tylko do użycia

Zakresy adresów podsieci nie mogą nakładać się na następujące zakresy zarezerwowane przez usługi Azure Kubernetes Services:

• 169.254.0.0/16
• 172.30.0.0/16
• 172.31.0.0/16
• 192.0.2.0/24

Jeśli utworzono środowisko aplikacji kontenera za pomocą niestandardowej trasy CIDR usługi, upewnij się, że podsieć aplikacji kontenera (lub dowolna podsieć równorzędna) nie powoduje konfliktu z niestandardowym zakresem CIDR usługi.

Konfiguracja podsieci z interfejsem wiersza polecenia

W miarę tworzenia środowiska usługi Container Apps należy podać identyfikatory zasobów dla jednej podsieci.

Jeśli używasz interfejsu wiersza polecenia, parametrem do zdefiniowania identyfikatora zasobu podsieci jest infrastructure-subnet-resource-id. Podsieć hostuje składniki infrastruktury i kontenery aplikacji użytkownika.

Jeśli używasz interfejsu wiersza polecenia platformy Azure z użyciem tylko środowiska, a zakres platformyReservedCidr jest zdefiniowany, obie podsieci nie mogą pokrywać się z zakresem adresów IP zdefiniowanym w elemencie platformReservedCidr.

Trasy

Trasy zdefiniowane przez użytkownika (UDR)

Trasy definiowane przez użytkownika (UDR) i ruch wychodzący kontrolowany za pośrednictwem usługi NAT Gateway są obsługiwane w środowisku profilów obciążeń. W środowisku tylko do użycia te funkcje nie są obsługiwane.

Uwaga

W przypadku korzystania z trasy zdefiniowanej przez użytkownika z usługą Azure Firewall w usłudze Azure Container Apps należy dodać pewne tagi FQDN i usługi do listy dozwolonych zapory. Aby dowiedzieć się więcej, zobacz Konfigurowanie trasy zdefiniowanej przez użytkownika za pomocą usługi Azure Firewall.

• Tras definiowanych przez użytkownika można używać wraz ze środowiskami profilów obciążeń, aby ograniczyć ruch wychodzący z aplikacji kontenera za pośrednictwem usługi Azure Firewall lub innych urządzeń sieciowych.

• Konfigurowanie tras definiowanych przez użytkownika odbywa się poza zakresem środowiska usługi Container Apps.

Platforma Azure tworzy domyślną tabelę tras dla sieci wirtualnych podczas tworzenia. Implementując tabelę tras zdefiniowaną przez użytkownika, możesz kontrolować sposób kierowania ruchu w sieci wirtualnej. Można na przykład utworzyć trasę zdefiniowaną przez użytkownika, która kieruje cały ruch do zapory.

Konfigurowanie trasy zdefiniowanej przez użytkownika za pomocą usługi Azure Firewall

Trasy zdefiniowane przez użytkownika są obsługiwane tylko w środowisku profilów obciążeń. Następujące reguły aplikacji i sieci należy dodać do listy dozwolonych zapory w zależności od używanych zasobów.

Uwaga

Aby zapoznać się z przewodnikiem dotyczącym konfigurowania trasy zdefiniowanej przez użytkownika za pomocą usługi Container Apps w celu ograniczenia ruchu wychodzącego za pomocą usługi Azure Firewall, zapoznaj się z instrukcjami dotyczącymi usługi Container Apps i Azure Firewall.

Reguły aplikacji

Reguły aplikacji zezwalają na ruch lub odmawiają go na podstawie warstwy aplikacji. Następujące reguły aplikacji zapory dla ruchu wychodzącego są wymagane na podstawie scenariusza.

Scenariusze	Nazwy fqdn	opis
Wszystkie scenariusze	mcr.microsoft.com, *.data.mcr.microsoft.com	Te nazwy FQDN dla usługi Microsoft Container Registry (MCR) są używane przez usługę Azure Container Apps, a te reguły aplikacji lub reguły sieciowe dla mcR muszą zostać dodane do listy dozwolonych podczas korzystania z usługi Azure Container Apps z usługą Azure Firewall.
Azure Container Registry (ACR)	Twój adres ACR, , *.blob.core.windows.netlogin.microsoft.com	Te nazwy FQDN są wymagane w przypadku korzystania z usługi Azure Container Apps z usługami ACR i Azure Firewall.
Azure Key Vault	Your-Azure-Key-Vault-address, login.microsoft.com	Te nazwy FQDN są wymagane oprócz tagu usługi wymaganego dla reguły sieciowej dla usługi Azure Key Vault.
Tożsamość zarządzana	*.identity.azure.net, , login.microsoftonline.com, , *.login.microsoftonline.com*.login.microsoft.com	Te nazwy FQDN są wymagane w przypadku korzystania z tożsamości zarządzanej z usługą Azure Firewall w usłudze Azure Container Apps.
Rejestr usługi Docker Hub	hub.docker.com, , registry-1.docker.ioproduction.cloudflare.docker.com	Jeśli używasz rejestru usługi Docker Hub i chcesz uzyskać do niego dostęp za pośrednictwem zapory, musisz dodać te nazwy FQDN do zapory.

Reguły sieci

Reguły sieci zezwalają na ruch lub odmawiają go na podstawie warstwy sieci i transportu. Następujące reguły sieciowe zapory dla ruchu wychodzącego są wymagane na podstawie scenariusza.

Scenariusze	Tag usługi	opis
Wszystkie scenariusze	MicrosoftContainerRegistry, AzureFrontDoorFirstParty	Te tagi usługi dla usługi Microsoft Container Registry (MCR) są używane przez usługę Azure Container Apps, a te reguły sieci lub reguły aplikacji dla mcR muszą zostać dodane do listy dozwolonych podczas korzystania z usługi Azure Container Apps z usługą Azure Firewall.
Azure Container Registry (ACR)	AzureContainerRegistry, AzureActiveDirectory	W przypadku korzystania z usługi ACR z usługą Azure Container Apps należy skonfigurować te reguły aplikacji używane przez usługę Azure Container Registry.
Azure Key Vault	AzureKeyVault, AzureActiveDirectory	Te tagi usługi są wymagane oprócz nazwy FQDN dla reguły aplikacji dla usługi Azure Key Vault.
Tożsamość zarządzana	AzureActiveDirectory	W przypadku korzystania z tożsamości zarządzanej z usługą Azure Container Apps należy skonfigurować te reguły aplikacji używane przez tożsamość zarządzaną.

Uwaga

W przypadku zasobów platformy Azure używanych z usługą Azure Firewall, których nie wymieniono w tym artykule, zapoznaj się z dokumentacją tagów usług.

Integracja bramy translatora adresów sieciowych

Brama translatora adresów sieciowych umożliwia uproszczenie łączności wychodzącej dla wychodzącego ruchu internetowego w sieci wirtualnej w środowisku profilów obciążeń.

Podczas konfigurowania bramy translatora adresów sieciowych w podsieci brama translatora adresów sieciowych udostępnia statyczny publiczny adres IP dla danego środowiska. Cały ruch wychodzący z aplikacji kontenera jest kierowany przez statyczny publiczny adres IP bramy translatora adresów sieciowych.

Zabezpieczenia środowiska

Możesz w pełni zabezpieczyć środowisko profilów obciążeń ruchu sieciowego ruchu przychodzącego i wychodzącego, wykonując następujące akcje:

• Utwórz wewnętrzne środowisko aplikacji kontenera w środowisku profilów obciążeń. Aby uzyskać instrukcje, zobacz Zarządzanie profilami obciążeń za pomocą interfejsu wiersza polecenia platformy Azure.

• Integrowanie aplikacji kontenera z usługą Application Gateway.

• Skonfiguruj trasę zdefiniowaną przez użytkownika, aby kierować cały ruch przez usługę Azure Firewall.

Szyfrowanie sieci na poziomie środowiska (wersja zapoznawcza)

Usługa Azure Container Apps obsługuje szyfrowanie sieci na poziomie środowiska przy użyciu zabezpieczeń warstwy transportu wzajemnego (mTLS). Gdy wymagane jest kompleksowe szyfrowanie, usługa mTLS szyfruje dane przesyłane między aplikacjami w środowisku.

Aplikacje w środowisku usługi Container Apps są automatycznie uwierzytelniane. Jednak środowisko uruchomieniowe usługi Container Apps nie obsługuje autoryzacji do kontroli dostępu między aplikacjami przy użyciu wbudowanego zestawu mTLS.

Gdy aplikacje komunikują się z klientem spoza środowiska, obsługiwane jest uwierzytelnianie dwukierunkowe za pomocą biblioteki mTLS. Aby dowiedzieć się więcej, zobacz konfigurowanie certyfikatów klienta.

Uwaga

Włączenie biblioteki mTLS dla aplikacji może zwiększyć opóźnienie odpowiedzi i zmniejszyć maksymalną przepływność w scenariuszach wysokiego obciążenia.

Interfejs wiersza polecenia platformy Azure

Usługę mTLS można włączyć przy użyciu następujących poleceń.

Podczas tworzenia:

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-mtls

W przypadku istniejącej aplikacji kontenera:

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-mtls

Szablon usługi ARM

Bibliotekę mTLS można włączyć w szablonie usługi ARM dla środowisk usługi Container Apps przy użyciu następującej konfiguracji.

{
  ...
  "properties": {
       "peerAuthentication":{
            "mtls": {
                "enabled": "true|false"
            }
        }
  ...
}

DNS

• Niestandardowy system DNS: jeśli sieć wirtualna używa niestandardowego serwera DNS zamiast domyślnego serwera DNS dostarczonego przez platformę Azure, skonfiguruj serwer DNS, aby przekazywać nierozwiązane zapytania DNS do usługi 168.63.129.16. Rekursywne narzędzia rozpoznawania nazw platformy Azure używają tego adresu IP do rozwiązywania żądań. Podczas konfigurowania sieciowej grupy zabezpieczeń lub zapory nie blokuj 168.63.129.16 adresu, w przeciwnym razie środowisko usługi Container Apps nie będzie działać poprawnie.

• Ruch przychodzący w zakresie sieci wirtualnej: jeśli planujesz używać ruchu przychodzącego w zakresie sieci wirtualnej w środowisku wewnętrznym, skonfiguruj domeny na jeden z następujących sposobów:

  1. Domeny inne niż niestandardowe: jeśli nie planujesz używania domeny niestandardowej, utwórz prywatną strefę DNS, która rozpoznaje domyślną domenę środowiska Container Apps na statyczny adres IP środowiska Container Apps. Możesz użyć usługi Azure Prywatna strefa DNS lub własnego serwera DNS. Jeśli używasz usługi Azure Prywatna strefa DNS, utwórz prywatną strefę DNS o nazwie jako domenę domyślną środowiska aplikacji kontenera (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io) z rekordemA. Rekord A zawiera nazwę *<DNS Suffix> i statyczny adres IP środowiska Container Apps.

  2. Domeny niestandardowe: jeśli planujesz używać domen niestandardowych i używasz zewnętrznego środowiska usługi Container Apps, użyj publicznie rozpoznawalnej domeny, aby dodać domenę niestandardową i certyfikat do aplikacji kontenera. Jeśli używasz wewnętrznego środowiska usługi Container Apps, nie ma weryfikacji powiązania DNS, ponieważ dostęp do klastra można uzyskać tylko z poziomu sieci wirtualnej. Ponadto utwórz prywatną strefę DNS, która rozpoznaje domenę wierzchołka na statyczny adres IP środowiska Container Apps. Możesz użyć usługi Azure Prywatna strefa DNS lub własnego serwera DNS. Jeśli używasz usługi Azure Prywatna strefa DNS, utwórz strefę Prywatna strefa DNS o nazwie jako domenę wierzchołka z rekordem A wskazującym statyczny adres IP środowiska usługi Container Apps.

Statyczny adres IP środowiska Container Apps jest dostępny w witrynie Azure Portal w niestandardowym sufiksie DNS strony aplikacji kontenera lub za pomocą polecenia interfejsu wiersza polecenia az containerapp env list platformy Azure.

Zasoby zarządzane

Podczas wdrażania środowiska wewnętrznego lub zewnętrznego w sieci zostanie utworzona nowa grupa zasobów w subskrypcji platformy Azure, w której jest hostowane środowisko. Ta grupa zasobów zawiera składniki infrastruktury zarządzane przez platformę Azure Container Apps. Nie należy modyfikować usług w tej grupie ani samej grupie zasobów.

Środowisko profilów obciążeń

Nazwa grupy zasobów utworzonej w subskrypcji platformy Azure, w której hostowane jest środowisko, jest domyślnie poprzedzona prefiksem ME_ , a nazwa grupy zasobów można dostosować podczas tworzenia środowiska aplikacji kontenera.

W przypadku środowisk zewnętrznych grupa zasobów zawiera publiczny adres IP używany specjalnie do łączności przychodzącej ze środowiskiem zewnętrznym i modułem równoważenia obciążenia. W przypadku środowisk wewnętrznych grupa zasobów zawiera tylko moduł równoważenia obciążenia.

Oprócz standardowych rozliczeń usługi Azure Container Apps opłaty są naliczane za:

• Jeden standardowy statyczny publiczny adres IP dla ruchu wychodzącego w przypadku korzystania ze środowiska wewnętrznego lub zewnętrznego oraz jeden standardowy statyczny publiczny adres IP dla ruchu przychodzącego w przypadku korzystania ze środowiska zewnętrznego. Jeśli potrzebujesz więcej publicznych adresów IP na potrzeby ruchu wychodzącego z powodu problemów z siecią SNAT, otwórz bilet pomocy technicznej, aby poprosić o zastąpienie.

• Jeden standardowy moduł równoważenia obciążenia.

• Koszt przetwarzanych danych (w GB) obejmuje zarówno ruch przychodzący, jak i wychodzący na potrzeby operacji zarządzania.

Środowisko tylko do użycia

Nazwa grupy zasobów utworzonej w subskrypcji platformy Azure, w której jest hostowane środowisko, jest domyślnie poprzedzona prefiksem MC_ , a nazwa grupy zasobów nie może być dostosowywana podczas tworzenia aplikacji kontenera. Grupa zasobów zawiera publiczne adresy IP używane specjalnie do łączności wychodzącej ze środowiska i modułu równoważenia obciążenia.

Oprócz standardowych rozliczeń usługi Azure Container Apps opłaty są naliczane za:

• Jeden standardowy statyczny publiczny adres IP dla ruchu wychodzącego. Jeśli potrzebujesz więcej adresów IP dla ruchu wychodzącego z powodu problemów z tłumaczeniem adresów sieciowych (SNAT), otwórz bilet pomocy technicznej, aby zażądać zastąpienia.

• Dwa standardowe moduły równoważenia obciążenia w przypadku korzystania ze środowiska wewnętrznego lub jeden standardowy moduł równoważenia obciążenia w przypadku korzystania ze środowiska zewnętrznego. Każdy moduł równoważenia obciążenia ma mniej niż sześć reguł. Koszt przetwarzanych danych (w GB) obejmuje zarówno ruch przychodzący, jak i wychodzący na potrzeby operacji zarządzania.

Następne kroki

• Wdrażanie przy użyciu środowiska zewnętrznego
• Wdrażanie przy użyciu środowiska wewnętrznego