Domande frequenti sul ritiro di Firebase Extensions

Perché stiamo ritirando Firebase Extensions?

A causa di modifiche e ritiri imminenti all'interno della nostra infrastruttura Google Cloud di base, ritireremo il servizio Firebase Extensions gestito.

Le estensioni esistenti di cui è stato eseguito il deployment smetteranno di funzionare dopo il 31 marzo 2027?

No. Le estensioni già implementate vengono eseguite direttamente sull'infrastruttura standard di Google Cloud (ad esempio Cloud Functions, Eventarc, Cloud Run e Cloud Tasks) e continueranno a essere eseguite indefinitamente.

Tuttavia, dopo il 31 marzo 2027, non potrai più aggiornare, riconfigurare o disinstallare queste estensioni tramite la console o la CLI Firebase. Perderai anche la possibilità di scaricare le configurazioni delle estensioni esistenti per facilitare la migrazione a un kit di funzioni. Ti consigliamo vivamente di eseguire la migrazione o l'esportazione della configurazione delle estensioni entro il 31 marzo 2027.

Cosa succede se un utente non fa nulla?

Se un utente non interviene, le funzioni di cui è stato eseguito il deployment continueranno a essere eseguite come asset standard. Tuttavia, dopo il 31 marzo 2027:

1. Non possono modificare i parametri di configurazione o aggiornare le variabili di ambiente.
2. Non possono applicare correzioni di bug, patch di sicurezza o upgrade delle dipendenze.
3. Non possono scaricare la configurazione dell'estensione per configurare in modo identico un kit di funzioni sostitutivo.
4. La maggior parte delle estensioni è attualmente basata sull'SDK legacy Cloud Functions v1, che è associato a runtime Node.js precedenti. Una volta ritirati completamente questi runtime legacy da Google Cloud, le funzioni potrebbero smettere di essere eseguite o essere disattivate. Consulta Supporto del runtime.

Esiste un prodotto che sostituisce Firebase Extensions?

Abbiamo aggiunto molte funzionalità a Cloud Functions per renderli in grado di sostituire le estensioni. In particolare, i kit di funzioni, che possono essere distribuiti utilizzando npm e consentono di eseguire il deployment di più istanze di funzioni, in modo simile a come è possibile installare più volte le estensioni in un singolo progetto.

Tuttavia, spetta a ogni publisher di estensioni determinare se vuole pubblicare una sostituzione ufficiale del kit di funzioni su npm. Poiché le estensioni sono open source, se l'editore non vuole creare una sostituzione ufficiale, qualsiasi sviluppatore può creare un fork per creare una sostituzione non ufficiale con Cloud Functions utilizzando le nostre API di 2ª gen. nell'SDK Node.

Gli editori che vogliono effettuare una sostituzione devono seguire le istruzioni riportate nella guida alla migrazione per gli editori.

Gli utenti che vogliono usufruire dei pacchetti di sostituzione ufficiali o creare i propri possono seguire le istruzioni riportate nella guida alla migrazione per gli utenti.

Cosa devo fare in qualità di utente dell'estensione?

Se sei un utente di estensioni e non utilizzi più quelle installate, disinstallale prima del 31 marzo 2027.

Dopo il ritiro, il pulsante "Disinstalla" nella console Firebase e i comandi CLI corrispondenti verranno rimossi. Devi eliminare manualmente tutte le risorse Google Cloud associate, inclusi i singoli Cloud Functions, i secret Secret Manager, le code Cloud Tasks e i service account IAM personalizzati, utilizzando la console Google Cloud.

Tuttavia, se utilizzi attivamente le estensioni installate, ti consigliamo vivamente di eseguire la migrazione ai function kit. Per passare ai kit di funzioni, segui le istruzioni riportate nella nostra guida alla migrazione per gli utenti.

Puoi scegliere di non eseguire la migrazione ai kit di funzioni. In questo caso, ti consigliamo vivamente di aggiornare tutte le tue estensioni alle versioni più recenti, mantenerle aggiornate ed esportare le configurazioni delle estensioni esistenti nel caso in cui tu voglia eseguire la migrazione in un secondo momento.

Che cosa devo fare in qualità di publisher di estensioni?

