FAQ Penghentian Penggunaan Firebase Extensions

Mengapa kami menghentikan penggunaan Firebase Extensions?

Karena perubahan dan penghentian penggunaan yang akan datang dalam Google Cloudinfrastruktur dasar kami, kami akan menghentikan layanan terkelola Firebase Extensions.

Apakah ekstensi yang sudah di-deploy akan berhenti berfungsi setelah 31 Maret 2027?

Tidak. Ekstensi yang sudah di-deploy berjalan langsung di infrastruktur Google Cloud standar (seperti Cloud Functions, Eventarc, Cloud Run, dan Cloud Tasks) dan akan terus dieksekusi tanpa batas waktu.

Namun, setelah 31 Maret 2027, Anda tidak akan dapat lagi mengupdate, mengonfigurasi ulang, atau meng-uninstal ekstensi ini melalui konsol atau CLI Firebase. Anda juga akan kehilangan kemampuan untuk mendownload konfigurasi ekstensi yang ada untuk membantu migrasi ke kit fungsi. Sebaiknya migrasikan atau ekspor konfigurasi ekstensi sebelum 31 Maret 2027.

Apa yang terjadi jika pengguna tidak melakukan tindakan apa pun?

Jika pengguna tidak melakukan tindakan apa pun, fungsi yang sudah di-deploy akan terus berjalan sebagai aset standar. Namun, setelah 31 Maret 2027:

1. Mereka tidak dapat mengubah parameter konfigurasi atau memperbarui variabel lingkungan.
2. Mereka tidak dapat menerapkan perbaikan bug, patch keamanan, atau upgrade dependensi.
3. Mereka tidak dapat mendownload konfigurasi ekstensi untuk membantu mengonfigurasi kit fungsi pengganti secara identik.
4. Sebagian besar ekstensi saat ini dibangun di SDK Cloud Functions v1 lama, yang terkait dengan runtime Node.js yang lebih lama. Setelah runtime lama ini dihentikan sepenuhnya oleh Google Cloud, fungsi dapat berhenti berjalan atau dinonaktifkan. Lihat Dukungan runtime.

Apakah ada yang menggantikan Firebase Extensions?

Kami telah menambahkan banyak fitur ke Cloud Functions agar dapat menggantikan ekstensi. Terutama kit fungsi yang dapat didistribusikan menggunakan npm dan memungkinkan Anda men-deploy beberapa instance fungsi, mirip dengan cara Anda dapat menginstal ekstensi beberapa kali dalam satu project.

Namun, setiap penayang ekstensi berhak menentukan apakah mereka ingin memublikasikan penggantian kit fungsi resmi di npm. Karena ekstensi bersifat open source, jika penayang tidak ingin membuat pengganti resmi, developer mana pun dapat membuat fork untuk membuat pengganti tidak resmi dengan Cloud Functions menggunakan API generasi ke-2 di Node SDK.

Penayang yang ingin melakukan penggantian harus mengikuti petunjuk dalam panduan migrasi untuk penayang.

Pengguna yang ingin memanfaatkan paket penggantian resmi atau membuat penggantian sendiri dapat mengikuti petunjuk dalam panduan migrasi untuk pengguna.

Apa yang harus saya lakukan sebagai pengguna ekstensi?

Jika Anda adalah pengguna ekstensi dan tidak lagi menggunakan ekstensi yang terinstal, uninstal ekstensi tersebut sebelum 31 Maret 2027.

Setelah penonaktifan, tombol "Uninstall" di konsol Firebase dan perintah CLI yang sesuai akan dihapus. Anda harus menghapus semua resource Google Cloud terkait secara manual, termasuk Cloud Functions, secret Secret Manager, antrean Cloud Tasks, dan akun layanan IAM kustom satu per satu, menggunakan konsol Google Cloud.

Namun, jika Anda aktif menggunakan ekstensi yang diinstal, sebaiknya migrasikan ke kit fungsi. Untuk beralih ke kit fungsi, gunakan petunjuk dalam panduan migrasi untuk pengguna.

Anda dapat memilih untuk tidak melakukan migrasi ke kit fungsi, dan dalam hal ini, sebaiknya Anda mengupdate semua ekstensi ke versi terbarunya, terus mengupdatenya, dan mengekspor konfigurasi ekstensi yang ada jika Anda ingin melakukan migrasi nanti.

Apa yang harus saya lakukan sebagai penayang ekstensi?

