Ambiente di esecuzione delle funzioni di Cloud Run

Nota: le informazioni contenute in questo documento si applicano in genere sia Funzioni Cloud Run (1ª generazione.) e Cloud Run (in precedenza Cloud Functions (2ª generazione.)), se non diversamente indicato. Per conoscere le funzionalità aggiuntive supportate dalle funzioni di Cloud Run, consulta Confronto tra le versioni delle funzioni di Cloud Run.

Le funzioni di Cloud Run vengono eseguite in un ambiente serverless completamente gestito in cui gestisce l'infrastruttura, i sistemi operativi e gli ambienti di runtime. Ogni funzione viene eseguita nella propria esecuzione sicura isolata di contesto, scala automaticamente e ha un ciclo di vita indipendente funzioni.

Runtime

Le funzioni di Cloud Run supportano più runtime dei linguaggi. Ciascuno contiene un set standard di pacchetti di sistema, nonché gli strumenti e le librerie necessari per quel linguaggio. Avrai bisogno della Valore ID runtime se esegui il deployment delle funzioni dalla riga di comando o tramite Terraform.

Gli aggiornamenti di sicurezza e manutenzione sono disponibili per tutte le funzioni di Cloud Run e funzioni Cloud Run (1ª generazione.). Questi aggiornamenti vengono applicati automaticamente o manualmente. a seconda dell'ambiente e di come lo hai configurato. Per ulteriori informazioni sugli aggiornamenti dell'ambiente di esecuzione, consulta Proteggi la funzione Cloud Run.

Le immagini di runtime sono ospitate in ogni regione in cui è disponibile Artifact Registry. Puoi personalizzare il percorso dell'immagine runtime sostituendo la prima parte dell'URI con la regione di tua scelta:

REGION-docker.pkg.dev/serverless-runtimes/STACK/runtimes/RUNTIME_ID

Sostituisci:

• REGION con la regione preferita, ad esempio us-central1
• STACK con lo stack del sistema operativo preferito, ad esempio google-22-full
• RUNTIME_ID con l'ID runtime utilizzato dalla tua funzione, ad esempio python310

Ad esempio, l'ultima immagine di base Node.js 20 che utilizza lo stack google-22-full, ospitati in us-central1 verrebbero indicati come riferimento con questo URL: us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/nodejs22

Node.js

Runtime	Generazione	ID runtime	Impilati	Immagine di base del runtime
Node.js 22 (solo anteprima)	Esegui funzioni	nodejs22	google-22-pieno	google-22-completo/nodejs22
Node.js 20	1ª generazione., Esegui funzioni	nodejs20	google-22-pieno	google-22-completo/nodejs20
Node.js 18	1ª generazione., Esegui funzioni	nodejs18	google-22-pieno	google-22-completo/nodejs18
Node.js 16	1ª generazione., Esegui funzioni	nodejs16	google-18-completo	google-18-completo/nodjes16
Node.js 14	1ª generazione., Esegui funzioni	nodejs14	google-18-completo	google-18-completo/nodjes14
Node.js 12	1ª generazione., Esegui funzioni	nodejs12	google-18-completo	google-18-completo/nodjes14
Node.js 10	1ª generazione., Esegui funzioni	nodejs10	google-18-completo	google-18-completo/nodjes10
Node.js 8	1ª generazione., Esegui funzioni	nodejs8	Dismesso	Dismesso
Node.js 6	1ª generazione., Esegui funzioni	nodejs6	Dismesso	Dismesso

Python

Runtime	Generazione	ID runtime	Impilati	Immagine di base del runtime
Python 3.12	1ª generazione., Esegui funzioni	python312	google-22-pieno	google-22-full/python312
Python 3.11	1ª generazione., Esegui funzioni	python311	google-22-pieno	google-22-full/python311
Python 3.10	1ª generazione., Esegui funzioni	python310	google-22-pieno	google-22-full/python311
Python 3.9	1ª generazione., Esegui funzioni	python39	google-18-completo	google-18-full/python39
Python 3.8	1ª generazione., Esegui funzioni	python38	google-18-completo	google-18-full/python38
Python 3.7	1ª generazione., Esegui funzioni	python37	google-18-completo	google-18-full/python37

