Benutzerdefinierte Azure Container Apps-Containersitzungen (Vorschau)
Zusätzlich zum integrierten Codeinterpreter, den dynamische Azure Container Apps-Sitzungen bereitstellen, können Sie auch benutzerdefinierte Container verwenden, um Ihre eigenen Sitzungssandboxes zu definieren.
Hinweis
Dynamische Azure Container Apps-Sitzungen befinden sich derzeit in der Vorschau. Weitere Informationen finden Sie unter Einschränkungen der Vorschauversion.
Verwendungsmöglichkeiten für benutzerdefinierte Containersitzungen
Mit benutzerdefinierten Containern können Sie Lösungen erstellen, die speziell auf Ihre Anforderungen zugeschnitten sind. Sie ermöglichen es Ihnen, Code oder Anwendungen in Umgebungen auszuführen, die schnell und kurzlebig sind und sichere Sandkastenbereiche mit Hyper-V bieten. Darüber hinaus können sie mit optionaler Netzwerkisolation konfiguriert werden. Beispiele hierfür sind:
Codeinterpreter: Wenn Sie nicht vertrauenswürdigen Code in sicheren Sandboxes mit einer Sprache ausführen müssen, die im integrierten Interpreter nicht unterstützt wird, oder Sie die vollständige Kontrolle über die Codeinterpreterumgebung benötigen.
Isolierte Ausführung: Wenn Sie Anwendungen in feindlichen Szenarien mit mehreren Mandanten ausführen müssen, in denen jeder Mandant oder Benutzer über eine eigene Sandkastenumgebung verfügt. Diese Umgebungen sind voneinander und von der Hostanwendung isoliert. Beispiele sind u. a. Anwendungen, die vom Benutzer bereitgestellten Code ausführen, Code, der Endbenutzerzugriff auf eine cloudbasierte Shell gewährt, KI-Agents und Entwicklungsumgebungen.
Verwenden benutzerdefinierter Containersitzungen
Um benutzerdefinierte Containersitzungen zu verwenden, erstellen Sie zunächst einen Sitzungspool mit einem benutzerdefinierten Containerimage. Azure Container Apps startet Container automatisch mit den bereitgestellten Images in ihren eigenen Hyper-V-Sandboxes. Sobald der Container gestartet wurde, ist er für den Sitzungspool verfügbar.
Wenn Ihre Anwendung eine Sitzung anfordert, wird sofort eine Instanz aus dem Pool zugeordnet. Die Sitzung bleibt aktiv, bis sie in einen Leerlaufzustand wechselt, wird dann automatisch beendet und zerstört.
Erstellen eines benutzerdefinierten Containersitzungspools
Um einen benutzerdefinierten Containersitzungspool zu erstellen, müssen Sie ein Containerimage und Konfigurationseinstellungen für den Pool bereitstellen.
Sie rufen mithilfe von HTTP-Anforderungen einzelne Sitzungen auf oder kommunizieren mit diesen. Der benutzerdefinierte Container muss einen HTTP-Server auf einem von Ihnen angegebenen Port verfügbar machen, um auf diese Anforderungen zu reagieren.
Wenn Sie einen benutzerdefinierten Containersitzungspool mit der Azure-Befehlszeilenschnittstelle (Command Line Interface, CLI) erstellen möchten, stellen Sie mithilfe der folgenden Befehle sicher, dass Sie über die aktuellen Versionen der Azure CLI und der Azure Container Apps-Erweiterung verfügen:
az upgrade
az extension add --name containerapp --upgrade --allow-preview true -y
Benutzerdefinierte Containersitzungspools erfordern eine Azure Container Apps-Umgebung mit Unterstützung für Workloadprofile. Falls Sie nicht über eine Umgebung verfügen, verwenden Sie den Befehl az containerapp env create -n <ENVIRONMENT_NAME> -g <RESOURCE_GROUP> --location <LOCATION> --enable-workload-profiles
, um eine zu erstellen.
Verwenden Sie den Befehl az containerapp sessionpool create
, um einen benutzerdefinierten Containersitzungspool zu erstellen.
Im folgenden Beispiel wird ein Sitzungspool namens my-session-pool
mit dem benutzerdefinierten Containerimage myregistry.azurecr.io/my-container-image:1.0
erstellt.
Ersetzen Sie vor dem Senden der Anforderung die Platzhalter zwischen den Klammern (<>
) durch die entsprechenden Werte für Ihren Sitzungspool und die Sitzungs-ID.
az containerapp sessionpool create \
--name my-session-pool \
--resource-group <RESOURCE_GROUP> \
--environment <ENVIRONMENT> \
--registry-server myregistry.azurecr.io \
--registry-username <USER_NAME> \
--registry-password <PASSWORD> \
--container-type CustomContainer \
--image myregistry.azurecr.io/my-container-image:1.0 \
--cpu 0.25 --memory 0.5Gi \
--target-port 80 \
--cooldown-period 300 \
--network-status EgressDisabled \
--max-sessions 10 \
--ready-sessions 5 \
--env-vars "key1=value1" "key2=value2" \
--location <LOCATION>
Dieser Befehl erstellt einen Sitzungspool mit den folgenden Einstellungen:
Parameter | Wert | Beschreibung |
---|---|---|
--name |
my-session-pool |
Der Name des Sitzungspools. |
--resource-group |
my-resource-group |
Die Ressourcengruppe, die den Sitzungspool enthält. |
--environment |
my-environment |
Der Name der Ressourcen-ID der Umgebung der Container-App. |
--container-type |
CustomContainer |
Der Containertyp des Sitzungspools. Für benutzerdefinierte Containersitzungen muss der Typ CustomContainer sein. |
--image |
myregistry.azurecr.io/my-container-image:1.0 |
Das Containerimage, das für den Sitzungspool verwendet werden soll. |
--registry-server |
myregistry.azurecr.io |
Der Hostname des Containerregistrierungsservers. |
--registry-username |
my-username |
Der Benutzername für die Anmeldung bei der Containerregistrierung. |
--registry-password |
my-password |
Das Kennwort für die Anmeldung bei der Containerregistrierung. |
--cpu |
0.25 |
Die erforderliche CPU in Kernen. |
--memory |
0.5Gi |
Der erforderliche Arbeitsspeicher. |
--target-port |
80 |
Der Sitzungsport, der für eingehenden Datenverkehr verwendet wird. |
--cooldown-period |
300 |
Die Anzahl von Sekunden, nach der eine Sitzung im Leerlauf beendet wird. Der Leerlaufzeitraum wird jedes Mal zurückgesetzt, wenn die API der Sitzung aufgerufen wird. Der Wert muss zwischen 300 und 3600 liegen. |
--network-status |
Legt fest, ob ausgehender Netzwerkdatenverkehr aus der Sitzung zulässig ist. Gültige Werte sind EgressDisabled (Standard) und EgressEnabled . |
|
--max-sessions |
10 |
Die maximale Anzahl von Sitzungen, die gleichzeitig zugeordnet werden können. |
--ready-sessions |
5 |
Die Zielanzahl von Sitzungen, die immer im Sitzungspool bereit sind. Erhöhen Sie diese Anzahl, wenn Sitzungen schneller zugeordnet werden, als der Pool aufgefüllt wird. |
--env-vars |
"key1=value1" "key2=value2" |
Die Umgebungsvariablen, die im Container festgelegt werden sollen. |
--location |
"Supported Location" |
Der Speicherort des Sitzungspools. |
Verwenden Sie den Befehl az containerapp sessionpool update
, um den Sitzungspool zu aktualisieren.
Wichtig
Wenn die Sitzung zum Ausführen von nicht vertrauenswürdigem Code verwendet wird, schließen Sie keine Informationen oder Daten ein, auf die der nicht vertrauenswürdige Code nicht zugreifen soll. Gehen Sie davon aus, dass der Code schädlich ist und Vollzugriff auf den Container hat, einschließlich der Umgebungsvariablen, Geheimnisse und Dateien.
Mit Sitzungen arbeiten
Ihre Anwendung interagiert mithilfe der Verwaltungs-API des Sitzungspools mit einer Sitzung.
Der Verwaltungsendpunkt eines Pools für benutzerdefinierte Containersitzungen weist folgendes Format auf: https://<SESSION_POOL>.<ENVIRONMENT_ID>.<REGION>.azurecontainerapps.io
.
Verwenden Sie den Befehl az containerapp sessionpool show
, um den Verwaltungsendpunkt des Sitzungspools abzurufen:
az containerapp sessionpool show \
--name <SESSION_POOL_NAME> \
--resource-group <RESOURCE_GROUP> \
--query "properties.poolManagementEndpoint" \
--output tsv
Alle Anforderungen an den Verwaltungsendpunkt des Pools müssen einen Authorization
-Header mit einem Bearertoken enthalten. Informationen zum Authentifizieren mit der Poolverwaltungs-API finden Sie unter Authentifizierung.
Jede API-Anforderung muss auch den Abfragezeichenfolgenparameter identifier
mit der Sitzungs-ID enthalten. Mit dieser eindeutigen Sitzungs-ID kann Ihre Anwendung mit bestimmten Sitzungen interagieren. Weitere Informationen zu Sitzungs-IDs finden Sie unter Sitzungs-IDs.
Wichtig
Der Sitzungsbezeichner ist vertrauliche Information, was einen sicheren Prozess erfordert, während Sie seinen Wert erstellen und verwalten. Um diesen Wert zu schützen, muss Ihre Anwendung sicherstellen, dass jeder Benutzer oder Mandant nur Zugriff auf seine eigenen Sitzungen hat. Wenn Sie den Zugriff auf Sitzungen nicht sichern, kann dies zu Missbrauch oder unbefugtem Zugriff auf Daten führen, die in den Sitzungen Ihrer Benutzer gespeichert sind. Weitere Informationen finden Sie unter Sitzungs-IDs.
Weiterleiten von Anforderungen an den Container der Sitzung:
Alle Elemente im Pfad, die dem Verwaltungsendpunkt für den Basispool folgen, werden an den Container der Sitzung weitergeleitet.
Wenn Sie z. B. <POOL_MANAGEMENT_ENDPOINT>/api/uploadfile
aufrufen, wird die Anforderung an den Container der Sitzung an 0.0.0.0:<TARGET_PORT>/api/uploadfile
weitergeleitet.
Kontinuierliche Sitzungsinteraktion:
Sie können weiterhin Anforderungen an dieselbe Sitzung senden. Wenn länger als die Abkühldauer keine Anforderungen an die Sitzung gesendet werden, wird die Sitzung automatisch gelöscht.
Beispielanforderung
Das folgende Beispiel zeigt eine Anforderung an eine benutzerdefinierte Containersitzung anhand einer Benutzer-ID.
Ersetzen Sie vor dem Senden der Anforderung die Platzhalter zwischen den Klammern (<>
) durch Werte, die für Ihre Anforderung spezifisch sind.
POST https://<SESSION_POOL_NAME>.<ENVIRONMENT_ID>.<REGION>.azurecontainerapps.io/<API_PATH_EXPOSED_BY_CONTAINER>?identifier=<USER_ID>
Authorization: Bearer <TOKEN>
{
"command": "echo 'Hello, world!'"
}
Diese Anforderung wird an die benutzerdefinierte Containersitzung mit dem Bezeichner für die Benutzer-ID weitergeleitet. Wenn die Sitzung noch nicht ausgeführt wird, ordnet Azure Container Apps eine Sitzung aus dem Pool zu, bevor die Anforderung weitergeleitet wird.
Im Beispiel empfängt der Container der Sitzung die Anforderung unter http://0.0.0.0:<INGRESS_PORT>/<API_PATH_EXPOSED_BY_CONTAINER>
.