Contratto runtime container

Questa pagina elenca i requisiti e i comportamenti chiave dei container in Cloud Run. La pagina evidenzia anche le differenze tra i servizi Cloud Run, i job Cloud Run e i pool di worker Cloud Run, ove opportuno.

Lingue e immagini supportate

L'immagine container può eseguire codice scritto nel linguaggio di programmazione che preferisci e utilizzare qualsiasi immagine di base, a condizione che rispetti i vincoli elencati in questa pagina.

Gli eseguibili nell'immagine container devono essere compilati per Linux a 64 bit. Cloud Run supporta in modo specifico il formato ABI Linux x86_64.

Cloud Run accetta immagini container nei formati immagine Docker Image Manifest V2, Schema 1, Schema 2 e OCI. Cloud Run accetta anche immagini container compresse con Zstd.

Se esegui il deployment di un'immagine multi-architettura, l'elenco dei manifest deve includere linux/amd64.

Per le funzioni di cui è stato eseguito il deployment con Cloud Run, puoi utilizzare una delle immagini di base del runtime di Cloud Run pubblicate dai buildpack di Google Cloud per ricevere aggiornamenti automatici di sicurezza e manutenzione. Consulta il programma di supporto del runtime per i runtime supportati.

In attesa di richieste sulla porta corretta (servizi)

Un servizio Cloud Run avvia istanze Cloud Run per gestire le richieste in entrata. Un'istanza Cloud Run ha sempre un singolo container di ingresso in ascolto di richieste e, facoltativamente, uno o più container collaterali. I seguenti dettagli di configurazione delle porte si applicano solo al container di ingresso, non ai sidecar.

Il container di ingresso all'interno di un'istanza deve essere in ascolto delle richieste su 0.0.0.0 sulla porta a cui vengono inviate le richieste. In particolare, il container di ingresso non deve rimanere in ascolto su 127.0.0.1. Per impostazione predefinita, le richieste vengono inviate a 8080, ma puoi configurare Cloud Run per inviare le richieste alla porta che preferisci. Cloud Run inserisce la variabile di ambiente PORT nel container di ingresso.

Il container in esecuzione in un'esecuzione del job deve uscire al termine

Per i job Cloud Run, il container deve uscire con il codice di uscita 0 quando il job è stato completato correttamente e con un codice di uscita diverso da zero quando il job non è riuscito.

Poiché i job non devono gestire le richieste, il container non deve ascoltare su una porta o avviare un server web.

Crittografia del livello di trasporto (TLS)

Il contenitore non deve implementare direttamente alcun protocollo TLS (Transport Layer Security). TLS viene terminato da Cloud Run per HTTPS e gRPC, quindi le richieste vengono inviate tramite proxy come HTTP/1 o gRPC al container senza TLS.

Se configuri un servizio Cloud Run per utilizzare HTTP/2 end-to-end, il container deve gestire le richieste in formato HTTP/2 cleartext (h2c), perché TLS viene comunque terminato automaticamente da Cloud Run.

Risposte (servizi)

Per i servizi Cloud Run, il container deve inviare una risposta entro il tempo specificato nell'impostazione del timeout della richiesta dopo aver ricevuto una richiesta, incluso il tempo di avvio del container. In caso contrario, la richiesta viene terminata e viene restituito un errore 504.

Memorizzazione nella cache delle risposte e cookie

Se la risposta del servizio Cloud Run contiene un'intestazione Set-Cookie, Cloud Run imposta l'intestazione Cache-Control su private in modo che la risposta non venga memorizzata nella cache. In questo modo, altri utenti non possono recuperare il cookie.

Variabili di ambiente

Per i servizi e i job Cloud Run sono disponibili diversi set di variabili di ambiente.

Variabili di ambiente per i servizi

Le seguenti variabili di ambiente vengono aggiunte automaticamente a tutti i container in esecuzione, ad eccezione di PORT. La variabile PORT viene aggiunta solo al container in entrata:

Nome Descrizione Esempio
PORT La porta su cui deve rimanere in ascolto il server HTTP. 8080
K_SERVICE Il nome del servizio Cloud Run in esecuzione. hello-world
K_REVISION Il nome della revisione Cloud Run in esecuzione. hello-world.1
K_CONFIGURATION Il nome della configurazione Cloud Run che ha creato la revisione. hello-world

Variabili di ambiente per i job

