Informazioni sugli ambienti di esecuzione dei servizi

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 questo non può essere modificato per i job.

L'ambiente di esecuzione di prima generazione è caratterizzato da tempi di avvio a freddo rapidi e dall'emulazione della maggior parte, ma non di tutte, le chiamate al sistema operativo. In origine, questo era l'unico ambiente di esecuzione disponibile per i servizi in Cloud Run.

L'ambiente di esecuzione di seconda generazione offre la piena compatibilità con Linux anziché l'emulazione delle chiamate di sistema. Questo ambiente di esecuzione fornisce:

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

Sebbene l'ambiente di esecuzione di seconda generazione in genere funzioni più velocemente con un carico sostenuto, ha tempi di avvio a freddo più lunghi rispetto alla prima generazione per alcuni servizi.

Entrambi gli ambienti di esecuzione hanno lo stesso prezzo. Per ulteriori dettagli, consulta la pagina dei prezzi di Cloud Run.

Come scegliere un ambiente di esecuzione

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

  • Il tuo servizio Cloud Run ha un traffico burst e deve scalare rapidamente a molte istanze oppure il tuo servizio è sensibile ai tempi di avvio a freddo.
  • Il tuo servizio Cloud Run ha un traffico poco frequente che causa frequenti scalabilità orizzontale 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 tuo servizio deve utilizzare NFS, che è supportato solo dalla seconda generazione.
  • Il tuo servizio ha un traffico abbastanza costante e tollera avvii completi un po' più lenti.
  • Il tuo servizio ha carichi di lavoro che richiedono un uso intensivo della CPU.
  • Il tuo servizio potrebbe trarre vantaggio da prestazioni di rete più veloci.
  • Il tuo servizio deve utilizzare software che presenta 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 un'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 gestore SIGTERM nel container, soprattutto se utilizzi la fatturazione basata sulle richieste.

La gestione di SIGTERM offre al contenitore la possibilità di eseguire qualsiasi attività di pulizia necessaria, come lo svuotamento dei log prima di uscire. Se il container non rileva SIGTERM, avrà comunque 10 secondi per eseguire queste attività; questi 10 secondi sono fatturabili.

Come verificare se il container 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 che stai consultando. Potresti dover autorizzarlo e attendere il 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 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 segue il formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .

  3. Apri un'altra scheda in Cloud Shell e recupera 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 un segnale SIGTERM al contenitore

    docker kill -s SIGTERM CONTAINER_ID

  5. Torna alla scheda in cui hai richiamato docker run per vedere se il container è uscito (si è arrestato). Se il segnale SIGTERM ha causato l'uscita del container, il container gestisce SIGTERM.

Come gestire SIGTERM

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

In alternativa, puoi modificare l'applicazione per gestire direttamente SIGTERM.

Passaggi successivi