Delen via


Dynamische sessies in Azure Container Apps

Dynamische sessies in Azure Container Apps bieden snelle toegang tot beveiligde sandboxomgevingen die ideaal zijn voor het uitvoeren van code of toepassingen waarvoor een sterke isolatie van andere workloads is vereist.

Sessies worden uitgevoerd binnen de context van een sessiepool, die een koude start vermindert om ervoor te zorgen dat een sessie direct beschikbaar is.

Met sessies krijgt u het volgende:

  • Sterke isolatie: sessies worden van elkaar en van de hostomgeving geïsoleerd. Elke sessie wordt uitgevoerd in een eigen Hyper-V-sandbox en biedt beveiliging en isolatie op bedrijfsniveau. U kunt eventueel netwerkisolatie inschakelen om de beveiliging verder te verbeteren.

  • Eenvoudige toegang: sessies worden geopend via een REST API. Een unieke id markeert elke sessie. Als er geen sessie met een bepaalde id bestaat, wordt automatisch een nieuwe sessie toegewezen.

  • Volledig beheerd: Container Apps beheert de levenscyclus van een sessie volledig. Sessies worden automatisch opgeschoond wanneer ze niet meer in gebruik zijn.

  • Snel opstarten: nieuwe sessies worden in milliseconden toegewezen. Snelle start-ups worden bereikt door automatisch een pool met kant-en-klare, maar niet-toegewezen sessies te onderhouden.

  • Schaalbaar: sessies kunnen op grote schaal worden uitgevoerd. U kunt honderden of duizenden sessies gelijktijdig uitvoeren.

  • API-toegang: sessies worden via één HTTP-eindpunt beschikbaar gesteld aan uw toepassing.

Sessie

Een sessie is een sandbox-omgeving die niet-vertrouwde code of uw toepassing uitvoert.

Elke sessie is geïsoleerd van alle andere sessies en van de hostomgeving met een Hyper-V-sandbox . Hyper-V technologie vormt de basis voor sessieisolatie en zorgt ervoor dat verschillende sessies onafhankelijk werken met de benodigde beveiligingsgrenzen. Voor verbeterde netwerkbeveiliging kunt u sessienetwerkisolatie inschakelen voor uw sessie.

Er zijn twee verschillende soorten sessies.

Sessietypen

Azure Container Apps ondersteunt twee typen sessies:

Typologie Beschrijving Factureringsmodel
Code-interpretersessies Volledig beheerde code-interpreter waarmee u code kunt uitvoeren in een sandbox die vooraf is geïnstalleerd met populaire bibliotheken.

Ideaal voor het uitvoeren van niet-vertrouwde code, zoals code die wordt geleverd door gebruikers van uw toepassing of code die wordt gegenereerd door een groot taalmodel (LLM).

U kunt de sessie direct gebruiken zonder aanpassingen, of met een taalmodelframework.
Per sessie (verbruik)
Aangepaste containersessies Optie Bring Your Own Container waarbij u uw eigen containerinstallatiekopieën uitvoert in beveiligde, geïsoleerde sandboxes.

Deze methode is een goede optie als u een aangepaste code-interpreter wilt uitvoeren voor een taal die niet standaard wordt ondersteund, of workloads waarvoor een sterke isolatie is vereist.
Toegewezen abonnement voor Container Apps

Elke sessie, ongeacht het type, wordt uitgevoerd in de context van een sessiegroep.

Sessiegroepen

Azure Container Apps onderhoudt een pool met kant-en-klare, maar niet-toegewezen sessies om subseconde sessietoewijzingstijden te bieden. Wanneer uw toepassing een aanvraag indient voor een sessie die nog niet eerder is gebruikt, wijst de pool automatisch een nieuwe sessie voor u toe. Wanneer sessies worden toegewezen, wordt de pool automatisch aangevuld om een constant aantal gereede sessies te onderhouden.

Elke sessiegroep is beschikbaar voor uw app via een unieke locatie voor het beheer van pools.

Sessie-levenscyclus

