Najczęstsze pytania dotyczące wycofywania Rozszerzeń w Firebase

Dlaczego wycofujemy Firebase Extensions?

Ze względu na nadchodzące zmiany i wycofanie niektórych elementów naszej podstawowej Google Cloud infrastruktury wycofamy zarządzaną usługę Firebase Extensions.

Czy wdrożone wcześniej rozszerzenia przestaną działać po 31 marca 2027 r.?

Nie. Wdrożone już rozszerzenia działają bezpośrednio w standardowej infrastrukturze Google Cloud (np. Cloud Functions, Eventarc, Cloud Run i Cloud Tasks) i będą działać bezterminowo.

Po 31 marca 2027 r. nie będzie można aktualizować, ponownie konfigurować ani odinstalowywać tych rozszerzeń za pomocą Firebasekonsoli ani interfejsu CLI. Stracisz też możliwość pobierania dotychczasowych konfiguracji rozszerzeń, co ułatwi przejście na zestaw funkcji. Zdecydowanie zalecamy przeniesienie lub wyeksportowanie konfiguracji rozszerzenia do 31 marca 2027 roku.

Co się stanie, jeśli użytkownik nic nie zrobi?

Jeśli użytkownik nie podejmie żadnych działań, wdrożone funkcje będą nadal działać jako standardowe zasoby. Po 31 marca 2027 r.:

1. Nie mogą zmieniać parametrów konfiguracji ani aktualizować zmiennych środowiskowych.
2. Nie mogą oni stosować poprawek błędów, poprawek zabezpieczeń ani uaktualnień zależności.
3. Nie mogą pobrać konfiguracji rozszerzenia, aby identycznie skonfigurować zamienny zestaw funkcji.
4. Większość rozszerzeń jest obecnie oparta na starszej wersji Cloud Functions pakietu SDK v1, która jest powiązana ze starszymi środowiskami wykonawczymi Node.js. Gdy te starsze środowiska wykonawcze zostaną całkowicie wycofane przez Google Cloud, funkcje mogą przestać działać lub zostać wyłączone. Zobacz Obsługa środowiska wykonawczego.

Czy Rozszerzenia w Firebase są zastępowane przez coś innego?

Dodaliśmy do Cloud Functions wiele funkcji, aby mogły zastąpić rozszerzenia. W szczególności zestawy funkcji, które można rozpowszechniać za pomocą npm i które umożliwiają wdrażanie wielu instancji funkcji, podobnie jak można instalować rozszerzenia wiele razy w jednym projekcie.

Jednak to wydawca każdego rozszerzenia decyduje, czy chce opublikować na npm oficjalny zamiennik zestawu funkcji. Rozszerzenia są dostępne na licencji open source, więc jeśli wydawca nie chce wprowadzić oficjalnego zamiennika, każdy deweloper może utworzyć jego nieoficjalną wersję, Cloud Functions korzystając z interfejsów API 2 generacji w pakiecie SDK Node.

Wydawcy, którzy chcą dokonać wymiany, powinni postępować zgodnie z instrukcjami podanymi w przewodniku po migracji dla wydawców.

Użytkownicy, którzy chcą skorzystać z oficjalnych pakietów zastępczych lub utworzyć własne, mogą postępować zgodnie z instrukcjami w przewodniku migracji dla użytkowników.

Co powinienem zrobić jako użytkownik rozszerzenia?

Jeśli jesteś użytkownikiem rozszerzeń i nie używasz już zainstalowanych rozszerzeń, odinstaluj je przed 31 marca 2027 roku.

Po wycofaniu z użytku przycisk „Odinstaluj” w Firebase konsoli i odpowiednie polecenia CLI zostaną usunięte. Musisz ręcznie usunąć wszystkie powiązane zasoby Google Cloud, w tym poszczególne Cloud Functions, Secret Manager wpisy tajne, Cloud Tasks kolejki i niestandardowe konta usługi IAM, za pomocą konsoli Google Cloud.

Jeśli jednak aktywnie korzystasz z zainstalowanych rozszerzeń, zdecydowanie zalecamy przejście na zestawy funkcji. Aby przejść na zestawy funkcji, postępuj zgodnie z instrukcjami w naszym przewodniku po migracji dla użytkowników.

Możesz zrezygnować z migracji do zestawów funkcji. W takim przypadku zdecydowanie zalecamy zaktualizowanie wszystkich rozszerzeń do najnowszych wersji i ich bieżące aktualizowanie oraz wyeksportowanie dotychczasowych konfiguracji rozszerzeń na wypadek, gdyby w przyszłości zechcesz przeprowadzić migrację.

Co mam zrobić jako wydawca rozszerzenia?