Ti invitiamo a eseguire la migrazione delle estensioni pubblicate ai kit di funzioni pubblicati su npm. Puoi iniziare eseguendo la migrazione dell'estensione alle funzioni di 2ª gen., che è un prerequisito per la creazione di un kit di funzioni. Ciò comporta il packaging della logica dell'estensione utilizzando l'SDK Cloud Functions v2. Abbiamo aggiornato l'SDK Cloud Functions v2 con il supporto di funzionalità come eventi del ciclo di vita e sicurezza dichiarativa. Ora puoi migrare il codice di estensione esistente a una funzione di 2ª gen. con modifiche minime alla logica di business principale. Queste funzioni possono essere pubblicate utilizzando un pacchetto npm. Per maggiori dettagli, consulta la nostra guida alla migrazione per i publisher.

E se avessi altre domande?

Gli utenti che hanno domande possono consultare la nostra guida alla migrazione degli utenti. Se hai ancora domande dopo aver utilizzato la guida, puoi contattare l'assistenza Firebase.

Gli editori che hanno domande su come eseguire la migrazione di Firebase Extensions possono utilizzare la nostra guida alla migrazione per gli editori. Questa guida include istruzioni su come rimanere informato sugli aggiornamenti e ricevere assistenza per fornire un'alternativa alle estensioni pubblicate.

Quali sono i percorsi di migrazione principali disponibili?

A partire da settembre 2026, Firebase supporta ufficialmente due percorsi di migrazione principali:

1. Esegui la migrazione a una funzione condivisa NPM ("kit di funzioni"): consigliata per Stream Firestore to BigQuery e per tutti gli altri kit di funzioni che diventano disponibili su npm. La logica principale è inclusa in un pacchetto come libreria NPM standard utilizzando l'SDK Cloud Functions v2. Gli utenti inizializzano un codebase Cloud Functions standard, installano il pacchetto, esportano nuovamente le funzioni e le eseguono il deployment in modo indipendente utilizzando la CLI.
2. Fork and Self-Manage: consigliato per tutte le estensioni che non hanno un kit di funzioni disponibile su npm. Gli utenti copiano o creano un fork del codice sorgente dell'estensione open source, refactoring dei trigger in funzioni Firebase v2 standard utilizzando le competenze di migrazione dell'AI con il massimo impegno o guide manuali e assumono la piena proprietà della base di codice e della sua manutenzione continua.

Quali estensioni vengono migrate ai kit di funzioni?

L'estensione Stream Firestore to BigQuery è stata migrata a un kit di funzioni disponibile come pacchetto npm @firebase-function-kits/firestore-bigquery-export.

Perché la migrazione richiede l'upgrade dalla versione 1 alla versione 2 di Cloud Functions?

L'assistenza standard di Cloud Functions v1 termina con il runtime Node.js 22. Per evitare una "doppia migrazione" in cui gli sviluppatori eseguono la migrazione da Firebase Extensions solo per essere costretti a un secondo refactoring manuale quando i runtime legacy vengono ritirati, Firebase consiglia vivamente di eseguire l'upgrade di tutte le funzioni migrate all'SDK v2 immediatamente durante questa transizione ed è obbligatorio per i kit di funzioni.

In qualità di utente delle estensioni, puoi anche creare i tuoi kit di funzioni utilizzando la guida alla migrazione degli utenti.

La migrazione a Cloud Functions autogestito cambierà la fatturazione di un cliente?

In genere, no. Le estensioni di cui è stato eseguito il deployment addebitano già ai clienti le risorse Google Cloud sottostanti che consumano, ad esempio le invocazioni Cloud Functions, Cloud Storage o lo spazio di archiviazione e le query BigQuery. Tuttavia, durante la finestra di migrazione, i clienti potrebbero sostenere un piccolo costo aggiuntivo temporaneo se eseguono in parallelo sia la funzione Firebase Extensions legacy sia quella sostitutiva appena implementata per garantire un trasferimento sicuro.

Come viene gestita la fatturazione per Mandiant o altri account aziendali specializzati?

Questo ritiro è una modifica a livello di piattaforma che interessa tutti i progetti Firebase e Google Cloud. Gli accordi standard di fatturazione e abbonamento non subiscono modifiche. Se i clienti richiedono crediti SLA a causa di tempi di inattività per il ritiro o riscontrano eccezioni di fatturazione complesse, riassegna la richiesta direttamente tramite i normali canali di assistenza per la fatturazione.