De Container Apps-runtime beheert automatisch de levenscyclus voor elke sessie in een pool. Het leven van een sessie begint terwijl de sessie wordt gestart en wordt voortgezet terwijl de sessie in gebruik is. Nadat er geen aanvragen zijn voor de sessie nadat de afkoeltijd is verstreken, wordt de sessie vernietigd.

De volgende statussen definiëren deze levenscyclus:

  1. In behandeling: Wanneer een sessie wordt gestart, heeft deze de status In behandeling. De tijdsduur die een sessie in deze status doorbrengt, is afhankelijk van de containerafbeelding en instellingen die zijn opgegeven voor de sessiepool. Een sessie met deze status wordt niet toegevoegd aan de groep met gereede sessies.

  2. Niet toegewezen: zodra een sessie is gestart, wordt deze toegevoegd aan de pool en wordt deze beschikbaar voor toewijzing. Voor aangepaste containersessies kunt u opgeven hoeveel gereede sessies in de pool moeten worden onderhouden. Dit aantal moet worden verhoogd als sessies sneller worden toegewezen dan ze worden aangevuld.

  3. Toegewezen: Wanneer u een aanvraag verzendt naar een niet-uitgevoerde sessie, biedt de pool een nieuwe sessie en plaatst deze in een toegewezen status. Volgende aanvragen met dezelfde sessie-id worden gerouteerd naar dezelfde sessie, zodat efficiënt hergebruik mogelijk is zonder koude start. Elke toegewezen sessie is gekoppeld aan een sessie-id.

  4. Vernietigd: als een sessie geen aanvragen ontvangt voor een duur die is gedefinieerd door de cooldownPeriodInSeconds instelling, worden de sessie en de bijbehorende Hyper-V sandbox veilig verwijderd. Deze automatische opschoningsinstallatie verbetert het resourcebeheer en de beveiliging.

De Container Apps-runtime beheert automatisch de levenscyclus voor elke sessie in een sessiegroep.

Regionale beschikbaarheid

Dynamische sessies zijn beschikbaar in de volgende regio's:

Regio Code-interpreter Aangepaste container
Australië - oost
Brazilië Zuid -
Canada Oost -
Azië - oost
VS - oost
Oostelijke Verenigde Staten 2
Centraal Frankrijk -
Duitsland - west-centraal
Italië - noord
Oost-Japan -
Centraal-Korea -
VS - noord-centraal
Europa - noord
Noorwegen - oost
Polen - centraal
Zuid-Afrika - noord -
Zuid-India -
Zweden - centraal
Zwitserland - noord
VAE Noord -
Verenigd Koninkrijk Zuid
VS - west-centraal
West-Europa
Westelijke VS
VS - west 2
Westelijke VS 3

Facturatie

Aangepaste containersessies worden gefactureerd op basis van de resources die door de sessiegroep worden gebruikt. Zie Azure Container Apps-facturering voor meer informatie.

Beveiliging

Gebruik de volgende methoden om de beveiliging van uw dynamische sessies te verbeteren.

  • Beveiligde id's: gebruik altijd beveiligde sessie-id's . Genereer sessie-id's met behulp van cryptografische methoden om unieke en onvoorspelbare waarden te garanderen. Vermijd het gebruik van sequentiële id's die kunnen worden geraden door een aanvaller.

  • HTTPS gebruiken: gebruik altijd HTTPS om gegevens tijdens overdracht te versleutelen. Hierdoor worden sessie-id's en gevoelige gegevens die worden uitgewisseld tussen de client en de server beschermd tegen onderschepping.

  • De levensduur van de sessie beperken: time-outs implementeren voor sessies. Sta bijvoorbeeld maximaal 15 minuten inactiviteit toe voordat de sessie automatisch wordt beëindigd. Dit helpt bij het beperken van risico's als gevolg van een verloren of onbeheerd apparaat.

  • Regelmatige controles en bewaking: controleer regelmatig de procedures en logboeken voor sessiebeheer. Implementeer bewakingshulpprogramma's om verdachte activiteiten te waarschuwen, zoals herhaalde mislukte aanmeldingspogingen of abnormale sessielengten.