Omówienie sesji dynamicznych usługi Azure Container Apps

Artykuł
06/20/2024

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.

Uwaga

Sesje dynamiczne usługi Azure Container Apps są obecnie dostępne w wersji zapoznawczej.

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.

Identyfikatory sesji

Podczas interakcji z sesjami w puli należy zdefiniować identyfikator sesji, aby zarządzać każdą sesją. Identyfikator sesji jest ciągiem swobodnym, co oznacza, że można go zdefiniować w dowolny sposób, który odpowiada potrzebom aplikacji. Ten identyfikator jest kluczowym elementem określania zachowania sesji:

Ponowne użycie istniejących sesji: ta sesja jest ponownie wykorzystywana, jeśli istnieje już uruchomiona sesja zgodna z identyfikatorem.
Alokacja nowych sesji: jeśli żadna uruchomiona sesja nie jest zgodna z identyfikatorem, nowa sesja zostanie automatycznie przydzielona z puli.

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. 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 .>

Identyfikator sesji jest przekazywany w parametrze zapytania o nazwie identifier w adresie URL podczas wysyłania żądania do sesji.

W przypadku sesji interpretera kodu można również użyć integracji z platformą 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, która ma niezbędne przypisania ról w puli sesji.

Ochrona identyfikatorów sesji

Identyfikator sesji jest poufnymi informacjami, które wymagają bezpiecznego procesu podczas tworzenia wartości i zarządzania nią. Aby chronić tę wartość, 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

Uwierzytelnianie jest obsługiwane przy użyciu tokenów firmy Microsoft Entra (dawniej Azure Active Directory). Prawidłowe tokeny usługi Microsoft Entra są generowane przez tożsamość należącą do funkcji wykonawczej sesji usługi Azure ContainerApps i współautora w puli sesji.

Aby przypisać role do tożsamości, użyj następujących poleceń interfejsu wiersza polecenia platformy Azure:

az role assignment create \
    --role "Azure ContainerApps Session Executor" \
    --assignee <PRINCIPAL_ID> \
    --scope <SESSION_POOL_RESOURCE_ID>

az role assignment create \
    --role "Contributor" \
    --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

W języku C#możesz użyć Azure.Identity biblioteki do wygenerowania tokenu. Najpierw zainstaluj bibliotekę:

dotnet add package Azure.Identity

Następnie użyj następującego kodu, aby wygenerować token:

using Azure.Identity;

var credential = new DefaultAzureCredential();
var token = credential.GetToken(new TokenRequestContext(new[] { "https://dynamicsessions.io/.default" }));
var accessToken = token.Token;

W języku JavaScript możesz użyć @azure/identity biblioteki do wygenerowania tokenu. Najpierw zainstaluj bibliotekę:

npm install @azure/identity

Następnie użyj następującego kodu, aby wygenerować token:

const { DefaultAzureCredential } = require("@azure/identity");
const { TokenCredential } = require("@azure/core-auth");

const credential = new DefaultAzureCredential();
const token = await credential.getToken("https://dynamicsessions.io/.default");
const accessToken = token.token;

W języku Python możesz użyć azure-identity biblioteki do wygenerowania tokenu. Najpierw zainstaluj bibliotekę:

pip install azure-identity

Następnie użyj następującego kodu, aby wygenerować token:

from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
token = credential.get_token("https://dynamicsessions.io/.default")
access_token = token.token

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.

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 cooldownPeriodInSeconds przez 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.

Ograniczenia wersji zapoznawczej

Sesje dynamiczne usługi Azure Container Apps są obecnie dostępne w wersji zapoznawczej. Obowiązują następujące ograniczenia:

Jest ona dostępna tylko w następujących regionach:

Region (Region)	Interpreter kodu	Kontener niestandardowy
Azja Wschodnia	✔	✔
Wschodnie stany USA	✔	✔
Zachodnie stany USA 2	✔	✔
Północno-środkowe stany USA	✔	-
Europa Północna	✔	-

Rejestrowanie nie jest obsługiwane. Aplikacja może rejestrować żądania do interfejsu API zarządzania pulą sesji i odpowiedzi.

Następne kroki

Sesje interpretera kodu

Udostępnij za pośrednictwem

Omówienie sesji dynamicznych usługi Azure Container Apps

Rodzaje sesji

Interpreter kodu

Kontener niestandardowy

Pojęcia

Pule sesji

Sesje

Identyfikatory sesji

Ochrona identyfikatorów sesji

Uwierzytelnianie

Cykl życia

Zabezpieczenia

Ograniczenia wersji zapoznawczej

Następne kroki

Opinia

Opinia

Dodatkowe zasoby