Per i job Cloud Run, vengono impostate le seguenti variabili di ambiente:

Nome Descrizione Esempio
CLOUD_RUN_JOB Il nome del job Cloud Run in esecuzione. hello-world
CLOUD_RUN_EXECUTION Il nome dell'esecuzione Cloud Run in esecuzione. hello-world-abc
CLOUD_RUN_TASK_INDEX L'indice di questa attività. Inizia da 0 per la prima attività e aumenta di 1 per ogni attività successiva, fino al numero massimo di attività meno 1. Se imposti --parallelism su un valore maggiore di 1, le attività potrebbero non seguire l'ordine dell'indice. Ad esempio, l'attività 2 potrebbe iniziare prima dell'attività 1. 0
CLOUD_RUN_TASK_ATTEMPT Il numero di tentativi di ripetizione di questa attività. Inizia da 0 per il primo tentativo e aumenta di 1 per ogni tentativo successivo, fino al valore massimo di tentativi. 0
CLOUD_RUN_TASK_COUNT Il numero di attività definite nel parametro --tasks. 1

Variabili di ambiente per i worker pool

Cloud Run imposta le seguenti variabili di ambiente per i worker pool:

Nome Descrizione Esempio
CLOUD_RUN_WORKER_POOL Il nome del pool di worker Cloud Run in esecuzione. hello-world
CLOUD_RUN_WORKER_POOL_REVISION Il nome della revisione del pool di worker Cloud Run in esecuzione. hello-world.1

Requisiti per le intestazioni di richiesta e risposta (servizi)

Per i servizi, Cloud Run limita i nomi degli header ai caratteri ASCII stampabili non di spaziatura e non può contenere i due punti. Cloud Run limita i valori delle intestazioni a caratteri ASCII visibili, oltre a spazi e tabulazioni orizzontali, in conformità con IETF RFC 7230.

Accesso al file system

Il file system di ogni container è scrivibile e soggetto al seguente comportamento:

  • Si tratta di un file system in memoria, quindi la scrittura utilizza la memoria dell'istanza.
  • I dati scritti nel file system non vengono conservati quando l'istanza viene arrestata.

Non puoi specificare un limite di dimensioni per questo file system, quindi puoi potenzialmente utilizzare tutta la memoria allocata alla tua istanza scrivendo nel file system in memoria, il che causerà l'arresto anomalo dell'istanza. Puoi evitare questo problema se utilizzi un volume in memoria dedicato con un limite di dimensioni.

Ciclo di vita dell'istanza

Le caratteristiche del ciclo di vita differiscono per i servizi e i job Cloud Run, pertanto sono descritte separatamente nelle seguenti sottosezioni.

Per i servizi

Le seguenti caratteristiche si applicano solo ai servizi.

Scalabilità del servizio

Per impostazione predefinita, un servizio Cloud Run viene scalato automaticamente al numero di istanze necessarie per gestire tutte le richieste, gli eventi o l'utilizzo della CPU in entrata. Se hai bisogno di un maggiore controllo sul comportamento di scalabilità, puoi utilizzare facoltativamente lo scaling manuale.

Ogni istanza esegue un numero fisso di container: un container di ingresso e, facoltativamente, uno o più container sidecar.

Quando una revisione non riceve traffico, viene scalata fino al numero minimo di istanze configurato (zero per impostazione predefinita).

Avvio

Per i servizi Cloud Run, le istanze devono rimanere in ascolto delle richieste entro 4 minuti dall'avvio e tutti i container all'interno dell'istanza devono essere integri. Durante questo tempo di avvio, alle istanze viene allocata la CPU. Puoi attivare il boosting della CPU all'avvio per aumentare temporaneamente l'allocazione della CPU durante l'avvio dell'istanza al fine di ridurre la latenza di avvio.

Le richieste verranno inviate al container di ingresso non appena sarà in ascolto sulla porta configurata.

Una richiesta in attesa di un'istanza rimarrà in sospeso in una coda come segue:

Le richieste rimarranno in attesa fino a 3, 5 volte il tempo di avvio medio delle istanze di container di questo servizio o 10 secondi, a seconda di quale sia il valore maggiore.

Puoi configurare un probe di avvio per determinare se il container è stato avviato ed è pronto a gestire le richieste.