Vai

Runtime	Generazione	ID runtime	Impilati	Immagine di base del runtime
Vai a 1,22	Esegui funzioni	go122	google-22-pieno	google-22-completo/go122
Go 1.21	Esegui funzioni	go121	google-22-pieno	google-22-completo/go121
Go 1.20	Esegui funzioni	go120	google-22-pieno	google-22-completo/go120
Go 1.19	1ª generazione., Esegui funzioni	go119	google-22-pieno	google-22-completo/go119
Go 1.18	1ª generazione., Esegui funzioni	go118	google-22-pieno	google-22-completo/go120
Go 1.16	1ª generazione., Esegui funzioni	go116	google-18-completo	google-18-completo/go116
Go 1.13	1ª generazione., Esegui funzioni	go113	google-18-completo	google-18-completo/go113
Go 1.11	1ª generazione., Esegui funzioni	go111	Dismesso	Dismesso

Nota: gli stati delle norme di rilascio di Go che ogni release principale di Go sia supportata fino a quando non ci saranno due release principali più recenti. Date importanti potrebbero non essere disponibili finché versioni più recenti di Go non saranno rese disponibili pubblicamente.

Java

Runtime	Generazione	ID runtime	Impilati	Immagine di base del runtime
Java 21	Esegui funzioni	java21	google-22-pieno	google-22-full/java21
Java 17	1ª generazione., Esegui funzioni	java17	google-22-pieno	google-22-full/java17
Java 11	1ª generazione., Esegui funzioni	java11	google-18	google-18/java11

Ruby

Runtime	Generazione	ID runtime	Impilati	Immagine di base del runtime
Ruby 3.3	1ª generazione., Esegui funzioni	ruby33	google-22-pieno	google-22-completo/ruby33
Ruby 3.2	1ª generazione., Esegui funzioni	ruby32	google-22-pieno	google-22-completo/ruby32
Ruby 3.0	1ª generazione., Esegui funzioni	ruby30	google-18-completo	google-18-completo/ruby30
Ruby 2.7	1ª generazione., Esegui funzioni	ruby27	google-18-completo	google-18-completo/ruby27
Ruby 2.6	1ª generazione., Esegui funzioni	ruby26	google-18-completo	google-18-completo/ruby26

PHP

Runtime	Generazione	ID runtime	Impilati	Immagine di base del runtime
PHP 8.3	Esegui funzioni	php83	google-22-pieno	google-22-full/php83
PHP 8.2	1ª generazione., Esegui funzioni	php82	google-22-pieno	google-22-full/php82
PHP 8.1	1ª generazione., Esegui funzioni	php81	google-18-completo	google-18-full/php81
PHP 7.4	1ª generazione., Esegui funzioni	php74	google-18-completo	google-18-full/php74

.NET Core

Runtime	Generazione	ID runtime	Impilati	Immagine di base del runtime
.NET Core 8	Esegui funzioni	dotnet8	google-22-pieno	google-22-full/dotnet8
.NET Core 6	1ª generazione., Esegui funzioni	dotnet6	google-22-pieno	google-22-full/dotnet6
.NET Core 3	1ª generazione., Esegui funzioni	dotnet3	google-18-completo	google-18-completo/dotnet3

Comportamento di scalabilità automatica

Le funzioni Cloud Run implementano il paradigma serverless, in cui esegui il tuo codice senza preoccuparti dell'infrastruttura sottostante, come i server o macchine virtuali. Una volta eseguito il deployment, le tue funzioni vengono gestite automaticamente e su larga scala.

