Funktionen verwalten (1. Generation)

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

Funktionen bereitstellen

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

firebase deploy --only functions

Standardmäßig werden mit der Firebase CLI alle Funktionen in Ihrer Quelle gleichzeitig bereitgestellt. Wenn Ihr Projekt mehr als fünf 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 vermeiden, dass Sie auf Bereitstellungskontingente stoßen. Beispiel:

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

Wenn Sie eine große Anzahl von Funktionen bereitstellen, überschreiten Sie möglicherweise das Standardkontingent und erhalten HTTP-Fehlermeldungen vom Typ 429 oder 500. Um dieses Problem zu beheben, stellen Sie Funktionen in Gruppen von maximal 10 bereit.

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

Standardmäßig sucht die Firebase CLI im functions/ Ordner nach dem Quellcode. Sie können Funktionen auch in Codebases oder mehreren Dateisätzen organisieren.

Funktionen löschen

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

  • Explizit in der Firebase CLI mit functions:delete
  • Explizit in der Google Cloud Konsole.
  • 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.

Die explizite Funktionslöschung in der Firebase CLI unterstützt mehrere Argumente sowie Funktions gruppen 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 in allen Regionen mit dem angegebenen Namen übereinstimmen: 

    firebase functions:delete FUNCTION-1_NAME

  • Löscht eine angegebene 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

  • Umgeht die Bestätigungsaufforderung: 

    firebase functions:delete FUNCTION-1_NAME --force

Bei der impliziten Funktionslöschung 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 den Namen, die Regionen oder den Trigger für Funktionen ändern, die Produktions-Traffic verarbeiten, folgen Sie der Anleitung in diesem Abschnitt, um den Verlust von Ereignissen während der Änderung zu vermeiden. Bevor Sie diese Schritte ausführen, prüfen Sie, 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 eine Node.js-Funktion namens webhook in webhookNew ändern möchten, überarbeiten Sie den Code so:

// before
const functions = require('firebase-functions/v1');

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

// after
const functions = require('firebase-functions/v1');

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

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

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

# Wait until deployment is done; now both webhookNew and webhook 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 vermeiden, indem Sie diese 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 Regionensätzen ausgeführt.
  3. Löschen Sie die vorherige Funktion.

Wenn Sie beispielsweise eine Funktion namens webhook haben, die sich derzeit in der Standardregion für Funktionen us-central1 befindet, und Sie sie zu asia-northeast1 migrieren möchten, müssen Sie zuerst den Quellcode ändern, um die Funktion umzubenennen und die Region zu überarbeiten.

// before
const functions = require('firebase-functions/v1');

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

// after
const functions = require('firebase-functions/v1');

exports.webhookAsia = functions
    .region('asia-northeast1')
    .https.onRequest((req, res) => {
            res.send("Hello");
    });

Stellen Sie dann die Funktion mit folgendem Befehl bereit:

firebase deploy --only functions:webhookAsia

Jetzt werden zwei identische Funktionen ausgeführt: webhook in us-central1, und webhookAsia in asia-northeast1.

Löschen Sie dann webhook:

firebase functions:delete webhook

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

Triggertyp einer Funktion ändern

Im Laufe der Zeit müssen Sie möglicherweise den Triggertyp einer Funktion für Ihre Cloud Functions for Firebase Bereitstellung aus verschiedenen Gründen ä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 einfach den Quellcode ändern und firebase deploy ausführen. Um Fehler zu vermeiden, ändern Sie den Triggertyp einer Funktion so:

  1. Ändern Sie den Quellcode, um eine neue Funktion mit dem gewünschten Triggertyp einzufügen.
  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 aus der Produktion mit der Firebase CLI.

Wenn Sie beispielsweise eine Node.js-Funktion namens objectChanged mit dem Legacy-Ereignistyp onChange haben und sie in onFinalize ändern möchten, benennen Sie zuerst die Funktion um und bearbeiten Sie sie so, dass sie den Ereignistyp onFinalize hat.

// before
const functions = require('firebase-functions/v1');

exports.objectChanged = functions.storage.object().onChange((object) => {
    return console.log('File name is: ', object.name);
});

// after
const functions = require('firebase-functions/v1');

exports.objectFinalized = functions.storage.object().onFinalize((object) => {
    return console.log('File name is: ', object.name);
});

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 objectFinalized
firebase deploy --only functions:objectFinalized

# Wait until deployment is done; now both objectChanged and objectFinalized are running

# Delete objectChanged
firebase functions:delete objectChanged

Laufzeitoptionen festlegen

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

