Funktionen verwalten

Sie können Funktionen mit Firebase-Befehlen oder durch Festlegen von Laufzeitoptionen im Quellcode Ihrer Funktionen bereitstellen, löschen und ändern.

Funktionen bereitstellen

Führen Sie den folgenden Firebase-CLI-Befehl aus, um Funktionen bereitzustellen:

firebase deploy --only functions

Standardmäßig stellt die Firebase-Befehlszeile alle Funktionen in Ihrer Quelle gleichzeitig bereit. Wenn Ihr Projekt mehr als 5 Funktionen enthält, empfehlen wir, das Flag --only mit bestimmten Funktionsnamen zu verwenden, um nur die Funktionen bereitzustellen, die Sie bearbeitet haben. Wenn Sie bestimmte Funktionen auf diese Weise bereitstellen, wird der Bereitstellungsprozess beschleunigt und Sie können Bereitstellungskontingente vermeiden. Beispiel:

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

Wenn Sie eine große Anzahl von Funktionen bereitstellen, kann es sein, dass Sie das Standardkontingent überschreiten und die HTTP-Fehlermeldung 429 oder 500 erhalten. Stellen Sie Funktionen in Gruppen von maximal 10 Funktionen bereit, um dieses Problem zu beheben.

Eine vollständige Liste der verfügbaren Befehle finden Sie in der Firebase-CLI-Referenz.

Standardmäßig sucht die Firebase-Befehlszeile im Ordner functions/ nach dem Quellcode. Alternativ können Sie Funktionen in Codebasen oder mehreren Dateisätzen organisieren.

Bereitstellungsartefakte bereinigen

Im Rahmen der Funktionsbereitstellung werden Container-Images generiert und in Artifact Registry gespeichert. Diese Images sind für die Ausführung Ihrer bereitgestellten Funktionen nicht erforderlich. Cloud Functions ruft bei der ersten Bereitstellung eine Kopie des Images ab und behält sie bei. Die gespeicherten Artefakte sind jedoch nicht erforderlich, damit die Funktion zur Laufzeit funktioniert.

Diese Container-Images sind zwar oft klein, können sich aber im Laufe der Zeit ansammeln und zu Ihren Speicherkosten beitragen. Möglicherweise möchten Sie sie für einen bestimmten Zeitraum aufbewahren, wenn Sie die erstellten Artefakte prüfen oder Container-Scans auf Sicherheitslücken ausführen möchten.

Um die Speicherkosten zu verwalten, können Sie mit der Firebase-Befehlszeile ab Version 14.0.0 eine Artifact Registry-Bereinigungsrichtlinie für Repositories konfigurieren, in denen Bereitstellungsartefakte nach jeder Funktionsbereitstellung gespeichert werden.

Sie können eine Bereinigungsrichtlinie manuell mit dem Befehl functions:artifacts:setpolicy einrichten oder bearbeiten:

firebase functions:artifacts:setpolicy

Standardmäßig wird mit diesem Befehl Artifact Registry so konfiguriert, dass Container-Images, die älter als 1 Tag sind, automatisch gelöscht werden. Dies bietet ein angemessenes Gleichgewicht zwischen der Minimierung der Speicherkosten und der Möglichkeit, aktuelle Builds zu prüfen.

Sie können die Aufbewahrungsdauer mit der Option --days anpassen:

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

Wenn Sie Funktionen in mehreren Regionen bereitstellen, können Sie mit der Option --location eine Bereinigungsrichtlinie für einen bestimmten Standort einrichten:

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

Artefaktbereinigung deaktivieren

Wenn Sie die Image-Bereinigung lieber manuell verwalten möchten oder keine Images gelöscht werden sollen, können Sie die Bereinigungsrichtlinien vollständig deaktivieren:

$ firebase functions:artifacts:setpolicy --none

Mit diesem Befehl werden alle vorhandenen Bereinigungsrichtlinien entfernt, die von der Firebase-Befehlszeile eingerichtet wurden. Außerdem wird verhindert, dass Firebase nach Funktionsbereitstellungen eine Bereinigungsrichtlinie einrichtet.