Sebaiknya migrasikan ekstensi yang dipublikasikan ke kit fungsi yang dipublikasikan di npm. Anda dapat memulai dengan memigrasikan ekstensi ke fungsi generasi ke-2, yang merupakan prasyarat untuk membuat kit fungsi. Hal ini melibatkan pengemasan logika ekstensi menggunakan SDK Cloud Functions v2. Kami telah mengupdate SDK Cloud Functions v2 dengan dukungan untuk fitur seperti keamanan deklaratif dan peristiwa siklus proses. Sekarang Anda dapat memigrasikan kode ekstensi yang ada ke fungsi generasi ke-2 dengan perubahan minimal pada logika bisnis inti Anda. Fungsi ini dapat dipublikasikan menggunakan paket npm. Untuk mengetahui detailnya, lihat panduan migrasi untuk penayang kami.

Bagaimana jika saya memiliki pertanyaan lain?

Pengguna yang memiliki pertanyaan dapat menggunakan panduan migrasi pengguna kami. Jika masih ada pertanyaan setelah menggunakan panduan ini, Anda dapat menghubungi Dukungan Firebase.

Penayang yang memiliki pertanyaan tentang cara melakukan migrasi Firebase Extensions dapat menggunakan panduan migrasi untuk penayang kami. Panduan ini berisi petunjuk tentang cara mendapatkan informasi terbaru dan mendapatkan bantuan untuk menyediakan alternatif bagi ekstensi yang Anda publikasikan.

Apa jalur migrasi utama yang tersedia?

Mulai September 2026, Firebase secara resmi mendukung dua jalur migrasi utama:

1. Bermigrasi ke Fungsi Bersama NPM ("function kit"): Direkomendasikan untuk Stream Firestore ke BigQuery dan function kit lainnya yang tersedia di npm. Logika inti dikemas sebagai library NPM standar menggunakan Cloud Functions SDK v2. Pengguna melakukan inisialisasi codebase Cloud Functions standar, menginstal paket, mengekspor ulang fungsi, dan men-deploy-nya secara independen menggunakan CLI.
2. Fork dan Kelola Sendiri: Direkomendasikan untuk semua ekstensi yang tidak memiliki function kit yang tersedia di npm. Pengguna menyalin atau membuat cabang kode sumber ekstensi open source, memfaktorkan ulang pemicu ke dalam Fungsi Firebase v2 standar menggunakan keterampilan migrasi AI terbaik atau panduan manual, dan mengambil kepemilikan penuh atas codebase dan pemeliharaannya yang berkelanjutan.

Ekstensi mana yang dimigrasikan ke kit fungsi?

Ekstensi Stream Firestore to BigQuery telah dimigrasikan ke kit fungsi yang tersedia sebagai paket npm @firebase-function-kits/firestore-bigquery-export.

Mengapa migrasi memerlukan upgrade dari Cloud Functions v1 ke v2?

Dukungan standar Cloud Functions v1 berakhir dengan runtime Node.js 22. Untuk mencegah "migrasi ganda" saat developer bermigrasi dari Firebase Extensions hanya untuk dipaksa melakukan refaktorisasi manual kedua saat runtime lama dihentikan, Firebase sangat merekomendasikan upgrade semua fungsi yang dimigrasikan ke SDK v2 segera selama transisi ini, dan hal ini diperlukan untuk kit fungsi.

Sebagai pengguna Ekstensi, Anda juga dapat membuat kit fungsi sendiri menggunakan panduan migrasi pengguna.

Apakah migrasi ke Cloud Functions yang dikelola sendiri akan mengubah penagihan pelanggan?

Umumnya, tidak. Ekstensi yang di-deploy sudah menagih pelanggan untuk resource Google Cloud pokok yang mereka gunakan, seperti pemanggilan Cloud Functions, Cloud Storage, atau BigQuery penyimpanan dan kueri. Namun, selama periode migrasi, pelanggan mungkin dikenai biaya tambahan kecil dan sementara jika menjalankan fungsi Firebase Extensions lama dan fungsi pengganti yang baru di-deploy secara paralel untuk memastikan peralihan yang aman.

Bagaimana penagihan ditangani untuk Mandiant atau akun perusahaan khusus lainnya?

Penghentian penggunaan ini adalah perubahan di seluruh platform yang memengaruhi semua project Firebase dan Google Cloud. Pengaturan penagihan dan langganan standar tidak terpengaruh. Jika pelanggan meminta kredit SLA karena waktu nonaktif akibat penghentian penggunaan atau mengalami pengecualian penagihan yang rumit, eskalasikan kasus langsung melalui saluran dukungan penagihan normal.