Qual è il rischio di perdita di dati o interruzione del servizio durante la migrazione?

La transizione delle risorse gestite a codebase autogestite comporta un rischio minimo di interruzione del servizio o perdita di eventi.

• Interruzione dei trigger: se i vecchi trigger vengono eliminati prima che i nuovi siano attivi, si crea un intervallo in cui gli eventi (ad es. scritture di documenti Cloud Firestore) vengono persi definitivamente. Ti consigliamo di eseguire il deployment del kit di sostituzione e di convalidarlo prima di rimuovere l'estensione per evitare perdite di dati.
• Lacune nelle autorizzazioni: se la base di codice appena implementata non dispone delle autorizzazioni IAM necessarie, le operazioni, come la scrittura in BigQuery, non andranno a buon fine in modo silenzioso o si arresteranno in modo anomalo in fase di runtime. Abbiamo aggiunto la sicurezza dichiarativa per le funzioni, quindi il primo deployment del kit eseguito da un account che può eseguire query e impostare ruoli e generare un service account dovrebbe mitigare questo problema.

Come possiamo evitare la perdita di dati per l'estensione di esportazione critica da Cloud Firestore a BigQuery?

Per ottenere una transizione sicura e senza perdita di dati, l'assistenza deve consigliare agli utenti di seguire un cutover basato sulla sovrapposizione anziché uno basato sul divario. Questo è il comportamento predefinito con la migrazione ai kit:

1. Esegui il deployment del kit di funzioni sostitutivo mentre l'estensione è ancora installata e in esecuzione. Attendi qualche minuto affinché Eventarc esegua il provisioning completo.
2. Scrivi un documento di test nella raccolta Cloud Firestore osservata e verifica che la nuova funzione autogestita scriva correttamente una riga corrispondente nella tabella del log delle modifiche BigQuery (con un nuovo ID evento).
3. Una volta confermato il funzionamento del nuovo deployment, disinstalla o disattiva immediatamente l'estensione precedente per interrompere il comportamento di doppia scrittura.
4. Mantieni la finestra di sovrapposizione il più breve possibile per ridurre al minimo il costo dell'elaborazione duplicata di ogni scrittura e la possibilità di righe duplicate nel log delle modifiche BigQuery non elaborate.
5. Nella maggior parte dei casi, la tabella Raw Changelog (*_raw_changelog) deduplica in base a insertID e anche nei casi in cui vengono visualizzate righe duplicate nel changelog, la visualizzazione più recente della tabella (*_raw_latest) sarà corretta.

Ulteriori informazioni sulla migrazione di questa estensione in particolare e su come eseguire il ripristino in caso di perdita di dati sono disponibili nel file README.md del kit.

Cosa devo fare se il passaggio di provisioning del ciclo di vita non va a buon fine?

Nel servizio gestito, le attività di configurazione (come la creazione di BigQuery set di dati, tabelle e viste) venivano gestite automaticamente. Nel modello NPM autogestito, questi vengono attivati utilizzando una funzione di coda di attività del ciclo di vita; ad esempio, in firestore-bigquery-export questa funzione è chiamata initBigQuerySync.

Se questo passaggio non riesce o non viene eseguito automaticamente:

1. Verifica che al service account di runtime Cloud Functions siano stati concessi i ruoli IAM richiesti. Ad esempio, per firestore-bigquery-export questo include:

   • Per creare risorse e inserire righe: roles/bigquery.dataEditor
   • Per eseguire job e creare viste: roles/bigquery.user
   • Per mettere in coda l'attività di provisioning: roles/cloudtasks.enqueuer

2. Verifica che il chiamante disponga delle autorizzazioni roles/cloudtasks.enqueuer.

3. Esegui di nuovo manualmente il comando di inizializzazione del ciclo di vita utilizzando la CLI:

   firebase functions:lifecycle:run afterInstall KIT_INSTANCE_ID
   

4. Controlla i log di Cloud Logging sia per la funzione di attivazione sia per l'esecuzione della coda di attività per diagnosticare eventuali errori di autorizzazione o configurazione.

Come viene eseguita la migrazione delle credenziali Secret Manager?