Le funzioni Cloud Run gestisce le richieste in entrata assegnandole a instances della funzione. A seconda del volume di richieste, nonché il numero di istanze di funzione esistenti, le funzioni Cloud Run possono assegnare a un'istanza esistente o crearne una nuova.

Se il volume delle richieste in entrata supera il numero di istanze esistenti, Le funzioni Cloud Run possono avviare più nuove istanze per gestire le richieste. Questo comportamento di scalabilità automatica consente alle funzioni Cloud Run di gestire molti richieste in parallelo, ognuna utilizzando una diversa istanza della funzione.

Nota: un aumento estremamente rapido del traffico in entrata può causare a intermittenza alcune richieste non vanno a buon fine con un codice HTTP 500. Questo perché le richieste timeout nella coda di attesa durante l'attesa della creazione di nuove istanze. Configura il carico di lavoro in modo da aumentare gradualmente il traffico nel corso del corso di un minuto può risolvere questo problema. Vedi anche Risoluzione dei problemi delle funzioni di Cloud Run per saperne di più.

In alcuni casi, la scalabilità illimitata potrebbe non essere desiderata. Per risolvere questo problema, Le funzioni di Cloud Run consentono di configurare numero massimo di istanze che possono coesistere in qualsiasi momento per una particolare funzione.

Condizione stateless

Per abilitare la gestione e la scalabilità automatiche delle funzioni, le funzioni devono essere stateless: una chiamata di funzione non deve basarsi sullo stato in memoria impostato da una chiamata precedente. Le chiamate potrebbero essere gestite da una funzione diversa di Compute Engine, che non condividono variabili globali, memoria, file system o altre stato.

Nota: sebbene non sia necessario, lo stato in memoria spesso può essere riutilizzato come un'ottimizzazione delle prestazioni; vedi il consiglio in Suggerimenti utili per maggiori dettagli.

Se devi condividere lo stato tra le chiamate di funzione, la funzione deve usa un servizio come Memorystore, Datastore Firestore oppure Cloud Storage per rendere persistenti i dati. Consulta: database Google Cloud e Prodotti di archiviazione Google Cloud per ulteriori informazioni le opzioni di database e archiviazione fornite da Google Cloud.

Contemporaneità

Funzioni Cloud Run

Le funzioni Cloud Run supportano la gestione di più richieste in parallelo su un un'istanza di funzione singola. Questo può essere utile per evitare avvii a freddo, dato che un'istanza già in uso può elaborare più richieste contemporaneamente, riducendo la latenza complessiva. Per maggiori dettagli, vedi Contemporaneità.

Funzioni Cloud Run (1ª generazione.)

Nelle funzioni Cloud Run (1ª generazione.), ogni istanza di una funzione gestisce solo uno richiesta in parallelo. Ciò significa che, mentre il codice ne sta elaborando uno, non c'è alcuna possibilità che una seconda richiesta venga instradata allo stesso in esecuzione in un'istanza Compute Engine. Di conseguenza, la richiesta originale può utilizzare la quantità completa di risorse (memoria e CPU) che assegni.

Poiché le richieste in parallelo nelle funzioni Cloud Run (1ª generazione.) vengono elaborate istanze di funzione diverse, non condividono variabili o memoria locale. Consulta: Stateless e Per ulteriori informazioni, consulta la durata di un'istanza di funzione.

Avvii a freddo

Una nuova istanza di funzione viene avviata in due casi:

• Quando esegui il deployment della funzione.

• Quando viene creata automaticamente una nuova istanza di funzione per fare lo scale up per il carico, o occasionalmente per sostituire un'istanza esistente.

L'avvio di una nuova istanza di funzione comporta il caricamento del runtime e del codice. Le richieste che includono l'avvio dell'istanza di funzione, chiamato avvii a freddo, possono essere rispetto alle richieste instradate a istanze di funzione esistenti. Se la tua funzione riceve un carico costante, tuttavia, il numero di avvii a freddo è generalmente trascurabile, a meno che la funzione abbia arresti anomali frequenti e richieda il riavvio di dell'ambiente della funzione.

