Questions fréquentes sur l'arrêt des extensions Firebase

Pourquoi abandonnons-nous Firebase Extensions ?

En raison des modifications et des abandons à venir dans notre infrastructure Google Cloud sous-jacente, nous allons arrêter le service Firebase Extensions géré.

Les extensions déployées existantes cesseront-elles de fonctionner après le 31 mars 2027 ?

Non. Les extensions déjà déployées s'exécutent directement sur l'infrastructure Google Cloud standard (telle que Cloud Functions, Eventarc, Cloud Run et Cloud Tasks) et continueront de s'exécuter indéfiniment.

Toutefois, après le 31 mars 2027, vous ne pourrez plus mettre à jour, reconfigurer ni désinstaller ces extensions à l'aide de la console ou de la CLI Firebase. Vous ne pourrez plus non plus télécharger vos configurations d'extension existantes pour vous aider à migrer vers un kit de fonctions. Nous vous recommandons vivement de migrer ou d'exporter la configuration de l'extension d'ici le 31 mars 2027.

Que se passe-t-il si un utilisateur ne fait rien ?

Si un utilisateur n'effectue aucune action, ses fonctions déployées existantes continueront de s'exécuter en tant qu'éléments standards. Toutefois, après le 31 mars 2027 :

1. Ils ne peuvent pas modifier les paramètres de configuration ni mettre à jour les variables d'environnement.
2. Ils ne peuvent pas appliquer de corrections de bugs, de correctifs de sécurité ni de mises à niveau des dépendances.
3. Ils ne peuvent pas télécharger la configuration de l'extension pour configurer de manière identique un kit de remplacement.
4. La plupart des extensions sont actuellement basées sur l'ancien SDK Cloud Functions v1, qui est lié à des environnements d'exécution Node.js plus anciens. Une fois ces anciens runtimes entièrement mis hors service par Google Cloud, les fonctions peuvent cesser de s'exécuter ou être désactivées. Consultez Prise en charge des environnements d'exécution.

Les extensions Firebase sont-elles remplacées par autre chose ?

Nous avons ajouté de nombreuses fonctionnalités à Cloud Functions pour qu'il puisse remplacer les extensions. Il s'agit notamment des kits de fonctions, qui peuvent être distribués à l'aide de npm et vous permettent de déployer plusieurs instances de fonctions, de la même manière que vous pouvez installer plusieurs fois des extensions dans un même projet.

Toutefois, il appartient à chaque éditeur d'extension de déterminer s'il souhaite publier un kit de fonctions de remplacement officiel sur npm. Comme les extensions sont open source, si l'éditeur ne souhaite pas créer de remplacement officiel, n'importe quel développeur peut le dupliquer pour créer un remplacement non officiel avec Cloud Functions à l'aide de nos API de 2e génération dans le SDK Node.

Les éditeurs qui souhaitent effectuer un remplacement doivent suivre les instructions du guide de migration pour les éditeurs.

Les utilisateurs qui souhaitent profiter des packages de remplacement officiels ou créer leurs propres remplacements peuvent suivre les instructions du guide de migration pour les utilisateurs.

Que dois-je faire en tant qu'utilisateur de l'extension ?

Si vous êtes un utilisateur d'extensions et que vous n'utilisez plus celles que vous avez installées, désinstallez-les avant le 31 mars 2027.

Après l'arrêt, le bouton "Désinstaller" de la console Firebase et les commandes CLI correspondantes seront supprimés. Vous devez supprimer manuellement toutes les ressources Google Cloud associées, y compris les Cloud Functions, les secrets Secret Manager, les files d'attente Cloud Tasks et les comptes de service IAM personnalisés individuels, à l'aide de la console Google Cloud.

Toutefois, si vous utilisez activement vos extensions installées, nous vous recommandons vivement de migrer vers les kits de fonctions. Pour passer aux kits de fonctions, suivez les instructions de notre guide de migration pour les utilisateurs.

Vous pouvez choisir de ne pas migrer vers les kits de fonctions. Dans ce cas, nous vous recommandons vivement de mettre à jour toutes vos extensions vers leur dernière version, de les maintenir à jour et d'exporter vos configurations d'extension existantes au cas où vous souhaiteriez migrer ultérieurement.

Que dois-je faire en tant qu'éditeur d'extensions ?