Nel modello gestito, le risorse Secret Manager venivano associate automaticamente alle istanze dell'estensione. Quando utilizzi i comandi ext:migrate o ext:export --mode functions per esportare la configurazione delle estensioni in un kit di funzioni, impediamo alle estensioni di gestire questi secret in modo che rimangano nel tuo progetto dopo la disinstallazione dell'estensione. Se in futuro vuoi rimuovere questi secret, devi farlo manualmente nella console Google Cloud.

Cosa succede se un utente vuole eseguire più istanze di un'estensione di cui è stata eseguita la migrazione?

Abbiamo introdotto i kit di funzioni per supportare più istanze di una funzione in modo simile a come puoi avere più versioni di un'estensione. Ogni kit riceverà un ID istanza kit univoco, simile a un codebase e utilizzabile in modo intercambiabile con i codebase nei comandi CLI. Una volta eseguito il deployment, tutte le funzioni in un'istanza del kit avranno il prefisso kit-<instance-id>- per garantire che ogni funzione abbia un nome univoco, in modo simile al prefisso ext-<extension-instance-id>- nelle estensioni. Per scoprire di più su come utilizzare i kit di funzioni nell'ambito della migrazione, consulta la nostra guida alla migrazione degli utenti.

L'installazione del kit utilizza npm. Cosa succede se voglio utilizzare Yarn o un altro gestore di pacchetti compatibile con Node?

Al momento non abbiamo in programma di supportare Yarn o altri gestori di pacchetti. L'installazione del kit funziona eseguendo direttamente i comandi npm durante la configurazione del codice sorgente del kit alla prima installazione.

In alternativa, puoi creare una directory di origine, installare il pacchetto npm del kit e configurarlo con build ed esportazioni appropriate. Fai riferimento ai nostri modelli TypeScript index-kit in firebase-tools o guarda un kit installato tramite npm come esempio. Una volta fatto, puoi installarlo come un kit locale utilizzando --directory anziché --package. In futuro, dovrai identificare il kit in base alla directory o all'ID, ma potrai utilizzare i comandi del kit per aggiungere e rimuovere le istanze.

La mia estensione utilizza i parametri di sistema avanzati del repository Docker o della chiave KMS. Come posso configurarla nei kit di funzioni?

Al momento non supportiamo la configurazione di un repository Docker o di una chiave KMS in Cloud Functions per Firebase. Se esegui la migrazione da un'estensione con questi parametri di sistema configurati e vuoi conservare questa funzionalità, puoi applicare i parametri alle funzioni del nuovo kit utilizzando gcloud CLI.

Prerequisiti

1. Esegui il deployment del kit di funzioni inizialmente seguendo le guide alla migrazione in modo che le funzioni esistano in Google Cloud.

2. Definisci le variabili di ambiente nel terminale:

   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. Crea in anticipo .gcloudignore nella radice dell'origine del kit in modo che i file di build compilati non vengano ignorati da .gitignore:

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

4. Concedi le autorizzazioni IAM richieste:

   • Per le chiavi KMS (concede l'accesso alla decrittografia agli agenti di servizio):

     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
     

   • Per Artifact Registry (concede l'accesso in scrittura a Cloud Build e l'accesso in lettura a 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"
     

Applicare le impostazioni utilizzando gcloud CLI

Esegui gcloud functions deploy per ogni funzione del 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}"

Tieni presente che questa soluzione alternativa non funziona nelle seguenti condizioni:

1. Nuove istanze del kit: l'aggiunta di un'istanza in firebase.json crea una nuova risorsa Cloud Functions v2 che utilizza per impostazione predefinita chiavi gestite da Google e gcf-artifacts. Devi eseguire gcloud per ogni nuova istanza.
2. Ricreazione della funzione: la modifica di un tipo di trigger (ad esempio da HTTPS a un trigger Cloud Firestore), l'alterazione del punto di ingresso o il cambio di nome fa sì che la CLI Firebase elimini la vecchia funzione e ne crei una nuova. La nuova funzione perde queste impostazioni finché non esegui di nuovo gcloud.
3. Deriva della configurazione: la CLI Firebase non mostra lo stato di KMS o del repository Docker nei log firebase functions:list o diff, il che rende difficile l'audit dell'infrastruttura.

Verifica dell'esito positivo

Per verificare che il repository e la chiave di crittografia siano stati applicati, esegui questo comando:

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