Häufig gestellte Fragen zur Einstellung von Firebase Extensions

Warum wird Firebase Extensions eingestellt?

Aufgrund anstehender Änderungen und Einstellungen in unserer zugrunde liegenden Google Cloud-Infrastruktur stellen wir den verwalteten Firebase Extensions-Dienst ein.

Werden vorhandene bereitgestellte Erweiterungen nach dem 31. März 2027 nicht mehr funktionieren?

Nein. Bereits bereitgestellte Erweiterungen werden direkt auf der Standardinfrastruktur von Google Cloud (z. B. Cloud Functions, Eventarc, Cloud Run und Cloud Tasks) ausgeführt und laufen auf unbestimmte Zeit weiter.

Nach dem 31. März 2027 können Sie diese Erweiterungen jedoch nicht mehr über die Firebase-Konsole oder die CLI aktualisieren, neu konfigurieren oder deinstallieren. Außerdem können Sie Ihre vorhandenen Erweiterungskonfigurationen nicht mehr herunterladen, um die Migration zu einem Funktions-Kit zu erleichtern. Wir empfehlen dringend, die Erweiterungskonfiguration bis zum 31. März 2027 zu migrieren oder zu exportieren.

Was passiert, wenn ein Nutzer nichts unternimmt?

Wenn ein Nutzer nichts unternimmt, werden seine vorhandenen bereitgestellten Funktionen weiterhin als Standard-Assets ausgeführt. Nach dem 31. März 2027 gilt jedoch Folgendes:

1. Sie können keine Konfigurationsparameter ändern oder Umgebungsvariablen aktualisieren.
2. Sie können keine Fehlerkorrekturen, Sicherheitspatches oder Abhängigkeitsupgrades anwenden.
3. Sie können die Erweiterungskonfiguration nicht herunterladen, um ein Ersatz-Funktionskit identisch zu konfigurieren.
4. Die meisten Erweiterungen basieren derzeit auf dem alten Cloud Functions v1 SDK, das an ältere Node.js-Laufzeiten gebunden ist. Sobald diese Legacy-Laufzeiten von Google Cloud vollständig außer Betrieb genommen wurden, werden die Funktionen möglicherweise nicht mehr ausgeführt oder deaktiviert. Weitere Informationen finden Sie unter Laufzeitunterstützung.

Wird Firebase Extensions durch etwas ersetzt?

Wir haben Cloud Functions viele Funktionen hinzugefügt, damit sie Erweiterungen ersetzen können. Besonders erwähnenswert sind Funktionskits, die über npm verteilt werden können und mit denen Sie mehrere Instanzen von Funktionen bereitstellen können. Das ist ähnlich wie bei der mehrfachen Installation von Erweiterungen in einem einzelnen Projekt.

Es liegt jedoch im Ermessen jedes Erweiterungs-Publishers, ob er einen offiziellen Ersatz für das Funktions-Kit auf npm veröffentlichen möchte. Da Erweiterungen Open Source sind, kann jeder Entwickler sie forken, um mit Cloud Functions eine inoffizielle Ersatzversion zu erstellen, wenn der Publisher keinen offiziellen Ersatz anbieten möchte. Dazu kann er unsere APIs der 2. Generation im Node SDK verwenden.

Verlage und Webpublisher, die einen Ersatz vornehmen möchten, sollten der Anleitung im Migrationsleitfaden für Verlage und Webpublisher folgen.

Nutzer, die offizielle Ersatzpakete verwenden oder eigene erstellen möchten, können der Anleitung im Migrationsleitfaden für Nutzer folgen.

Was sollte ich als Erweiterungsnutzer tun?

Wenn Sie eine Erweiterung verwenden und sie nicht mehr benötigen, deinstallieren Sie sie bitte vor dem 31. März 2027.

Nach der Außerbetriebnahme werden der Button „Deinstallieren“ in der Firebase-Konsole und die entsprechenden CLI-Befehle entfernt. Sie müssen alle zugehörigen Google Cloud-Ressourcen, einschließlich der einzelnen Cloud Functions, Secret Manager-Secrets, Cloud Tasks-Warteschlangen und benutzerdefinierten IAM-Dienstkonten, manuell über die Google Cloud-Konsole löschen.

Wenn Sie Ihre installierten Erweiterungen jedoch aktiv nutzen, empfehlen wir dringend, zu Funktionskits zu migrieren. Wenn Sie auf Funktions-Kits umstellen möchten, folgen Sie der Anleitung in unserem Migrationsleitfaden für Nutzer.

