Câu hỏi thường gặp về việc ngừng cung cấp Tiện ích Firebase

Tại sao chúng tôi ngừng cung cấp Firebase Extensions?

Do những thay đổi và việc ngừng cung cấp sắp tới trong cơ sở hạ tầng Google Cloud cơ bản của chúng tôi, chúng tôi sẽ ngừng cung cấp dịch vụ Firebase Extensions được quản lý.

Các tiện ích đã triển khai hiện có có ngừng hoạt động sau ngày 31 tháng 3 năm 2027 không?

Không. Các tiện ích đã triển khai sẽ chạy trực tiếp trên cơ sở hạ tầng Google Cloud tiêu chuẩn (chẳng hạn như Cloud Functions, Eventarc, Cloud Run và Cloud Tasks) và sẽ tiếp tục thực thi vô thời hạn.

Tuy nhiên, sau ngày 31 tháng 3 năm 2027, bạn sẽ mất toàn bộ khả năng cập nhật, định cấu hình lại hoặc gỡ cài đặt các tiện ích này thông qua bảng điều khiển Firebase hoặc CLI. Bạn cũng sẽ mất khả năng tải các cấu hình tiện ích hiện có xuống để hỗ trợ việc di chuyển sang một bộ chức năng. Bạn nên di chuyển hoặc xuất cấu hình tiện ích trước ngày 31 tháng 3 năm 2027.

Điều gì xảy ra nếu người dùng không làm gì cả?

Nếu người dùng không làm gì cả, các hàm đã triển khai hiện có của họ sẽ tiếp tục chạy dưới dạng tài sản tiêu chuẩn. Tuy nhiên, sau ngày 31 tháng 3 năm 2027:

1. Họ không thể thay đổi các thông số cấu hình hoặc cập nhật các biến môi trường.
2. Họ không thể áp dụng các bản sửa lỗi, bản vá bảo mật hoặc bản nâng cấp phần phụ thuộc.
3. Chúng không thể tải cấu hình tiện ích xuống để giúp định cấu hình giống hệt một bộ chức năng thay thế.
4. Hầu hết các tiện ích hiện được xây dựng trên SDK Cloud Functions phiên bản 1 cũ, được liên kết với các thời gian chạy Node.js cũ. Sau khi Google Cloud ngừng hoạt động hoàn toàn các thời gian chạy cũ này, các hàm có thể ngừng chạy hoặc bị vô hiệu hoá. Xem phần Hỗ trợ thời gian chạy.

Có sản phẩm nào thay thế Tiện ích Firebase không?

Chúng tôi đã thêm nhiều tính năng vào Cloud Functions để chúng có thể thay thế các tiện ích. Đặc biệt là các bộ hàm có thể được phân phối bằng npm và cho phép bạn triển khai nhiều phiên bản hàm, tương tự như cách bạn có thể cài đặt nhiều tiện ích trong một dự án duy nhất.

Tuy nhiên, mỗi nhà xuất bản tiện ích sẽ tự quyết định xem họ có muốn xuất bản một phiên bản thay thế chính thức của bộ hàm trên npm hay không. Vì các tiện ích là mã nguồn mở, nên nếu nhà xuất bản không muốn thay thế chính thức, thì nhà phát triển nào cũng có thể phát triển nhánh tiện ích đó để tạo một tiện ích thay thế không chính thức bằng Cloud Functions bằng cách sử dụng API thế hệ thứ 2 trong Node SDK.

Những nhà xuất bản muốn thay thế nên làm theo hướng dẫn trong hướng dẫn di chuyển dành cho nhà xuất bản.

Những người dùng muốn tận dụng các gói thay thế chính thức hoặc tạo gói thay thế của riêng mình có thể làm theo hướng dẫn trong hướng dẫn di chuyển dành cho người dùng.

Tôi nên làm gì với tư cách là người dùng tiện ích?

Nếu bạn là người dùng tiện ích và không còn sử dụng các tiện ích đã cài đặt, hãy gỡ cài đặt các tiện ích đó trước ngày 31 tháng 3 năm 2027.

Sau khi ngừng hoạt động, nút "Gỡ cài đặt" trong bảng điều khiển Firebase và các lệnh CLI tương ứng sẽ bị xoá. Bạn phải xoá tất cả các tài nguyên Google Cloud được liên kết theo cách thủ công, bao gồm cả Cloud Functions riêng lẻ, Secret Manager bí mật, Cloud Tasks hàng đợi và tài khoản dịch vụ IAM tuỳ chỉnh, bằng cách sử dụng bảng điều khiển Google Cloud.

