Gérer les fonctions

Vous pouvez déployer, supprimer et modifier des fonctions à l'aide des commandes de la CLI Firebase ou en définissant des options d'exécution dans le code source de vos fonctions.

Déployer des fonctions

Pour déployer des fonctions, exécutez cette commande Firebase CLI :

firebase deploy --only functions

Par défaut, la CLI Firebase déploie toutes les fonctions de votre source en même temps. Si votre projet contient plus de cinq fonctions, nous vous recommandons d'utiliser l'indicateur --only avec des noms de fonctions spécifiques pour ne déployer que les fonctions que vous avez modifiées. Déployer des fonctions spécifiques de cette manière accélère le processus de déploiement et vous aide à éviter de dépasser les quotas de déploiement. Exemple :

firebase deploy --only functions:addMessage,functions:makeUppercase

Lorsque vous déployez un grand nombre de fonctions, vous pouvez dépasser le quota standard et recevoir des messages d'erreur HTTP 429 ou 500. Pour résoudre ce problème, déployez les fonctions par groupes de 10 ou moins.

Consultez la documentation de référence sur la CLI Firebase pour obtenir la liste complète des commandes disponibles.

Par défaut, l'interface de ligne de commande Firebase recherche le code source dans le dossier functions/. Si vous préférez, vous pouvez organiser les fonctions dans des bases de code ou plusieurs ensembles de fichiers.

Nettoyer les artefacts de déploiement

Lors du déploiement des fonctions, des images de conteneurs sont générées et stockées dans Artifact Registry. Ces images ne sont pas nécessaires à l'exécution de vos fonctions déployées. Cloud Functions récupère et conserve une copie de l'image lors du déploiement initial, mais les artefacts stockés ne sont pas nécessaires au fonctionnement de la fonction lors de l'exécution.

Bien que ces images de conteneurs soient souvent petites, elles peuvent s'accumuler au fil du temps et contribuer à vos coûts de stockage. Vous pouvez préférer les conserver pendant un certain temps si vous prévoyez d'inspecter les artefacts créés ou d'exécuter des analyses de vulnérabilité des conteneurs.

Pour vous aider à gérer les coûts de stockage, la CLI Firebase 14.0.0 et les versions ultérieures vous permettent de configurer une règle de nettoyage Artifact Registry pour les dépôts qui stockent les artefacts de déploiement après chaque déploiement de fonction.

Vous pouvez configurer ou modifier manuellement une règle de nettoyage à l'aide de la commande functions:artifacts:setpolicy :

firebase functions:artifacts:setpolicy

Par défaut, cette commande configure Artifact Registry pour supprimer automatiquement les images de conteneur de plus d'un jour. Cela permet de trouver un équilibre raisonnable entre la réduction des coûts de stockage et l'inspection potentielle des versions récentes.

Vous pouvez personnaliser la période de conservation à l'aide de l'option --days :

firebase functions:artifacts:setpolicy --days 7  # Delete images older than 7 days

Si vous déployez des fonctions dans plusieurs régions, vous pouvez configurer une règle de nettoyage pour un emplacement spécifique à l'aide de l'option --location :

$ firebase functions:artifacts:setpolicy --location europe-west1

Désactiver le nettoyage des artefacts

Si vous préférez gérer le nettoyage des images manuellement ou si vous ne souhaitez pas que des images soient supprimées, vous pouvez désactiver complètement les règles de nettoyage :

$ firebase functions:artifacts:setpolicy --none

Cette commande supprime toute règle de nettoyage existante configurée par la CLI Firebase et empêche Firebase de configurer une règle de nettoyage après le déploiement des fonctions.

Supprimer des fonctions

Vous pouvez supprimer des fonctions déployées précédemment de différentes manières :

• explicitement dans la CLI Firebase avec functions:delete
• explicitement dans la console Google Cloud.
• implicitement en supprimant la fonction de la source avant le déploiement.

Toutes les opérations de suppression vous invitent à confirmer avant de supprimer la fonction de la production.

La suppression explicite de fonctions dans la CLI Firebase accepte plusieurs arguments ainsi que des groupes de fonctions, et vous permet de spécifier une fonction s'exécutant dans une région particulière. Vous pouvez également ignorer l'invite de confirmation.