Sie können die Migration zu Funktionskits auch ablehnen. In diesem Fall empfehlen wir dringend, alle Ihre Erweiterungen auf die neuesten Versionen zu aktualisieren, sie auf dem neuesten Stand zu halten und Ihre bestehenden Erweiterungskonfigurationen zu exportieren, falls Sie später migrieren möchten.

Was muss ich als Erweiterungs-Publisher tun?

Wir empfehlen Ihnen, Ihre veröffentlichten Erweiterungen zu Funktions-Kits zu migrieren, die auf npm veröffentlicht wurden. Beginnen Sie mit der Migration Ihrer Erweiterung zu Funktionen der 2. Generation. Das ist eine Voraussetzung für die Erstellung eines Funktions-Kits. Dazu müssen Sie die Logik Ihrer Erweiterung mit dem Cloud Functions v2-SDK verpacken. Wir haben das Cloud Functions v2 SDK aktualisiert und unterstützen jetzt Funktionen wie deklarative Sicherheit und Lebenszyklusereignisse. Sie können Ihren vorhandenen Erweiterungscode jetzt mit minimalen Änderungen an Ihrer primären Geschäftslogik zu einer Funktion der 2. Generation migrieren. Diese Funktionen können über ein npm-Paket veröffentlicht werden. Weitere Informationen finden Sie in unserem Migrationsleitfaden für Publisher.

Was mache ich, wenn ich weitere Fragen habe?

Nutzer mit Fragen können unseren Leitfaden zur Nutzermigration verwenden. Wenn Sie nach der Verwendung der Anleitung noch Fragen haben, wenden Sie sich an den Firebase-Support.

Verlage und Webpublisher, die Fragen zur Migration von Firebase Extensions haben, können unseren Migrationsleitfaden für Verlage und Webpublisher nutzen. Dieser Leitfaden enthält eine Anleitung dazu, wie Sie über Updates informiert bleiben und Hilfe bei der Bereitstellung einer Alternative zu Ihren veröffentlichten Erweiterungen erhalten.

Welche primären Migrationspfade sind verfügbar?

Ab September 2026 werden in Firebase offiziell zwei primäre Migrationspfade unterstützt:

1. Zu einer NPM-Shared Function („Funktionskit“) migrieren: Empfohlen für „Firestore in BigQuery streamen“ und alle anderen Funktionskits, die auf npm verfügbar sind. Die Kernlogik ist als standardmäßige NPM-Bibliothek mit dem Cloud Functions v2 SDK verpackt. Nutzer initialisieren eine Standard-Cloud Functions-Codebasis, installieren das Paket, exportieren die Funktionen neu und stellen sie unabhängig voneinander über die CLI bereit.
2. Fork and Self-Manage (Abzweigen und selbst verwalten): Empfohlen für alle Erweiterungen, für die kein Funktionskit auf npm verfügbar ist. Nutzer kopieren oder forken den Quellcode der Open-Source-Erweiterung, refaktorieren die Trigger mithilfe von KI-Migrationsfunktionen oder manuellen Anleitungen in Standardfunktionen vom Typ Firebase v2 und übernehmen die volle Verantwortung für die Codebasis und ihre laufende Wartung.

Welche Erweiterungen werden zu Funktions-Kits migriert?

Die Erweiterung Firestore in BigQuery streamen wurde zu einem Function Kit migriert, das als npm-Paket @firebase-function-kits/firestore-bigquery-export verfügbar ist.

Warum ist für die Migration ein Upgrade von Cloud Functions v1 auf v2 erforderlich?

Der Standardsupport für Cloud Functions v1 endet mit der Node.js 22-Laufzeit. Um eine „doppelte Migration“ zu vermeiden, bei der Entwickler von Firebase Extensions migrieren und dann bei der Einstellung der Legacy-Laufzeiten zu einem zweiten manuellen Refactoring gezwungen werden, Firebase empfiehlt dringend, alle migrierten Funktionen während dieser Umstellung sofort auf das v2-SDK zu aktualisieren. Für Funktionskits ist dies erforderlich.

Als Nutzer von Erweiterungen können Sie auch eigene Funktions-Kits erstellen. Folgen Sie dazu der Anleitung zur Nutzermigration.

Ändert sich die Abrechnung eines Kunden, wenn er zu selbstverwalteten Cloud Functions migriert?

Im Allgemeinen nicht. Bei bereitgestellten Erweiterungen werden Kunden bereits für die zugrunde liegenden Google Cloud-Ressourcen in Rechnung gestellt, die sie nutzen, z. B. Cloud Functions-Aufrufe, Cloud Storage oder BigQuery-Speicher und ‑Abfragen. Während des Migrationszeitraums können Kunden jedoch vorübergehend geringe zusätzliche Kosten entstehen, wenn sie sowohl die alte Firebase Extensions als auch die neu bereitgestellte Ersatzfunktion parallel ausführen, um einen sicheren Übergang zu gewährleisten.