Tuy nhiên, nếu đang sử dụng các tiện ích đã cài đặt, bạn nên di chuyển sang bộ công cụ chức năng. Để chuyển sang bộ công cụ chức năng, hãy làm theo hướng dẫn trong hướng dẫn di chuyển dành cho người dùng.

Bạn có thể chọn không di chuyển sang bộ chức năng. Trong trường hợp đó, bạn nên cập nhật tất cả các tiện ích của mình lên phiên bản mới nhất, luôn cập nhật các tiện ích đó và xuất cấu hình tiện ích hiện có trong trường hợp bạn muốn di chuyển sau này.

Tôi nên làm gì với tư cách là nhà xuất bản tiện ích?

Bạn nên di chuyển các tiện ích đã xuất bản sang bộ chức năng được xuất bản trên npm. Bạn có thể bắt đầu bằng cách di chuyển tiện ích của mình sang các hàm thế hệ thứ 2. Đây là điều kiện tiên quyết để tạo một bộ hàm. Việc này liên quan đến việc đóng gói logic mở rộng bằng SDK Cloud Functions phiên bản 2. Chúng tôi đã cập nhật SDK Cloud Functions phiên bản 2 để hỗ trợ các tính năng như bảo mật khai báo và sự kiện trong vòng đời. Giờ đây, bạn có thể di chuyển mã tiện ích hiện có sang hàm thế hệ thứ 2 mà chỉ cần thay đổi tối thiểu đối với logic kinh doanh cốt lõi. Bạn có thể xuất bản các hàm này bằng gói npm. Để biết thông tin chi tiết, hãy xem hướng dẫn di chuyển dành cho nhà xuất bản.

Nếu tôi có câu hỏi khác thì sao?

Người dùng có thắc mắc có thể tham khảo hướng dẫn di chuyển người dùng của chúng tôi. Nếu vẫn còn thắc mắc sau khi tham khảo hướng dẫn này, bạn có thể liên hệ với Nhóm hỗ trợ Firebase.

Những nhà xuất bản có thắc mắc về cách di chuyển Firebase Extensions có thể tham khảo hướng dẫn di chuyển dành cho nhà xuất bản. Hướng dẫn này bao gồm các chỉ dẫn về cách bạn có thể nắm bắt thông tin cập nhật và nhận trợ giúp để cung cấp giải pháp thay thế cho các tiện ích đã xuất bản.

Những đường di chuyển chính hiện có là gì?

Kể từ tháng 9 năm 2026, Firebase sẽ chính thức hỗ trợ 2 lộ trình di chuyển chính:

1. Di chuyển sang Hàm dùng chung NPM ("bộ hàm"): Nên dùng cho Stream Firestore sang BigQuery và mọi bộ hàm khác có trên npm. Logic cốt lõi được đóng gói dưới dạng một thư viện NPM tiêu chuẩn bằng cách sử dụng SDK Cloud Functions phiên bản 2. Người dùng khởi tạo một toàn bộ mã nguồn Cloud Functions tiêu chuẩn, cài đặt gói, xuất lại các hàm và triển khai chúng một cách độc lập bằng CLI.
2. Phát triển nhánh và tự quản lý: Nên dùng cho tất cả các tiện ích không có bộ công cụ chức năng trên npm. Người dùng sao chép hoặc phát triển nhánh mã nguồn mở của tiện ích, cải tiến các điều kiện kích hoạt thành các Hàm Firebase phiên bản 2 tiêu chuẩn bằng cách sử dụng các kỹ năng di chuyển AI tốt nhất hoặc hướng dẫn thủ công, đồng thời nắm toàn quyền sở hữu toàn bộ mã nguồn và hoạt động bảo trì liên tục của toàn bộ mã nguồn đó.

Những tiện ích nào đang được di chuyển sang bộ công cụ chức năng?

Tiện ích Stream Firestore to BigQuery (Truyền trực tuyến Firestore đến BigQuery) đã được di chuyển sang một bộ hàm có sẵn dưới dạng gói npm @firebase-function-kits/firestore-bigquery-export.