Funktionen löschen

Sie können zuvor bereitgestellte Funktionen auf folgende Weise löschen:

• explizit in der Firebase-Befehlszeile mit functions:delete

• explizit in der Google Cloud Console.

• implizit, indem Sie die Funktion vor der Bereitstellung aus der Quelle entfernen.

Bei allen Löschvorgängen werden Sie aufgefordert, den Vorgang zu bestätigen, bevor die Funktion aus der Produktion entfernt wird.

Das explizite Löschen von Funktionen in der Firebase-Befehlszeile unterstützt mehrere Argumente sowie Funktionsgruppen und ermöglicht es Ihnen, eine Funktion anzugeben, die in einer bestimmten Region ausgeführt wird. Außerdem können Sie die Bestätigungsaufforderung überschreiben.

• Löscht alle Funktionen, die dem angegebenen Namen in allen Regionen entsprechen:

  firebase functions:delete FUNCTION-1_NAME

• Löscht eine bestimmte Funktion, die in einer nicht standardmäßigen Region ausgeführt wird:

  firebase functions:delete FUNCTION-1_NAME --region REGION_NAME

• Löscht mehrere Funktionen:

  firebase functions:delete FUNCTION-1_NAME FUNCTION-2_NAME

• Löscht eine angegebene Funktionsgruppe:

  firebase functions:delete GROUP_NAME

• Überspringt die Bestätigungsaufforderung:

  firebase functions:delete FUNCTION-1_NAME --force

Wenn Sie eine Funktion explizit mit der Firebase-Befehlszeile oder der Google Cloud Console löschen, müssen Sie die Funktion auch aus dem Quellcode Ihrer Funktionen löschen. Wenn Sie die Funktion nicht aus Ihren Quelldateien entfernen, wird sie bei nachfolgenden Bereitstellungen mit firebase deploy wieder in der Produktion bereitgestellt.

Beim impliziten Löschen von Funktionen parst firebase deploy Ihre Quelle und entfernt alle Funktionen aus der Produktion, die aus der Datei entfernt wurden.

Name, Region oder Trigger einer Funktion ändern

Wenn Sie die Regionen oder Trigger für Funktionen umbenennen oder ändern, die Produktions-Traffic verarbeiten, folgen Sie den Schritten in diesem Abschnitt, um zu vermeiden, dass während der Änderung Ereignisse verloren gehen. Bevor Sie diese Schritte ausführen, sollten Sie prüfen, ob Ihre Funktion idempotent ist, da während der Änderung sowohl die neue als auch die alte Version Ihrer Funktion gleichzeitig ausgeführt werden.

Funktion umbenennen

Wenn Sie eine Funktion umbenennen möchten, erstellen Sie eine neue umbenannte Version der Funktion in Ihrer Quelle und führen Sie dann zwei separate Bereitstellungsbefehle aus. Mit dem ersten Befehl wird die neu benannte Funktion bereitgestellt und mit dem zweiten Befehl wird die zuvor bereitgestellte Version entfernt. Wenn Sie beispielsweise einen HTTP-getriggerten Webhook umbenennen möchten, ändern Sie den Code so:

// 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!")

Führen Sie dann die folgenden Befehle aus, um die neue Funktion bereitzustellen:

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

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

# Delete webhook
firebase functions:delete webhook

Region oder Regionen einer Funktion ändern

Wenn Sie die angegebenen Regionen für eine Funktion ändern, die Produktions-Traffic verarbeitet, können Sie Ereignisverluste verhindern, indem Sie die folgenden Schritte in der angegebenen Reihenfolge ausführen:

1. Benennen Sie die Funktion um und ändern Sie die Region oder Regionen nach Bedarf.
2. Stellen Sie die umbenannte Funktion bereit. Dadurch wird derselbe Code vorübergehend in beiden Regionen ausgeführt.
3. Löschen Sie die vorherige Funktion.

