Environnement d'exécution de fonctions Cloud Run
Les fonctions Cloud Run s'exécutent 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
Les fonctions Cloud Run acceptent 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 des fonctions Cloud Run et des fonctions Cloud Run (1re génération). 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 Run.
Les images d'exécution sont hébergées dans chaque région où Artifact Registry est disponible. Vous pouvez personnaliser le chemin d'accès de l'image d'exécution en remplaçant la première partie de l'URI par la région de votre choix:
REGION-docker.pkg.dev/serverless-runtimes/STACK/runtimes/RUNTIME_ID
Remplacez :
- REGION par la région préférée, par exemple
us-central1
. - STACK par la pile de système d'exploitation souhaitée, par exemple
google-22-full
- RUNTIME_ID par l'ID d'exécution utilisé par votre fonction, par exemple
python310
.
Par exemple, la dernière image de base Node.js 20 utilisant la pile google-22-full
, hébergée dans us-central1
, serait référencée avec cette URL : us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/nodejs22
Node.js
Exécution | ID d'exécution | Piles | Image de base de l'environnement d'exécution |
---|---|---|---|
Node.js 22 (version bêta uniquement) |
nodejs22 |
|
|
Node.js 20 | nodejs20 |
|
|
Node.js 18 | nodejs18 |
|
|
Node.js 16 | nodejs16 | google-18-full | google-18-full/nodjes16 |
Node.js 14 | nodejs14 | google-18-full | google-18-full/nodjes14 |
Node.js 12 | nodejs12 | google-18-full | google-18-full/nodjes14 |
Node.js 10 | nodejs10 | google-18-full | google-18-full/nodjes10 |
Node.js 8 | nodejs8 | Hors service | Hors service |
Node.js 6 | nodejs6 | Hors service | Hors service |
Python
Exécution | ID d'exécution | Piles | Image de base de l'environnement d'exécution |
---|---|---|---|
Python 3.12 | python312 |
|
|
Python 3.11 | python311 |
|
|
Python 3.10 | python310 |
|
|
Python 3.9 | python39 | google-18-full | google-18-full/python39 |
Python 3.8 | python38 | google-18-full | google-18-full/python38 |
Python 3.7 | python37 | google-18-full | google-18-full/python37 |
Go
Exécution | ID d'exécution | Piles | Image de base de l'environnement d'exécution |
---|---|---|---|
Go 1.22 | go122 |
|
|
Go 1.21 | go121 |
|
|
Go 1.20 | go120 |
|
|
Go 1.19 | go119 |
|
|
Go 1.18 | go118 |
|
|
Go 1.16 | go116 | google-18-full | google-18-full/go116 |
Go 1.13 | go113 | google-18-full | google-18-full/go113 |
Go 1.11 | go111 | Hors service | Hors service |
Java
Exécution | ID d'exécution | Piles | Image de base de l'environnement d'exécution |
---|---|---|---|
Java 21 | java21 |
|
|
Java 17 | java17 |
|
|
Java 11 | java11 | google-18 | google-18/java11 |
Ruby
Exécution | ID d'exécution | Piles | Image de base de l'environnement d'exécution |
---|---|---|---|
Ruby 3.3 | ruby33 |
|
|
Ruby 3.2 | ruby32 |
|
|
Ruby 3.0 | ruby30 | google-18-full | google-18-full/ruby30 |
Ruby 2.7 | ruby27 | google-18-full | google-18-full/ruby27 |
Ruby 2.6 | ruby26 | google-18-full | google-18-full/ruby26 |
PHP
Exécution | ID d'exécution | Piles | Image de base de l'environnement d'exécution |
---|---|---|---|
PHP 8.3 | php83 |
|
|
PHP 8.2 | php82 |
|
|
PHP 8.1 | php81 | google-18-full | google-18-full/php81 |
PHP 7.4 | php74 | google-18-full | google-18-full/php74 |
.NET Core
Exécution | ID d'exécution | Piles | Image de base de l'environnement d'exécution |
---|---|---|---|
.NET Core 8 | dotnet8 |
|
|
.NET Core 6 | dotnet6 |
|
|
.NET Core 3 | dotnet3 | google-18-full | google-18-full/dotnet3 |
Comportement d'autoscaling
Les fonctions Cloud Run mettent 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.
Les fonctions Cloud Run gèrent 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, les fonctions Cloud Run peuvent 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, les fonctions Cloud Run peuvent démarrer plusieurs nouvelles instances pour gérer les requêtes. Ce comportement de scaling automatique permet aux fonctions Cloud Run de gérer de nombreuses requêtes en parallèle, chacune utilisant une instance différente de votre fonction.
Dans certains cas, un scaling illimité peut être souhaitable. Pour résoudre ce problème, les fonctions Cloud Run vous permettent 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.
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é
Fonctions Cloud Run
Les fonctions Cloud Run permettent 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é
Fonctions Cloud Run (1re génération)
Dans les fonctions Cloud Run (1re génération), 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 les fonctions Cloud Run (1re génération) 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 les fonctions Cloud Run.
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.
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
Python
Go
Java
Ruby
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, les fonctions Cloud Run ne garantissent 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, la fonction n'est appelée à nouveau que si de nouvelles 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.
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.