Environnement d'exécution Cloud Functions

Remarque : Les informations de ce document s'appliquent généralement à Cloud Functions (1st gen) et à Cloud Functions (2nd gen), sauf indication contraire. Pour découvrir les fonctionnalités supplémentaires compatibles avec la 2e génération, consultez la section Comparaison des versions de Cloud Functions.

Cloud Functions s'exécute dans un environnement sans serveur entièrement géré, dans lequel Google gère l'infrastructure, les systèmes d'exploitation et les environnements d'exécution. Chaque fonction Cloud Functions s'exécute dans son propre contexte sécurisé et isolé, évolue automatiquement et dispose d'un cycle de vie indépendant des autres fonctions.

Environnements d'exécution

Cloud Functions accepte plusieurs environnements d'exécution de langage. Chaque package contient un ensemble standard de packages système, ainsi que les outils et bibliothèques nécessaires pour ce langage. Vous aurez besoin de la valeur de l'ID d'exécution si vous déployez des fonctions à partir de la ligne de commande ou via Terraform.

Les mises à jour de sécurité et de maintenance sont disponibles pour tous les environnements d'exécution de 1re et 2e générations. Ces mises à jour sont appliquées automatiquement ou manuellement, en fonction de l'environnement et de la manière dont vous l'avez configuré. Pour en savoir plus sur les mises à jour de l'environnement d'exécution, consultez la page Sécuriser votre fonction Cloud.

Node.js

Environnement d'exécution	Génération	Environnement	ID d'exécution	Image de l'environnement d'exécution	Obsolescence	Mise hors service
Node.js 20	1st gen, 2nd gen	Ubuntu 22.04	nodejs20	gcr.io/gae-runtimes/buildpacks/nodejs20/run	2026-04-30
Node.js 18	1st gen, 2nd gen	Ubuntu 22.04	nodejs18	gcr.io/gae-runtimes/buildpacks/nodejs18/run	2025-04-30
Node.js 16	1st gen, 2nd gen	Ubuntu 18.04	Node.js 16	gcr.io/gae-runtimes/buildpacks/nodejs16/run	2024-01-30
Node.js 14	1st gen, 2nd gen	Ubuntu 18.04	nodejs14	gcr.io/gae-runtimes/buildpacks/nodejs14/run	2024-01-30
Node.js 12	1st gen, 2nd gen	Ubuntu 18.04	nodejs12	gcr.io/gae-runtimes/buildpacks/nodejs12s/run	2024-01-30
Node.js 10	1st gen, 2nd gen	Ubuntu 18.04	nodejs10	gcr.io/gae-runtimes/buildpacks/nodejs10/run	2024-01-30
Node.js 8	1st gen, 2nd gen	Ubuntu 18.04	nodejs8	gcr.io/gae-runtimes/buildpacks/nodejs8/run	2020-06-05	Févr. 2021
Node.js 6	1st gen, 2nd gen	Ubuntu 18.04	nodejs6	gcr.io/gae-runtimes/buildpacks/nodejs6/run	2019-04-17	Août 2020

Python

Environnement d'exécution	Génération	Environnement	ID d'exécution	Image de l'environnement d'exécution	Obsolescence	Mise hors service
Python 3.12	1st gen, 2nd gen	Ubuntu 22.04	python312	gcr.io/gae-runtimes/buildpacks/python312/run	2028-10-02
Python 3.11	1st gen, 2nd gen	Ubuntu 22.04	python311	gcr.io/gae-runtimes/buildpacks/python311/run	2027-10-24
Python 3.10	1st gen, 2nd gen	Ubuntu 22.04	python310	gcr.io/gae-runtimes/buildpacks/python310/run	2026-10-04
Python 3.9	1st gen, 2nd gen	Ubuntu 18.04	python39	gcr.io/gae-runtimes/buildpacks/python39/run	2025-10-05
Python 3.8	1st gen, 2nd gen	Ubuntu 18.04	python38	gcr.io/gae-runtimes/buildpacks/python38/run	2024-10-14
Python 3.7	1re génération	Ubuntu 18.04	python37	gcr.io/gae-runtimes/buildpacks/python37/run	2024-01-30

Go