Wenn Sie beispielsweise eine durch Cloud Firestore ausgelöste Funktion haben, die derzeit in us-central1 bereitgestellt ist, und Sie sie zu asia-northeast1 migrieren möchten, müssen Sie zuerst Ihren Quellcode ändern, um die Funktion umzubenennen und die Region zu überarbeiten.

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

Führen Sie dann die Bereitstellung aus:

firebase deploy --only functions:firestoreTriggerAsia

Jetzt werden zwei identische Funktionen ausgeführt: firestoreTrigger wird in us-central1 und firestoreTriggerAsia in asia-northeast1 ausgeführt.

Löschen Sie dann firestoreTrigger:

firebase functions:delete firestoreTrigger

Jetzt gibt es nur noch eine Funktion – firestoreTriggerAsia, die in asia-northeast1 ausgeführt wird.

Triggertyp einer Funktion ändern

Wenn Sie Ihre Cloud Functions for Firebase-Bereitstellung im Laufe der Zeit weiterentwickeln, müssen Sie möglicherweise aus verschiedenen Gründen den Triggertyp einer Funktion ändern. Beispielsweise möchten Sie möglicherweise von einem Typ von Firebase Realtime Database- oder Cloud Firestore-Ereignis zu einem anderen Typ wechseln.

Es ist nicht möglich, den Ereignistyp einer Funktion zu ändern, indem Sie nur den Quellcode ändern und firebase deploy ausführen. So ändern Sie den Triggertyp einer Funktion, um Fehler zu vermeiden:

1. Ändern Sie den Quellcode so, dass er eine neue Funktion mit dem gewünschten Triggertyp enthält.
2. Stellen Sie die Funktion bereit. Dadurch werden vorübergehend sowohl die alte als auch die neue Funktion ausgeführt.
3. Löschen Sie die alte Funktion explizit mit der Firebase-Befehlszeile aus der Produktion.

Wenn Sie beispielsweise eine Funktion hatten, die beim Löschen eines Objekts ausgelöst wurde, dann aber die Objektversionsverwaltung aktiviert haben und stattdessen das Archivierungsereignis abonnieren möchten, benennen Sie die Funktion zuerst um und bearbeiten Sie sie, um den neuen Triggertyp zu erhalten.

// 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):
  # ...

Führen Sie dann die folgenden Befehle aus, um zuerst die neue Funktion zu erstellen, bevor Sie die alte Funktion löschen:

# 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

Laufzeitoptionen festlegen

Mit Cloud Functions for Firebase können Sie Laufzeitoptionen wie die Node.js-Laufzeitversion und das Zeitlimit pro Funktion, die Arbeitsspeicherzuweisung und die minimale/maximale Anzahl von Funktionsinstanzen auswählen.

Als Best Practice sollten diese Optionen (mit Ausnahme der Node.js-Version) für ein Konfigurationsobjekt im Funktionscode festgelegt werden. Dieses RuntimeOptions-Objekt ist die „Source of Truth“ für die Laufzeitoptionen Ihrer Funktion und überschreibt Optionen, die mit einer anderen Methode festgelegt wurden (z. B. mit der Google Cloud-Konsole oder gcloud CLI).

Wenn Sie in Ihrem Entwicklungs-Workflow Laufzeitoptionen manuell über die Google Cloud-Konsole oder gcloud CLI festlegen und nicht möchten, dass diese Werte bei jeder Bereitstellung überschrieben werden, setzen Sie die Option preserveExternalChanges auf true. Wenn diese Option auf true gesetzt ist, führt Firebase die in Ihrem Code festgelegten Laufzeitoptionen mit den Einstellungen der aktuell bereitgestellten Version Ihrer Funktion mit der folgenden Priorität zusammen:

1. Option ist im Funktionscode festgelegt: Externe Änderungen überschreiben.
2. Die Option ist im Funktionscode auf RESET_VALUE festgelegt: Externe Änderungen werden mit dem Standardwert überschrieben.
3. Die Option ist nicht im Funktionscode, aber in der aktuell bereitgestellten Funktion festgelegt: Die in der bereitgestellten Funktion angegebene Option wird verwendet.

