Übersicht: Dynamische Azure Container Apps-Sitzungen

Dynamische Azure Container Apps-Sitzungen bieten schnellen Zugriff auf sichere Sandkastenumgebungen, die sich ideal für die Ausführung von Code oder Anwendungen eignen, die eine starke Isolation von anderen Workloads erfordern.

Sitzungen verfügen über die folgenden Attribute:

• Starke Isolation: Sitzungen sind voneinander und von der Hostumgebung isoliert. Jede Sitzung wird in einer eigenen Hyper-V-Sandbox ausgeführt, die Sicherheit und Isolation auf Unternehmensniveau bietet. Optional können Sie die Netzwerkisolation aktivieren, um die Sicherheit weiter zu verbessern.

• Einfacher Zugriff: Auf Sitzungen wird über eine REST-API zugegriffen. Ein eindeutiger Bezeichner (ID) kennzeichnete jede Sitzung. Wenn eine Sitzung mit einem bestimmten Bezeichner nicht vorhanden ist, wird automatisch eine neue Sitzung zugeordnet.

• Vollständig verwaltet: Der Lebenszyklus von Sitzungen wird vollständig von der Plattform verwaltet. Sitzungen werden automatisch bereinigt, wenn sie nicht mehr verwendet werden.

• Schneller Start: Eine neue Sitzung wird innerhalb von Millisekunden zugeordnet. Schnelle Starts werden erreicht, indem automatisch ein Pool von Sitzungen aufrechterhalten wird, die einsatzbereit, aber nicht zugeordnet sind.

• Skalierbar: Sitzungen können in großem Stil ausgeführt werden. Sie können Hunderte oder Tausende von Sitzungen gleichzeitig ausführen.

Sitzungstypen

Azure Container Apps unterstützt zwei Sitzungstypen:

Codeinterpreter

Codeinterpretersitzungen ermöglichen Ihnen die Ausführung von Code in einer Sandbox, in der beliebte Bibliotheken vorinstalliert sind. Sie eignen sich ideal zum Ausführen von nicht vertrauenswürdigem Code, z. B. Code, der von Benutzern Ihrer Anwendung bereitgestellt oder von einem großen Sprachmodell (Large Language Model, LLM) generiert wird. Erfahren Sie mehr über Codeinterpretersitzungen.

Benutzerdefinierter Container

Benutzerdefinierte Containersitzungen ermöglichen Ihnen das Ausführen Ihrer eigenen Containerimages in sicheren, isolierten Sandboxes. Sie können sie verwenden, um einen benutzerdefinierten Codeinterpreter für eine Sprache auszuführen, die nicht standardmäßig unterstützt wird, oder um Workloads auszuführen, die eine starke Isolation erfordern. Erfahren Sie mehr über benutzerdefinierte Containersitzungen.

Konzepte

Die wichtigsten Konzepte in Zusammenhang mit dynamischen Azure Container Apps-Sitzungen sind Sitzungspools und Sitzungen.

Sitzungspools

Um Sitzungen in weniger als einer Sekunde bereitzustellen, verwaltet Azure Container Apps einen Pool von Sitzungen, die bereit, aber nicht zugeordnet sind. Wenn Sie eine Anforderung an eine neue Sitzung übermitteln, ordnet die Plattform Ihnen eine Sitzung aus dem Pool zu. Wenn Sitzungen zugeordnet werden, füllt die Plattform den Pool automatisch wieder auf, um eine konstante Anzahl von einsatzbereiten Sitzungen aufrechtzuerhalten.

Sie können Pools konfigurieren, um die maximale Anzahl von Sitzungen, die gleichzeitig zugeordnet werden können, über die maxConcurrentSessions-Eigenschaft festzulegen. Mit der cooldownPeriodInSeconds-Eigenschaft können Sie die Wartezeit nach der letzten Anforderung festlegen, bevor eine Sitzung gelöscht wird. Für benutzerdefinierte Containersitzungen können Sie auch das Containerimage und die Einstellungen angeben, die für die Sitzungen im Pool verwendet werden sollen. Unter anderem können Sie über readySessionInstances die Zielanzahl von Sitzungen festlegen, die im Pool bereit gehalten werden sollen.

Sitzungen