Tại sao quá trình di chuyển yêu cầu nâng cấp từ Cloud Functions phiên bản 1 lên phiên bản 2?

Cloud Functions phiên bản 1 sẽ ngừng hỗ trợ tiêu chuẩn với thời gian chạy Node.js 22. Để ngăn chặn tình trạng "di chuyển hai lần" khi nhà phát triển di chuyển khỏi Firebase Extensions chỉ để buộc phải tái cấu trúc thủ công lần thứ hai khi các thời gian chạy cũ ngừng hoạt động, Firebase đặc biệt khuyến khích việc nâng cấp tất cả các hàm đã di chuyển lên SDK phiên bản 2 ngay trong quá trình chuyển đổi này và đây là yêu cầu bắt buộc đối với các bộ hàm.

Là người dùng Tiện ích, bạn cũng có thể tạo bộ hàm của riêng mình bằng cách sử dụng hướng dẫn di chuyển người dùng.

Việc di chuyển sang Cloud Functions tự quản lý có làm thay đổi thông tin thanh toán của khách hàng không?

Thường thì không. Các tiện ích đã triển khai sẽ tính phí khách hàng cho các tài nguyên Google Cloud cơ bản mà họ sử dụng, chẳng hạn như lệnh gọi Cloud Functions, Cloud Storage hoặc bộ nhớ và truy vấn BigQuery. Tuy nhiên, trong thời gian di chuyển, khách hàng có thể phải chịu một khoản chi phí bổ sung nhỏ, tạm thời nếu họ chạy song song cả Firebase Extensions cũ và chức năng thay thế mới triển khai để đảm bảo quá trình chuyển đổi diễn ra an toàn.

Việc thanh toán được xử lý như thế nào đối với Mandiant hoặc các tài khoản doanh nghiệp chuyên biệt khác?

Việc ngừng sử dụng này là một thay đổi trên toàn nền tảng, ảnh hưởng đến tất cả các dự án Firebase và Google Cloud. Các thoả thuận thanh toán và gói thuê bao tiêu chuẩn sẽ không bị ảnh hưởng. Nếu khách hàng yêu cầu cấp tín dụng theo SLA do thời gian ngừng hoạt động vì ngừng cung cấp hoặc gặp phải các trường hợp ngoại lệ phức tạp về việc thanh toán, hãy chuyển trực tiếp trường hợp đó lên các kênh hỗ trợ thanh toán thông thường.

Rủi ro mất dữ liệu hoặc thời gian ngừng dịch vụ trong quá trình di chuyển là bao nhiêu?

Việc chuyển đổi tài nguyên được quản lý sang cơ sở mã tự quản lý có thể gây ra một rủi ro nhỏ về việc gián đoạn dịch vụ hoặc mất sự kiện.

• Gây gián đoạn cho điều kiện kích hoạt: Nếu các điều kiện kích hoạt cũ bị xoá trước khi các điều kiện kích hoạt mới hoạt động, thì sẽ có một khoảng trống nơi các sự kiện (ví dụ: thao tác ghi tài liệu Cloud Firestore) bị bỏ lỡ và mất vĩnh viễn. Bạn nên triển khai bộ thay thế và xác thực bộ thay thế đó trước khi tháo tiện ích để tránh mất dữ liệu.
• Khoảng trống về quyền: Nếu toàn bộ mã nguồn mới triển khai thiếu các quyền IAM cần thiết, thì các thao tác (chẳng hạn như ghi vào BigQuery) sẽ tự động không thực hiện được hoặc gặp sự cố trong thời gian chạy. Chúng tôi đã thêm tính năng bảo mật khai báo cho các hàm, vì vậy, lần triển khai bộ công cụ đầu tiên do một tài khoản có thể truy vấn và đặt vai trò cũng như tạo tài khoản dịch vụ thực hiện sẽ giảm thiểu vấn đề này.

Làm cách nào để ngăn chặn mất dữ liệu cho tiện ích Xuất Cloud Firestore sang BigQuery quan trọng?

Để đạt được quá trình chuyển đổi an toàn và không mất dữ liệu, nhóm hỗ trợ phải khuyên người dùng nên thực hiện quy trình chuyển đổi dựa trên sự trùng lặp thay vì dựa trên khoảng trống. Đây là lựa chọn mặc định khi di chuyển sang các bộ công cụ:

1. Triển khai bộ chức năng thay thế trong khi tiện ích vẫn được cài đặt và đang chạy. Chờ vài phút để Eventarc cấp phép hoàn toàn.
2. Viết một tài liệu kiểm thử vào bộ sưu tập Cloud Firestore được theo dõi và xác minh rằng hàm tự quản lý mới đã ghi thành công một hàng tương ứng vào bảng nhật ký thay đổi BigQuery (mang một mã sự kiện mới).
3. Sau khi xác nhận rằng quy trình triển khai mới đang hoạt động, hãy gỡ cài đặt hoặc vô hiệu hoá ngay tiện ích cũ để chấm dứt hành vi ghi kép.
4. Giữ khoảng thời gian trùng lặp ngắn nhất có thể để giảm thiểu chi phí xử lý trùng lặp của mỗi thao tác ghi và khả năng có các hàng trùng lặp trong nhật ký thay đổi BigQuery thô.
5. Trong hầu hết các trường hợp, Bảng nhật ký thay đổi thô (*_raw_changelog) sẽ loại bỏ các mục trùng lặp theo insertID và ngay cả trong trường hợp bạn nhận được các hàng trùng lặp trong nhật ký thay đổi, chế độ xem mới nhất của bảng (*_raw_latest) sẽ chính xác.

Thông tin chi tiết về cách di chuyển tiện ích này nói riêng và cách khôi phục dữ liệu bị mất có trong README.md của bộ công cụ.

Tôi nên làm gì nếu bước cấp phép theo vòng đời không thành công?

Trong dịch vụ được quản lý, các tác vụ thiết lập (chẳng hạn như tạo BigQuery tập dữ liệu, bảng và khung hiển thị) được xử lý tự động. Theo mô hình NPM tự quản lý, các sự kiện này được kích hoạt bằng cách sử dụng một hàm hàng đợi tác vụ vòng đời; ví dụ: trong firestore-bigquery-export, hàm này được gọi là initBigQuerySync.

Nếu bước này không thành công hoặc không chạy tự động:

1. Xác minh rằng tài khoản dịch vụ thời gian chạy Cloud Functions đã được cấp các vai trò IAM cần thiết. Ví dụ: đối với firestore-bigquery-export, điều này bao gồm:

   • Cách tạo tài nguyên và chèn hàng: roles/bigquery.dataEditor
   • Cách chạy các thao tác và tạo chế độ xem: roles/bigquery.user
   • Cách đưa việc cần làm về việc cung cấp vào hàng đợi: roles/cloudtasks.enqueuer

2. Xác nhận rằng phương thức gọi có quyền roles/cloudtasks.enqueuer.

3. Chạy lại lệnh khởi động vòng đời theo cách thủ công bằng giao diện dòng lệnh:

   firebase functions:lifecycle:run afterInstall KIT_INSTANCE_ID
   

4. Kiểm tra nhật ký Cloud Logging cho cả hàm kích hoạt và quá trình thực thi hàng đợi tác vụ để chẩn đoán mọi lỗi về quyền hoặc cấu hình.

Thông tin đăng nhập Secret Manager được di chuyển như thế nào?

Theo mô hình được quản lý, các tài nguyên Secret Manager sẽ tự động được liên kết với các thực thể tiện ích. Khi bạn dùng lệnh ext:migrate hoặc ext:export --mode functions để xuất cấu hình tiện ích sang một bộ công cụ hàm, chúng tôi sẽ ngăn tiện ích quản lý các khoá bí mật này để chúng vẫn nằm trong dự án của bạn sau khi tiện ích bị gỡ cài đặt. Nếu muốn xoá các khoá bí mật này trong tương lai, bạn phải xoá theo cách thủ công trong bảng điều khiển Google Cloud.

Điều gì xảy ra nếu người dùng muốn chạy nhiều phiên bản của một tiện ích đã di chuyển?

Chúng tôi đã giới thiệu bộ hàm để hỗ trợ nhiều phiên bản của một hàm, tương tự như cách bạn có thể có nhiều phiên bản của một tiện ích. Mỗi bộ công cụ sẽ có một mã nhận dạng riêng biệt cho thực thể bộ công cụ, tương tự như một toàn bộ mã nguồn và có thể dùng thay thế cho toàn bộ mã nguồn trong các lệnh CLI. Khi được triển khai, tất cả các hàm trong một phiên bản của bộ công cụ sẽ có tiền tố kit-<instance-id>- để đảm bảo mọi hàm đều có tên riêng biệt, tương tự như tiền tố ext-<extension-instance-id>- trong các tiện ích. Để tìm hiểu thêm về cách sử dụng bộ công cụ chức năng trong quá trình di chuyển, hãy xem hướng dẫn di chuyển người dùng của chúng tôi.