Die Verwendung der Option preserveExternalChanges: true wird für die meisten Szenarien nicht empfohlen, da Ihr Code dann nicht mehr die vollständige „Source of Truth“ für Laufzeitoptionen für Ihre Funktionen ist. Wenn Sie sie verwenden, rufen Sie die Google Cloud-Konsole auf oder verwenden Sie die gcloud CLI, um die vollständige Konfiguration einer Funktion aufzurufen.

Node.js-Version festlegen

Das Firebase SDK für Cloud Functions ermöglicht die Auswahl einer Node.js-Laufzeit. Sie können alle Funktionen in einem Projekt ausschließlich in der Laufzeitumgebung ausführen, die einer der folgenden unterstützten Node.js-Versionen entspricht:

• Node.js 22
• Node.js 20
• Node.js 18 (eingestellt)

Die Node.js-Versionen 14 und 16 wurden Anfang 2025 eingestellt. Die Bereitstellung mit diesen Versionen ist deaktiviert. Wichtige Informationen zum laufenden Support für diese Node.js-Versionen finden Sie im Supportzeitplan.

So legen Sie die Node.js-Version fest:

Sie können die Version im Feld engines in der Datei package.json festlegen, die während der Initialisierung in Ihrem functions/-Verzeichnis erstellt wurde. Wenn Sie beispielsweise nur Version 20 verwenden möchten, bearbeiten Sie diese Zeile in package.json:

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

Wenn Sie den Yarn-Paketmanager verwenden oder andere spezifische Anforderungen für das Feld engines haben, können Sie die Laufzeit für das Firebase SDK für Cloud Functions stattdessen in firebase.json festlegen:

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

Die Befehlszeile verwendet den in firebase.json festgelegten Wert vor allen Werten oder Bereichen, die Sie separat in package.json festlegen.

Node.js-Laufzeit aktualisieren

So aktualisieren Sie Ihre Node.js-Laufzeit:

1. Achten Sie darauf, dass für Ihr Projekt das Blaze-Preismodell gilt.
2. Sie benötigen die Firebase-Befehlszeile ab Version 11.18.0.
3. Ändern Sie den Wert engines in der Datei package.json, die während der Initialisierung in Ihrem Verzeichnis functions/ erstellt wurde. Wenn Sie beispielsweise ein Upgrade von Version 18 auf Version 20 durchführen, sollte der Eintrag so aussehen: "engines": {"node": "20"}
4. Optional können Sie Ihre Änderungen mit dem Firebase Local Emulator Suite testen.
5. Stellen Sie alle Funktionen noch einmal bereit.

Node.js-Modulsystem auswählen

Das Standardmodulsystem in Node.js ist CommonJS (CJS). Aktuelle Node.js-Versionen unterstützen jedoch auch ECMAScript-Module (ESM). Cloud Functions unterstützt beides.

Standardmäßig verwenden Ihre Funktionen CommonJS. Das bedeutet, dass Importe und Exporte so aussehen:

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

exports.helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));

Wenn Sie stattdessen ESM verwenden möchten, legen Sie das Feld "type": "module" in der Datei package.json fest:

  {
   ...
   "type": "module",
   ...
  }

Verwenden Sie nach dem Festlegen die ESM-Syntax import und export:

import {onRequest} from "firebase-functions/https";

export const helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));

Beide Modulsysteme werden vollständig unterstützt. Sie können die Option auswählen, die am besten zu Ihrem Projekt passt. Weitere Informationen finden Sie in der Node.js-Dokumentation zu Modulen.

Python-Version festlegen

Firebase SDK für Cloud Functions-Versionen 12.0.0 und höher ermöglichen die Auswahl der Python-Laufzeit. Legen Sie die Laufzeitversion in firebase.json so fest:

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

Skalierungsverhalten steuern