Eine Sitzung ist eine Sandkastenumgebung, in der Ihr Code oder Ihre Anwendung ausgeführt wird. Jede Sitzung ist von anderen Sitzungen und von der Hostumgebung mit einer Hyper-V-Sandbox isoliert. Optional können Sie die Netzwerkisolation aktivieren, um die Sicherheit weiter zu verbessern.

Sie interagieren mit Sitzungen in einem Sitzungspool, indem Sie HTTP-Anforderungen übermitteln. Jeder Sitzungspool verfügt über einen eindeutigen Poolverwaltungsendpunkt.

Für Codeinterpretersitzungen können Sie auch eine Integration in ein LLM-Framework verwenden.

Sitzungs-IDs

Um eine HTTP-Anforderung an eine Sitzung zu senden, müssen Sie in der Anforderung eine Sitzungs-ID angeben. Sie übergeben die Sitzungs-ID in einem Abfrageparameter namens identifier in der URL, wenn Sie eine Anforderung an eine Sitzung senden.

• Wenn bereits eine Sitzung mit dem Bezeichner vorhanden ist, wird die Anforderung an die vorhandene Sitzung übermittelt.
• Wenn keine Sitzung mit diesem Bezeichner vorhanden ist, wird automatisch eine neue Sitzung zugewiesen, bevor die Anforderung übermittelt wird.

Bezeichnerformat

Die Sitzungs-ID ist eine Freiformzeichenfolge, d. h. Sie können je nach den Anforderungen Ihrer Anwendung eine beliebige ID festlegen.

Die Sitzungs-ID ist eine Zeichenfolge, die Sie definieren und die innerhalb des Sitzungspools eindeutig ist. Wenn Sie eine Webanwendung erstellen, können Sie die Benutzer-ID als Sitzungs-ID verwenden. Wenn Sie einen Chatbot erstellen, können Sie die Unterhaltungs-ID verwenden.

Die ID muss eine Zeichenfolge sein, die 4 bis 128 Zeichen lang ist. Sie darf nur alphanumerische Zeichen und folgende Sonderzeichen enthalten: |, -, &, ^, %, $, #, (, ), {, }, [, ], ;, < und >.

Schützen von Sitzungsbezeichnern

Sitzungs-IDs gelten als vertrauliche Informationen, die Sie sicher verwalten müssen. Ihre Anwendung muss sicherstellen, dass alle Benutzenden oder Mandant nur Zugriff auf die eigenen Sitzungen haben.

Die spezifischen Strategien, die den Missbrauch von Sitzungsbezeichnern verhindern, unterscheiden sich je nach Design und Architektur Ihrer App. Ihre App muss jedoch immer die vollständige Kontrolle über die Erstellung und Verwendung von Sitzungs-IDs haben, damit ein böswilliger Benutzer nicht auf die Sitzung eines anderen Benutzers zugreifen kann.

Beispiele für geeignete Strategien umfassen:

• Eine Sitzung pro Benutzer: Wenn Ihre App eine Sitzung pro Benutzer verwendet, muss jeder Benutzer sicher authentifiziert werden, und Ihre App muss für jeden angemeldeten Benutzer einen eindeutigen Sitzungsbezeichner verwenden.
• Eine Sitzung pro Agentunterhaltung: Wenn Ihre App eine Sitzung pro KI-Agent-Unterhaltung verwendet, stellen Sie sicher, dass Ihre App für jede Unterhaltung, die vom Endbenutzer nicht geändert werden kann, einen eindeutigen Sitzungsbezeichner verwendet.

Authentifizierung und Autorisierung

Wenn Sie Anforderungen mithilfe der Poolverwaltungs-API an eine Sitzung übermitteln, erfolgt die Authentifizierung mithilfe von Microsoft Entra-Token (ehemals Azure Active Directory). Nur Microsoft Entra-Token aus einer Identität, die zur Rolle Azure ContainerApps-Sitzungsausführer im Sitzungspool gehört, sind berechtigt, die Poolverwaltungs-API aufzurufen.

Verwenden Sie den folgenden Azure CLI-Befehl, um einer Identität die Rolle zuzuweisen:

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