Als Best Practice sollten diese Optionen (mit Ausnahme der Node.js-Version) in einem Konfigurationsobjekt im Funktionscode festgelegt werden. Dieses RuntimeOptions Objekt ist die Quelle der Wahrheit für die Laufzeitoptionen Ihrer Funktion und überschreibt Optionen, die mit einer anderen Methode festgelegt wurden (z. B. in der Google Cloud Console oder gcloud CLI).

Wenn Sie Laufzeitoptionen manuell über die Google Cloud Console oder gcloud CLI festlegen und Sie 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 zusammen. Dabei gilt die folgende Priorität:

  1. Option ist im Funktionscode festgelegt: Externe Änderungen überschreiben.
  2. Option ist im Funktionscode auf RESET_VALUE gesetzt: Externe Änderungen mit dem Standardwert überschreiben.
  3. Option ist nicht im Funktionscode festgelegt, aber in der aktuell bereitgestellten Funktion: Verwenden Sie die in der bereitgestellten Funktion angegebene Option.

Die Option preserveExternalChanges: true wird für die meisten Szenarien nicht empfohlen , da Ihr Code dann nicht mehr die vollständige Quelle der Wahrheit für die Laufzeitoptionen Ihrer Funktionen ist. Wenn Sie sie verwenden, prüfen Sie die Google Cloud Console oder verwenden Sie die gcloud CLI, um die vollständige Konfiguration einer Funktion aufzurufen.

Node.js-Version festlegen

Mit dem Firebase SDK for Cloud Functions können Sie eine Node.js-Laufzeit auswählen. Sie können alle Funktionen in einem Projekt ausschließlich in der Laufzeitumgebung ausführen, die einer dieser unterstützten Node.js-Versionen entspricht:

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

Im Supportzeitplan finden Sie wichtige Informationen zur laufenden Unterstützung für diese Node.js-Versionen.

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 Verzeichnis functions/ erstellt wurde. Wenn Sie beispielsweise nur Version 20 verwenden möchten, bearbeiten Sie diese Zeile in package.json:

  "engines": {"node": "22"}

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

  {
    "functions": {
      "runtime": "nodejs22"
    }
  }

Die CLI verwendet den in firebase.json festgelegten Wert vor allen Werten oder Bereichen, die Sie separat in package.json festgelegt haben.

Node.js-Laufzeit aktualisieren

So aktualisieren Sie Ihre Node.js-Laufzeit:

  1. Prüfen Sie, ob Ihr Projekt das Blaze-Preismodell hat.
  2. Prüfen Sie, ob Sie die Firebase CLI-Version 11.18.0 oder höher verwenden.
  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 16 auf Version 18 durchführen, sollte der Eintrag so aussehen: "engines": {"node": "18"}
  4. Optional können Sie Ihre Änderungen mit der 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), aber aktuelle Node.js-Versionen unterstützen auch ECMAScript-Module (ESM). Cloud Functions unterstützt beide.

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

const functions = require("firebase-functions/v1");

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

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

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

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

import functions from "firebase-functions/v1";

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

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

Skalierungsverhalten steuern

Standardmäßig skaliert Cloud Functions for Firebase die Anzahl der ausgeführten Instanzen basierend auf der Anzahl der eingehenden Anfragen. Bei geringerem Traffic kann die Anzahl der Instanzen auf null reduziert werden. Wenn Ihre App 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 Höchstanzahl 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 Sicherungsdienst zu begrenzen, z. B. zu einer Datenbank.

Anzahl der Kaltstarts reduzieren

Verwenden Sie die runWith Methode, um die Mindestanzahl von Instanzen für eine Funktion im Quellcode festzulegen. Diese Methode akzeptiert ein JSON-Objekt, das der RuntimeOptions Schnittstelle entspricht und den Wert für minInstances definiert. Mit dieser Funktion werden beispielsweise mindestens fünf Instanzen einsatzbereit gehalten:

exports.getAutocompleteResponse = functions
    .runWith({
      // Keep 5 instances warm for this latency-critical function
      minInstances: 5,
    })
    .https.onCall((data, context) => {
      // Autocomplete a user's search term
    });
index.js

Beachten Sie beim Festlegen eines Werts für minInstances Folgendes:

  • Wenn Cloud Functions for Firebase Ihre App über die Einstellung minInstances hinaus skaliert, tritt für jede Instanz über diesem Schwellenwert ein Kaltstart auf.
  • Kaltstarts haben die größten Auswirkungen auf Apps mit unregelmäßigem Traffic. Wenn Ihre App unregelmäßigen Traffic hat und Sie einen minInstances-Wert festlegen, der hoch genug ist, um Kaltstarts bei jeder Traffic-Zunahme zu reduzieren, wird die Latenz deutlich reduziert. Bei Apps mit konstantem Traffic haben Kaltstarts wahrscheinlich keine großen Auswirkungen auf die Leistung.

  • Das Festlegen von Mindestinstanzen kann für Produktionsumgebungen sinnvoll sein, sollte aber in Testumgebungen in der Regel vermieden werden. Wenn Sie in Ihrem Testprojekt auf null skalieren, aber trotzdem Kaltstarts in Ihrem Produktionsprojekt reduzieren möchten, können Sie minInstances basierend auf der Umgebungsvariable FIREBASE_CONFIG festlegen:

    // Get Firebase project id from `FIREBASE_CONFIG` environment variable