Kit install sử dụng npm; nếu tôi muốn dùng Yarn hoặc một trình quản lý gói khác tương thích với Node thì sao?

Hiện tại, chúng tôi không có kế hoạch hỗ trợ Yarn hoặc các trình quản lý gói khác. Quy trình cài đặt bộ công cụ hoạt động bằng cách trực tiếp thực thi các lệnh npm khi thiết lập mã nguồn bộ công cụ trong lần cài đặt đầu tiên.

Ngoài ra, bạn có thể tạo một thư mục nguồn, tự cài đặt gói npm của bộ công cụ và thiết lập gói này bằng các bản dựng và tệp xuất phù hợp. Tham khảo các mẫu index-kit TypeScript của chúng tôi trong firebase-tools hoặc xem một bộ công cụ đã cài đặt npm làm ví dụ. Sau khi thực hiện việc này, bạn có thể cài đặt nó như một bộ công cụ cục bộ bằng cách sử dụng --directory thay vì --package. Từ giờ trở đi, bạn sẽ cần xác định bộ công cụ theo thư mục hoặc mã nhận dạng, nhưng bạn có thể dùng các lệnh của bộ công cụ để thêm và xoá các phiên bản.

Tiện ích của tôi sử dụng các thông số hệ thống nâng cao của kho lưu trữ Docker hoặc khoá KMS; làm cách nào để tôi định cấu hình thông số này trong bộ công cụ hàm?

Hiện tại, chúng tôi không hỗ trợ việc định cấu hình kho lưu trữ Docker hoặc khoá KMS trong Cloud Functions cho Firebase. Nếu đang di chuyển từ một tiện ích có các tham số hệ thống này được định cấu hình và muốn giữ lại chức năng này, bạn có thể áp dụng các tham số cho các hàm của bộ công cụ mới bằng cách sử dụng gcloud CLI.

Điều kiện tiên quyết

1. Ban đầu, hãy triển khai bộ hàm theo hướng dẫn di chuyển để các hàm tồn tại trong Google Cloud.

2. Xác định các biến môi trường trong thiết bị đầu cuối:

   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. Tạo trước .gcloudignore trong thư mục gốc của nguồn của bộ công cụ để .gitignore không bỏ qua các tệp bản dựng đã biên dịch:

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

4. Cấp các quyền IAM bắt buộc:

   • Đối với khoá KMS (cấp quyền giải mã cho các tác nhân dịch vụ):

     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
     

   • Đối với Artifact Registry (cấp quyền ghi cho Cloud Build và quyền đọc cho 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"
     

Áp dụng chế độ cài đặt bằng cách sử dụng gcloud CLI

Chạy gcloud functions deploy cho từng hàm trong bộ công cụ của bạn:

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

Xin lưu ý rằng giải pháp này sẽ không hoạt động trong các trường hợp sau:

1. Các phiên bản bộ khoá mới: Việc thêm một phiên bản trong firebase.json sẽ tạo một tài nguyên Cloud Functions v2 mới, mặc định là các khoá do Google quản lý và gcf-artifacts. Bạn phải chạy gcloud cho mỗi phiên bản mới.
2. Tạo lại hàm: Việc thay đổi loại trình kích hoạt (ví dụ: từ HTTPS sang trình kích hoạt Cloud Firestore), sửa đổi điểm nhập hoặc đổi tên sẽ khiến CLI Firebase xoá hàm cũ và tạo một hàm mới. Chức năng mới sẽ mất các chế độ cài đặt này cho đến khi bạn chạy lại gcloud.
3. Sai lệch cấu hình: CLI Firebase không hiển thị trạng thái KMS hoặc kho lưu trữ Docker trong firebase functions:list hoặc nhật ký chênh lệch, điều này gây khó khăn cho việc kiểm tra cơ sở hạ tầng.

Xác minh thành công

Để xác nhận rằng kho lưu trữ và khoá mã hoá đã được áp dụng, hãy chạy lệnh sau:

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