Nous vous encourageons à migrer vos extensions publiées vers des kits de fonctions publiés sur npm. Vous pouvez commencer par migrer votre extension vers des fonctions de 2e génération, ce qui est une condition préalable à la création d'un kit de fonctions. Cela implique d'empaqueter la logique de votre extension à l'aide du SDK Cloud Functions v2. Nous avons mis à jour le SDK Cloud Functions v2 pour prendre en charge des fonctionnalités telles que la sécurité déclarative et les événements de cycle de vie. Vous pouvez désormais migrer votre code d'extension existant vers une fonction de deuxième génération en apportant un minimum de modifications à votre logique métier principale. Ces fonctions peuvent être publiées à l'aide d'un package npm. Pour en savoir plus, consultez notre guide de migration pour les éditeurs.

Que faire si j'ai d'autres questions ?

Les utilisateurs qui ont des questions peuvent consulter notre guide de migration des utilisateurs. Si vous avez encore des questions après avoir consulté le guide, vous pouvez contacter l'assistance Firebase.

Les éditeurs qui ont des questions sur la migration de Firebase Extensions peuvent consulter notre guide de migration pour les éditeurs. Ce guide vous explique comment rester informé des mises à jour et obtenir de l'aide pour proposer une alternative à vos extensions publiées.

Quels sont les principaux chemins de migration disponibles ?

À partir de septembre 2026, Firebase sera officiellement compatible avec deux principaux chemins de migration :

1. Migrez vers une fonction partagée NPM ("kit de fonctions") : recommandé pour Stream Firestore vers BigQuery et tous les autres kits de fonctions qui deviendront disponibles sur npm. La logique principale est empaquetée sous forme de bibliothèque NPM standard à l'aide du SDK Cloud Functions v2. Les utilisateurs initialisent un code source Cloud Functions standard, installent le package, réexportent les fonctions et les déploient indépendamment à l'aide de la CLI.
2. Fork and Self-Manage (Fork et autogestion) : recommandé pour toutes les extensions qui ne disposent pas d'un kit de fonctions disponible sur npm. Les utilisateurs copient ou dupliquent le code source de l'extension Open Source, refactorisent les déclencheurs en fonctions Firebase v2 standards à l'aide de compétences de migration de l'IA au mieux ou de guides manuels, et prennent l'entière responsabilité du code et de sa maintenance continue.

Quelles extensions sont migrées vers des kits de fonctions ?

L'extension Diffuser Firestore vers BigQuery a été migrée vers un kit de fonctions disponible sous forme de package npm @firebase-function-kits/firestore-bigquery-export.

Pourquoi la migration nécessite-t-elle de passer de la version 1 à la version 2 de Cloud Functions ?

L'assistance standard pour Cloud Functions v1 se termine avec l'environnement d'exécution Node.js 22. Pour éviter une "double migration" où les développeurs migrent depuis Firebase Extensions uniquement pour être forcés à une deuxième refactorisation manuelle lorsque les anciens runtimes seront abandonnés, Firebase recommande vivement de mettre à niveau toutes les fonctions migrées vers le SDK v2 immédiatement pendant cette transition. Cette mise à niveau est obligatoire pour les kits de fonctions.

En tant qu'utilisateur d'extensions, vous pouvez également créer vos propres kits de fonctions à l'aide du guide de migration pour les utilisateurs.

La migration vers Cloud Functions autogéré aura-t-elle une incidence sur la facturation d'un client ?

En général, non. Les extensions déployées facturent déjà aux clients les ressources Google Cloud sous-jacentes qu'ils consomment, comme les appels Cloud Functions, Cloud Storage ou le stockage et les requêtes BigQuery. Toutefois, pendant la période de migration, les clients peuvent encourir un petit coût supplémentaire temporaire s'ils exécutent à la fois l'ancienne fonction Firebase Extensions et la nouvelle fonction de remplacement déployée en parallèle pour assurer une transition sûre.

Comment la facturation est-elle gérée pour les comptes Mandiant ou d'autres comptes d'entreprise spécialisés ?

Cette obsolescence est une modification à l'échelle de la plate-forme qui affecte tous les projets Firebase et Google Cloud. Les modalités de facturation et d'abonnement standards ne sont pas affectées. Si des clients demandent des crédits SLA en raison d'un temps d'arrêt lié à l'abandon d'un produit ou rencontrent des exceptions de facturation complexes, escaladez la demande directement via les canaux d'assistance pour la facturation habituels.