Standardmäßig skaliert Cloud Functions for Firebase die Anzahl der ausgeführten Instanzen basierend auf der Anzahl der eingehenden Anfragen. Bei geringem Traffic kann die Anzahl der Instanzen auf null herunterskaliert werden. Wenn Ihre Anwendung jedoch eine geringere Latenz erfordert und Sie die Anzahl von Kaltstarts begrenzen möchten, können Sie dieses Standardverhalten ändern. Dazu geben Sie eine Mindestanzahl von Containerinstanzen an, die einsatzbereit sind und Anfragen bedienen können.

Ebenso können Sie eine maximale Anzahl festlegen, um die Skalierung von Instanzen als Reaktion auf eingehende Anfragen zu begrenzen. Verwenden Sie diese Einstellung, um Ihre Kosten zu kontrollieren oder die Anzahl der Verbindungen zu einem unterstützenden Dienst zu begrenzen, z. B. zu einer Datenbank.

Wenn Sie diese Einstellungen zusammen mit der instanzspezifischen Einstellung für die Nebenläufigkeit (neu in der 2. Generation) verwenden, können Sie das Skalierungsverhalten für Ihre Funktionen steuern und optimieren. Die Art Ihrer Anwendung und Funktion bestimmt, welche Einstellungen am kostengünstigsten sind und die beste Leistung erzielen.

Für einige Anwendungen mit geringem Traffic ist eine niedrigere CPU-Option ohne Multi-Nebenläufigkeit optimal. Bei anderen, bei denen Kaltstarts ein kritisches Problem darstellen, bedeutet das Festlegen einer hohen Gleichzeitigkeit und einer Mindestanzahl von Instanzen, dass eine Reihe von Instanzen immer aktiv gehalten wird, um große Trafficspitzen zu bewältigen.

Bei kleineren Anwendungen mit sehr wenig Traffic bedeutet die Festlegung einer niedrigen maximalen Anzahl von Instanzen mit hoher Gleichzeitigkeit, dass die Anwendung Traffic-Spitzen bewältigen kann, ohne dass übermäßige Kosten entstehen. Wenn die maximale Anzahl von Instanzen jedoch zu niedrig festgelegt ist, werden Anfragen möglicherweise verworfen, wenn die Obergrenze erreicht ist.

Gleichzeitige Anfragen zulassen

In Cloud Functions for Firebase (1. Generation) konnte jede Instanz jeweils nur eine Anfrage verarbeiten. Das Skalierungsverhalten wurde daher nur mit den Einstellungen für die Mindest- und Höchstanzahl von Instanzen festgelegt. In Cloud Functions for Firebase (2. Generation) können Sie nicht nur die Anzahl der Instanzen steuern, sondern mit der Option concurrency auch die Anzahl der Anfragen, die jede Instanz gleichzeitig verarbeiten kann. Der Standardwert für die Nebenläufigkeit ist 80, Sie können ihn aber auf eine beliebige Ganzzahl zwischen 1 und 1.000 festlegen.

Funktionen mit höheren Nebenläufigkeitseinstellungen können Trafficspitzen ohne Kaltstart abfangen, da jede Instanz wahrscheinlich etwas Spielraum hat. Wenn eine Instanz für die Verarbeitung von bis zu 50 gleichzeitigen Anfragen konfiguriert ist, aber derzeit nur 25 Anfragen verarbeitet, kann sie eine Spitze von 25 zusätzlichen Anfragen verarbeiten, ohne dass eine neue Instanz kalt gestartet werden muss. Bei einer Nebenläufigkeitseinstellung von nur 1 könnte dieser Anstieg der Anfragen dagegen zu 25 Kaltstarts führen.

Dieses vereinfachte Szenario zeigt die potenziellen Effizienzgewinne der Nebenläufigkeit. In der Praxis ist das Skalierungsverhalten zur Optimierung der Effizienz und zur Reduzierung von Kaltstarts mit Gleichzeitigkeit komplexer. Die Nebenläufigkeit in Cloud Functions for Firebase der 2. Generation wird von Cloud Run unterstützt und folgt den Regeln von Cloud Run für das Autoscaling von Containerinstanzen.