Environnement d'exécution	Génération	Environnement	ID d'exécution	Image de l'environnement d'exécution	Obsolescence	Mise hors service
Go 1.22	2e génération	Ubuntu 22.04	go122	gcr.io/gae-runtimes/buildpacks/go122/run
Go 1.21	1st gen, 2nd gen	Ubuntu 22.04	go121	gcr.io/gae-runtimes/buildpacks/go121/run
Go 1.20	1st gen, 2nd gen	Ubuntu 22.04	go120	gcr.io/gae-runtimes/buildpacks/go120/run
Go 1.19	1st gen, 2nd gen	Ubuntu 22.04	go119	gcr.io/gae-runtimes/buildpacks/go119/run	2024-04-30
Go 1.18	1st gen, 2nd gen	Ubuntu 22.04	go118	gcr.io/gae-runtimes/buildpacks/go118/run	2024-01-30
Go 1.16	1st gen, 2nd gen	Ubuntu 18.04	go116	gcr.io/gae-runtimes/buildpacks/go116/run	2024-01-30
Go 1.13	1st gen, 2nd gen	Ubuntu 18.04	go113	gcr.io/gae-runtimes/buildpacks/go113/run	2024-01-30
Go 1.12	1st gen, 2nd gen	Ubuntu 18.04	go112	gcr.io/gae-runtimes/buildpacks/go112/run	2024-01-30
Go 1.11	1st gen, 2nd gen	Ubuntu 18.04	go111	gcr.io/gae-runtimes/buildpacks/go111/run	2020-08-05	Févr. 2021

Remarque : Les règles de version de Go stipulent que chaque version majeure de Go reste prise en charge jusqu'à ce que deux versions majeures plus récentes soient disponibles. Les dates clés peuvent ne pas être disponibles tant que des versions plus récentes de Go ne sont pas accessibles au public.

Java

Environnement d'exécution	Génération	Environnement	ID d'exécution	Image de l'environnement d'exécution	Obsolescence	Mise hors service
Java 21	2e génération	Ubuntu 22.04	java21	gcr.io/gae-runtimes/buildpacks/java21/run	octobre 2031
Java 17	1st gen, 2nd gen	Ubuntu 22.04	java17	gcr.io/gae-runtimes/buildpacks/java17/run	Octobre 2027
Java 11	1st gen, 2nd gen	Ubuntu 18.04	java11	gcr.io/gae-runtimes/buildpacks/java11/run	Octobre 2024

Ruby

Environnement d'exécution	Génération	Environnement	ID d'exécution	Image de l'environnement d'exécution	Obsolescence	Mise hors service
Ruby 3.2	1st gen, 2nd gen	Ubuntu 22.04	ruby32	gcr.io/gae-runtimes/buildpacks/ruby32/run	2026-03-31
Ruby 3.0	1st gen, 2nd gen	Ubuntu 18.04	ruby30	gcr.io/gae-runtimes/buildpacks/ruby30/run	2024-03-31
Ruby 2.7	1st gen, 2nd gen	Ubuntu 18.04	ruby27	gcr.io/gae-runtimes/buildpacks/ruby27/run	2024-01-30
Ruby 2.6	1st gen, 2nd gen	Ubuntu 18.04	ruby26	gcr.io/gae-runtimes/buildpacks/ruby26/run	2024-01-30

PHP

Environnement d'exécution	Environnement	Génération	ID d'exécution	Image de l'environnement d'exécution	Obsolescence	Mise hors service
PHP 8.3	2e génération	Ubuntu 22.04	php83	gcr.io/gae-runtimes/buildpacks/php83/run	2026-11-23	2027-11-23
PHP 8.2	1st gen, 2nd gen	Ubuntu 22.04	php82	gcr.io/gae-runtimes/buildpacks/php82/run	2025-12-08
PHP 8.1	1st gen, 2nd gen	Ubuntu 18.04	php81	gcr.io/gae-runtimes/buildpacks/php81/run	2024-11-25
PHP 7.4	1st gen, 2nd gen	Ubuntu 18.04	php74	gcr.io/gae-runtimes/buildpacks/php74/run	2024-01-30

.NET Core