Quels sont les risques de perte de données ou d'indisponibilité du service pendant la migration ?

La transition des ressources gérées vers des bases de code autogérées présente un risque mineur d'interruption de service ou de perte d'événements.

• Perturbation des déclencheurs : si les anciens déclencheurs sont supprimés avant que les nouveaux ne soient actifs, un écart est créé, ce qui entraîne la perte définitive d'événements (par exemple, les écritures de documents Cloud Firestore). Nous vous recommandons de déployer le kit de remplacement et de le valider avant de supprimer l'extension pour éviter toute perte de données.
• Manque d'autorisations : si le codebase nouvellement déployé ne dispose pas des autorisations IAM nécessaires, les opérations, comme l'écriture dans BigQuery, échoueront en mode silencieux ou planteront lors de l'exécution. Nous avons ajouté une sécurité déclarative pour les fonctions. Le premier déploiement du kit effectué par un compte pouvant interroger et définir des rôles, et générer un compte de service devrait atténuer ce problème.

Comment éviter la perte de données pour l'extension d'exportation Cloud Firestore vers BigQuery critique ?

Pour assurer une transition sûre et sans perte de données, l'assistance doit conseiller aux utilisateurs de suivre une transition basée sur le chevauchement plutôt que sur un écart. Il s'agit du comportement par défaut lors de la migration vers les kits :