Beachten Sie beim Experimentieren mit höheren Nebenläufigkeitseinstellungen in Cloud Functions for Firebase (2. Generation) Folgendes:

• Höhere Nebenläufigkeitseinstellungen erfordern möglicherweise mehr CPU und RAM für eine optimale Leistung, bis ein praktisches Limit erreicht ist. Einer Funktion, die beispielsweise eine intensive Bild- oder Videoverarbeitung durchführt, fehlen möglicherweise die Ressourcen, um 1.000 gleichzeitige Anfragen zu verarbeiten, selbst wenn die CPU- und RAM-Einstellungen maximiert sind.
• Da Cloud Functions for Firebase (2. Generation) auf Cloud Run basiert, können Sie auch die Anleitung für Google Cloud zur Optimierung der Nebenläufigkeit heranziehen.
• Testen Sie die Multikonkurrenz gründlich in einer Testumgebung, bevor Sie in der Produktion auf Multikonkurrenz umstellen.

Mindestanzahl von Instanzen einsatzbereit halten

Sie können die Mindestanzahl von Instanzen für eine Funktion im Quellcode festlegen. Mit dieser Funktion wird beispielsweise eine Mindestanzahl von 5 Instanzen festgelegt, die einsatzbereit gehalten werden sollen:

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:

Beachten Sie beim Festlegen eines Mindestwerts für Instanzen Folgendes:

• Wenn Cloud Functions for Firebase Ihre Anwendung über Ihre Einstellung hinaus skaliert, kommt es für jede Instanz über diesem Schwellenwert zu einem Kaltstart.
• Kaltstarts haben die schwerwiegendsten Auswirkungen auf Anwendungen mit unregelmäßigem Traffic. Wenn Ihre Anwendung unregelmäßigen Traffic hat und Sie einen Wert festlegen, der hoch genug ist, um Kaltstarts bei jedem Traffic-Anstieg zu reduzieren, wird die Latenz erheblich reduziert. Bei Anwendungen mit konstantem Traffic ist es unwahrscheinlich, dass Kaltstarts die Leistung stark beeinträchtigen.