Zachęcamy do przeniesienia opublikowanych rozszerzeń do zestawów funkcji opublikowanych w npm. Możesz zacząć od migracji rozszerzenia do funkcji 2 generacji, co jest warunkiem wstępnym utworzenia zestawu funkcji. Wymaga to spakowania logiki rozszerzenia za pomocą pakietu SDK Cloud Functions w wersji 2. Zaktualizowaliśmy pakiet SDK Cloud Functions w wersji 2, aby obsługiwał funkcje takie jak deklaratywne zabezpieczenia i zdarzenia cyklu życia. Możesz teraz przenieść istniejący kod rozszerzenia do funkcji 2 generacji przy minimalnych zmianach w logice podstawowej działalności. Funkcje te można publikować za pomocą pakietu npm. Szczegółowe informacje znajdziesz w naszym przewodniku po migracji dla wydawców.

Co zrobić, jeśli mam inne pytania?

Użytkownicy, którzy mają pytania, mogą skorzystać z naszego przewodnika po migracji użytkowników. Jeśli po skorzystaniu z tego przewodnika nadal masz pytania, możesz skontaktować się z zespołem pomocy Firebase.

Wydawcy, którzy mają pytania dotyczące migracjiFirebase Extensions, mogą skorzystać z naszego przewodnika po migracji dla wydawców. Ten przewodnik zawiera instrukcje, jak być na bieżąco z aktualizacjami i uzyskać pomoc w udostępnianiu alternatywy dla opublikowanych rozszerzeń.

Jakie są główne dostępne ścieżki migracji?

Od września 2026 r. Firebase oficjalnie obsługuje 2 główne ścieżki migracji:

1. Migracja do funkcji udostępnianej w NPM („zestaw funkcji”): zalecana w przypadku przesyłania strumieniowego Firestore do BigQuery i innych zestawów funkcji, które staną się dostępne w NPM. Logika podstawowa jest spakowana jako standardowa biblioteka NPM przy użyciu pakietu SDK Cloud Functions w wersji 2. Użytkownicy inicjują standardową bazę koduCloud Functions, instalują pakiet, ponownie eksportują funkcje i wdrażają je niezależnie za pomocą interfejsu CLI.
2. Fork and Self-Manage (Rozwidlenie i samodzielne zarządzanie): zalecane w przypadku wszystkich rozszerzeń, które nie mają zestawu funkcji dostępnego w npm. Użytkownicy kopiują lub tworzą rozwidlenie kodu źródłowego rozszerzenia oprogramowania open source, refaktoryzują aktywatory w standardowe funkcje Firebase w wersji 2 za pomocą funkcji migracji AI lub ręcznych przewodników i przejmują pełną własność bazy kodu oraz jej bieżącą konserwację.

Które rozszerzenia są przenoszone do zestawów funkcji?

Rozszerzenie Stream Firestore to BigQuery zostało przeniesione do zestawu funkcji dostępnego jako pakiet npm @firebase-function-kits/firestore-bigquery-export.

Dlaczego migracja wymaga przejścia z Cloud Functions w wersji 1 na wersję 2?

Cloud Functions Wsparcie standardowe wersji 1 kończy się wraz ze środowiskiem wykonawczym Node.js 22. Aby zapobiec „podwójnej migracji”, w ramach której deweloperzy migrują z Firebase Extensions, a potem są zmuszeni do drugiego ręcznego refaktoryzowania, gdy starsze środowiska wykonawcze zostaną wycofane, Firebase zdecydowanie zaleca natychmiastowe uaktualnienie wszystkich zmigrowanych funkcji do pakietu SDK w wersji 2 podczas tego przejścia. Jest to wymagane w przypadku zestawów funkcji.

Jako użytkownik rozszerzeń możesz też tworzyć własne zestawy funkcji, korzystając z przewodnika migracji użytkowników.

Czy przejście na samodzielnie zarządzane Cloud Functions zmieni rozliczenia klienta?

Zasadniczo nie. Wdrożone rozszerzenia już obciążają klientów kosztami podstawowych Google Cloud zasobów, z których korzystają, takich jak Cloud Functions wywołania Cloud Storage lub BigQuery miejsce na dane i zapytania. Jednak w okresie migracji klienci mogą ponieść niewielki, tymczasowy dodatkowy koszt, jeśli w celu zapewnienia bezpiecznego przejścia będą równolegle korzystać ze starszej funkcji Firebase Extensions i nowo wdrożonej funkcji zastępczej.

Jak wygląda rozliczenie w przypadku Mandiant lub innych specjalistycznych kont firmowych?

Ta zmiana dotyczy całej platformy i wpływa na wszystkie projekty Firebase i Google Cloud. Standardowe ustalenia dotyczące płatności i subskrypcji pozostają bez zmian. Jeśli klienci proszą o przyznanie środków w ramach umowy SLA z powodu przestoju związanego z wycofaniem usługi lub napotykają złożone wyjątki dotyczące płatności, przekaż sprawę bezpośrednio przez zwykłe kanały pomocy dotyczące płatności.

