Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 werden im Kontext eines Sitzungspools ausgeführt, der den Kaltstart verringert, um die sofortige Verfügbarkeit einer Sitzung sicherzustellen.
Mit Sitzungen erhalten Sie Folgendes:
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: Container-Apps verwaltet den Lebenszyklus einer Sitzung vollständig. Sitzungen werden automatisch bereinigt, wenn sie nicht mehr verwendet werden.
Schneller Start: Neue Sitzungen werden in Millisekunden zugewiesen. 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.
API-Zugriff: Sitzungen werden über einen einzelnen HTTP-Endpunkt für Ihre Anwendung verfügbar gemacht.
Sitzung
Eine Sitzung ist eine Sandkastenumgebung, die nicht vertrauenswürdigen Code oder Ihre Anwendung ausführt.
Jede Sitzung ist von allen anderen Sitzungen und von der Hostumgebung mit einer Hyper-V-Sandbox isoliert. Hyper-V Technologie ist die Grundlage für die Sitzungsisolation, um sicherzustellen, dass verschiedene Sitzungen unabhängig von den erforderlichen Sicherheitsgrenzen funktionieren. Um die Netzwerksicherheit zu erhöhen, können Sie die Sitzungsnetzwerkisolation in Ihrer Sitzung aktivieren.
Es gibt zwei verschiedene Arten von Sitzungen.
Sitzungstypen
Azure Container Apps unterstützt zwei Sitzungstypen:
| type | BESCHREIBUNG | Abrechnungsmodell |
|---|---|---|
| Codeinterpretersitzungen | Vollständig verwalteter Codedolmetscher, mit dem Sie Code in einer Sandkastenumgebung ausführen können, die mit beliebten Bibliotheken vorinstalliert ist. Ideal zum Ausführen von nicht vertrauenswürdigem Code, z. B. code, der von Benutzern Ihrer Anwendung oder von einem großen Sprachmodell (LLM) generiert wird. Sie können die Sitzung entweder direkt oder mit einem Sprachmodell-Framework verwenden. |
Pro Sitzung (Verbrauch) |
| Benutzerdefinierte Containersitzungen | Die Option „Bring-Your-Own-Container“, bei der Sie Ihre eigenen Container-Images in sicheren, isolierten Sandboxes ausführen. Dieser Ansatz ist eine gute Option, wenn Sie einen benutzerdefinierten Codedolmetscher für eine Sprache ausführen möchten, die nicht sofort unterstützt wird, oder Workloads, die eine starke Isolierung erfordern. |
Dedizierter Container Apps-Plan |
Jede Sitzung wird unabhängig vom Typ im Kontext eines Sitzungspools ausgeführt.
Sitzungspools
Um eine Zuordnungszeit von unter einer Sekunde bereitzustellen, verwaltet Azure Container Apps einen Pool von Sitzungen, die bereit, aber nicht zugewiesen sind. Wenn Ihre Anwendung eine Anforderung für eine Sitzung vorgibt, die noch nicht verwendet wurde, weist der Pool automatisch eine neue Sitzung für Sie zu. Wenn Sitzungen zugewiesen werden, wird der Pool automatisch aufgefüllt, um eine konstante Anzahl von bereiten Sitzungen aufrechtzuerhalten.
Jeder Sitzungspool ist für Ihre App über einen eindeutigen Poolverwaltungs-Endpunktspeicherort verfügbar.
Sitzungslebenszyklus
Die Container Apps-Runtime verwaltet automatisch den Lebenszyklus jeder Sitzung in einem Pool. Die Lebensdauer einer Sitzung beginnt mit dem Start der Sitzung und dauert an, solange die Sitzung genutzt wird. Nachdem die Abkühlzeit abgelaufen ist und es keine Anfragen mehr an die Sitzung gibt, wird die Sitzung zerstört.
Die folgenden Zustände definieren diesen Lebenszyklus:
Ausstehend: Wenn eine Sitzung gestartet wird, befindet sie sich im Status „Ausstehend“. Die Zeitspanne, die eine Sitzung in diesem Zustand verbringt, hängt vom Containerimage und den für den Sitzungspool angegebenen Einstellungen ab. Eine Sitzung in diesem Zustand wird dem Pool der bereiten Sitzungen nicht hinzugefügt.
Nicht zugewiesen: Sobald eine Sitzung gestartet wurde, wird sie dem Pool hinzugefügt und steht für die Zuordnung zur Verfügung. Für benutzerdefinierte Containersitzungen können Sie angeben, wie viele verfügbare Sitzungen im Pool beibehalten werden sollen. Diese Zahl sollte erhöht werden, wenn Sitzungen schneller zugewiesen werden, als sie aufgefüllt werden.
Zugewiesen: Wenn Sie eine Anforderung an eine nicht ausgeführte Sitzung senden, stellt der Pool eine neue Sitzung bereit und platziert sie in einem zugewiesenen Zustand. Nachfolgende Anforderungen mit demselben Sitzungsbezeichner werden an dieselbe Sitzung weitergeleitet, sodass eine effiziente Wiederverwendung ohne Kaltstart möglich ist. Jede zugeordnete Sitzung ist einem Sitzungsbezeichner zugeordnet.
Zerstört: Wenn eine Sitzung keine Anforderungen für eine von der
cooldownPeriodInSecondsEinstellung definierte Dauer empfängt, werden die Sitzung und deren Hyper-V Sandkasten sicher gelöscht. Dieses automatische Bereinigungssetup verbessert die Ressourcenverwaltung und -sicherheit.
Die Container Apps-Runtime verwaltet automatisch den Lebenszyklus jeder Sitzung in einem Sitzungspool.
Regionale Verfügbarkeit
Dynamische Sitzungen sind in den folgenden Regionen verfügbar:
| Region | Code-Interpreter | Benutzerdefinierter Container |
|---|---|---|
| Australien (Osten) | ✔ | ✔ |
| Brasilien Süd | ✔ | ✔ |
| Canada Central | ✔ | ✔ |
| Kanada, Osten | ✔ | ✔ |
| Central US | ✔ | ✔ |
| Asien, Osten | ✔ | ✔ |
| Ost-USA | ✔ | ✔ |
| Ost-USA 2 | ✔ | ✔ |
| Frankreich, Mitte | ✔ | ✔ |
| Deutschland, Westen-Mitte | ✔ | ✔ |
| Italien, Norden | ✔ | ✔ |
| Japan, Osten | ✔ | ✔ |
| Zentral-Korea | ✔ | ✔ |
| USA Nord Mitte | ✔ | ✔ |
| Nordeuropa | ✔ | ✔ |
| Norwegen, Osten | ✔ | ✔ |
| Polen, Mitte | ✔ | ✔ |
| Südafrika Nord | ✔ | ✔ |
| Südindien | ✔ | ✔ |
| Schweden, Mitte | ✔ | ✔ |
| Schweiz, Norden | ✔ | ✔ |
| Vereinigte Arabische Emirate, Norden | ✔ | ✔ |
| Vereinigtes Königreich Süd | ✔ | ✔ |
| USA, Westen-Mitte | ✔ | ✔ |
| Westeuropa | ✔ | ✔ |
| Westen der USA | ✔ | ✔ |
| USA, Westen 2 | ✔ | ✔ |
| Westliches USA 3 | ✔ | ✔ |
Abrechnung
Benutzerdefinierte Containersitzungen werden basierend auf den vom Sitzungspool verbrauchten Ressourcen abgerechnet. Weitere Informationen finden Sie unter Abrechnung von Azure Container Apps.
Sicherheit
Verwenden Sie die folgenden Methoden, um die Sicherheit Ihrer dynamischen Sitzungen zu verstärken.
Sichere Bezeichner: Verwenden Sie jederzeit sichere Sitzungs-IDs . Generieren Sie Sitzungsbezeichner mithilfe kryptografischer Methoden, um eindeutige und unvorhersehbare Werte sicherzustellen. Vermeiden Sie sequenzielle IDs, die von einem Angreifer erraten werden könnten.
Verwenden Sie HTTPS: Verwenden Sie immer HTTPS, um Daten während der Übertragung zu verschlüsseln. Dadurch werden Sitzungsbezeichner und alle vertraulichen Daten, die zwischen Client und Server ausgetauscht werden, vor dem Abfangen geschützt.
Sitzungsdauer einschränken: Implementieren von Timeouts für Sitzungen. Lassen Sie beispielsweise maximal 15 Minuten Inaktivität zu, bevor die Sitzung automatisch beendet wird. Dadurch können Risiken aufgrund eines verloren gegangenen oder unbeaufsichtigten Geräts verringert werden.
Regelmäßige Audits und Überwachung: Überprüfen Sie regelmäßig sitzungsverwaltungspraktiken und -protokolle. Implementieren Sie Überwachungstools, um verdächtige Aktivitäten zu benachrichtigen, z. B. wiederholte fehlgeschlagene Anmeldeversuche oder ungewöhnliche Sitzungslängen.