Se il codice della funzione genera un'eccezione non rilevata o si arresta in modo anomalo un'istanza della funzione potrebbe essere riavviata. Ciò può causare un aumento del con conseguente maggiore latenza, per cui consigliamo di rilevare le eccezioni e in altro modo per evitare l'interruzione della procedura corrente. Consulta: Segnalare errori per un discussione su come gestire e segnalare errori nelle funzioni di Cloud Run.

Nota: nelle funzioni Cloud Run (1ª generazione.), la quantità di memoria concessa a una funzione influisce sull'allocazione della CPU, che a sua volta può influire sul tempo di avvio a freddo (vedi i prezzi). Sebbene questo sia vero anche Le funzioni Cloud Run per impostazione predefinita; nelle funzioni di Cloud Run è possibile scegliere configurazione dell'allocazione della CPU separate dalla memoria.

Se la funzione è sensibile alla latenza, valuta la possibilità di impostare una numero minimo di istanze evitare avvii a freddo.

Durata di un'istanza di funzione

Le istanze di funzione sono in genere resilienti e riutilizzate dalla funzione successiva di chiamate, a meno che non venga fatto lo scale down del numero di istanze per mancanza traffico in corso o la funzione si arresta in modo anomalo. Ciò significa che quando una funzione termina l'esecuzione, un'altra chiamata a una funzione può essere gestita dalla stessa funzione in esecuzione in un'istanza Compute Engine.

Nota: per ottimizzare le prestazioni, puoi memorizzare nella cache lo stato di tutte le chiamate in in un ambito globale, ove possibile. Tuttavia, la funzione non deve basarsi stato memorizzato nella cache, in quanto non vi è alcuna garanzia che la prossima chiamata raggiunga la stessa istanza di funzione, vedi Stateless.

Ambito della funzione e ambito globale

Una singola chiamata di funzione comporta l'esecuzione del solo corpo della dichiarata come punto di ingresso. L'ambito globale dell'origine della funzione il codice viene eseguito solo sugli avvii a freddo e non sulle istanze che sono già stati inizializzati.

Node.js

const functions = require('@google-cloud/functions-framework');

// TODO(developer): Define your own computations
const {lightComputation, heavyComputation} = require('./computations');

// Global (instance-wide) scope
// This computation runs once (at instance cold-start)
const instanceVar = heavyComputation();

/**
 * HTTP function that declares a variable.
 *
 * @param {Object} req request context.
 * @param {Object} res response context.
 */
functions.http('scopeDemo', (req, res) => {
  // Per-function scope
  // This computation runs every time this function is called
  const functionVar = lightComputation();

  res.send(`Per instance: ${instanceVar}, per function: ${functionVar}`);
});

Python

import time

import functions_framework


# Placeholder
def heavy_computation():
    return time.time()


# Placeholder
def light_computation():
    return time.time()


# Global (instance-wide) scope
# This computation runs at instance cold-start
instance_var = heavy_computation()


@functions_framework.http
def scope_demo(request):
    """
    HTTP Cloud Function that declares a variable.
    Args:
        request (flask.Request): The request object.
        <http://flask.pocoo.org/docs/1.0/api/#flask.Request>
    Returns:
        The response text, or any set of values that can be turned into a
        Response object using `make_response`
        <http://flask.pocoo.org/docs/1.0/api/#flask.Flask.make_response>.
    """

    # Per-function scope
    # This computation runs every time this function is called
    function_var = light_computation()
    return f"Instance: {instance_var}; function: {function_var}"

Vai

// h is in the global (instance-wide) scope.
var h string

// init runs during package initialization. So, this will only run during an
// an instance's cold start.
func init() {
	h = heavyComputation()
	functions.HTTP("ScopeDemo", ScopeDemo)
}