Jakie jest ryzyko utraty danych lub przestoju usługi podczas migracji?

Przenoszenie zarządzanych zasobów do baz kodu zarządzanych samodzielnie wiąże się z niewielkim ryzykiem przerwy w działaniu usługi lub utraty zdarzeń.

• Zakłócenie działania aktywatorów: jeśli stare aktywatory zostaną usunięte, zanim nowe zaczną działać, powstanie luka, w której zdarzenia (np. Cloud Firestorezapisywanie dokumentów) zostaną pominięte i trwale utracone. Aby uniknąć utraty danych, zalecamy wdrożenie zestawu zamiennego i sprawdzenie go przed usunięciem rozszerzenia.
• Brak uprawnień: jeśli nowo wdrożona baza kodu nie ma wymaganych uprawnień IAM, operacje takie jak zapisywanie w BigQuery będą kończyć się niepowodzeniem bez powiadamiania o tym lub będą powodować awarię w czasie działania. Dodaliśmy deklaratywne zabezpieczenia funkcji, więc pierwsze wdrożenie zestawu przez konto, które może wysyłać zapytania i ustawiać role oraz generować konto usługi, powinno rozwiązać ten problem.

Jak zapobiec utracie danych w przypadku kluczowego rozszerzenia eksportu Cloud Firestore–BigQuery?

Aby zapewnić bezpieczne przejście bez utraty danych, zespół pomocy musi zalecać użytkownikom przeprowadzenie przełączenia opartego na nakładaniu się, a nie na przerwie. Jest to domyślne ustawienie w przypadku migracji do zestawów:

1. Wdróż zestaw funkcji zamiennych, gdy rozszerzenie jest nadal zainstalowane i działa. Odczekaj kilka minut, aż Eventarc zostanie w pełni udostępniony.
2. Zapisz dokument testowy w obserwowanej kolekcji Cloud Firestore i sprawdź, czy nowa funkcja zarządzana samodzielnie zapisuje odpowiedni wiersz w tabeli dziennika zmian BigQuery (z nowym identyfikatorem zdarzenia).
3. Gdy potwierdzisz, że nowe wdrożenie działa, od razu odinstaluj lub wyłącz starsze rozszerzenie, aby zakończyć podwójne zapisywanie.
4. Okres nakładania się powinien być jak najkrótszy, aby zminimalizować koszt duplikowania przetwarzania każdego zapisu i możliwość wystąpienia zduplikowanych wierszy w surowym dzienniku zmian BigQuery.
5. W większości przypadków tabela surowych zmian (*_raw_changelog) usuwa duplikaty według insertID, a nawet jeśli w dzienniku zmian pojawią się zduplikowane wiersze, najnowszy widok tabeli (*_raw_latest) będzie prawidłowy.

Więcej informacji o migracji tego konkretnego rozszerzenia i o tym, jak odzyskać utracone dane, znajdziesz w pliku README.md.

Co zrobić, jeśli etap udostępniania cyklu życia zakończy się niepowodzeniem?

W ramach usługi zarządzanej zadania konfiguracyjne (takie jak tworzenie BigQueryzbiorów danych, tabel i widoków) były obsługiwane automatycznie. W modelu NPM zarządzanym samodzielnie są one wywoływane za pomocą funkcji kolejki zadań cyklu życia, np. w firestore-bigquery-export nazywa się ona initBigQuerySync.

Jeśli ten krok zakończy się niepowodzeniem lub nie zostanie uruchomiony automatycznie:

1. Sprawdź, czy konto usługi środowiska wykonawczego Cloud Functions ma przypisane wymagane role uprawnień. Na przykład w przypadku firestore-bigquery-export obejmuje to:

   • Aby utworzyć zasoby i wstawić wiersze: roles/bigquery.dataEditor
   • Aby uruchamiać zadania i tworzyć widoki: roles/bigquery.user
   • Aby dodać zadanie provisioningu do kolejki: roles/cloudtasks.enqueuer

2. Sprawdź, czy dzwoniący ma uprawnienia roles/cloudtasks.enqueuer.

3. Ręcznie uruchom ponownie polecenie inicjowania cyklu życia za pomocą interfejsu wiersza poleceń:

   firebase functions:lifecycle:run afterInstall KIT_INSTANCE_ID
   

4. Sprawdź logi Cloud Logging zarówno funkcji wyzwalającej, jak i wykonania kolejki zadań, aby zdiagnozować błędy uprawnień lub konfiguracji.

Jak przenoszone są dane logowania Secret Manager?

