Azure Container Apps

Azure Container Apps (ACA) to w pełni zarządzana, bezserwerowa usługa hostingu kontenerów, zbudowana na bazie Kubernetes i KEDA (Kubernetes Event-Driven Autoscaling). W przeciwieństwie do AKS nie zarządzają Państwo bezpośrednio płaszczyzną sterowania, pulami węzłów ani manifestami Kubernetes. Zamiast tego wdrażają Państwo kontenery za pomocą prostego interfejsu wiersza polecenia lub definicji YAML, a platforma Azure zajmuje się całą orkiestracją. ACA doskonale nadaje się do mikrousług, zapleczy API, procesów roboczych sterowanych zdarzeniami i zadań przetwarzania w tle, które muszą skalować się dynamicznie, w tym do zera.

Środowisko Container Apps to odizolowana granica, w ramach której działa co najmniej jedna aplikacja Container App. Wszystkie aplikacje w środowisku współdzielą tę samą sieć wirtualną i obszar roboczy usługi Log Analytics. Środowiska są przypisane do regionu i grupy zasobów. Można wdrożyć wiele środowisk, aby odizolować zespoły lub etapy (produkcję i środowisko przejściowe). Środowisko można opcjonalnie wstrzyknąć do sieci VNet, aby umożliwić prywatną komunikację między aplikacjami Container Apps a innymi usługami platformy Azure bez korzystania z publicznego internetu.

Aby wdrożyć aplikację Container App, należy określić obraz kontenera (z usługi Azure Container Registry lub dowolnego publicznego rejestru), liczbę replik oraz zmienne środowiskowe. Aplikacja jest publicznie dostępna za pośrednictwem automatycznie wygenerowanego adresu URL HTTPS po włączeniu ruchu przychodzącego zewnętrznego. Konfiguracja ruchu przychodzącego obejmuje port docelowy, podział ruchu na potrzeby wdrożeń blue-green oraz określenie, czy dozwolony jest wyłącznie protokół HTTP lub HTTPS. ACA pobiera obraz w czasie wdrażania; środowisko musi mieć uprawnienia do pobierania obrazów z rejestru.

Container Apps skaluje się za pomocą komponentów skalujących KEDA, które reagują na metryki zewnętrzne. Wbudowane komponenty skalujące KEDA obejmują: ruch HTTP (liczba jednoczesnych żądań na replikę), głębokość kolejki Azure Service Bus (liczba oczekujących komunikatów), Azure Storage Queue, Cron (skalowanie zależne od czasu) oraz CPU/pamięć. Gdy wartość metryki skalera spadnie do zera, a minReplicas będzie ustawione na 0, Container Apps skaluje się do zera — nie generując kosztów obliczeniowych do czasu nadejścia nowych żądań. Skalowanie do zera doskonale sprawdza się w przypadku procesów roboczych sterowanych zdarzeniami o sporadycznym obciążeniu.

Dapr (Distributed Application Runtime) to przenośne środowisko uruchomieniowe sterowane zdarzeniami, które upraszcza tworzenie mikrousług. Container Apps zapewnia natywną integrację z Dapr — można ją włączyć dla każdej aplikacji za pomocą pojedynczej flagi. Dapr udostępnia bloki konstrukcyjne do obsługi: wywoływania usług (z ponawianiem prób i mTLS), komunikacji pub/sub (abstrahującej Service Bus i Event Hubs), zarządzania stanem (abstrahującego Redis i Cosmos DB) oraz powiązań wyjściowych. Dzięki Dapr mikrousługi komunikują się za pośrednictwem sidecara Dapr, bez znajomości szczegółów bazowej infrastruktury.

Każde wdrożenie aplikacji Container App tworzy nową wersję. W trybie wielu wersji można podzielić ruch między wersje na potrzeby wdrożeń blue-green lub kanarkowych. Można na przykład skierować 10% ruchu do nowej wersji, a 90% do bieżącej stabilnej wersji. Przed zwiększeniem udziału ruchu nowej wersji do 100% należy monitorować w niej współczynniki błędów i opóźnienia. Stare wersje można dezaktywować, ale pozostają one w historii, co umożliwia natychmiastowe wycofanie zmiany przez przywrócenie wcześniejszego udziału ruchu.