// ScopeDemo is an example of using globally and locally
// scoped variables in a function.
func ScopeDemo(w http.ResponseWriter, r *http.Request) {
	l := lightComputation()
	fmt.Fprintf(w, "Global: %q, Local: %q", h, l)
}

Java

import com.google.cloud.functions.HttpFunction;
import com.google.cloud.functions.HttpRequest;
import com.google.cloud.functions.HttpResponse;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Arrays;

public class Scopes implements HttpFunction {
  // Global (instance-wide) scope
  // This computation runs at instance cold-start.
  // Warning: Class variables used in functions code must be thread-safe.
  private static final int INSTANCE_VAR = heavyComputation();

  @Override
  public void service(HttpRequest request, HttpResponse response)
      throws IOException {
    // Per-function scope
    // This computation runs every time this function is called
    int functionVar = lightComputation();

    var writer = new PrintWriter(response.getWriter());
    writer.printf("Instance: %s; function: %s", INSTANCE_VAR, functionVar);
  }

  private static int lightComputation() {
    int[] numbers = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
    return Arrays.stream(numbers).sum();
  }

  private static int heavyComputation() {
    int[] numbers = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
    return Arrays.stream(numbers).reduce((t, x) -> t * x).getAsInt();
  }
}

Ruby

# Global (instance-wide) scope.
# This block runs on cold start, before any function is invoked.
#
# Note: It is usually best to run global initialization in an on_startup block
# instead at the top level of the Ruby file. This is because top-level code
# could be executed to verify the function during deployment, whereas an
# on_startup block is run only when an actual function instance is starting up.
FunctionsFramework.on_startup do
  instance_data = perform_heavy_computation

  # To pass data into function invocations, the best practice is to set a
  # key-value pair using the Ruby Function Framework's built-in "set_global"
  # method. Functions can call the "global" method to retrieve the data by key.
  # (You can also use Ruby global variables or "toplevel" local variables, but
  # they can make it difficult to isolate global data for testing.)
  set_global :my_instance_data, instance_data
end

FunctionsFramework.http "tips_scopes" do |_request|
  # Per-function scope.
  # This method is called every time this function is called.
  invocation_data = perform_light_computation

  # Retrieve the data computed by the on_startup block.
  instance_data = global :my_instance_data

  "instance: #{instance_data}; function: #{invocation_data}"
end

Puoi usare le variabili globali per l'ottimizzazione del rendimento, ma non devi si basa sullo stato impostato nell'ambito globale dalle chiamate di funzione precedenti: Per ulteriori informazioni, consulta la sezione Stateless.

Si può presumere che per ogni istanza di funzione, l'ambito globale sia stato eseguito esattamente una volta prima di richiamare il codice della funzione. Tuttavia, devi non dipendono dal numero totale o dalla tempistica delle esecuzioni in ambito globale, potrebbe variare in base all'attività di scalabilità automatica.

Cronologia di esecuzione della funzione

Una funzione ha accesso alle risorse allocate (memoria e CPU) solo per durata dell'esecuzione della funzione. Il codice eseguito al di fuori del periodo di esecuzione non è l'esecuzione è garantita e può essere arrestata in qualsiasi momento. Pertanto, devi segnala sempre correttamente la fine dell'esecuzione della funzione ed evita di eseguirla qualsiasi codice al di fuori. Vedi Funzioni HTTP. Funzioni in background, e Funzioni CloudEvent per assistenza.

L'esecuzione della funzione è inoltre soggetta alla sua durata di timeout. Consulta: Timeout funzione per ulteriori informazioni.

Tieni conto delle tempistiche di esecuzione durante l'inizializzazione dell'applicazione. Le attività in background non devono essere create in ambito globale durante l'inizializzazione, al di fuori della durata della richiesta.

Garanzie di esecuzione

In genere le funzioni vengono richiamate una volta per ogni evento in arrivo. Tuttavia, Le funzioni Cloud Run non garantiscono una singola chiamata in tutti i casi a causa delle differenze negli scenari di errore.