# Delete all functions that match the specified name in all regions.
firebase functions:delete myFunction

# Delete a specified function running in a specific region.
firebase functions:delete myFunction --region us-east-1

# Delete more than one function
firebase functions:delete myFunction myOtherFunction

# Delete a specified functions group.
firebase functions:delete groupA

# Bypass the confirmation prompt.
firebase functions:delete myFunction --force

Avec la suppression implicite de fonctions, firebase deploy analyse votre source et supprime de la production toutes les fonctions qui ont été supprimées du fichier.

Modifier le nom, la région ou le déclencheur d'une fonction

Si vous renommez ou modifiez les régions ou le déclencheur des fonctions qui gèrent le trafic de production, suivez les étapes de cette section pour éviter de perdre des événements lors de la modification. Avant de suivre ces étapes, assurez-vous que votre fonction est idempotente, car les ancienne et nouvelle versions de votre fonction s'exécuteront en même temps pendant le changement.

Renommer une fonction

Pour renommer une fonction, créez une nouvelle version renommée de la fonction dans votre source, puis exécutez deux commandes de déploiement distinctes. La première commande déploie la fonction nouvellement nommée, et la seconde supprime la version précédemment déployée. Par exemple, si vous souhaitez renommer un webhook déclenché par HTTP, modifiez le code comme suit :

// before
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhook = onRequest((req, res) => {
    res.send("Hello");
});

// after
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhookNew = onRequest((req, res) => {
    res.send("Hello");
});

# before
from firebase_functions import https_fn