• Das Festlegen einer Mindestanzahl von Instanzen kann für Produktionsumgebungen sinnvoll sein, sollte aber in Testumgebungen in der Regel vermieden werden. Wenn Sie in Ihrem Testprojekt auf null skalieren, aber dennoch Kaltstarts in Ihrem Produktionsprojekt reduzieren möchten, können Sie in Ihrer parametrisierten Konfiguration einen Wert für die Mindestanzahl von Instanzen festlegen:

  Node.js

  const { onRequest } = require('firebase-functions/https');
  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 = onRequest(
    { minInstances: minInstancesConfig },
  (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.")
  

Maximale Anzahl von Instanzen für eine Funktion begrenzen

Sie können im Quellcode der Funktion einen Wert für die maximale Anzahl von Instanzen festlegen. Mit dieser Funktion wird beispielsweise ein Limit von 100 Instanzen festgelegt, um eine hypothetische Legacy-Datenbank nicht zu überlasten:

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

Wenn eine HTTP-Funktion auf das Limit für die maximale Anzahl von Instanzen hochskaliert wird, werden neue Anfragen 30 Sekunden lang in die Warteschlange gestellt und dann mit dem Antwortcode 429 Too Many Requests abgelehnt, wenn bis dahin keine Instanz verfügbar ist.

Weitere Informationen zu Best Practices für die Verwendung der Einstellungen für die maximale Anzahl von Instanzen finden Sie in diesen Best Practices für die Einstellung der maximalen Anzahl von Instanzen.

Dienstkonto festlegen

Die Standarddienstkonten für Funktionen haben umfassende Berechtigungen, damit Sie mit anderen Firebase- und Google Cloud-Diensten interagieren können:

• Funktionen der 2. Generation: PROJECT_NUMBER-compute@developer.gserviceaccount.com (mit dem Namen Compute Engine-Standarddienstkonto)
• Funktionen der 1. Generation: PROJECT_ID@appspot.gserviceaccount.com (mit dem Namen App Engine-Standarddienstkonto)

Möglicherweise möchten Sie das Standarddienstkonto überschreiben und eine Funktion auf die genau benötigten Ressourcen beschränken. Dazu können Sie ein benutzerdefiniertes Dienstkonto erstellen und es der entsprechenden Funktion mit dem Konfigurationswert serviceAccount zuweisen:

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

exports.helloWorld = onRequest(
    {
        // This function doesn't access other Firebase project resources, so it uses a limited service account.
        serviceAccount:
            "my-limited-access-sa@", // or prefer the full form: "my-limited-access-sa@my-project.iam.gserviceaccount.com"
    },
    (request, response) => {
        response.send("Hello from Firebase!");
    },
);

Wenn Sie für alle Ihre Funktionen dasselbe Dienstkonto festlegen möchten, können Sie dazu die Funktion setGlobalOptions verwenden.

Zeitlimit und Arbeitsspeicherzuweisung festlegen

In einigen Fällen gelten für Ihre Funktionen möglicherweise besondere Anforderungen für einen langen Zeitlimitwert oder eine große Speicherzuweisung. Sie können diese Werte entweder in der Google Cloud Console oder im Quellcode der Funktion (nur Firebase) festlegen. Verwenden Sie dazu Zeitüberschreitungswerte innerhalb dieser maximalen Dauer:

• HTTP- und aufrufbare Funktionen: 3.600 Sekunden (60 Minuten)
• Geplante/Aufgabenwarteschlangen-Funktionen: 1.800 Sekunden (30 Minuten)
• Andere ereignisgesteuerte Funktionen: 540 Sekunden (9 Minuten)

Wenn Sie die Arbeitsspeicherzuweisung und das Zeitlimit im Quellcode von Funktionen festlegen möchten, verwenden Sie die globalen Optionen für Arbeitsspeicher und Zeitlimit in Sekunden, um die virtuelle Maschine anzupassen, auf der Ihre Funktionen ausgeführt werden. Diese Cloud Storage-Funktion verwendet beispielsweise 1 GiB Arbeitsspeicher und hat ein Zeitlimit von 300 Sekunden:

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.

So legen Sie die Arbeitsspeicherzuweisung und das Zeitlimit in der Google Cloud Console fest:

1. Wählen Sie in der Google Cloud-Konsole im Menü auf der linken Seite Cloud Functions for Firebase aus.
2. Wählen Sie eine Funktion aus, indem Sie in der Funktionsliste auf ihren Namen klicken.
3. Klicken Sie im Menü oben auf das Symbol Bearbeiten.
4. Wählen Sie im Drop-down-Menü Zugewiesener Speicher eine Arbeitsspeicherzuweisung aus.
5. Klicken Sie auf Mehr, um die erweiterten Optionen aufzurufen, und geben Sie im Textfeld Zeitlimit eine Anzahl von Sekunden ein.
6. Klicken Sie auf Speichern, um die Funktion zu aktualisieren.

CPU-Standardeinstellungen überschreiben

Bei bis zu 2 GB zugewiesenem Arbeitsspeicher wird jede Funktion in Cloud Functions for Firebase (2. Generation) standardmäßig einer CPU zugewiesen und dann bei 4 und 8 GB auf 2 CPUs erhöht. Beachten Sie, dass sich dies erheblich vom Standardverhalten der 1. Generation unterscheidet, was zu etwas höheren Kosten für Funktionen mit wenig Arbeitsspeicher führen kann, wie in der folgenden Tabelle dargestellt:

Wenn Sie das Verhalten der 1. Generation für Ihre Funktionen der 2. Generation bevorzugen, legen Sie die Standardeinstellungen der 1. Generation als globale Option fest:

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

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

Für CPU-intensive Funktionen bietet die 2. Generation die Flexibilität, zusätzliche CPU zu konfigurieren. Sie können die CPU-Leistung für jede Funktion einzeln erhöhen:

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