Environnement d'exécution	Génération	Environnement	ID d'exécution	Image de l'environnement d'exécution	Obsolescence	Mise hors service
.NET Core 8	2e génération	Ubuntu 22.04	dotnet8	gcr.io/gae-runtimes/buildpacks/dotnet8/run
.NET Core 6	1st gen, 2nd gen	Ubuntu 22.04	dotnet6	gcr.io/gae-runtimes/buildpacks/dotnet6/run	2024-11-12
.NET Core 3	1st gen, 2nd gen	Ubuntu 18.04	dotnet3	gcr.io/gae-runtimes/buildpacks/dotnet3/run	2024-01-30

Comportement d'autoscaling

Cloud Functions met en œuvre le paradigme sans serveur, dans lequel vous exécutez simplement votre code sans vous soucier de l'infrastructure sous-jacente, telle que les serveurs ou les machines virtuelles. Une fois déployées, vos fonctions sont automatiquement gérées et adaptées.

Cloud Functions gère les requêtes entrantes en les attribuant à des instances de votre fonction. En fonction du volume de requêtes et du nombre d'instances de fonction existantes, Cloud Functions peut attribuer une requête à une instance existante ou en créer une.

Lorsque le volume de requêtes entrantes dépasse le nombre d'instances existantes, Cloud Functions peut démarrer plusieurs nouvelles instances pour gérer les requêtes. Ce comportement de scaling automatique permet à Cloud Functions de gérer de nombreuses requêtes en parallèle, chacune utilisant une instance différente de votre fonction.

Remarque : Une augmentation extrêmement rapide du trafic entrant peut entraîner l'échec de certaines requêtes avec un code HTTP 500. Cela est dû au fait que les requêtes expirent dans la file d'attente en attendant la création d'instances. Pour résoudre ce problème, vous devez configurer votre charge de travail pour qu'elle augmente progressivement le trafic au cours d'une minute. Pour en savoir plus, consultez la page Résoudre les problèmes liés à Cloud Functions.

Dans certains cas, un scaling illimité peut être souhaitable. Pour résoudre ce problème, Cloud Functions vous permet de configurer un nombre maximal d'instances pouvant coexister à un moment donné pour une fonction particulière.

Caractéristique "sans état"

Pour activer la gestion et le scaling automatiques de vos fonctions, celles-ci doivent être sans état : un appel de fonction ne doit pas dépendre de l'état en mémoire défini par un appel précédent. Les appels peuvent être gérés par différentes instances de fonctions qui ne partagent pas de variables globales, de mémoire, de systèmes de fichiers ou d'autres états.

Remarque : Bien qu'il ne faille pas s'y fier, il est souvent possible de réutiliser l'état en mémoire pour optimiser les performances. Pour en savoir plus, consultez la recommandation dans Conseils et astuces.

Si vous avez besoin de partager un état sur l'ensemble des appels de fonctions, votre fonction doit utiliser un service tel que Memorystore, Datastore, Firestore ou Cloud Storage pour conserver ces données. Consultez les pages Bases de données Google Cloud et Produits de stockage Google Cloud pour en savoir plus sur les options de base de données et de stockage proposées par Google Cloud.

Simultanéité

Cloud Functions (2nd gen)

Cloud Functions (2nd gen) permet de gérer plusieurs requêtes simultanées sur une seule instance de fonction. Cela peut être utile pour éviter les démarrages à froid, car une instance déjà préchauffée peut traiter plusieurs requêtes simultanément, ce qui réduit la latence globale. Pour en savoir plus, consultez la section Simultanéité

Cloud Functions (1st gen)

Dans Cloud Functions (1st gen), chaque instance d'une fonction ne traite qu'une seule requête simultanée à la fois. Cela signifie que lorsque votre code traite une requête, il est impossible qu'une deuxième requête soit acheminée vers la même instance. Ainsi, la requête d'origine peut utiliser la totalité des ressources (mémoire et processeur) que vous allouez.

Étant donné que les requêtes simultanées dans Cloud Functions (1st gen) sont traitées par différentes instances de fonctions, elles ne partagent pas les mêmes variables ni la même mémoire locale. Pour en savoir plus, consultez les sections Sans état et Durée de vie de l'instance de fonction.

Démarrages à froid

Une nouvelle instance de fonction est créée dans deux cas :