Container Apps obsługuje dwa sposoby wstrzykiwania konfiguracji: zmienne środowiskowe (do nies wrażliwej konfiguracji, takiej jak flagi funkcji lub adresy URL interfejsów API) oraz tajniki (do wartości wrażliwych, takich jak parametry połączenia). Tajniki są przechowywane na poziomie aplikacji Container App i wskazywane przez zmienne środowiskowe lub komponenty Dapr. W celu zapewnienia najwyższego poziomu bezpieczeństwa należy odwoływać się do tajników z usługi Azure Key Vault za pomocą tożsamości zarządzanej, aby wartość sekretu była pobierana w czasie działania i nigdy nie była przechowywana w płaszczyźnie konfiguracji aplikacji Container App.

Container Apps Jobs rozszerza platformę o obsługę obciążeń wykonywanych do zakończenia — kontenerów, które są uruchamiane, wykonują pracę, a następnie kończą działanie. Zadania obsługują trzy typy wyzwalaczy: Manual (wyzwalane za pośrednictwem interfejsu API lub interfejsu wiersza polecenia), Scheduled (wyrażenie cron) oraz Event-driven (skalowanie KEDA wyzwala każde wykonanie). Opłaty za zadania są naliczane wyłącznie za rzeczywisty czas wykonywania, dlatego doskonale nadają się one do przetwarzania wsadowego, generowania raportów, migracji baz danych oraz potoków wnioskowania ML uruchamianych okresowo lub w odpowiedzi na zdarzenia.

Container Apps wysyła dzienniki systemowe (zdarzenia platformy, takie jak tworzenie rewizji i skalowanie) oraz dzienniki konsoli (strumienie stdout/stderr aplikacji) do obszaru roboczego Log Analytics dołączonego do środowiska. Dzienniki można wyszukiwać za pomocą KQL: ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. Wbudowane metryki Azure Monitor obejmują liczbę replik, liczbę żądań, opóźnienie żądań oraz wykorzystanie procesora i pamięci dla każdej repliki — wszystkie są dostępne w witrynie Azure Portal bez dodatkowej konfiguracji.

Wybór odpowiedniej platformy kontenerowej Azure: Container Apps najlepiej sprawdza się w przypadku mikrousług, procesów roboczych sterowanych zdarzeniami i interfejsów API, gdy potrzebują Państwo zalet Kubernetes bez zarządzania klastrem — szczególnie gdy istotne jest skalowanie do zera. AKS jest najlepszym wyborem, gdy potrzebują Państwo pełnej kontroli nad Kubernetes, niestandardowych operatorów lub określonych konfiguracji węzłów (GPU, duża ilość pamięci). App Service najlepiej nadaje się do tradycyjnych aplikacji internetowych i interfejsów API, gdy zespół programistyczny preferuje prosty model PaaS bez narzutu związanego z zarządzaniem kontenerami. Wszystkie trzy usługi obsługują kontenery; różnica dotyczy poziomu złożoności zarządzania i zakresu kontroli.

Container Apps obsługuje dwa tryby ruchu przychodzącego: External (publicznie dostępny za pośrednictwem równoważonego obciążeniem punktu końcowego HTTPS z automatyczną obsługą TLS) oraz Internal (dostępny wyłącznie z tego samego środowiska Container Apps lub z zasobów połączonych z siecią VNet za pomocą peeringu). Wewnętrzny ruch przychodzący jest używany w przypadku usług zaplecza, które nigdy nie powinny być udostępniane w internecie. Aplikacje mogą wywoływać się wzajemnie za pomocą automatycznie wygenerowanej wewnętrznej nazwy DNS http://myapi w tym samym środowisku, co umożliwia prostą komunikację między usługami bez wdrażania bramy API.

Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

W tej lekcji dowiedzieli się Państwo, że Azure Container Apps zapewnia bezserwerowe uruchamianie kontenerów oparte na Kubernetes i KEDA, bez konieczności zarządzania klastrem, skalery KEDA umożliwiają skalowanie do zera na podstawie długości kolejki, ruchu HTTP lub harmonogramów cron, a integracja z Dapr upraszcza komunikację między mikrousługami i zarządzanie stanem. W następnej części połączymy wszystkie elementy w kompletny kompleksowy przepływ pracy dewelopera.