Apa risiko kehilangan data atau periode nonaktif layanan selama migrasi?

Mengubah resource terkelola menjadi codebase yang dikelola sendiri menimbulkan risiko kecil terjadinya gangguan layanan atau kehilangan peristiwa.

• Pemicu Gangguan: Jika pemicu lama dihapus sebelum pemicu baru aktif, akan ada kesenjangan yang menyebabkan peristiwa (misalnya, penulisan dokumen Cloud Firestore) terlewat dan hilang secara permanen. Sebaiknya deploy kit pengganti dan validasikan sebelum menghapus ekstensi untuk menghindari kehilangan data.
• Kekurangan Izin: Jika codebase yang baru di-deploy tidak memiliki izin IAM yang diperlukan, operasi, seperti menulis ke BigQuery, akan gagal tanpa ada peringatan atau error saat runtime. Kami telah menambahkan keamanan deklaratif untuk fungsi, sehingga deployment kit pertama yang dilakukan oleh akun yang dapat membuat kueri dan menetapkan peran serta membuat akun layanan akan mengurangi masalah ini.

Bagaimana cara mencegah kehilangan data untuk ekstensi Ekspor Cloud Firestore-ke-BigQuery yang penting?

Untuk mencapai transisi yang aman dan tanpa kehilangan data, dukungan harus menyarankan pengguna untuk mengikuti migrasi sistem berbasis tumpang-tindih, bukan yang berbasis kesenjangan. Ini adalah default dengan migrasi ke kit:

1. Deploy kit fungsi pengganti saat ekstensi masih diinstal dan berjalan. Tunggu beberapa menit hingga Eventarc selesai disediakan sepenuhnya.
2. Tulis dokumen pengujian ke koleksi Cloud Firestore yang dipantau dan verifikasi bahwa fungsi yang dikelola sendiri yang baru berhasil menulis baris yang sesuai ke tabel log perubahan BigQuery (membawa ID peristiwa baru).
3. Setelah deployment baru dikonfirmasi berfungsi, segera uninstal atau nonaktifkan ekstensi lama untuk menghentikan perilaku penulisan ganda.
4. Jaga agar jendela tumpang-tindih sesingkat mungkin untuk meminimalkan baris duplikat di log perubahan BigQuery mentah.

5. Penulisan ganda selama periode migrasi akan menghasilkan dua baris di Tabel Log Perubahan Mentah (*_raw_changelog) dengan data dokumen yang sama dan stempel waktu commit Cloud Firestore. Namun, tampilan terbaru tabel (*_raw_latest) akan benar.

Informasi selengkapnya tentang cara memigrasikan ekstensi ini secara khusus dan cara memulihkan data yang hilang dijelaskan dalam README.md kit.

Apa yang harus saya lakukan jika langkah penyediaan siklus proses gagal?

Dalam layanan terkelola, tugas penyiapan (seperti membuat BigQuery set data, tabel, dan tampilan) ditangani secara otomatis. Dalam model NPM yang dikelola sendiri, hal ini dipicu menggunakan fungsi task queue siklus proses; misalnya, di firestore-bigquery-export, hal ini disebut initBigQuerySync.

Jika langkah ini gagal atau tidak berjalan secara otomatis:

1. Pastikan akun layanan runtime Cloud Functions telah diberi peran IAM yang diperlukan. Misalnya, untuk firestore-bigquery-export, hal ini mencakup:

   • Untuk membuat resource dan menyisipkan baris: roles/bigquery.dataEditor
   • Untuk menjalankan tugas dan membuat tampilan: roles/bigquery.user
   • Untuk mengantrekan tugas penyediaan: roles/cloudtasks.enqueuer

2. Pastikan pemanggil memiliki izin roles/cloudtasks.enqueuer.

3. Jalankan kembali perintah inisialisasi siklus proses secara manual menggunakan CLI:

   firebase functions:lifecycle:run afterInstall KIT_INSTANCE_ID
   

4. Periksa log Cloud Logging untuk fungsi pemicu dan eksekusi task queue guna mendiagnosis error izin atau konfigurasi.

Bagaimana kredensial Secret Manager dimigrasikan?

