Informazioni sugli ambienti di esecuzione

Per impostazione predefinita, i servizi Cloud Run non hanno un ambiente di esecuzione specificato, il che significa che Cloud Run seleziona l'ambiente di esecuzione in base alle funzionalità utilizzate. Pertanto, a meno che tu non specifichi un ambiente di esecuzione per il tuo servizio, Cloud Run può selezionare l'ambiente di prima o seconda generazione.

Tieni presente che i job Cloud Run utilizzano solo l'ambiente di esecuzione di seconda generazione e che questo non può essere modificato per i job.

L'ambiente di esecuzione di prima generazione offre tempi di avvio a freddo rapidi ed emula la maggior parte, ma non tutte, le chiamate del sistema operativo. In origine, era l'unico ambiente di esecuzione disponibile per i servizi in Cloud Run.

L'ambiente di esecuzione di seconda generazione offre una compatibilità Linux completa anziché l'emulazione delle chiamate di sistema. Questo ambiente di esecuzione offre:

  • Prestazioni della CPU più elevate
  • Prestazioni di rete più rapide, in particolare in presenza di perdita di pacchetti
  • Compatibilità completa con Linux, incluso il supporto di tutte le chiamate di sistema, gli spazi dei nomi e i gruppi cgroup
  • Supporto del file system di rete

Sebbene l'ambiente di esecuzione di seconda generazione in genere funzioni più velocemente sotto carico sostenuto, ha tempi di avvio a freddo più lunghi rispetto alla prima generazione per la maggior parte dei servizi.

Puoi selezionare l'ambiente di esecuzione per il tuo servizio Cloud Run quando esegui il deployment di un nuovo servizio o di una nuova revisione del servizio. Se non specifichi un ambiente di esecuzione, per impostazione predefinita viene utilizzata la prima generazione.

Come scegliere un ambiente di esecuzione

Devi utilizzare la prima generazione se si applica una delle seguenti condizioni:

  • Il tuo servizio Cloud Run ha un traffico discontinuo e deve scalare rapidamente su molte istanze oppure è sensibile ai tempi di avvio a freddo.
  • Il servizio Cloud Run presenta un traffico infrequente che causa frequenti scalate da zero.
  • Vuoi utilizzare meno di 512 MiB di memoria. L'ambiente di esecuzione di seconda generazione richiede almeno 512 MiB di memoria.

Devi utilizzare la seconda generazione se una delle seguenti condizioni si applica al tuo servizio Cloud Run:

  • Il servizio deve utilizzare un file system di rete, supportato solo dalla seconda generazione.
  • Il servizio ha un traffico abbastanza costante e tollera avviamenti a freddo leggermente più lenti.
  • Il tuo servizio ha carichi di lavoro che richiedono molta CPU.
  • Il tuo servizio potrebbe trarre vantaggio da prestazioni di rete più rapide.
  • Il tuo servizio deve utilizzare software con problemi di esecuzione nella prima generazione a causa di chiamate di sistema non implementate.
  • Il tuo servizio richiede la funzionalità cgroup di Linux.
  • Il tuo servizio utilizza l'infrastruttura di terze parti per proteggere i container.

Best practice per l'utilizzo dell'ambiente di esecuzione di seconda generazione

Ti consigliamo di installare un handler SIGTERM nel contenitore, soprattutto se utilizzi il modello di fatturazione CPU On Demand.

La gestione di SIGTERM offre al contenitore la possibilità di eseguire le attività di pulizia necessarie, come lo svuotamento dei log, prima di uscire. Se il contenitore non intercetta SIGTERM, avrà comunque 10 secondi di tempo per eseguire queste attività. Questi 10 secondi sono fatturabili.

Come verificare se il contenitore gestisce SIGTERM

Per determinare se nel contenitore è installato un gestore SIGTERM:

  1. Avvia Cloud Shell. Puoi trovare Pulsante Attiva Cloud Run Attiva Cloud Shell nell'intestazione della pagina della documentazione in cui ti trovi. Potresti dover autorizzarlo e attendere il relativo provisioning. In alternativa, avvia una sessione autonoma.

  2. Esegui il container localmente in Cloud Shell:

    docker run IMAGE_URL

    Sostituisci IMAGE_URL con un riferimento all'immagine del container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se utilizzi Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL ha la forma LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG

  3. Apri un'altra scheda in Cloud Shell e visualizza un elenco dei container in esecuzione nella sessione Cloud Shell corrente:

    docker container ls

    Devi individuare l'ID contenitore restituito dal comando.

  4. Utilizzando l'ID contenitore, invia al contenitore un segnale SIGTERM

    docker kill -s SIGTERM CONTAINER_ID

  5. Torna alla scheda in cui hai invocato docker run per vedere se il contenitore è stato chiuso (interrotto). Se il segnale SIGTERM ha causato l'uscita del contenitore, il contenitore gestisce SIGTERM.

Come gestire SIGTERM

Se il contenitore non gestisce SIGTERM, il modo più semplice per aggiungere un gestore SIGTERM è avvolgere il servizio con tini. In questo modo, il servizio viene eseguito come sottoprocesso di tini, che assume il ruolo del processo di inizializzazione del contenitore. Per istruzioni, consulta le istruzioni di Docker.

In alternativa, puoi modificare l'applicazione in modo da gestire direttamente SIGTERM.

Passaggi successivi