Contratto runtime container

In questa pagina sono elencati i requisiti e i comportamenti chiave dei container in Cloud Run. Ci sono alcune differenze tra Cloud Run e i job Cloud Run: vengono chiamati appropriato.

Lingue e immagini supportate

L'immagine container può eseguire codice scritto nel linguaggio di programmazione del tuo e utilizzare qualsiasi immagine di base, purché rispetti i vincoli elencati in questa pagina.

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

Cloud Run accetta immagini container nel file manifest delle immagini Docker V2, Schema 1, Schema 2, e OCI.

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

In ascolto delle richieste sulla porta corretta (servizi)

Un servizio Cloud Run avvia le istanze di Cloud Run per gestire le richieste in entrata. Un'istanza Cloud Run ha sempre un singolo container in entrata che rimane in ascolto e, facoltativamente, uno o più container collaterali. La porta che segue i dettagli della configurazione si applicano solo al container in entrata, non ai file collaterali.

Il container in entrata di un'istanza deve rimanere in ascolto delle richieste 0.0.0.0 sulla porta a cui vengono inviate le richieste. Per impostazione predefinita, le richieste vengono inviate a 8080, ma puoi configurare Cloud Run per inviare richieste alla porta che preferisci. Cloud Run inserisce il parametro PORT nel container in entrata.

Il container in esecuzione nell'esecuzione di un job deve chiudersi al completamento

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

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

Crittografia TLS