Per un servizio Cloud Run costituito da istanze multi-container, puoi specificare la sequenza in cui i container vengono avviati all'interno dell'istanza configurando l'ordine di avvio dei container.

Elaborazione di una richiesta

Per i servizi Cloud Run, la CPU viene sempre allocata a tutti i container, inclusi i sidecar all'interno di un'istanza, finché la revisione Cloud Run elabora almeno una richiesta.

Inattivo

Per i servizi Cloud Run, un'istanza inattiva è un'istanza che non elabora alcuna richiesta.

La CPU allocata a tutti i container in un'istanza inattiva dipende dalle impostazioni di fatturazione configurate.

A meno che un'istanza non debba rimanere inattiva a causa dell'impostazione di configurazione del numero minimo di istanze, non rimarrà inattiva per più di 15 minuti.

Arresto

Per i servizi Cloud Run, un'istanza inattiva può essere arrestata in qualsiasi momento, incluse le istanze mantenute attive a causa di un numero minimo di istanze configurato. Se un'istanza che sta elaborando richieste deve essere arrestata, le richieste già in elaborazione hanno il tempo di essere completate e le nuove richieste in arrivo vengono indirizzate ad altre istanze. In casi eccezionali, Cloud Run potrebbe avviare un arresto e inviare un segnale SIGTERM a un container che sta ancora elaborando richieste.

Prima di arrestare un'istanza, Cloud Run invia un segnale SIGTERM a tutti i container di un'istanza, indicando l'inizio di un periodo di 10 secondi prima dell'arresto effettivo, dopodiché Cloud Run invia un segnale SIGKILL. Durante questo periodo, alla CPU viene allocata l'istanza e viene fatturata. Nei servizi che utilizzano l'ambiente di esecuzione di prima generazione, se l'istanza non intercetta il segnale SIGTERM, viene arrestata immediatamente. Nei servizi che utilizzano l'ambiente di esecuzione di seconda generazione, ti consigliamo di installare un gestore SIGTERM sul tuo container per ricevere un avviso quando Cloud Run sta per arrestare un'istanza.

Forced termination

Se uno o più container Cloud Run superano il limite di memoria totale del container, l'istanza viene terminata. Tutte le richieste ancora in elaborazione nell'istanza terminano con un errore HTTP 500.

Per le offerte di lavoro

Per i job Cloud Run, le istanze container vengono eseguite finché non vengono chiuse o finché non viene raggiunto il timeout dell'attività o finché il container non si arresta in modo anomalo.

Codici di uscita

Puoi utilizzare i codici di uscita del job per verificare se il job è stato completato correttamente o se si sono verificati errori. I codici di uscita sono valori numerici che corrispondono al completamento riuscito o a tipi specifici di errori.

La tabella seguente specifica i codici di uscita comuni e le relative definizioni:

Codice di uscita Indicatore Descrizione
0 Attività completata correttamente.
4 SIGILL L'attività ha tentato di accedere alla memoria a un indirizzo errato.
7 SIGBUS L'attività ha tentato di accedere alla memoria al di fuori dei limiti allocati.
9 SIGKILL L'attività viene terminata forzatamente, tramite azione dell'utente o intervento manuale.
11 SIGSEGV L'attività ha tentato di accedere a una memoria non autorizzata.
15 SIGTERM Quando un'attività supera il timeout configurato o viene annullata, riceve un segnale SIGTERM. Il server delle applicazioni invia il segnale SIGTERM per l'arresto dell'istanza di container. Se l'istanza non si arresta autonomamente entro pochi secondi dalla ricezione di SIGTERM, Cloud Run invia un segnale SIGKILL per una terminazione forzata. Se l'istanza viene chiusa correttamente con SIGTERM, potrebbe segnalare un codice di errore diverso; in caso contrario, restituisce SIGTERM.

Forced termination

Un'istanza container Cloud Run che supera il limite di memoria consentito viene terminata. Tutte le richieste ancora in fase di elaborazione sull'istanza di container terminano con un errore HTTP 500.

Se un'attività supera il timeout dell'attività, Cloud Run invia un segnale "SIGTERM" che indica l'inizio di un periodo di 10 secondi prima dell'arresto effettivo, dopodiché Cloud Run invia un segnale SIGKILL, arrestando l'istanza di container.

Durante questo periodo, alle istanze container viene allocata la CPU per l'intero ciclo di vita e vengono fatturate.