Il numero massimo o minimo di volte in cui la tua funzione può essere richiamata per un singolo evento dipende dal tipo di funzione:

• Le funzioni HTTP vengono richiamate al massimo una volta. Ciò è dovuto all'architettura sincrona delle chiamate HTTP e questo significa che qualsiasi errore che si verifica durante verrà restituita senza riprovare. Il chiamante di una funzione HTTP deve gestire gli errori e riprovare se necessario.

• Le funzioni basate su eventi vengono richiamate almeno una volta. Ciò è dovuto natura asincrona degli eventi, in cui nessun chiamante attende per la risposta. In rare circostanze, il sistema potrebbe richiamare un funzione basata su eventi più volte per garantire la pubblicazione dell'evento. Se la chiamata di una funzione basata su eventi ha esito negativo e restituisce un errore, la funzione non essere richiamati di nuovo, a meno che tentativi in caso di errore sono abilitati per quella funzione.

Per assicurarti che la funzione comporti correttamente i nuovi tentativi di esecuzione, dovresti renderla idempotente implementandola in modo che vengano restituiti (ed effetti collaterali) vengono generati anche se un evento viene pubblicato più volte. Nel caso delle funzioni HTTP, ciò significa anche restituire il valore desiderato anche se il chiamante riesegue le chiamate all'endpoint della funzione HTTP. Consulta: Ripetere le funzioni basate su eventi per ulteriori informazioni su come rendere idempotente la tua funzione.

Memoria e file system

A ogni funzione è allocata una certa quantità di memoria per l'utilizzo. Puoi per configurare la quantità di memoria al momento del deployment, Limiti di memoria per ulteriori informazioni.

L'ambiente di esecuzione della funzione include un file system in memoria che contiene i file e le directory di origine di cui è stato eseguito il deployment con la funzione (vedi Struttura del codice sorgente). La directory contenente i file di origine è di sola lettura, ma il resto del file system è scrivibile (ad eccezione dei file utilizzati dal sistema operativo). L'utilizzo del file system viene conteggiato ai fini della quantità di memoria utilizzata da una funzione.

La tua funzione può interagire con il file system utilizzando metodi standard in ogni linguaggio di programmazione.

Nota: nell'ambiente di esecuzione delle funzioni Cloud Run, la directory radice di il codice sorgente della funzione è la directory di lavoro corrente (.), con eccezione dei runtime Go, dove la directory radice del codice sorgente della funzione si trova sotto la directory di lavoro attuale all'indirizzo ./serverless_function_source_code.

Rete

La tua funzione può accedere alla rete internet pubblica utilizzando i metodi standard in ogni tramite librerie integrate offerte dal runtime oppure librerie di terze parti che includi come dipendenze.

Prova a riutilizzare le connessioni di rete nelle chiamate di funzione, descritta in Ottimizzazione del networking. Tuttavia, tieni presente che una connessione che rimane inutilizzata per 10 minuti potrebbe verrà chiuso dal sistema e ulteriori tentativi di utilizzare una connessione chiusa comportano la "reimpostazione della connessione" . Il codice deve utilizzare una libreria che gestisca bene le connessioni chiuse o che le gestisca esplicitamente costrutti di networking di basso livello.

Isolamento delle funzioni

Ogni funzione di cui è stato eseguito il deployment è isolata da tutte le altre funzioni, comprese quelle di cui è stato eseguito il deployment dallo stesso file di origine. In particolare, non condividono la memoria, variabili globali, file system o altri stati.

Per condividere i dati tra le funzioni di cui è stato eseguito il deployment, puoi utilizzare servizi come Memorystore Datastore Firestore oppure Cloud Storage. In alternativa, puoi richiamare una funzione un'altra usando i trigger appropriati e trasmettendo i dati necessari. Ad esempio, effettua una richiesta HTTP all'endpoint di una funzione HTTP o pubblica un messaggio a un argomento Pub/Sub per attivare un Pub/Sub personalizzata.