Wenn Sie eine LLM-Frameworkintegration verwenden, verarbeitet das Framework die Tokengenerierung und -verwaltung für Sie. Stellen Sie sicher, dass die Anwendung mit einer verwalteten Identität mit den erforderlichen Rollenzuweisungen im Sitzungspool konfiguriert ist.

Wenn Sie die API-Verwaltungsendpunkte des Pools direkt verwenden, müssen Sie ein Token generieren und in den Authorization-Header Ihrer HTTP-Anforderungen einschließen. Zusätzlich zu den zuvor erwähnten Rollenzuweisungen muss das Token einen Zielgruppenanspruch (aud) mit dem Wert https://dynamicsessions.io enthalten.

az account get-access-token --resource https://dynamicsessions.io

dotnet add package Azure.Identity

using Azure.Identity;

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

npm install @azure/identity

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;

pip install azure-identity

from azure.identity import DefaultAzureCredential

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

Lebenszyklus

Die Container Apps-Runtime verwaltet automatisch den Lebenszyklus jeder Sitzung in einem Sitzungspool.

• Ausstehend: Wenn eine Sitzung gestartet wird, befindet sie sich im Status „Ausstehend“. Wie lange eine Sitzung im Status „Ausstehend“ verbleibt, hängt vom Containerimage und von den Einstellungen ab, die Sie für den Sitzungspool angeben. Eine ausstehende Sitzung wird nicht zum Pool einsatzbereiter Sitzungen hinzugefügt.

• Bereit: Wenn eine Sitzung gestartet wurde und bereit ist, wird sie dem Pool hinzugefügt. Die Sitzung ist in diesem Status zur Zuordnung verfügbar. Bei benutzerdefinierten Containersitzungen können Sie die Zielanzahl einsatzbereiter Sitzungen angeben, die im Pool beibehalten werden sollen. Erhöhen Sie diese Anzahl, wenn Sitzungen schneller zugeordnet werden, als der Pool aufgefüllt wird.

• Zugeordnet: Wenn Sie eine Anforderung an eine nicht ausgeführte Sitzung senden, stellt der Pool eine neue Sitzung bereit und versetzt sie in den Status „Zugeordnet“. Nachfolgende Anforderungen mit derselben Sitzungs-ID werden an dieselbe Sitzung weitergeleitet.

• Löschen: Wenn eine Sitzung den Empfang von Anforderungen während des Zeitraums beendet, der mit der Einstellung cooldownPeriodInSeconds festgelegt wurde, werden die Sitzung und die zugehörige Hyper-V-Sandbox vollständig und sicher gelöscht.

Sicherheit

Dynamische Azure Container Apps-Sitzungen sind dafür konzipiert, nicht vertrauenswürdige Codes und Anwendungen in einer sicheren und isolierten Umgebung auszuführen. Obwohl Sitzungen voneinander isoliert sind, sind alle Daten innerhalb einer einzelnen Sitzung (einschließlich Dateien und Umgebungsvariablen) für Benutzer der Sitzung zugänglich. Sie sollten vertrauliche Daten nur dann in einer Sitzung konfigurieren oder hochladen, wenn Sie den Benutzern der Sitzung vertrauen.

Standardmäßig können Sitzungen keine ausgehenden Netzwerkanforderungen stellen. Sie können den Netzwerkzugriff steuern, indem Sie die Netzwerkstatuseinstellungen im Sitzungspool konfigurieren.

Befolgen Sie darüber hinaus den Leitfaden im Abschnitt Authentifizierung und Autorisierung, um sicherzustellen, dass nur autorisierte Benutzende auf Sitzungen zugreifen können, und den Abschnitt Schützen von Sitzungs-IDs, um sicherzustellen, dass Sitzungs-IDs sicher sind.

Einschränkungen der Vorschau

Dynamische Azure Container Apps-Sitzungen befinden sich derzeit in der Vorschau. Es gelten die folgenden Einschränkungen:

• Die Vorschau ist nur in folgenden Regionen verfügbar:

  Region	Codeinterpreter	Benutzerdefinierter Container
  Asien, Osten	✔	✔
  East US	✔	✔
  Deutschland, Westen-Mitte	✔	✔
  Italien, Norden	✔	✔
  Polen, Mitte	✔	✔
  USA Nord Mitte	✔	-
  Nordeuropa	✔	✔
  USA, Westen 2	✔	✔

Nächste Schritte