Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Le sessioni dinamiche delle app Contenitore di Azure offrono accesso rapido agli ambienti sandbox sicuri, ideali per l'esecuzione di codice o applicazioni che richiedono un isolamento sicuro da altri carichi di lavoro.
Le sessioni operano all'interno del contesto di un pool di sessioni che riduce l'avvio a freddo per garantire la disponibilità immediata di una sessione.
Con le sessioni, ottieni:
Isolamento sicuro: le sessioni sono isolate l'una dall'altra e dall'ambiente host. Ogni sessione viene eseguita nella propria sandbox Hyper-V, fornendo così sicurezza e isolamento di grado Enterprise. Facoltativamente, è possibile abilitare l'isolamento rete per migliorare ulteriormente la sicurezza.
Accesso semplice: le sessioni sono accessibili tramite un'API REST. Un identificatore univoco contrassegna ogni sessione. Se non esiste una sessione con un identificatore specificato, ne viene allocata automaticamente una nuova.
Gestione completa: Le App container gestiscono completamente il ciclo di vita di una sessione. Le sessioni vengono pulite automaticamente quando non sono più in uso.
Avvio rapido: le nuove sessioni vengono allocate in millisecondi. Gli avvi rapidi si ottengono mantenendo automaticamente un pool di sessioni pronte ma non allocate.
Scalabile: le sessioni possono essere eseguite su larga scala. È possibile eseguire centinaia o migliaia di sessioni contemporaneamente.
Accesso api: le sessioni vengono esposte all'applicazione tramite un singolo endpoint HTTP.
Sessione
Una sessione è un ambiente isolato in modalità sandbox che esegue codice non attendibile o la tua applicazione.
Ogni sessione è isolata da tutte le altre sessioni e dall'ambiente host con una sandbox Hyper-V . La tecnologia Hyper-V è alla base dell'isolamento della sessione, assicurando che diverse sessioni funzionino in modo indipendente con i confini di sicurezza necessari. Per migliorare la sicurezza di rete, è possibile abilitare l'isolamento della rete sessione nella sessione.
Esistono due tipi diversi di sessioni.
Tipi di sessione
App contenitore di Azure supporta due tipi di sessioni:
| Tipo | Descrizione | Modello di fatturazione |
|---|---|---|
| Sessioni dell'interprete di codice | Interprete di codice completamente gestito che consente di eseguire il codice in una sandbox preinstallata con le librerie più diffuse. Ideale per l'esecuzione di codice non attendibile, ad esempio il codice fornito dagli utenti dell'applicazione o il codice generato da un modello di linguaggio di grandi dimensioni (LLM). È possibile usare la sessione predefinita o con un framework del modello linguistico. |
Per sessione (consumo) |
| Sessioni di contenitori personalizzate | Opzione Bring Your Own Container in cui si eseguono immagini del contenitore personalizzate in sandbox sicure e isolate. Questo approccio è un'opzione valida se si vuole eseguire un interprete di codice personalizzato per un linguaggio non supportato per impostazione predefinita o carichi di lavoro che richiedono un isolamento sicuro. |
Piano dedicato per App contenitore |
Ogni sessione, indipendentemente dal tipo, viene eseguita nel contesto di un pool di sessioni.
Pool di sessioni
Per fornire tempi di allocazione delle sessioni di pochi millisecondi, Azure Container Apps gestisce un pool di sessioni pronte ma non allocate. Quando l'applicazione effettua una richiesta per una sessione che non è stata usata in precedenza, il pool assegna automaticamente una nuova sessione. Quando le sessioni vengono allocate, il pool viene rifornito automaticamente per mantenere un numero costante di sessioni pronte.
Ogni pool di sessioni è disponibile per l'app tramite una posizione univoca dell'endpoint di gestione del pool.
Ciclo di vita della sessione
Il runtime di App per container gestisce automaticamente il ciclo di vita di ogni sessione all'interno di un pool. La durata di una sessione inizia all'avvio della sessione e continua mentre la sessione è in uso. Quando non ci sono più richieste alla sessione dopo il tempo di raffreddamento, la sessione viene distrutta.
Gli stati seguenti definiscono questo ciclo di vita:
In sospeso: quando si avvia una sessione, si trova nello stato in sospeso. La quantità di tempo trascorso da una sessione in questo stato dipende dall'immagine del contenitore e dalle impostazioni specificate per il pool di sessioni. Una sessione in questo stato non viene aggiunta al pool di sessioni pronte.
Non allocato: una volta completata l'avvio di una sessione, viene aggiunto al pool e diventa disponibile per l'allocazione. Per le sessioni di contenitori personalizzate, è possibile specificare il numero di sessioni pronte da gestire nel pool. Questo numero deve essere aumentato se le sessioni vengono allocate più velocemente di quanto vengano rifornite.
Allocato: quando si invia una richiesta a una sessione non in esecuzione, il pool fornisce una nuova sessione e lo inserisce in uno stato allocato. Le richieste successive con lo stesso identificatore di sessione vengono instradate alla stessa sessione, consentendo un riutilizzo efficiente senza l'avvio a freddo. Ogni sessione allocata è associata a un identificatore di sessione.
Eliminato definitivamente: se una sessione non riceve richieste per una durata definita dall'impostazione
cooldownPeriodInSeconds, la sessione e la relativa sandbox Hyper-V vengono eliminate in modo sicuro. Questa configurazione di pulizia automatica migliora la gestione delle risorse e la sicurezza.
Il runtime di App contenitore gestisce automaticamente il ciclo di vita per ogni sessione in un pool di sessioni.
Aree di disponibilità
Le sessioni dinamiche sono disponibili nelle aree seguenti:
| Paese | Interprete del codice | Contenitore personalizzato |
|---|---|---|
| Australia orientale | ✔ | ✔ |
| Brasile meridionale | - | ✔ |
| Canada orientale | - | ✔ |
| Asia orientale | ✔ | ✔ |
| Stati Uniti orientali | ✔ | ✔ |
| Stati Uniti orientali 2 | ✔ | ✔ |
| Francia centrale | - | ✔ |
| Germania centro-occidentale | ✔ | ✔ |
| Italia settentrionale | ✔ | ✔ |
| Giappone orientale | ✔ | - |
| Corea centrale | - | ✔ |
| Stati Uniti centro-settentrionali | ✔ | ✔ |
| Europa settentrionale | ✔ | ✔ |
| Norvegia orientale | ✔ | ✔ |
| Polonia Centrale | ✔ | ✔ |
| Sudafrica settentrionale | - | ✔ |
| India meridionale | - | ✔ |
| Svezia centrale | ✔ | ✔ |
| Svizzera settentrionale | ✔ | ✔ |
| Emirati Arabi Uniti settentrionali | - | ✔ |
| Regno Unito meridionale | ✔ | ✔ |
| Stati Uniti centro-occidentali | ✔ | ✔ |
| Europa occidentale | ✔ | ✔ |
| Stati Uniti occidentali | ✔ | ✔ |
| West US 2 (Regione Ovest degli Stati Uniti 2) | ✔ | ✔ |
| Stati Uniti occidentali 3 | ✔ | ✔ |
Fatturazione
Le sessioni di contenitori personalizzate vengono fatturate in base alle risorse utilizzate dal pool di sessioni. Per altre informazioni, vedere Fatturazione delle app contenitore di Azure.
Sicurezza
Usare i metodi seguenti per rafforzare la sicurezza delle sessioni dinamiche.
Identificatori sicuri: usare sempre identificatori di sessione sicuri. Generare identificatori di sessione usando metodi di crittografia per garantire valori univoci e imprevedibili. Evitare di usare ID sequenziali che potrebbero essere indovinati da un utente malintenzionato.
Usare HTTPS: usare sempre HTTPS per crittografare i dati in transito. In questo modo si proteggono gli identificatori di sessione e i dati sensibili scambiati tra il client e il server dall'essere intercettati.
Limitare la durata della sessione: implementare timeout per le sessioni. Ad esempio, consentire un massimo di 15 minuti di inattività prima che la sessione venga terminata automaticamente. Ciò consente di attenuare i rischi dovuti a un dispositivo perso o incustodito.
Controlli e monitoraggio regolari: esaminare periodicamente le procedure e i log di gestione delle sessioni. Implementare gli strumenti di monitoraggio per avvisare le attività sospette, ad esempio tentativi di accesso ripetuti non riusciti o lunghezze di sessione anomale.