Dalam model terkelola, resource Secret Manager otomatis terikat ke instance ekstensi. Saat Anda menggunakan perintah ext:migrate atau ext:export --mode functions untuk mengekspor konfigurasi ekstensi ke kit fungsi, kami akan menghentikan ekstensi mengelola secret ini sehingga secret tetap berada di project Anda setelah ekstensi di-uninstal. Jika ingin menghapus rahasia ini pada masa mendatang, Anda harus melakukannya secara manual di konsol Google Cloud.

Bagaimana jika pengguna ingin menjalankan beberapa instance ekstensi yang dimigrasikan?

Kami memperkenalkan kit fungsi sebagai cara untuk mendukung beberapa instance fungsi mirip dengan cara Anda dapat memiliki beberapa versi ekstensi. Setiap kit akan mendapatkan ID instance kit unik, yang mirip dengan codebase dan dapat digunakan secara bergantian dengan codebase dalam perintah CLI. Saat di-deploy, semua fungsi dalam instance kit akan diawali dengan kit-<instance-id>- untuk memastikan setiap fungsi memiliki nama yang unik, mirip dengan awalan ext-<extension-instance-id>- dalam ekstensi. Untuk mempelajari lebih lanjut cara menggunakan kit fungsi sebagai bagian dari migrasi, lihat panduan migrasi pengguna kami.

Penginstalan Kit menggunakan npm; bagaimana jika saya ingin menggunakan Yarn atau pengelola paket lain yang kompatibel dengan Node?

Saat ini kami tidak berencana mendukung Yarn atau pengelola paket lainnya. Penginstalan kit berfungsi dengan menjalankan perintah npm secara langsung saat menyiapkan kode sumber kit pada penginstalan pertama.

Sebagai alternatif, Anda dapat membuat direktori sumber, menginstal paket npm kit sendiri, dan menyiapkannya dengan build dan ekspor yang sesuai. Lihat template index-kit TypeScript kami di firebase-tools atau lihat contoh kit yang diinstal npm. Setelah melakukannya, Anda dapat menginstalnya seperti kit lokal menggunakan --directory, bukan --package. Selanjutnya, Anda harus mengidentifikasi kit berdasarkan direktori atau ID, tetapi Anda dapat menggunakan perintah kit untuk menambahkan dan menghapus instance.

Ekstensi saya menggunakan parameter sistem lanjutan kunci KMS atau repositori Docker; bagaimana cara mengonfigurasi ini di kit fungsi?

Saat ini, kami tidak mendukung konfigurasi repositori Docker atau kunci KMS di Cloud Functions untuk Firebase. Jika Anda bermigrasi dari ekstensi dengan parameter sistem ini yang dikonfigurasi dan ingin mempertahankan fungsi ini, Anda dapat menerapkan parameter ke fungsi kit baru menggunakan gcloud CLI.

Prasyarat

1. Deploy kit fungsi Anda terlebih dahulu dengan mengikuti panduan migrasi agar fungsi ada di Google Cloud.

2. Tentukan variabel lingkungan Anda di 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. Buat .gcloudignore terlebih dahulu di root sumber kit agar file build yang dikompilasi tidak diabaikan oleh .gitignore:

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

4. Berikan izin IAM yang diperlukan:

   • Untuk kunci KMS (memberikan akses dekripsi ke agen layanan):

     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
     

   • Untuk Artifact Registry (memberikan akses tulis ke Cloud Build dan akses baca ke 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"
     

Menerapkan setelan menggunakan gcloud CLI

Jalankan gcloud functions deploy untuk setiap fungsi di kit Anda:

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

Perhatikan bahwa solusi ini tidak berfungsi dalam kondisi berikut:

1. Instance kit baru: Menambahkan instance di firebase.json akan membuat resource Cloud Functions v2 baru yang secara default menggunakan kunci yang dikelola Google dan gcf-artifacts. Anda harus menjalankan gcloud untuk setiap instance baru.
2. Pembuatan ulang fungsi: Mengubah jenis pemicu (misalnya, dari HTTPS ke pemicu Cloud Firestore), mengubah titik entri, atau mengganti nama akan menyebabkan CLI Firebase menghapus fungsi lama dan membuat fungsi baru. Fungsi baru akan kehilangan setelan ini hingga Anda menjalankan gcloud lagi.
3. Penyimpangan konfigurasi: CLI Firebase tidak menampilkan status KMS atau repositori Docker di firebase functions:list atau log perbedaan, sehingga menyulitkan audit infrastruktur.

Memverifikasi keberhasilan

Untuk mengonfirmasi bahwa repositori dan kunci enkripsi telah diterapkan, jalankan perintah berikut:

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