Consulta l'esempio di codice SIGTERM per scoprire come intercettare il segnale SIGTERM.

Per i pool di worker

Le seguenti caratteristiche si applicano solo ai pool di worker.

Scalabilità

I pool di worker non vengono scalati automaticamente. Scala manualmente il numero di istanze richieste dal pool di worker Cloud Run per gestire il carico di lavoro. Per impostazione predefinita, Cloud Run imposta il numero di istanze su 1. Puoi modificare questo numero aumentandolo o diminuendolo oppure puoi disattivare il ridimensionamento impostando il numero su 0. Per essere avviato e rimanere attivo, il tuo workload deve avere almeno un'istanza. Se imposti le istanze minime su 0, l'istanza worker non si avvierà, anche se il deployment è riuscito.

Avvio

Le istanze dei pool di worker Cloud Run avviano il container con l'entrypoint specificato nell'immagine container o nella configurazione del pool di worker. Tutti i container nell'istanza devono essere integri.

Per impostazione predefinita, le istanze di container Cloud Run utilizzano una CPU. Puoi aumentare o diminuire questo valore in base ai tuoi requisiti.

Puoi configurare un probe di avvio per determinare se il container è stato avviato. Il probe di avvio consente a Cloud Run di ispezionare l'integrità di un container dipendente, assicurandosi che venga superato correttamente prima di avviare il container successivo. Se non utilizzi i controlli di integrità, Cloud Run avvia i container nell'ordine specificato, anche se i container da cui dipendono non vengono avviati.

Allocazione delle risorse

I worker pool non sono inattivi. Indipendentemente dal suo stato, Cloud Run alloca sempre la CPU a tutti i container, inclusi i sidecar all'interno di un'istanza del pool di worker. Finché è in esecuzione, un'istanza è considerata attiva e viene fatturata di conseguenza.

Arresto

Cloud Run non fare lo scale down le istanze del pool di worker in base alle istanze inattive. Se un'istanza di elaborazione del carico di lavoro deve essere arrestata, Cloud Run dà il tempo alle attività in corso di completarsi e instrada i nuovi carichi di lavoro ad altre istanze. Cloud Run potrebbe anche avviare un arresto e inviare un segnale SIGTERM a un container che sta ancora elaborando un carico di lavoro.

Prima di arrestare un'istanza, Cloud Run invia un segnale SIGTERM a tutti i container di un'istanza. Questo segnale indica l'inizio di un periodo di 10 secondi prima dell'arresto effettivo, dopodiché Cloud Run invia un segnale SIGKILL. Durante questo periodo di arresto, all'istanza viene allocata la CPU e viene fatturata. Ti consigliamo di installare un gestore SIGTERM sul tuo container per ricevere un avviso quando Cloud Run sta per arrestare un'istanza.

Forced termination

Se uno o più container Cloud Run superano il limite di memoria totale del container, Cloud Run termina l'istanza. Tutte le richieste ancora in elaborazione sull'istanza terminano con un errore HTTP 500.

Risorse dell'istanza di container

Le sezioni seguenti descrivono le risorse per l'istanza container:

CPU

Per impostazione predefinita, a ogni container Cloud Run in un'istanza viene allocata la vCPU che è stata configurata (1 per impostazione predefinita). È possibile configurare i limiti della CPU su ogni container separatamente.

Una vCPU viene implementata come astrazione dell'hardware sottostante per fornire il tempo CPU equivalente approssimativo di un singolo hyperthread hardware su piattaforme CPU variabili. Tutte le piattaforme CPU utilizzate da Cloud Run supportano il set di istruzioni AVX2. Tieni presente che il contratto del container non contiene ulteriori dettagli sulla piattaforma CPU.

Il container potrebbe essere eseguito su più core contemporaneamente.

Per i servizi Cloud Run, l'allocazione della CPU dipende dalla fatturazione selezionata.

Se selezioni la fatturazione basata sulle istanze, la CPU viene allocata per tutta la durata dell'istanza. Se selezioni la fatturazione basata sulle richieste (impostazione predefinita), la CPU viene allocata quando le istanze elaborano le richieste. Per informazioni dettagliate, consulta le impostazioni di fatturazione.

Se hai configurato un numero di istanze minime, devi utilizzare la fatturazione basata sulle istanze in modo che la CPU venga allocata al di fuori delle richieste.