const envProjectId = JSON.parse(process.env.FIREBASE_CONFIG).projectId;

exports.renderProfilePage = functions
    .runWith({
      // Keep 5 instances warm for this latency-critical function
      // in production only. Default to 0 for test projects.
      minInstances: envProjectId === "my-production-project" ? 5 : 0,
    })
    .https.onRequest((req, res) => {
      // render some html
    });
    index.js

Maximale Anzahl von Instanzen für eine Funktion begrenzen

Verwenden Sie die runWith Methode, um die maximale Anzahl von Instanzen im Funktionsquellcode festzulegen. Diese Methode akzeptiert ein JSON-Objekt, das der RuntimeOptions Schnittstelle entspricht und Werte für maxInstances definiert. Mit dieser Funktion wird beispielsweise ein Limit von 100 Instanzen festgelegt, um eine hypothetische Legacy-Datenbank nicht zu überlasten:

exports.mirrorOrdersToLegacyDatabase = functions
    .runWith({
      // Legacy database only supports 100 simultaneous connections
      maxInstances: 100,
    })
    .firestore.document("orders/{orderId}")
    .onWrite((change, context) => {
      // Connect to legacy database
    });
index.js

Wenn eine HTTP-Funktion auf das Limit maxInstances skaliert 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 von Einstellungen für die maximale Anzahl von Instanzen finden Sie unter Best Practices für die Verwendung von maxInstances.

Dienstkonto festlegen

Das Standarddienstkonto für Funktionen der 1. Generation, PROJECT_ID@appspot.gserviceaccount.com ( _App Engine-Standarddienstkonto_ ), hat eine breite Palette von Berechtigungen, mit denen Sie mit anderen Firebase- und Google Cloud-Diensten interagieren können.

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 der Methode .runWith() zuweisen. Diese Methode verwendet ein Objekt mit Konfigurationsoptionen, einschließlich der Eigenschaft serviceAccount.

const functions = require("firebase-functions/v1");

exports.helloWorld = functions
    .runWith({
        // 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"
    })
    .https.onRequest((request, response) => {
        response.send("Hello from Firebase!");
    });

Zeitlimit und Arbeitsspeicherzuweisung festlegen

In einigen Fällen haben Ihre Funktionen möglicherweise spezielle Anforderungen an einen langen Zeitlimitwert oder eine große Speicherzuweisung. Sie können diese Werte entweder in der Google Cloud Console oder im Funktionsquellcode festlegen (nur Firebase).

Verwenden Sie den runWith Parameter, der im Firebase SDK für Cloud Functions 2.0.0 eingeführt wurde, um die Arbeitsspeicherzuweisung und das Zeitlimit im Funktionsquellcode festzulegen. Diese Laufzeitoption akzeptiert ein JSON-Objekt, das der RuntimeOptions Schnittstelle entspricht und Werte für timeoutSeconds und memory definiert. Diese Speicherfunktion verwendet beispielsweise 1 GB Arbeitsspeicher und hat ein Zeitlimit von 300 Sekunden:

exports.convertLargeFile = functions
    .runWith({
      // Ensure the function has enough memory and time
      // to process large files
      timeoutSeconds: 300,
      memory: "1GB",
    })
    .storage.object()
    .onFinalize((object) => {
      // Do some complicated things that take a lot of memory and time
    });
index.js

Der Höchstwert für timeoutSeconds ist 540 oder 9 Minuten. Die einer Funktion zugewiesene Speichermenge entspricht der für die Funktion zugewiesenen CPU, wie in dieser Liste der gültigen Werte für memory beschrieben:

  • 128MB – 200 MHz
  • 256MB – 400 MHz
  • 512MB – 800 MHz
  • 1GB – 1,4 GHz
  • 2GB – 2,4 GHz
  • 4GB – 4,8 GHz
  • 8GB – 4,8 GHz

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

  1. Wählen Sie in der Google Cloud Konsole im linken Menü Cloud Functions aus.
  2. Wählen Sie eine Funktion aus, indem Sie in der Liste der Funktionen 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.