Wie erfolgt die Abrechnung für Mandiant- oder andere spezielle Unternehmenskonten?

Diese Einstellung ist eine plattformweite Änderung, die sich auf alle Firebase- und Google Cloud-Projekte auswirkt. Die standardmäßigen Abrechnungs- und Abovereinbarungen sind davon nicht betroffen. Wenn Kunden aufgrund von Ausfallzeiten durch die Einstellung von Diensten oder komplexen Abrechnungsausnahmen SLA-Gutschriften anfordern, eskalieren Sie den Fall direkt über die normalen Abrechnungssupportkanäle.

Welches Risiko besteht für Datenverlust oder Dienstausfall während der Migration?

Bei der Umstellung verwalteter Ressourcen auf selbstverwaltete Codebases besteht ein geringes Risiko von Dienstunterbrechungen oder Ereignisverlusten.

• Unterbrechung von Triggern: Wenn alte Trigger gelöscht werden, bevor neue aktiv sind, entsteht eine Lücke, in der Ereignisse (z.B. Cloud Firestore-Dokumentvorgänge) nicht erfasst werden und dauerhaft verloren gehen. Wir empfehlen, das Ersatzkit bereitzustellen und zu validieren, bevor Sie die Erweiterung entfernen, um Datenverlust zu vermeiden.
• Berechtigungslücken: Wenn der neu bereitgestellten Codebasis die erforderlichen IAM-Berechtigungen fehlen, schlagen Vorgänge wie das Schreiben in BigQuery ohne Fehlermeldung fehl oder stürzen zur Laufzeit ab. Wir haben die deklarative Sicherheit für Funktionen hinzugefügt. Die erste Kit-Bereitstellung durch ein Konto, das Rollen abfragen und festlegen und ein Dienstkonto generieren kann, sollte dieses Problem beheben.

Wie verhindern wir Datenverlust bei der wichtigen Export-Erweiterung Cloud Firestore-zu-BigQuery?

Um einen sicheren Übergang ohne Datenverlust zu erreichen, muss der Support Nutzern raten, einen auf Überschneidungen basierenden Cutover anstelle eines auf Lücken basierenden Cutover zu verwenden. Das ist die Standardeinstellung bei der Migration zu Kits:

1. Stellen Sie das Ersatz-Funktions-Kit bereit, während die Erweiterung noch installiert ist und ausgeführt wird. Warten Sie einige Minuten, bis Eventarc vollständig bereitgestellt wurde.
2. Schreiben Sie ein Testdokument in die überwachte Sammlung Cloud Firestore und prüfen Sie, ob die neue selbstverwaltete Funktion erfolgreich eine entsprechende Zeile in die Changelog-Tabelle BigQuery schreibt (mit einer neuen Ereignis-ID).
3. Sobald die neue Bereitstellung wie erwartet funktioniert, sollten Sie die alte Erweiterung sofort deinstallieren oder deaktivieren, um das doppelte Schreiben zu beenden.
4. Halten Sie den Überschneidungszeitraum so kurz wie möglich, um doppelte Zeilen im Rohdaten-Changelog für BigQuery zu minimieren.

5. Beim Dual Writing während des Migrationszeitraums werden in der Raw Changelog Table (*_raw_changelog) zwei Zeilen mit denselben Dokumentdaten und demselben Cloud Firestore-Commit-Zeitstempel erstellt. Die aktuelle Ansicht der Tabelle (*_raw_latest) ist jedoch korrekt.

Weitere Informationen zur Migration dieser Erweiterung und zur Wiederherstellung nach einem Datenverlust finden Sie in der README.md-Datei des Kits.

Was soll ich tun, wenn der Schritt zur Bereitstellung des Lebenszyklus fehlschlägt?

Im Rahmen des verwalteten Dienstes wurden Einrichtungsaufgaben wie das Erstellen von BigQuery-Datasets, -Tabellen und -Ansichten automatisch ausgeführt. Beim selbstverwalteten NPM-Modell werden diese mit einer Lifecycle-Aufgabenwarteschlangenfunktion ausgelöst. In firestore-bigquery-export heißt diese beispielsweise initBigQuerySync.

Wenn dieser Schritt fehlschlägt oder nicht automatisch ausgeführt wird:

1. Prüfen Sie, ob dem Cloud Functions-Laufzeitdienstkonto die erforderlichen IAM-Rollen gewährt wurden. Für firestore-bigquery-export umfasst das beispielsweise:

   • So erstellen Sie Ressourcen und fügen Zeilen ein: roles/bigquery.dataEditor
   • Jobs ausführen und Ansichten erstellen: roles/bigquery.user
   • So stellen Sie die Bereitstellungsaufgabe in die Warteschlange ein: roles/cloudtasks.enqueuer

2. Prüfen Sie, ob der Anrufer die Berechtigungen für roles/cloudtasks.enqueuer hat.

3. Führen Sie den Befehl zur Initialisierung des Lebenszyklus manuell über die CLI noch einmal aus:

   firebase functions:lifecycle:run afterInstall KIT_INSTANCE_ID
   

4. Prüfen Sie die Cloud Logging-Logs sowohl für die Triggerfunktion als auch für die Ausführung der Aufgabenwarteschlange, um Berechtigungs- oder Konfigurationsfehler zu diagnostizieren.

Wie werden Secret Manager-Anmeldedaten migriert?

Im verwalteten Modell wurden Secret Manager-Ressourcen automatisch an die Erweiterungsinstanzen gebunden. Wenn Sie die Befehle ext:migrate oder ext:export --mode functions verwenden, um die Konfiguration Ihrer Erweiterungen in ein Funktionskit zu exportieren, werden diese Secrets nicht mehr von Erweiterungen verwaltet. Sie bleiben also in Ihrem Projekt, nachdem die Erweiterung deinstalliert wurde. Wenn Sie diese Secrets in Zukunft entfernen möchten, müssen Sie dies manuell in der Google Cloud-Konsole tun.

Was passiert, wenn ein Nutzer mehrere Instanzen einer migrierten Erweiterung ausführen möchte?

Wir haben Funktionskits eingeführt, um mehrere Instanzen einer Funktion zu unterstützen, ähnlich wie bei mehreren Versionen einer Erweiterung. Jedes Kit erhält eine eindeutige Kit-Instanz-ID, die einer Codebase ähnelt und in CLI-Befehlen austauschbar mit Codebases verwendet werden kann. Bei der Bereitstellung wird allen Funktionen in einer Kit-Instanz das Präfix kit-<instance-id>- vorangestellt, damit jede Funktion einen eindeutigen Namen hat. Das ist ähnlich wie beim Präfix ext-<extension-instance-id>- in Erweiterungen. Weitere Informationen zur Verwendung von Funktions-Kits im Rahmen der Migration finden Sie in unserer Anleitung zur Nutzermigration.

Für die Kit-Installation wird npm verwendet. Was ist, wenn ich Yarn oder einen anderen Node-kompatiblen Paketmanager verwenden möchte?

Wir haben derzeit keine Pläne, Yarn oder andere Paketmanager zu unterstützen. Bei der Installation des Kits werden npm-Befehle direkt ausgeführt, wenn der Quellcode des Kits bei der ersten Installation eingerichtet wird.

Alternativ können Sie ein Quellverzeichnis erstellen, das npm-Paket für das Kit selbst installieren und es mit entsprechenden Builds und Exporten einrichten. Sehen Sie sich unsere TypeScript-index-kit-Vorlagen in firebase-tools an oder verwenden Sie ein npm-installiertes Kit als Beispiel. Danach können Sie es wie ein lokales Kit mit --directory anstelle von --package installieren. Künftig müssen Sie das Kit anhand des Verzeichnisses oder der ID identifizieren. Sie können jedoch die Kit-Befehle verwenden, um Instanzen hinzuzufügen und zu entfernen.

Meine Erweiterung verwendet die erweiterten Systemparameter für das Docker-Repository oder den KMS-Schlüssel. Wie kann ich das in Funktionskits konfigurieren?

Derzeit wird die Konfiguration eines Docker-Repositorys oder KMS-Schlüssels in Cloud Functions für Firebase nicht unterstützt. Wenn Sie von einer Erweiterung mit diesen konfigurierten Systemparametern migrieren und diese Funktion beibehalten möchten, können Sie die Parameter mit gcloud CLI auf die Funktionen Ihres neuen Kits anwenden.

Voraussetzungen

1. Stellen Sie Ihr Funktionskit zuerst gemäß den Migrationsanleitungen bereit, damit die Funktionen in Google Cloud vorhanden sind.

2. Definieren Sie die Umgebungsvariablen in Ihrem Terminal:

   export PROJECT_ID="YOUR_PROJECT_ID"
   export FUNCTION_REGION="YOUR_REGION"          # e.g. us-east1
   export KIT_NAME="YOUR_KIT_NAME"                # e.g. firestore-bigquery-export
   export SOURCE_DIR="YOUR_KIT_SOURCE_DIR"       # e.g. "./function-kits/${KIT_NAME}/source"
   export REPO_NAME="YOUR_DOCKER_REPO_NAME"
   export KEY_RING="YOUR_KMS_KEY_RING"
   export KEY_NAME="YOUR_KMS_KEY_NAME"
   
   # Retrieve Project Number automatically
   export PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" --format="value(projectNumber)")
   