W modelu zarządzanym zasoby Secret Manager były automatycznie powiązane z instancjami rozszerzenia. Gdy używasz poleceń ext:migrate lub ext:export --mode functions, aby wyeksportować konfigurację rozszerzeń do pakietu funkcji, przestajemy zarządzać tymi kluczami tajnymi, aby po odinstalowaniu rozszerzenia pozostały one w projekcie. Jeśli w przyszłości zechcesz usunąć te klucze tajne, musisz to zrobić ręcznie w konsoli Google Cloud.

Co w sytuacji, gdy użytkownik chce uruchomić wiele instancji przeniesionego rozszerzenia?

Wprowadziliśmy zestawy funkcji, aby obsługiwać wiele instancji funkcji, podobnie jak w przypadku wielu wersji rozszerzenia. Każdy zestaw otrzyma unikalny identyfikator instancji zestawu, który jest podobny do bazy kodu i może być używany zamiennie z bazami kodu w poleceniach interfejsu CLI. Po wdrożeniu wszystkie funkcje w instancji pakietu będą miały prefiks kit-<instance-id>-, aby każda funkcja miała niepowtarzalną nazwę, podobnie jak prefiks ext-<extension-instance-id>- w przypadku rozszerzeń. Więcej informacji o korzystaniu z zestawów funkcji w ramach migracji znajdziesz w naszym przewodniku po migracji użytkowników.

Instalacja pakietu odbywa się za pomocą npm. Co zrobić, jeśli chcę użyć Yarn lub innego menedżera pakietów zgodnego z Node?

Obecnie nie planujemy obsługi Yarn ani innych menedżerów pakietów. Instalacja pakietu polega na bezpośrednim wykonywaniu poleceń npm podczas konfigurowania kodu źródłowego pakietu przy pierwszej instalacji.

Możesz też utworzyć katalog źródłowy, samodzielnie zainstalować pakiet npm zestawu i skonfigurować go za pomocą odpowiednich kompilacji i eksportów. Jako przykładu możesz użyć naszych szablonów TypeScript index-kit w firebase-tools lub zainstalowanego za pomocą npm pakietu. Gdy to zrobisz, możesz zainstalować go jak lokalny zestaw za pomocą --directory zamiast --package. Od teraz musisz identyfikować zestaw według katalogu lub identyfikatora, ale możesz używać poleceń zestawu do dodawania i usuwania instancji.

Moje rozszerzenie korzysta z zaawansowanych parametrów systemowych repozytorium Dockera lub klucza KMS. Jak mogę to skonfigurować w zestawach funkcji?

Obecnie nie obsługujemy konfigurowania repozytorium Dockera ani klucza KMS w Cloud Functions dla Firebase. Jeśli przeprowadzasz migrację z rozszerzenia, w którym skonfigurowano te parametry systemowe, i chcesz zachować tę funkcję, możesz zastosować parametry do funkcji nowego zestawu za pomocą funkcji gcloud CLI.

Wymagania wstępne

1. Początkowo wdróż zestaw funkcji zgodnie z przewodnikami migracji, aby funkcje istniały w Google Cloud.

2. Zdefiniuj zmienne środowiskowe w terminalu:

   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. Utwórz wstępnie folder .gcloudignore w katalogu głównym źródła zestawu, aby skompilowane pliki kompilacji nie były ignorowane przez .gitignore:

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

4. Przyznaj wymagane uprawnienia IAM:

   • W przypadku kluczy KMS (przyznaje agentom usługi dostęp do odszyfrowywania):

     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
     

   • W przypadku Artifact Registry (przyznaje uprawnienia do zapisu w Cloud Build i odczytu w 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"
     

Stosowanie ustawień za pomocą ikony gcloud CLI

Uruchom gcloud functions deploy dla każdej funkcji w zestawie:

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

Pamiętaj, że to rozwiązanie przestaje działać w tych sytuacjach:

1. Nowe instancje zestawu: dodanie instancji w firebase.json tworzy nowy zasób Cloud Functions w wersji 2, który domyślnie korzysta z kluczy zarządzanych przez Google i gcf-artifacts. W przypadku każdej nowej instancji musisz uruchomić gcloud.
2. Ponowne tworzenie funkcji: zmiana typu wyzwalacza (np. z HTTPS na wyzwalacz Cloud Firestore), zmiana punktu wejścia lub zmiana nazwy powoduje, że interfejs Firebase CLI usuwa starą funkcję i tworzy nową. Nowa funkcja utraci te ustawienia, dopóki nie uruchomisz ponownie gcloud.
3. Rozbieżność konfiguracji: interfejs Firebase CLI nie wyświetla stanu KMS ani repozytorium Dockera w firebase functions:list ani w dziennikach różnic, co utrudnia audytowanie infrastruktury.

Sprawdzanie powodzenia

Aby sprawdzić, czy repozytorium i klucz szyfrowania zostały zastosowane, uruchom to polecenie:

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