Omówienie sesji dynamicznych usługi Azure Container Apps
Dynamiczne sesje Azure Container Apps zapewniają szybki dostęp do bezpiecznych środowisk sandbox, które są idealne do uruchamiania kodu lub aplikacji wymagających silnej izolacji od innych obciążeń.
Sesje mają następujące atrybuty:
Silna izolacja: sesje są odizolowane od siebie i od środowiska hosta. Każda sesja jest uruchamiana we własnej piaskownicy funkcji Hyper-V, zapewniając bezpieczeństwo i izolację klasy korporacyjnej. Opcjonalnie możesz włączyć izolację sieci, aby dodatkowo zwiększyć bezpieczeństwo.
Prosty dostęp: sesje są dostępne za pośrednictwem interfejsu API REST. Unikatowy identyfikator oznacza każdą sesję. Jeśli sesja z danym identyfikatorem nie istnieje, nowa sesja zostanie automatycznie przydzielona.
W pełni zarządzane: platforma w pełni zarządza cyklem życia sesji. Sesje są automatycznie czyszczone, gdy nie są już używane.
Szybkie uruchamianie: nowa sesja jest przydzielana w milisekundach. Szybkie start-upy są osiągane przez automatyczne utrzymywanie puli gotowych, ale nieprzydzielonych sesji.
Skalowalne: sesje mogą być uruchamiane na dużą skalę. Można uruchamiać setki lub tysiące sesji jednocześnie.
Rodzaje sesji
Usługa Azure Container Apps obsługuje dwa typy sesji:
| Type | Opis | Model rozliczania |
|---|---|---|
| Interpreter kodu | W pełni zarządzany interpreter kodu | Na sesję (zużycie) |
| Kontener niestandardowy | Korzystanie z własnego kontenera | Dedykowany plan usługi Container Apps |
Interpreter kodu
Sesje interpretera kodu umożliwiają uruchamianie kodu w piaskownicy, która jest wstępnie zainstalowana z popularnymi bibliotekami. Doskonale nadają się do uruchamiania niezaufanego kodu, takiego jak kod dostarczony przez użytkowników aplikacji lub kod generowany przez duży model językowy (LLM). Dowiedz się więcej o sesjach interpretera kodu.
Kontener niestandardowy
Niestandardowe sesje kontenerów umożliwiają uruchamianie własnych obrazów kontenerów w bezpiecznych izolowanych piaskownicach. Można ich używać do uruchamiania niestandardowego interpretera kodu dla języka, który nie jest obsługiwany poza urządzeniem, lub do uruchamiania obciążeń wymagających silnej izolacji. Dowiedz się więcej o niestandardowych sesjach kontenerów.
Pojęcia
Kluczowe pojęcia w sesjach dynamicznych usługi Azure Container Apps to pule sesji i sesje.
Pule sesji
Aby zapewnić czas alokacji sesji podrzędnej, usługa Azure Container Apps utrzymuje pulę gotowych, ale nieprzydzielonych sesji. Po przesłaniu żądania do nowej sesji platforma przydziela sesję z puli do Ciebie. W miarę przydzielania sesji platforma automatycznie uzupełnia pulę w celu utrzymania stałej liczby gotowych sesji.
Pule można skonfigurować tak, aby ustawić maksymalną liczbę sesji, które można przydzielić współbieżnie za pośrednictwem maxConcurrentSessions właściwości . Czas oczekiwania można ustawić z ostatniego żądania przed usunięciem właściwości sesji cooldownPeriodInSeconds . W przypadku niestandardowych sesji kontenera można również określić obraz kontenera i ustawienia do użycia dla sesji w puli, w tym docelową liczbę sesji, które będą gotowe w puli za pośrednictwem programu readySessionInstances.
Sesje
Sesja to środowisko w trybie piaskownicy, które uruchamia kod lub aplikację. Każda sesja jest odizolowana od innych sesji i ze środowiska hosta przy użyciu piaskownicy funkcji Hyper-V . Opcjonalnie możesz włączyć izolację sieci, aby dodatkowo zwiększyć bezpieczeństwo.
Interakcja z sesjami w puli sesji jest wysyłana przez wysyłanie żądań HTTP. Każda pula sesji ma unikatowy punkt końcowy zarządzania pulą.
W przypadku sesji interpretera kodu można również użyć integracji z platformą LLM.
Identyfikatory sesji
Aby wysłać żądanie HTTP do sesji, musisz podać identyfikator sesji w żądaniu. Identyfikator sesji jest przekazywany w parametrze zapytania o nazwie identifier w adresie URL podczas wysyłania żądania do sesji.
- Jeśli sesja z identyfikatorem już istnieje, żądanie zostanie wysłane do istniejącej sesji.
- Jeśli sesja z identyfikatorem nie istnieje, nowa sesja zostanie automatycznie przydzielona przed wysłaniem żądania.
Format identyfikatora
Identyfikator sesji jest ciągiem swobodnym, co oznacza, że można go zdefiniować w dowolny sposób, który odpowiada potrzebom aplikacji.
Identyfikator sesji jest ciągiem zdefiniowanym, który jest unikatowy w puli sesji. Jeśli tworzysz aplikację internetową, możesz użyć identyfikatora użytkownika jako identyfikatora sesji. Jeśli tworzysz czatbota, możesz użyć identyfikatora konwersacji.
Identyfikator musi być ciągiem o długości od 4 do 128 znaków i może zawierać tylko znaki alfanumeryczne i znaki specjalne z tej listy: |, [%^$&#})(-];{, <i .>
Ochrona identyfikatorów sesji
Identyfikator sesji jest poufnymi informacjami, którymi musisz zarządzać bezpiecznie. Aplikacja musi mieć pewność, że każdy użytkownik lub dzierżawa ma dostęp tylko do własnych sesji.
Konkretne strategie, które uniemożliwiają nieprawidłowe użycie identyfikatorów sesji, różnią się w zależności od projektu i architektury aplikacji. Jednak aplikacja musi zawsze mieć pełną kontrolę nad tworzeniem i używaniem identyfikatorów sesji, aby złośliwy użytkownik nie mógł uzyskać dostępu do sesji innego użytkownika.
Przykładowe strategie obejmują:
- Jedna sesja na użytkownika: jeśli aplikacja używa jednej sesji na użytkownika, każdy użytkownik musi być bezpiecznie uwierzytelniony, a aplikacja musi używać unikatowego identyfikatora sesji dla każdego zalogowanego użytkownika.
- Jedna sesja na konwersację agenta: jeśli aplikacja używa jednej sesji na konwersację agenta sztucznej inteligencji, upewnij się, że aplikacja używa unikatowego identyfikatora sesji dla każdej konwersacji, której nie można modyfikować przez użytkownika końcowego.
Ważne
Brak bezpiecznego dostępu do sesji może spowodować nieprawidłowe użycie lub nieautoryzowany dostęp do danych przechowywanych w sesjach użytkowników.
Uwierzytelnianie i autoryzacja
Podczas wysyłania żądań do sesji przy użyciu interfejsu API zarządzania pulą uwierzytelnianie jest obsługiwane przy użyciu tokenów firmy Microsoft Entra (dawniej Azure Active Directory). Tylko tokeny firmy Microsoft z tożsamości należącej do roli wykonawczej sesji usługi Azure ContainerApps w puli sesji są autoryzowane do wywoływania interfejsu API zarządzania pulą.
Aby przypisać rolę do tożsamości, użyj następującego polecenia interfejsu wiersza polecenia platformy Azure:
az role assignment create \
--role "Azure ContainerApps Session Executor" \
--assignee <PRINCIPAL_ID> \
--scope <SESSION_POOL_RESOURCE_ID>
Jeśli używasz integracji platformy LLM, platforma obsługuje generowanie tokenów i zarządzanie nimi. Upewnij się, że aplikacja jest skonfigurowana przy użyciu tożsamości zarządzanej z niezbędnymi przypisaniami ról w puli sesji.
Jeśli bezpośrednio używasz punktów końcowych interfejsu API zarządzania puli, musisz wygenerować token i dołączyć go do Authorization nagłówka żądań HTTP. Oprócz wymienionych wcześniej przypisań ról token musi zawierać oświadczenie odbiorców (aud) o wartości https://dynamicsessions.io.
Aby wygenerować token przy użyciu interfejsu wiersza polecenia platformy Azure, uruchom następujące polecenie:
az account get-access-token --resource https://dynamicsessions.io
Ważne
Prawidłowy token może służyć do tworzenia i uzyskiwania dostępu do dowolnej sesji w puli. Zachowaj bezpieczeństwo tokenów i nie udostępniaj ich niezaufanym stronom. Użytkownicy końcowi powinni uzyskiwać dostęp do sesji za pośrednictwem aplikacji, a nie bezpośrednio. Nigdy nie powinny mieć dostępu do tokenów używanych do uwierzytelniania żądań w puli sesji.
Cykl życia
Środowisko uruchomieniowe usługi Container Apps automatycznie zarządza cyklem życia każdej sesji w puli sesji.
Oczekujące: po uruchomieniu sesji jest ona w stanie oczekiwania. Ilość czasu, jaki sesja spędza w stanie oczekiwania, zależy od obrazu kontenera i ustawień dla puli sesji. Oczekująca sesja nie jest dodawana do puli gotowych sesji.
Gotowe: gdy sesja zostanie zakończona i będzie gotowa, zostanie dodana do puli. Sesja jest dostępna w tym stanie alokacji. W przypadku niestandardowych sesji kontenerów można określić docelową liczbę gotowych sesji do przechowywania w puli. Zwiększ tę liczbę, jeśli sesje są przydzielane szybciej niż pula jest uzupełniana.
Przydzielone: po wysłaniu żądania do sesji, która nie działa, pula udostępnia nową sesję i umieszcza ją w stanie przydzielonym. Kolejne żądania z tym samym identyfikatorem sesji są kierowane do tej samej sesji.
Usuwanie: gdy sesja przestanie odbierać żądania w czasie zdefiniowanym
cooldownPeriodInSecondsprzez to ustawienie, sesja i jej piaskownica funkcji Hyper-V są całkowicie i bezpiecznie usuwane.
Zabezpieczenia
Sesje dynamiczne usługi Azure Container Apps są tworzone w celu uruchamiania niezaufanego kodu i aplikacji w bezpiecznym i izolowanym środowisku. Podczas gdy sesje są odizolowane od siebie, wszystkie elementy w ramach jednej sesji, w tym pliki i zmienne środowiskowe, są dostępne dla użytkowników sesji. Należy skonfigurować lub przekazać poufne dane tylko do sesji, jeśli ufasz użytkownikom sesji.
Domyślnie sesje nie mogą wysyłać wychodzących żądań sieciowych. Dostęp sieciowy można kontrolować, konfigurując ustawienia stanu sieci w puli sesji.
Ponadto postępuj zgodnie ze wskazówkami w sekcji uwierzytelnianie i autoryzacja , aby upewnić się, że tylko autoryzowani użytkownicy mogą uzyskiwać dostęp do sesji i w sekcji Ochrona identyfikatorów sesji, aby upewnić się, że identyfikatory sesji są bezpieczne.
Ograniczenia wersji zapoznawczej
Następujące ograniczenia dotyczą sesji dynamicznych:
Jest ona dostępna tylko w następujących regionach:
Region (Region) Interpreter kodu Kontener niestandardowy Australia Wschodnia ✔ ✔ Środkowe stany USA — EUAP ✔ ✔ Wschodnie stany USA 2 — EUAP ✔ ✔ Wschodnie stany USA ✔ ✔ Azja Wschodnia ✔ ✔ Niemcy Środkowo-Zachodnie ✔ ✔ Włochy Północne ✔ ✔ Północno-środkowe stany USA ✔ - Polska Środkowa ✔ ✔ Szwajcaria Północna ✔ ✔ Zachodnio-środkowe stany USA ✔ ✔ Zachodnie stany USA 2 ✔ ✔