1. Déployez le kit de fonctions de remplacement pendant que l'extension est toujours installée et en cours d'exécution. Attendez quelques minutes que le provisionnement d'Eventarc soit terminé.
2. Écrivez un document de test dans la collection Cloud Firestore observée et vérifiez que la nouvelle fonction autogérée écrit correctement une ligne correspondante dans la table du journal des modifications BigQuery (avec un nouvel ID d'événement).
3. Une fois que vous avez vérifié que le nouveau déploiement fonctionne, désinstallez ou désactivez immédiatement l'ancienne extension pour mettre fin au comportement de double écriture.
4. Réduisez au maximum la fenêtre de chevauchement pour limiter les lignes en double dans le journal des modifications BigQuery brutes.

5. L'écriture double pendant la période de migration entraînera la création de deux lignes dans la table Raw Changelog (*_raw_changelog) avec les mêmes données de document et le même code temporel de commit Cloud Firestore. Toutefois, la dernière vue du tableau (*_raw_latest) sera correcte.

Pour en savoir plus sur la migration de cette extension en particulier et sur la façon de récupérer les données perdues, consultez le fichier README.md du kit.

Que dois-je faire si l'étape de provisionnement du cycle de vie échoue ?

Dans le service géré, les tâches de configuration (comme la création d'ensembles de données, de tables et de vues BigQuery) étaient gérées automatiquement. Dans le modèle NPM autogéré, ces éléments sont déclenchés à l'aide d'une fonction de file d'attente des tâches de cycle de vie. Par exemple, dans firestore-bigquery-export, cette fonction est appelée initBigQuerySync.

Si cette étape échoue ou ne s'exécute pas automatiquement :

1. Vérifiez que le compte de service d'exécution Cloud Functions dispose des rôles IAM requis. Par exemple, pour firestore-bigquery-export, cela inclut :

   • Pour créer des ressources et insérer des lignes : roles/bigquery.dataEditor
   • Pour exécuter des jobs et créer des vues : roles/bigquery.user
   • Pour mettre en file d'attente la tâche de provisionnement : roles/cloudtasks.enqueuer

2. Vérifiez que l'appelant dispose des autorisations roles/cloudtasks.enqueuer.

3. Exécutez manuellement la commande d'initialisation du cycle de vie à l'aide de la CLI :

   firebase functions:lifecycle:run afterInstall KIT_INSTANCE_ID
   

4. Consultez les journaux Cloud Logging pour la fonction de déclencheur et l'exécution de la file d'attente des tâches afin de diagnostiquer les éventuelles erreurs d'autorisation ou de configuration.

Comment les identifiants Secret Manager sont-ils migrés ?

Dans le modèle géré, les ressources Secret Manager étaient automatiquement liées aux instances d'extension. Lorsque vous utilisez les commandes ext:migrate ou ext:export --mode functions pour exporter la configuration de vos extensions vers un kit de fonctions, nous empêchons les extensions de gérer ces secrets afin qu'ils restent dans votre projet après la désinstallation de l'extension. Si vous souhaitez supprimer ces secrets à l'avenir, vous devrez le faire manuellement dans la console Google Cloud.

Que se passe-t-il si un utilisateur souhaite exécuter plusieurs instances d'une extension migrée ?

Nous avons introduit les kits de fonctions pour prendre en charge plusieurs instances d'une fonction, comme vous pouvez avoir plusieurs versions d'une extension. Chaque kit recevra un ID d'instance de kit unique, qui est semblable à une base de code et peut être utilisé de manière interchangeable avec les bases de code dans les commandes CLI. Une fois déployées, toutes les fonctions d'une instance de kit seront précédées de kit-<instance-id>- pour s'assurer que chaque fonction possède un nom unique, comme le préfixe ext-<extension-instance-id>- dans les extensions. Pour en savoir plus sur l'utilisation des kits de fonctions lors de la migration, consultez notre guide de migration pour les utilisateurs.

L'installation du kit utilise npm. Que faire si je souhaite utiliser Yarn ou un autre gestionnaire de packages compatible avec Node ?

Nous ne prévoyons pas actuellement de prendre en charge Yarn ni d'autres gestionnaires de packages. L'installation du kit fonctionne en exécutant directement les commandes npm lors de la configuration du code source du kit lors de la première installation.

Vous pouvez également créer un répertoire source, installer vous-même le package npm du kit et le configurer avec les compilations et les exportations appropriées. Consultez nos modèles TypeScript index-kit dans firebase-tools ou examinez un kit installé avec npm comme exemple. Une fois cette opération effectuée, vous pouvez l'installer comme un kit local à l'aide de --directory plutôt que de --package. À l'avenir, vous devrez identifier le kit par répertoire ou ID, mais vous pourrez utiliser les commandes du kit pour ajouter et supprimer des instances.

Mon extension utilise les paramètres système avancés du dépôt Docker ou de la clé KMS. Comment puis-je les configurer dans les kits de fonctions ?

Pour le moment, nous ne prenons pas en charge la configuration d'un dépôt Docker ni d'une clé KMS dans Cloud Functions pour Firebase. Si vous migrez depuis une extension avec ces paramètres système configurés et que vous souhaitez conserver cette fonctionnalité, vous pouvez appliquer les paramètres aux fonctions de votre nouveau kit à l'aide de gcloud CLI.

Conditions préalables

1. Déployez votre kit de fonctions initialement en suivant les guides de migration afin que les fonctions existent dans Google Cloud.

2. Définissez vos variables d'environnement dans votre 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. Créez .gcloudignore dans la racine source du kit afin que les fichiers de compilation compilés ne soient pas ignorés par .gitignore :

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

4. Accorde les autorisations IAM requises :

   • Pour les clés KMS (qui accordent l'accès au déchiffrement aux agents de service) :

     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
     

   • Pour Artifact Registry (accorde un accès en écriture à Cloud Build et un accès en lecture à 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"
     

Appliquer les paramètres à l'aide de gcloud CLI

Exécutez gcloud functions deploy pour chaque fonction de votre kit :

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}"

Notez que cette solution de contournement ne fonctionne pas dans les cas suivants :

1. Nouvelles instances de kit : l'ajout d'une instance dans firebase.json crée une ressource Cloud Functions v2 qui utilise par défaut les clés gérées par Google et gcf-artifacts. Vous devez exécuter gcloud pour chaque nouvelle instance.
2. Recréation de la fonction : si vous modifiez un type de déclencheur (par exemple, en passant de HTTPS à un déclencheur Cloud Firestore), que vous modifiez le point d'entrée ou que vous renommez la fonction, la CLI Firebase supprime l'ancienne fonction et en crée une. La nouvelle fonction perd ces paramètres jusqu'à ce que vous exécutiez à nouveau gcloud.
3. Dérive de configuration : l'interface de ligne de commande Firebase n'affiche pas l'état du dépôt KMS ou Docker dans les journaux firebase functions:list ni dans les journaux de différences, ce qui rend l'audit de l'infrastructure difficile.

Vérifier la réussite de l'opération

Pour vérifier que le dépôt et la clé de chiffrement ont été appliqués, exécutez la commande suivante :

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