Il container non deve implementare alcuna sicurezza del livello di trasporto direttamente. TLS è terminati 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 Se usi HTTP/2 end-to-end, il container deve gestire le richieste con testo in chiaro HTTP/2 (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 impostazione di timeout della richiesta dopo riceve una richiesta, tra cui 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 valore Set-Cookie intestazione, Cloud Run imposta l'intestazione Cache-Control su private in modo che che la risposta non venga memorizzata nella cache. Questo impedisce ad altri utenti di recuperare cookie.

Variabili di ambiente

Sono disponibili diversi set di variabili di ambiente per Cloud Run servizi e offerte di lavoro.

Variabili di ambiente per i servizi

Le seguenti variabili di ambiente vengono aggiunte automaticamente a tutti di container tranne PORT. La variabile PORT viene aggiunta solo al container in entrata:

Nome	Descrizione	Esempio
PORT	La porta su cui il server HTTP deve rimanere in ascolto.	8080
K_SERVICE	Il nome del servizio Cloud Run in esecuzione.	hello-world
K_REVISION	Il nome della revisione di 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, sono 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 di Cloud Run in esecuzione.	hello-world-abc
CLOUD_RUN_TASK_INDEX	L'indice di questa attività. Inizia da 0 per la prima attività e incrementa 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, è possibile che l'attività 2 venga avviata prima dell'attività 1.	0
CLOUD_RUN_TASK_ATTEMPT	Il numero di nuovi tentativi per questa attività. Inizia da 0 per il primo tentativo e incrementa di 1 per ogni tentativo successivo, fino al valore massimo dei nuovi tentativi.	0
CLOUD_RUN_TASK_COUNT	Il numero di attività definito nel parametro --tasks.	1

Requisiti delle intestazioni di richiesta e risposta (servizi)

Per i servizi Cloud Run, i nomi delle intestazioni sono limitati a un carattere ASCII non vuoto stampabile e non possono contengono due punti. I valori dell'intestazione sono limitati a caratteri ASCII visibili più e tabulazione orizzontale secondo IETF RFC 7230

Accesso al file system

Il file system in ciascuno dei tuoi container è scrivibile ed è soggetto ai seguenti comportamento:

• Si tratta di un file system in memoria, quindi per scriverci utilizza la classe di un'istanza.
• I dati scritti nel file system non vengono mantenuti quando l'istanza viene è stata interrotta.

Tieni presente che non è possibile specificare un limite di dimensione per questo file system, utilizzare potenzialmente tutta la memoria allocata all'istanza scrivendo al file system in memoria, provocando l'arresto anomalo dell'istanza. Puoi evitarlo problema se utilizzi un volume in memoria dedicato con un limite di dimensione.

Ciclo di vita dell'istanza

Le caratteristiche del ciclo di vita sono diverse per i job e i servizi Cloud Run, quindi descritti separatamente nelle seguenti sottosezioni.

Per i servizi

Le seguenti indicazioni sono valide solo per i servizi.

Scalabilità del servizio

Un servizio Cloud Run viene scalato automaticamente al numero di istanze necessarie per gestire tutte le richieste, gli eventi di utilizzo della CPU.

Ogni istanza esegue un numero fisso di container: un container in entrata e, facoltativamente, uno o più container collaterali.

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

Avvio

Per i servizi Cloud Run, le istanze devono rimanere in ascolto delle richieste all'interno 4 minuti dopo l'avvio e in tutti i container al suo interno l'istanza deve essere integro. Durante questo tempo di avvio, alle istanze viene allocata la CPU. Puoi abilita il booster della CPU all'avvio per aumentare temporaneamente l'allocazione della CPU durante l'avvio dell'istanza in modo da per ridurre la latenza di avvio.

Le richieste verranno inviate al container in entrata non appena è in ascolto la porta configurata.

Una richiesta in attesa di un'istanza rimane in attesa in una coda che segue:

• Se vengono avviate nuove istanze, ad esempio durante uno scale out, le richieste almeno il tempo di avvio medio delle istanze di container di questo servizio. Sono inclusi i casi in cui la richiesta avvia uno scale out, ad esempio durante la scalabilità partendo da zero.
• Se il tempo di avvio è inferiore a 10 secondi, le richieste scadranno per un massimo di 10 secondi.
• Se non sono presenti istanze in fase di avvio e la richiesta non avviano uno scale out, le richieste pendono per un massimo di per 10 secondi.

Puoi configurare un probe di avvio 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 del container.

Elaborazione di una richiesta

Per i servizi Cloud Run, la CPU viene sempre allocata a tutti i container, inclusi i file collaterali all'interno di un'istanza, purché la revisione di Cloud Run elabori almeno una richiesta

Inattivo

Per i servizi Cloud Run, un'istanza inattiva è una non per l'elaborazione delle richieste.

La CPU allocata a tutti i container in un'istanza inattiva dipende dal tipo di CPU configurato Allocazione della CPU.

A meno che un'istanza non debba essere mantenuta inattiva a causa il numero minimo di istanze non verrà mantenuto inattivo per più di 15 minuti.

Arresto

Per i servizi Cloud Run, un'istanza inattiva può essere arrestata in qualsiasi momento, ad esempio mantenute in uso tramite un numero minimo di istanze. Se un'istanza che sta elaborando le richieste deve essere arrestata, le nuove richieste in entrata vengono instradate ad altre istanze e quelle attualmente in corso elaborati vengono concessi il tempo necessario per essere completati. In casi eccezionali, Cloud Run potrebbe avviare un arresto e inviare Indicatore SIGTERM a un container che sta ancora elaborando le richieste.

Prima di arrestare un'istanza, Cloud Run invia un segnale SIGTERM a tutti i container in un'istanza, che indica l'inizio di un periodo di 10 secondi prima dell'arresto effettivo, dopodiché Cloud Run invia un segnale SIGKILL. Durante questo periodo, all'istanza viene allocata la CPU e viene fatturato il relativo importo. Nei servizi che utilizzano l'ambiente di esecuzione di prima generazione, se l'istanza non intercetta l'indicatore SIGTERM, viene arrestata immediatamente. Fai riferimento agli esempi di codice per scoprire come intrappolare il segnale SIGTERM.

Chiusura forzata

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

Per offerte di lavoro

Per i job Cloud Run, le istanze di container vengono eseguite fino a quando viene chiusa l'istanza o fino al timeout dell'attività o fino a quando il container si arresta in modo anomalo.

Chiusura forzata

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

Se un'attività supera il timeout, Cloud Run invia un "SIGTERM" che indica l'inizio di un Periodo di 10 secondi prima dell'effettivo arresto A questo punto Cloud Run invia un'email SIGKILL, che arresta l'istanza di container.

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

Fai riferimento all'esempio di codice SIGTERM. per scoprire come intrappolare il segnale SIGTERM.

Risorse istanza container

CPU

A ogni container Cloud Run in un'istanza viene allocata per impostazione predefinita la vCPU che è stato configurato (1 per impostazione predefinita). È possibile configurare i limiti di CPU separatamente su ogni container.

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

Il container può essere eseguito su più core contemporaneamente.

Per i servizi Cloud Run, puoi specificare la CPU da allocare sempre durante la vita dell'istanza o possono essere allocati solo durante l'avvio dell'istanza e l'elaborazione delle richieste. Per maggiori dettagli, consulta Allocazione della CPU.

Se hai configurato un numero di istanze minime, anche queste saranno soggette alla configurazione dell'allocazione della CPU.

Puoi abilitare il booster della CPU all'avvio per aumentare temporaneamente l'allocazione della CPU durante l'avvio dell'istanza in modo da per ridurre la latenza di avvio.

Memoria

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

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 come OpCache PHP
• Utilizzo memoria per richiesta
• Volumi in memoria condivisi

Contemporaneità (servizi)

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

Sandbox del container

Se utilizzi l'ambiente di esecuzione di prima generazione, viene eseguito il sandboxing dei container Cloud Run la sandbox del runtime del container gVisor. Come documentato nel riferimento per la compatibilità delle chiamate di sistema con gVisor, alcune chiamate di sistema potrebbero non essere supportate da questa sandbox del container.

Se utilizzi l'ambiente di esecuzione di seconda generazione, la compatibilità con Linux è completa. 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 impostata su Google Compute Engine.

L'ambiente di esecuzione di seconda generazione esegue il codice di servizio in un ambiente dello spazio dei nomi di processo, quindi inizia come il processo di inizializzazione del container, che ha la semantica del processo. Nell'ambiente di esecuzione di prima generazione, il servizio non viene eseguito come processo init del container.

Server metadati istanza

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

Per accedere ai dati del server dei metadati, utilizza le richieste HTTP Endpoint http://metadata.google.internal/ con Metadata-Flavor: Google intestazione: non sono necessarie librerie client. Per ulteriori informazioni, vedi Recupero dei metadati.

Nella tabella seguente sono elencate alcune delle informazioni sul server dei metadati disponibili:

Percorso	Descrizione
/computeMetadata/v1/project/project-id	ID del progetto a cui appartiene il servizio o il job Cloud Run
/computeMetadata/v1/project/numeric-project-id	Numero del progetto a cui appartiene il servizio o il job Cloud Run
/computeMetadata/v1/instance/region	La 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'account di servizio 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 su Zona Google Cloud alle istanze in esecuzione. Di conseguenza, l'attributo dei metadati /computeMetadata/v1/instance/zone restituisce sempre projects/PROJECT-NUMBER/zones/REGION-1.

Nomi file

I nomi di file che utilizzi nei contenitori devono essere compatibili con UTF-8 (UTF-8) o qualcosa che possa essere convertito automaticamente in UTF-8. Se i nomi dei file utilizzano codifiche diverse, eseguire la build Docker su una macchina con nomi di file compatibili con UTF-8, ed evita di copiare file in un contenitore che contiene nomi UTF-8 incompatibili.

Il deployment dei container non riesce se i nomi file non sono compatibili con UTF-8. Tieni presente che non ci sono limitazioni al carattere che utilizzi all'interno di un file.

Connessioni in uscita

Timeout delle richieste in uscita

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

Reimpostazione della connessione in uscita

I flussi di connessioni dal container a VPC e a internet possono terminati occasionalmente e sostituiti al riavvio dell'infrastruttura sottostante o aggiornato. Se la tua applicazione riutilizza connessioni di lunga durata, ti consigliamo di configurare l'applicazione per ristabilire le connessioni evitare il riutilizzo di una connessione inattiva.