Puoi attivare il boosting della CPU all'avvio per aumentare temporaneamente l'allocazione della CPU durante l'avvio dell'istanza al fine di ridurre la latenza di avvio.

Memoria

Per impostazione predefinita, a ogni container Cloud Run viene allocata la memoria che è stata configurata, (512 MiB per impostazione predefinita). È possibile configurare i limiti di memoria su ogni container separatamente.

Gli utilizzi tipici della memoria includono:

  • Codice caricato in memoria per eseguire il servizio
  • Scrittura nel file system
  • Processi aggiuntivi in esecuzione nel container, ad esempio un server nginx
  • Sistemi di memorizzazione nella cache in memoria come OpCache di PHP
  • Utilizzo della memoria per richiesta
  • Volumi in memoria condivisi

GPU

Puoi configurare un container in un'istanza Cloud Run per accedere a una GPU. Se il servizio Cloud Run viene sottoposto a deployment con container sidecar, solo un container nel deployment può accedere alla GPU. Per requisiti e dettagli, vedi Configurare la GPU.

Librerie NVIDIA

Per impostazione predefinita, tutte le librerie dei driver NVIDIA L4 sono montate in /usr/local/nvidia/lib64. Cloud Run aggiunge automaticamente questo percorso alla variabile di ambiente LD_LIBRARY_PATH (ovvero ${LD_LIBRARY_PATH}:/usr/local/nvidia/lib64) del container con la GPU. In questo modo, il linker dinamico può trovare le librerie dei driver NVIDIA. Il linker cerca e risolve i percorsi nell'ordine in cui li elenchi nella variabile di ambiente LD_LIBRARY_PATH. I valori che specifichi in questa variabile hanno la precedenza sul percorso predefinito delle librerie dei driver Cloud Run /usr/local/nvidia/lib64.

Se vuoi utilizzare una versione di CUDA superiore alla 12.2, il modo più semplice è fare affidamento a un'immagine di base NVIDIA più recente con i pacchetti di compatibilità avanzata già installati. Un'altra opzione è installare manualmente i pacchetti di compatibilità futura NVIDIA e aggiungerli a LD_LIBRARY_PATH. Consulta la matrice di compatibilità di NVIDIA per determinare quali versioni di CUDA sono compatibili con la versione del driver NVIDIA fornita (535.216.03).

Contemporaneità (servizi)

Per i servizi Cloud Run, per impostazione predefinita ogni istanza Cloud Run è impostata su più contemporaneità, dove il container di ingresso può ricevere più di una richiesta contemporaneamente. Puoi modificare questa opzione impostando la concorrenza.

Sandbox del container

Se utilizzi l'ambiente di esecuzione di prima generazione, i container Cloud Run vengono sottoposti a sandbox utilizzando la sandbox del runtime del container gVisor. Come documentato nel riferimento alla compatibilità delle chiamate di sistema gVisor, alcune chiamate di sistema potrebbero non essere supportate da questa sandbox del container.

Se utilizzi l'ambiente di esecuzione di seconda generazione, hai la piena compatibilità con Linux. I job Cloud Run utilizzano sempre l'ambiente di esecuzione di seconda generazione. Nell'ambiente di esecuzione di seconda generazione, /sys/class/dmi/id/product_name è impostato su Google Compute Engine.

L'ambiente di esecuzione di seconda generazione esegue il codice del servizio in uno spazio dei nomi dei processi separato, quindi inizia come processo di inizializzazione del container con una semantica speciale dei processi. Nell'ambiente di esecuzione di prima generazione, il codice del servizio non viene eseguito come processo di inizializzazione del container.

Limiti dei descrittori di file

Gli ambienti Cloud Run di prima e seconda generazione impostano un limite al numero di descrittori di file che un processo può aprire a 25.000. Ciò si applica al contenitore e a qualsiasi processo figlio che crea (fork). Questo è un limite rigido. Se superi il limite, la tua istanza potrebbe esaurire i descrittori di file/socket.

Limiti nell'ambiente di seconda generazione

Ad eccezione dei limiti dei descrittori di file descritti in precedenza, i limiti nell'ambiente di seconda generazione sono limiti Linux standard.

Ad esempio, i limiti al numero di descrittori di file che possono essere aperti (come acquisito in: /proc/sys/fs/file-max) utilizzano il valore predefinito di circa il 10% della memoria. Per informazioni dettagliate, consulta file-max e file-nr nella documentazione del kernel.