• Lorsque vous déployez une fonction.

• Lorsqu'une nouvelle instance de fonction est automatiquement créée pour s'adapter à la charge actuelle ou, plus rarement, pour remplacer une instance existante.

Le lancement d'une nouvelle instance de fonction implique le chargement de l'environnement d'exécution et de votre code. Les requêtes qui impliquent le démarrage d'une instance de fonction, appelées démarrages à froid, peuvent être plus lentes que les requêtes acheminées vers des instances de fonction existantes. Si votre fonction reçoit une charge constante, le nombre de démarrages à froid est généralement négligeable, à moins que votre fonction connaisse de nombreux plantages et nécessite un redémarrage de tout son environnement.

Si votre code de fonction génère une exception non détectée ou bloque le processus en cours, l'instance de fonction peut être redémarrée. Cela peut entraîner des démarrages à froid plus élevés et une latence plus élevée. Nous vous recommandons donc de capturer les exceptions et d'éviter l'arrêt du processus en cours. Consultez la page Signaler des erreurs pour savoir comment gérer et signaler les erreurs dans Cloud Functions.

Remarque : Dans la première génération, la quantité de mémoire attribuée à une fonction affecte l'allocation du processeur, ce qui peut avoir un impact sur le démarrage à froid (voir la section Tarifs). Bien que cela s'applique également à la 2e génération par défaut, vous avez la possibilité de configurer l'allocation du processeur en dehors de la mémoire.

Si votre fonction est sensible à la latence, envisagez de définir un nombre minimal d'instances pour éviter les démarrages à froid.

Durée de vie de l'instance de fonction

Les instances de fonction sont généralement résilientes et réutilisées par des appels de fonctions ultérieurs, à moins que le nombre d'instances soit réduit en raison d'un manque de trafic continu ou de plantage de votre fonction. Cela signifie que lorsque l'exécution d'une fonction se termine, un autre appel de fonction peut être géré par cette même instance de fonction.

Remarque : Vous pouvez mettre en cache l'état des appels dans le champ d'application global à des fins d'optimisation. Cependant, votre fonction ne doit pas se fier à cet état mis en cache, car rien ne garantit que l'appel suivant sera transmis à la même instance de fonction. Consultez la section Sans état.

Champ d'application de la fonction et champ d'application global

Un appel de fonction unique entraîne seulement l'exécution du corps de la fonction déclarée comme point d'entrée. Le champ d'application global de votre code source de fonction n'est exécuté que lors de démarrages à froid, et non sur des instances déjà initialisées.

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}"

Go

// 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

Vous pouvez utiliser des variables globales à des fins d'optimisation, mais vous ne devez pas vous fier à l'état défini dans le champ d'application global par les appels de fonctions précédents. Pour plus d'informations, consultez la page Sans état.

Vous pouvez considérer que pour chaque instance de fonction, le champ d'application global aura été exécuté une fois avant que votre code de fonction ne soit appelé. Toutefois, vous ne devez pas dépendre du nombre total d'exécutions de champ d'application global, ni de leur planification, car elles peuvent varier en fonction de l'activité de l'autoscaling.

Chronologie d'exécution des fonctions

Une fonction n'a accès à ses ressources allouées (mémoire et processeur) que pendant sa durée d'exécution. L'exécution du code en dehors de la période d'exécution n'est pas garantie et peut être interrompue à tout moment. Par conséquent, vous devez toujours signaler la fin de l'exécution de votre fonction et éviter d'exécuter du code au-delà. Pour obtenir des conseils, consultez les pages Fonctions HTTP, Fonctions d'arrière-plan et Fonctions CloudEvent.

L'exécution d'une fonction est également soumise à un délai d'inactivité. Pour en savoir plus, consultez la section Délai d'inactivité d'une fonction.

Tenez compte de la chronologie d'exécution lors de l'initialisation de votre application. Les tâches en arrière-plan ne doivent pas être créées dans le champ d'application global lors de l'initialisation, car elles s'exécutent en dehors de la durée d'une requête.

Garanties d'exécution

Vos fonctions sont généralement appelées une seule fois pour chaque événement entrant. Cependant, Cloud Functions ne garantit pas un appel unique dans tous les cas, en raison de différences dans les scénarios d'erreur.