@https_fn.on_request()
def webhook(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

# after
from firebase_functions import https_fn

@https_fn.on_request()
def webhook_new(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

Exécutez ensuite les commandes suivantes pour déployer la nouvelle fonction :

# Deploy new function
firebase deploy --only functions:webhookNew

# Wait until deployment is done; now both functions are running

# Delete webhook
firebase functions:delete webhook

Modifier la région ou les régions d'une fonction

Si vous modifiez les régions spécifiées pour une fonction qui gère le trafic de production, vous pouvez éviter la perte d'événements en procédant comme suit :

1. Renommez la fonction et modifiez sa ou ses régions comme vous le souhaitez.
2. Déployez la fonction renommée, ce qui entraîne l'exécution temporaire du même code dans les deux ensembles de régions.
3. Supprimez la fonction précédente.

Par exemple, si vous avez une fonction déclenchée par Cloud Firestore qui se trouve actuellement dans la région de fonctions par défaut us-central1 et que vous souhaitez la migrer vers asia-northeast1, vous devez d'abord modifier votre code source pour renommer la fonction et réviser la région.

// before
exports.firestoreTrigger = onDocumentCreated(
  "my-collection/{docId}",
  (event) => {},
);

// after
exports.firestoreTriggerAsia = onDocumentCreated(
  {
    document: "my-collection/{docId}",
    region: "asia-northeast1",
  },
  (event) => {},
);

# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
    pass

# After
@firestore_fn.on_document_created("my-collection/{docId}",
                                  region="asia-northeast1")
def firestore_trigger_asia(event):
    pass

Déployez ensuite en exécutant la commande suivante :

firebase deploy --only functions:firestoreTriggerAsia

Deux fonctions identiques sont désormais en cours d'exécution : firestoreTrigger s'exécute dans us-central1 et firestoreTriggerAsia s'exécute dans asia-northeast1.

Supprimez ensuite firestoreTrigger :

firebase functions:delete firestoreTrigger

Il n'y a plus qu'une seule fonction, firestoreTriggerAsia, qui s'exécute dans asia-northeast1.

Modifier le type de déclencheur d'une fonction

Au fur et à mesure que vous développez votre déploiement Cloud Functions for Firebase, vous devrez peut-être modifier le type de déclencheur d'une fonction pour diverses raisons. Par exemple, vous pouvez passer d'un type d'événement Firebase Realtime Database ou Cloud Firestore à un autre.

Il n'est pas possible de modifier le type d'événement d'une fonction en modifiant simplement le code source et en exécutant firebase deploy. Pour éviter les erreurs, modifiez le type de déclencheur d'une fonction en suivant cette procédure :

1. Modifiez le code source pour inclure une nouvelle fonction avec le type de déclencheur souhaité.
2. Déployez la fonction, ce qui entraîne l'exécution temporaire des anciennes et nouvelles fonctions.
3. Supprimez explicitement l'ancienne fonction de production à l'aide de la CLI Firebase.

Par exemple, si vous aviez une fonction déclenchée lorsqu'un objet était supprimé, mais que vous avez ensuite activé la gestion des versions d'objets et que vous souhaitez vous abonner à l'événement d'archivage, commencez par renommer la fonction et modifiez-la pour qu'elle ait le nouveau type de déclencheur.

// before
const {onObjectDeleted} = require("firebase-functions/v2/storage");

exports.objectDeleted = onObjectDeleted((event) => {
    // ...
});

// after
const {onObjectArchived} = require("firebase-functions/v2/storage");

exports.objectArchived = onObjectArchived((event) => {
    // ...
});

# before
from firebase_functions import storage_fn

@storage_fn.on_object_deleted()
def object_deleted(event):
  # ...

# after 
from firebase_functions import storage_fn

@storage_fn.on_object_archived()
def object_archived(event):
  # ...

Exécutez ensuite les commandes suivantes pour créer la nouvelle fonction avant de supprimer l'ancienne :

# Create new function objectArchived
firebase deploy --only functions:objectArchived

# Wait until deployment is done; now both objectDeleted and objectArchived are running

# Delete objectDeleted
firebase functions:delete objectDeleted

Définir les options d'exécution

Cloud Functions for Firebase vous permet de sélectionner des options d'exécution telles que la version de l'environnement d'exécution Node.js, ainsi que le délai avant expiration, l'allocation de mémoire et le nombre minimal/maximal d'instances de fonction par fonction.

Nous vous recommandons de définir ces options (à l'exception de la version Node.js) dans un objet de configuration à l'intérieur du code de la fonction. Cet objet RuntimeOptions est la source de vérité pour les options d'exécution de votre fonction. Il remplace les options définies par toute autre méthode (par exemple, via la console Google Cloud ou la gcloud CLI).

Si votre workflow de développement implique de définir manuellement des options d'exécution via la console Google Cloud ou gcloud CLI et que vous ne souhaitez pas que ces valeurs soient remplacées à chaque déploiement, définissez l'option preserveExternalChanges sur true. Si cette option est définie sur true, Firebase fusionne les options d'exécution définies dans votre code avec les paramètres de la version actuellement déployée de votre fonction, selon la priorité suivante :

1. L'option est définie dans le code des fonctions : remplace les modifications externes.
2. L'option est définie sur RESET_VALUE dans le code des fonctions : remplacez les modifications externes par la valeur par défaut.
3. L'option n'est pas définie dans le code des fonctions, mais elle l'est dans la fonction actuellement déployée : utilisez l'option spécifiée dans la fonction déployée.

L'utilisation de l'option preserveExternalChanges: true est déconseillée pour la plupart des scénarios, car votre code ne sera plus la source de vérité complète pour les options d'exécution de vos fonctions. Si vous l'utilisez, consultez la console Google Cloud ou utilisez gcloud CLI pour afficher la configuration complète d'une fonction.

Définir la version de Node.js

Le SDK Firebase pour Cloud Functions permet de sélectionner un environnement d'exécution Node.js. Vous pouvez choisir d'exécuter toutes les fonctions d'un projet exclusivement dans l'environnement d'exécution correspondant à l'une des versions Node.js compatibles suivantes :

• Node.js 22
• Node.js 20
• Node.js 18 (obsolète)

Les versions 14 et 16 de Node.js ont été mises hors service début 2025. Le déploiement avec ces versions est désactivé. Consultez le calendrier de compatibilité pour obtenir des informations importantes sur la compatibilité continue de ces versions de Node.js.

Pour définir la version de Node.js :

Vous pouvez définir la version dans le champ engines du fichier package.json créé dans votre répertoire functions/ lors de l'initialisation. Par exemple, pour n'utiliser que la version 20, modifiez cette ligne dans package.json :

  "engines": {"node": "20"}

Si vous utilisez le gestionnaire de packages Yarn ou si vous avez d'autres exigences spécifiques pour le champ engines, vous pouvez définir le runtime pour le SDK Firebase pour Cloud Functions dans firebase.json à la place :

  {
    "functions": {
      "runtime": "nodejs20" // or nodejs22
    }
  }

L'interface de ligne de commande utilise la valeur définie dans firebase.json de préférence à toute valeur ou plage que vous définissez séparément dans package.json.

Mettre à niveau votre environnement d'exécution Node.js

Pour mettre à niveau votre environnement d'exécution Node.js :

1. Assurez-vous que votre projet est associé au forfait Blaze.
2. Assurez-vous d'utiliser la CLI Firebase version 11.18.0 ou ultérieure.
3. Modifiez la valeur engines dans le fichier package.json créé dans votre répertoire functions/ lors de l'initialisation. Par exemple, si vous passez de la version 18 à la version 20, l'entrée doit se présenter comme suit : "engines": {"node": "20"}
4. Vous pouvez également tester vos modifications à l'aide de Firebase Local Emulator Suite.
5. Redéployez toutes les fonctions.

Définir la version Python

Le SDK Firebase pour les versions 12.0.0 et ultérieures de Cloud Functions permet de sélectionner le runtime Python. Définissez la version d'exécution dans firebase.json comme indiqué :

  {
    "functions": {
      "runtime": "python310" // or python311
    }
  }

Contrôler le comportement du scaling

Par défaut, Cloud Functions for Firebase adapte le nombre d'instances en cours d'exécution en fonction du nombre de requêtes entrantes, et peut même le réduire à zéro en cas de trafic réduit. Toutefois, si votre application nécessite une latence réduite et que vous souhaitez limiter le nombre de démarrages à froid, vous pouvez modifier ce comportement par défaut en spécifiant un nombre minimal d'instances de conteneur à garder en attente et prêtes à traiter des requêtes.

De même, vous pouvez définir un nombre maximal pour limiter le scaling des instances en réponse aux requêtes entrantes. Utilisez ce paramètre pour contrôler vos coûts ou limiter le nombre de connexions à un service de backend, tel qu'une base de données.

En utilisant ces paramètres avec le paramètre de simultanéité par instance (nouveau dans la 2e génération), vous pouvez contrôler et ajuster le comportement de scaling de vos fonctions. La nature de votre application et de votre fonction déterminera les paramètres les plus rentables et les plus performants.

Pour certaines applications à faible trafic, une option de processeur inférieure sans multiconcurrence est optimale. Pour les autres cas où les démarrages à froid sont un problème critique, la définition d'une simultanéité et d'un nombre minimal d'instances élevés signifie qu'un ensemble d'instances est toujours maintenu au chaud pour gérer les pics de trafic importants.

Pour les applications à plus petite échelle qui reçoivent très peu de trafic, définir un nombre maximal d'instances faible avec une concurrence élevée signifie que l'application peut gérer les pics de trafic sans entraîner de coûts excessifs. Cependant, n'oubliez pas que si le nombre maximal d'instances est trop faible, les requêtes peuvent être abandonnées lorsque le plafond est atteint.

Autoriser les requêtes simultanées

Dans Cloud Functions for Firebase (1re génération), chaque instance pouvait traiter une requête à la fois. Le comportement de scaling était donc défini uniquement avec les paramètres du nombre minimal et maximal d'instances. En plus de contrôler le nombre d'instances, dans Cloud Functions for Firebase (2e génération), vous pouvez contrôler le nombre de requêtes que chaque instance peut traiter simultanément avec l'option concurrency. La valeur de simultanéité par défaut est de 80, mais vous pouvez la définir sur n'importe quel entier compris entre 1 et 1 000.

Les fonctions avec des paramètres de simultanéité plus élevés peuvent absorber les pics de trafic sans démarrage à froid, car chaque instance dispose probablement d'une certaine marge. Si une instance est configurée pour gérer jusqu'à 50 requêtes simultanées, mais qu'elle n'en gère actuellement que 25, elle peut gérer un pic de 25 requêtes supplémentaires sans nécessiter le démarrage à froid d'une nouvelle instance. En revanche, avec un paramètre de simultanéité de 1, ce pic de requêtes pourrait entraîner 25 démarrages à froid.

Ce scénario simplifié illustre les gains d'efficacité potentiels de la simultanéité. En réalité, le comportement de scaling visant à optimiser l'efficacité et à réduire les démarrages à froid avec la simultanéité est plus complexe. La simultanéité dans Cloud Functions for Firebase 2e génération est optimisée par Cloud Run et suit les règles d'Cloud Run concernant l'autoscaling des instances de conteneur.

Lorsque vous testez des paramètres de simultanéité plus élevés dans Cloud Functions for Firebase (2e génération), tenez compte des points suivants :

• Des paramètres de simultanéité plus élevés peuvent nécessiter plus de processeur et de RAM pour des performances optimales, jusqu'à atteindre une limite pratique. Par exemple, une fonction qui effectue un traitement intensif d'images ou de vidéos peut manquer de ressources pour gérer 1 000 requêtes simultanées, même lorsque ses paramètres de processeur et de RAM sont maximaux.
• Étant donné que Cloud Functions for Firebase (2e génération) est optimisé par Cloud Run, vous pouvez également consulter les conseils de Google Cloud pour optimiser la simultanéité.
• Veillez à tester minutieusement la multidevise dans un environnement de test avant de l'activer en production.

Garder un nombre minimal d'instances en attente

Vous pouvez définir un nombre minimal d'instances pour une fonction dans le code source. Par exemple, cette fonction définit un minimum de cinq instances pour le maintien au chaud :

const { onCall } = require("firebase-functions/v2/https");

exports.getAutocompleteResponse = onCall(
  {
    // Keep 5 instances warm for this latency-critical function
    minInstances: 5,
  },
  (event) => {
    // Autocomplete user’s search term
  }
);

@https_fn.on_call(min_instances=5)
def get_autocomplete_response(event: https_fn.CallableRequest) -> https_fn.Response:

Voici quelques éléments à prendre en compte lorsque vous définissez une valeur minimale pour les instances :

• Si Cloud Functions for Firebase met à l'échelle votre application au-delà de votre paramètre, vous subirez un démarrage à froid pour chaque instance au-dessus de ce seuil.
• Les démarrages à froid ont l'effet le plus important sur les applications dont le trafic est irrégulier. Si votre application connaît des pics de trafic et que vous définissez une valeur suffisamment élevée pour réduire les démarrages à froid à chaque augmentation du trafic, vous constaterez une latence considérablement réduite. Pour les applications avec un trafic constant, les démarrages à froid ne sont pas susceptibles d'affecter gravement les performances.

• Il peut être judicieux de définir un nombre minimal d'instances pour les environnements de production, mais il est généralement préférable de l'éviter dans les environnements de test. Pour effectuer un scaling à zéro dans votre projet de test tout en réduisant les démarrages à froid dans votre projet de production, vous pouvez définir une valeur d'instances minimales dans votre configuration paramétrée :

  Node.js

  const functions = require('firebase-functions/v1');
  const { defineInt, defineString } = require('firebase-functions/params');
  
  // Define some parameters
  const minInstancesConfig = defineInt('HELLO_WORLD_MININSTANCES');
  const welcomeMessage = defineString('WELCOME_MESSAGE');
  
  // To use configured parameters inside the config for a function, provide them 
  // directly. To use them at runtime, call .value() on them.
  export const helloWorld = functions.runWith({ minInstances: minInstancesConfig}).https.onRequest(
    (req, res) => {
      res.send(`${welcomeMessage.value()}! I am a function.`);
    }
  );
  

  Python

  MIN_INSTANCES = params.IntParam("HELLO_WORLD_MININSTANCES")
  WELCOME_MESSAGE = params.StringParam("WELCOME_MESSAGE")
  
  @https_fn.on_request(min_instances=MIN_INSTANCES.value())
  def get_autocomplete_response(event: https_fn.Request) -> https_fn.Response:
      return https_fn.Response(f"{WELCOME_MESSAGE.value()} I'm a function.")
  

Limiter le nombre maximal d'instances pour une fonction

Vous pouvez définir une valeur pour le nombre maximal d'instances dans le code source de la fonction. Par exemple, cette fonction définit une limite de 100 instances afin de ne pas surcharger une hypothétique ancienne base de données :

const { onMessagePublished } = require("firebase-functions/v2/pubsub");

exports.mirrorevents = onMessagePublished(
  { topic: "topic-name", maxInstances: 100 },
  (event) => {
    // Connect to legacy database
  }
);

@pubsub_fn.on_message_published(topic="topic-name", max_instances=100)
def mirrorevents(event: pubsub_fn.CloudEvent):
#  Connect to legacy database

Si une fonction HTTP est mise à l'échelle jusqu'à la limite maximale d'instances, les nouvelles requêtes sont mises en file d'attente pendant 30 secondes, puis refusées avec un code de réponse 429 Too Many Requests si aucune instance n'est disponible d'ici là.

Pour en savoir plus sur les bonnes pratiques concernant l'utilisation des paramètres du nombre maximal d'instances, consultez les bonnes pratiques pour définir le nombre maximal d'instances.

Définir le délai avant expiration et l'allocation de mémoire

Dans certains cas, vos fonctions peuvent avoir des exigences particulières concernant une longue valeur de délai avant expiration ou une grande allocation de mémoire. Vous pouvez définir ces valeurs dans la console Google Cloud ou dans le code source de la fonction (Firebase uniquement).

Pour définir l'allocation de mémoire et le délai avant expiration dans le code source des fonctions, utilisez les options globales pour la mémoire et les secondes de délai avant expiration afin de personnaliser la machine virtuelle exécutant vos fonctions. Par exemple, cette fonction Cloud Storage utilise 1 Gio de mémoire et expire au bout de 300 secondes :

exports.convertLargeFile = onObjectFinalized({
  timeoutSeconds: 300,
  memory: "1GiB",
}, (event) => {
  // Do some complicated things that take a lot of memory and time
});

@storage_fn.on_object_finalized(timeout_sec=300, memory=options.MemoryOption.GB_1)
def convert_large_file(event: storage_fn.CloudEvent):
# Do some complicated things that take a lot of memory and time.

La valeur maximale du délai avant expiration en secondes est de 540, soit neuf minutes.

Pour définir l'allocation de mémoire et le délai avant expiration dans la console Google Cloud :

1. Dans la console Google Cloud, sélectionnez Cloud Functions for Firebase dans le menu de gauche.
2. Sélectionnez une fonction en cliquant sur son nom dans la liste des fonctions.
3. Cliquez sur l'icône Modifier dans le menu du haut.
4. Sélectionnez une allocation de mémoire dans le menu déroulant Mémoire allouée.
5. Cliquez sur Plus pour afficher les options avancées, puis saisissez un nombre de secondes dans la zone de texte Délai avant expiration.
6. Cliquez sur Enregistrer pour mettre à jour la fonction.

Remplacer les paramètres par défaut du processeur

Jusqu'à 2 Go de mémoire allouée : chaque fonction dans Cloud Functions for Firebase (2e génération) est définie par défaut sur un processeur, puis passe à deux processeurs pour 4 et 8 Go. Notez que ce comportement est très différent de celui par défaut de la 1re génération, ce qui peut entraîner des coûts légèrement plus élevés pour les fonctions à faible mémoire, comme indiqué dans le tableau suivant :

Si vous préférez le comportement de 1re génération pour vos fonctions de 2e génération, définissez les valeurs par défaut de 1re génération comme option globale :

// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });

# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")

Pour les fonctions gourmandes en ressources processeur, la 2e génération offre la possibilité de configurer des processeurs supplémentaires. Vous pouvez augmenter la puissance du processeur pour chaque fonction, comme indiqué ci-dessous :

// Boost CPU in a function:
export const analyzeImage = onObjectFinalized({ cpu: 2 }, (event) => {
  // computer vision goes here
});

# Boost CPU in a function:
@storage_fn.on_object_finalized(cpu=2)
def analyze_image(event: storage_fn.CloudEvent):
# computer vision goes here