Analogamente, max_map_count (come acquisito in /proc/sys/vm/max_map_count), che imposta il numero di aree di memoria che un processo può avere, utilizza il valore predefinito di 65535. Per informazioni dettagliate, consulta max-map-count nella documentazione del kernel.

Container privilegiati e binari setuid

Cloud Run non supporta i container privilegiati. Di conseguenza, Cloud Run non supporta i file binari che utilizzano i flag setuid per gli utenti non root, ad esempio gcsfuse o sudo, e potrebbe non riuscire a causa di autorizzazioni insufficienti.

Un'alternativa è eseguire questi file binari come utente root e poi utilizzare il comando su per passare a un altro utente in fase di runtime.

Ad esempio, nel Dockerfile rimuovi l'istruzione USER e nello script di punto di ingresso utilizza la seguente sequenza:

gcsfuse ...                 # Run gcsfuse as root
su myuser -c "/yourapp.sh"  # Switch to 'myuser' and run 'yourapp.sh'

Utente che esegue

Se il nome utente non esiste, Cloud Run esegue il container come utente root (uid=0).

Server di metadati dell'istanza

Le istanze Cloud Run espongono un server di metadati che puoi utilizzare per recuperare i dettagli sui tuoi container, come l'ID progetto, la regione, l'ID istanza o i service account. Puoi anche utilizzare il server di metadati per generare token per l'identità del servizio.

Per accedere ai dati del server di metadati, utilizza le richieste HTTP all'endpoint http://metadata.google.internal/ con l'intestazione Metadata-Flavor: Google: non sono necessarie librerie client. Per saperne di più, consulta la sezione Recupero dei metadati.

La seguente tabella elenca alcune delle informazioni del server di metadati disponibili:

Percorso Descrizione
/computeMetadata/v1/project/project-id ID progetto a cui appartiene il servizio o il job Cloud Run
/computeMetadata/v1/project/numeric-project-id Numero di progetto del progetto a cui appartiene il servizio o il job Cloud Run
/computeMetadata/v1/instance/region Regione di questo servizio o job Cloud Run, restituisce projects/PROJECT-NUMBER/regions/REGION
/computeMetadata/v1/instance/id Identificatore univoco dell'istanza (disponibile anche nei log).
/computeMetadata/v1/instance/service-accounts/default/email Email per l'identità del servizio di questo servizio o job Cloud Run.
/computeMetadata/v1/instance/service-accounts/default/token Genera un token di accesso OAuth2 per l'service account di questo servizio o job Cloud Run. L'agente di servizio Cloud Run viene utilizzato per recuperare un token. Questo endpoint restituirà una risposta JSON con un attributo access_token. Scopri di più su come estrarre e utilizzare questo token di accesso.

Tieni presente che Cloud Run non fornisce dettagli sulla zona in cui sono in esecuzione le istanze.Google Cloud Di conseguenza, l'attributo dei metadati /computeMetadata/v1/instance/zone restituisce sempre projects/PROJECT-NUMBER/zones/REGION-1.

Nomi file

I nomi dei file utilizzati nei contenitori devono essere compatibili con UTF-8, ovvero UTF-8 o qualcosa che possa essere convertito automaticamente in UTF-8 in modo sicuro. Se i nomi dei file utilizzano codifiche diverse, esegui la build Docker su una macchina con nomi di file compatibili con UTF-8 ed evita di copiare file in un container che contiene nomi UTF-8 incompatibili.

Il deployment del contenitore non riesce se i nomi dei file non sono compatibili con UTF-8. Tieni presente che non esistono restrizioni sulla codifica dei caratteri che utilizzi all'interno di un file.

Timeout delle richieste in uscita

Per i servizi e i job Cloud Run, si verifica un timeout dopo 10 minuti di inattività per le richieste dal container al VPC. Per le richieste dal container a internet, si verifica un timeout dopo 20 minuti di inattività.

Reimpostazioni della connessione in uscita

I flussi di connessione dal container sia alla VPC sia a internet possono essere interrotti e sostituiti occasionalmente quando l'infrastruttura sottostante viene riavviata o aggiornata. Se la tua applicazione riutilizza connessioni di lunga durata, ti consigliamo di configurarla in modo da ristabilire le connessioni per evitare il riutilizzo di una connessione non più attiva.