Le nombre maximum ou minimum d'appels de fonctions pour un seul événement dépend du type de fonction :

• Les fonctions HTTP sont appelées au maximum une fois. Cela est dû à la nature synchrone des appels HTTP. Ainsi, toute erreur survenant lors de l'appel de la fonction sera affichée sans nouvelle tentative. L'appelant d'une fonction HTTP doit assumer la gestion des erreurs, ainsi que des nouvelles tentatives, le cas échéant.

• Les fonctions basées sur des événements sont appelées au moins une fois. Cela est dû à la nature asynchrone de la gestion de ces événements, dans lesquels aucun appelant n'attend de réponse. Dans de rares cas, le système peut appeler plusieurs fois une fonction basée sur des événements, afin d'assurer la diffusion de l'événement. Si un appel de fonction basée sur des événements échoue et renvoie une erreur, cet appel ne sera pas renouvelé, sauf si des tentatives en cas d'échec sont activées pour cette fonction.

Pour vous assurer que votre fonction se comporte correctement lors de nouvelles tentatives d’exécution, vous devez la rendre idempotente en la mettant en œuvre de sorte qu'un événement produise les résultats souhaités (et les effets secondaires), même s’il est transmis plusieurs fois. Dans le cas des fonctions HTTP, cela signifie également renvoyer la valeur souhaitée, même si l'appelant réessaie d'appeler le point de terminaison de la fonction HTTP. Consultez la page Effectuer de nouvelles tentatives d'exécution des fonctions basées sur des événements pour plus d'informations sur la manière de rendre votre fonction idempotente.

Mémoire et système de fichiers

Chaque fonction dispose d'une certaine quantité de mémoire allouée à son utilisation. Vous pouvez configurer la quantité de mémoire au déploiement. Pour en savoir plus, consultez la section Limites de mémoire.

L'environnement d'exécution de fonction inclut un système de fichiers en mémoire contenant les fichiers sources et les répertoires déployés avec votre fonction (voir Structurer le code source). Le répertoire contenant vos fichiers source est en lecture seule, mais le reste du système de fichiers est accessible en écriture (à l'exception des fichiers utilisés par le système d'exploitation). L'utilisation du système de fichiers est comptabilisée dans l'utilisation de la mémoire d'une fonction.

Votre fonction peut interagir avec le système de fichiers à l'aide de méthodes standards dans chaque langage de programmation.

Remarque : Dans l'environnement d'exécution Cloud Functions, le répertoire racine du code source de votre fonction est le répertoire de travail actuel (.), à l'exception des environnements d'exécution Go, où le répertoire racine du code source de votre fonction se trouve sous le répertoire de travail actuel à l'emplacement ./serverless_function_source_code.

Réseau

Votre fonction peut accéder à l'Internet public en utilisant des méthodes standards dans chaque langage de programmation, que ce soit via des bibliothèques intégrées proposées par l'environnement d'exécution ou des bibliothèques tierces que vous incluez en tant que dépendances.

Essayez de réutiliser les connexions réseau pour vos appels de fonctions, comme décrit dans la section Optimisation des réseaux. Notez toutefois qu'une connexion inutilisée pendant 10 minutes peut être fermée par le système et que toute nouvelle tentative d'utilisation d'une connexion fermée entraîne une erreur de type "Connexion réinitialisée". Votre code doit utiliser une bibliothèque qui gère les connexions fermées de manière appropriée, ou bien les gérer explicitement si vous utilisez des constructions réseau de bas niveau.

Isolation de fonction

Chaque fonction déployée est isolée de toutes les autres fonctions, même celles déployées à partir du même fichier source. Plus précisément, elles ne partagent pas de mémoire, de variables globales, de systèmes de fichiers ou d'autres états.

Pour partager des données entre des fonctions déployées, vous pouvez utiliser des services tels que Memorystore, Datastore, Firestore ou Cloud Storage. Vous pouvez également appeler une fonction à partir d'une autre en utilisant les déclencheurs appropriés et en transmettant les données nécessaires. Par exemple, envoyez une requête HTTP au point de terminaison d'une fonction HTTP ou publiez un message dans un sujet Pub/Sub pour déclencher une fonction Pub/Sub.