3. Erstellen Sie .gcloudignore im Quellstammverzeichnis des Kits vorab, damit kompilierte Build-Dateien nicht von .gitignore ignoriert werden:

   cat << 'EOF' > "${SOURCE_DIR}/.gcloudignore"
   .gcloudignore
   .git
   .gitignore
   
   node_modules
   #!include:.gitignore
   !lib/**
   EOF
   

4. Erforderliche IAM-Berechtigungen gewähren:

   • Für KMS-Schlüssel (gewährt Dienst-Agents Zugriff auf die Entschlüsselung):

     for SERVICE_ACCOUNT in \
       "service-${PROJECT_NUMBER}@serverless-robot-prod.iam.gserviceaccount.com" \
       "service-${PROJECT_NUMBER}@gcf-admin-robot.iam.gserviceaccount.com" \
       "service-${PROJECT_NUMBER}@gcp-sa-artifactregistry.iam.gserviceaccount.com"
     do
       gcloud kms keys add-iam-policy-binding "$KEY_NAME" \
         --keyring="$KEY_RING" \
         --location="$FUNCTION_REGION" \
         --project="$PROJECT_ID" \
         --member="serviceAccount:${SERVICE_ACCOUNT}" \
         --role="roles/cloudkms.cryptoKeyEncrypterDecrypter"
     done
     

   • Für Artifact Registry (gewährt Schreibzugriff auf Cloud Build und Lesezugriff auf Cloud Run):

     # Grant the Cloud Build / Compute Service Account permission to write images to the repository
     gcloud artifacts repositories add-iam-policy-binding "$REPO_NAME" \
       --location="$FUNCTION_REGION" \
       --project="$PROJECT_ID" \
       --member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \
       --role="roles/artifactregistry.writer"
     
     # Grant Cloud Run permission to pull images from the repository
     gcloud artifacts repositories add-iam-policy-binding "$REPO_NAME" \
       --location="$FUNCTION_REGION" \
       --project="$PROJECT_ID" \
       --member="serviceAccount:service-${PROJECT_NUMBER}@serverless-robot-prod.iam.gserviceaccount.com" \
       --role="roles/artifactregistry.reader"
     

Einstellungen über die gcloud CLI anwenden

Führen Sie gcloud functions deploy für jede Funktion in Ihrem Kit aus:

gcloud functions deploy FUNCTION_NAME \
  --project="$PROJECT_ID" \
  --region="$FUNCTION_REGION" \
  --source="./function-kits/${KIT_NAME}/source" \
  --docker-repository="projects/${PROJECT_ID}/locations/${FUNCTION_REGION}/repositories/${REPO_NAME}" \
  --kms-key="projects/${PROJECT_ID}/locations/${FUNCTION_REGION}/keyRings/${KEY_RING}/cryptoKeys/${KEY_NAME}"

Beachten Sie, dass dieser Workaround unter den folgenden Bedingungen nicht funktioniert:

1. Neue Kit-Instanzen: Wenn Sie in firebase.json eine Instanz hinzufügen, wird eine neue Cloud Functions-Ressource der Version 2 erstellt, für die standardmäßig von Google verwaltete Schlüssel und gcf-artifacts verwendet werden. Sie müssen gcloud für jede neue Instanz ausführen.
2. Funktion neu erstellen: Wenn Sie einen Triggertyp ändern (z. B. von HTTPS zu einem Cloud Firestore-Trigger), den Einstiegspunkt ändern oder die Funktion umbenennen, löscht die Firebase-Befehlszeile die alte Funktion und erstellt eine neue. Die neue Funktion verliert diese Einstellungen, bis Sie gcloud noch einmal ausführen.
3. Konfigurationsabweichung: In der Firebase CLI wird der KMS- oder Docker-Repository-Status nicht in firebase functions:list- oder Diff-Protokollen angezeigt, was die Infrastrukturprüfung erschwert.

Erfolg überprüfen

Führen Sie den folgenden Befehl aus, um zu prüfen, ob das Repository und der Verschlüsselungsschlüssel angewendet wurden:

gcloud functions describe FUNCTION_NAME \
  --region="$FUNCTION_REGION" \
  --project="$PROJECT_ID" \
  --format="yaml(state, buildConfig.dockerRepository, kmsKeyName)"