Omówienie platformy .NET w usłudze Azure Container Apps
Aby wdrożyć aplikację .NET w środowisku natywnym w chmurze, na przykład Azure Container Apps, należy podjąć decyzje, aby zapewnić bezproblemowe i bezpieczne działanie aplikacji. W tym przewodniku opisano kluczowe pojęcia związane z wdrażaniem aplikacji .NET w usłudze Azure Container Apps.
Azure Container Apps to w pełni zarządzana bezserwerowa usługa kontenera, która umożliwia uruchamianie konteneryzowanych aplikacji bez konieczności zarządzania podstawową infrastrukturą. Usługa Container Apps obejmuje wbudowaną obsługę funkcji, w tym skalowania automatycznego, kontroli kondycji i certyfikatów zabezpieczeń warstwy transportu (TLS).
Ten artykuł zawiera szczegółowe informacje na temat pojęć i zagadnień, które należy uwzględnić podczas wdrażania aplikacji platformy .NET w usłudze Azure Container Apps.
Wybieranie typu zasobu
Usługa Container Apps obsługuje dwa typy zasobów: aplikacje i zadania. Aplikacje są stale uruchomione usługi, podczas gdy zadania są zadaniami krótkoterminowymi przeznaczonymi do uruchamiania w celu ukończenia.
Podczas przygotowywania do wdrożenia aplikacji należy wziąć pod uwagę różnice między tymi dwoma typami aplikacji, ponieważ ich zachowanie wpływa na sposób zarządzania aplikacją .NET. W poniższej tabeli opisano różnicę w przypadkach użycia między zadaniami i .
| Przypadek użycia | Typ zasobu |
|---|---|
| Internetowy interfejs API platformy ASP.NET Core obsługujący żądania HTTP | Aplikacja |
| Aplikacja konsolowa platformy .NET Core, która przetwarza niektóre dane, a następnie kończy działanie | Zadanie |
| Stale uruchomiona usługa w tle, która przetwarza komunikaty z kolejki | Aplikacja |
| Usługa optymalizacji obrazów uruchamiana tylko wtedy, gdy duże obrazy są zapisywane na koncie magazynu. | Zadanie |
| Aplikacja korzystająca z platformy, takiej jak Hangfire, Quartz.NET lub zestaw SDK usługi Azure WebJobs | Aplikacja |
Konteneryzowanie i wdrażanie aplikacji .NET
W przypadku aplikacji lub zadań należy skompilować obraz kontenera, aby spakować aplikację platformy .NET. Aby uzyskać więcej informacji na temat kompilowania obrazu kontenera, zobacz Docker images for ASP.NET Core (Obrazy platformy Docker dla platformy ASP.NET Core).
Po skonfigurowaniu możesz wdrożyć aplikację w usłudze Azure Container Apps, wykonując następujące przewodniki:
- Samouczek: wdrażanie w usłudze Azure Container Apps przy użyciu programu Visual Studio
- Szybki start: kompilowanie i wdrażanie z repozytorium do usługi Azure Container Apps
- Tworzenie zadania za pomocą usługi Azure Container Apps
Korzystanie z ruchu przychodzącego HTTP
Usługa Azure Container Apps obejmuje wbudowany ruch przychodzący HTTP, który umożliwia uwidocznienie aplikacji na ruch wychodzący spoza kontenera. Ruch przychodzący usługi Container Apps znajduje się między aplikacją a użytkownikiem końcowym. Ponieważ ruch przychodzący działa jako pośrednik, niezależnie od tego, co widzi użytkownik końcowy, kończy się na ruchu przychodzącym i cokolwiek aplikacja widzi na początku ruchu przychodzącego.
Ruch przychodzący zarządza kończeniem żądań protokołu TLS i domenami niestandardowymi, eliminując konieczność ręcznego skonfigurowania ich w aplikacji. Za pośrednictwem ruchu przychodzącego port 443 jest uwidoczniony dla ruchu HTTPS i opcjonalnie port 80 dla ruchu HTTP. Ruch przychodzący przekazuje żądania do aplikacji na swoim porcie docelowym.
Jeśli aplikacja potrzebuje metadanych dotyczących oryginalnego żądania, może używać nagłówków przesłanych dalej X.
Aby dowiedzieć się więcej, zobacz Ruch przychodzący HTTP w usłudze Azure Container Apps.
Definiowanie portu docelowego
Aby odbierać ruch, ruch przychodzący jest skonfigurowany na porcie docelowym, na którym aplikacja nasłuchuje ruchu.
Gdy ASP.NET Core jest uruchomiona w kontenerze, aplikacja nasłuchuje portów zgodnie z konfiguracją w obrazie kontenera. W przypadku korzystania z oficjalnych obrazów ASP.NET Core aplikacja jest skonfigurowana do nasłuchiwania protokołu HTTP na domyślnym porcie. Port domyślny zależy od wersji ASP.NET Core.
| Środowisko uruchomieniowe | Port docelowy |
|---|---|
| ASP.NET Core 7 i starszych | 80 |
| ASP.NET Core 8 i nowszych | 8080 |
Podczas konfigurowania ruchu przychodzącego ustaw port docelowy na numer odpowiadający używanemu obrazowi kontenera.
Definiowanie nagłówków przesłanych dalej X
Gdy ruch przychodzący obsługuje oryginalne żądanie HTTP, aplikacja widzi ruch przychodzący jako klient. Istnieją sytuacje, w których aplikacja musi znać oryginalny adres IP klienta lub oryginalny protokół (HTTP lub HTTPS). Dostęp do informacji o protokole i adresie IP można uzyskać za pośrednictwem nagłówka X-Forwarded-*żądania.
Oryginalne wartości z tych nagłówków można odczytać, korzystając ForwardedHeaders z obiektu.
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
options.KnownNetworks.Clear();
options.KnownProxies.Clear();
});
Aby uzyskać więcej informacji na temat pracy z nagłówkami żądań, zobacz Konfigurowanie ASP.NET Core do pracy z serwerami proxy i modułami równoważenia obciążenia.
Tworzenie aplikacji platformy .NET natywnych dla chmury
Aplikacje wdrażane w usłudze Container Apps często działają najlepiej podczas tworzenia podstaw zasad natywnych dla chmury. W poniższych sekcjach opisano typowe problemy związane z aplikacjami natywnymi dla chmury.
Konfiguracja aplikacji
Podczas wdrażania aplikacji .NET w usłudze Azure Container Apps użyj zmiennych środowiskowych do przechowywania informacji o konfiguracji zamiast używania appsettings.json. Dzięki temu można skonfigurować aplikację na różne sposoby w różnych środowiskach. Ponadto użycie zmiennych środowiskowych ułatwia zarządzanie wartościami konfiguracji bez konieczności ponownego kompilowania i ponownego wdrażania obrazu kontenera.
W usłudze Azure Container Apps ustawiasz zmienne środowiskowe podczas definiowania kontenera aplikacji lub zadania. Przechowywanie poufnych wartości w wpisach tajnych i odwoływania się do nich jako zmiennych środowiskowych. Aby dowiedzieć się więcej na temat zarządzania wpisami tajnymi, zobacz Zarządzanie wpisami tajnymi w usłudze Azure Container Apps.
Tożsamość zarządzana
Usługa Azure Container Apps obsługuje tożsamość zarządzaną, która umożliwia aplikacji dostęp do innych usług platformy Azure bez konieczności wymiany poświadczeń. Aby dowiedzieć się więcej na temat bezpiecznej komunikacji między usługami platformy Azure, zobacz Tożsamości zarządzane w usłudze Azure Container Apps.
Rejestrowanie
W środowisku natywnym dla chmury rejestrowanie ma kluczowe znaczenie dla monitorowania i rozwiązywania problemów z aplikacjami. Domyślnie usługa Azure Container Apps używa usługi Azure Log Analytics do zbierania dzienników z kontenerów. Możesz skonfigurować innych dostawców rejestrowania. Aby dowiedzieć się więcej na temat rejestrowania aplikacji, zobacz Opcje magazynu dzienników i monitorowania w usłudze Azure Container Apps.
Podczas konfigurowania dostawcy rejestrowania, który zapisuje dzienniki w konsoli, usługa Azure Container Apps zbiera i przechowuje komunikaty dziennika.
Sondy kondycji
Usługa Azure Container Apps obejmuje wbudowaną obsługę sond kondycji, co umożliwia monitorowanie kondycji aplikacji. Jeśli sonda określa, że aplikacja jest w złej kondycji, kontener zostanie automatycznie uruchomiony ponownie. Aby dowiedzieć się więcej na temat sond kondycji, zobacz Sondy kondycji w usłudze Azure Container Apps.
Aby zaimplementować logikę niestandardową w celu określenia kondycji aplikacji, możesz skonfigurować punkt końcowy kontroli kondycji. Aby dowiedzieć się więcej na temat punktów końcowych kontroli kondycji, zobacz Kontrole kondycji w usłudze ASP.NET Core.
Zagadnienia dotyczące skalowania automatycznego
Domyślnie usługa Azure Container Apps automatycznie skaluje aplikacje ASP.NET Core na podstawie liczby przychodzących żądań HTTP. Można również skonfigurować niestandardowe reguły skalowania automatycznego na podstawie innych metryk, takich jak użycie procesora CPU lub pamięci. Aby dowiedzieć się więcej na temat skalowania, zobacz Ustawianie reguł skalowania w usłudze Azure Container Apps.
W programie .NET 8.0.4 lub nowszym aplikacje ASP.NET Core korzystające z ochrony danych są automatycznie konfigurowane do przechowywania chronionych danych dostępnych dla wszystkich replik w miarę skalowania aplikacji. Gdy aplikacja zacznie skalować, menedżer kluczy obsługuje klucze zapisu i udostępniania w wielu poprawkach. W miarę wdrażania aplikacji zmienna środowiskowa autoConfigureDataProtection jest automatycznie ustawiana true w celu włączenia tej funkcji. Aby uzyskać więcej informacji na temat tej automatycznej konfiguracji, zobacz to żądanie ściągnięcia w usłudze GitHub.
Skalowanie automatyczne zmienia liczbę replik aplikacji na podstawie zdefiniowanych reguł. Domyślnie usługa Container Apps losowo kieruje ruch przychodzący do replik aplikacji ASP.NET Core. Ponieważ ruch może być podzielony między różne repliki, aplikacja powinna być bezstanowa, aby aplikacja nie napotykała problemów związanych z stanem.
Funkcje takie jak ochrona przed fałszerzowaniem, uwierzytelnianiem, usługą SignalR, serwerem Blazor i stronami Razor zależą od ochrony danych, wymagają dodatkowej konfiguracji, aby działały prawidłowo podczas skalowania do wielu replik.
Konfigurowanie ochrony danych
ASP.NET Core ma specjalne funkcje ochrony i niechronić danych, takich jak dane sesji i tokeny ochrony przed fałszerzacją. Domyślnie klucze ochrony danych są przechowywane w systemie plików, który nie jest odpowiedni dla środowiska natywnego dla chmury.
Jeśli wdrażasz aplikację .NET Aspire, ochrona danych jest automatycznie konfigurowana. We wszystkich innych sytuacjach należy ręcznie skonfigurować ochronę danych.
Konfigurowanie ASP.NET Core SignalR
ASP.NET Core SignalR wymaga płaszczyzny wstecznej do dystrybucji komunikatów do wielu replik serwera. Podczas wdrażania aplikacji ASP.NET Core z usługą SignalR w usłudze Azure Container Apps należy skonfigurować jedną z obsługiwanych płaszczyzn zaplecza, takich jak Azure SignalR Service lub Redis. Aby dowiedzieć się więcej o planach prac, zobacz ASP.NET Core SignalR hostowanie i skalowanie.
Konfigurowanie serwera Blazor
ASP.NET Core Blazor Server aplikacje przechowują stan na serwerze, co oznacza, że każdy klient musi być połączony z tą samą repliką serwera podczas sesji. Podczas wdrażania aplikacji Blazor Server w usłudze Azure Container Apps należy włączyć sesje sticky, aby upewnić się, że klienci są kierowani do tej samej repliki. Aby dowiedzieć się więcej, zobacz Koligacja sesji w usłudze Azure Container Apps.