Firebase Extensions desteğinin sonlandırılması hakkında SSS

Neden Firebase Extensions desteğini sonlandırıyoruz?

Temel Google Cloud altyapımızda yapılacak değişiklikler ve kullanımdan kaldırılacak özellikler nedeniyle, yönetilen Firebase Extensions hizmetini kullanımdan kaldıracağız.

Mevcut dağıtılmış uzantılar 31 Mart 2027'den sonra çalışmayı durduracak mı?

Hayır. Halihazırda dağıtılmış uzantılar doğrudan standart Google Cloud altyapısında (ör. Cloud Functions, Eventarc, Cloud Run ve Cloud Tasks) çalışır ve süresiz olarak yürütülmeye devam eder.

Ancak 31 Mart 2027'den sonra bu uzantıları Firebase konsolu veya CLI üzerinden güncelleyemeyecek, yeniden yapılandıramayacak ya da kaldıramayacaksınız. Ayrıca, işlev kitine geçişe yardımcı olması için mevcut uzantı yapılandırmalarınızı indirme olanağını da kaybedeceksiniz. Uzantı yapılandırmasını 31 Mart 2027'ye kadar taşımanızı veya dışa aktarmanızı önemle tavsiye ederiz.

Kullanıcı hiçbir şey yapmazsa ne olur?

Kullanıcı herhangi bir işlem yapmazsa mevcut dağıtılmış işlevleri standart öğeler olarak çalışmaya devam eder. Ancak 31 Mart 2027'den sonra:

1. Yapılandırma parametrelerini değiştiremez veya ortam değişkenlerini güncelleyemezler.
2. Hata düzeltmelerini, güvenlik yamalarını veya bağımlılık yükseltmelerini uygulayamazlar.
3. Yedek işlev kitini aynı şekilde yapılandırmak için uzantı yapılandırmasını indiremezler.
4. Çoğu uzantı şu anda eski Cloud Functions v1 SDK'sında oluşturuluyor. Bu SDK, eski Node.js çalışma zamanlarına bağlıdır. Bu eski çalışma zamanları Google Cloud tarafından tamamen devre dışı bırakıldıktan sonra işlevler çalışmayı durdurabilir veya devre dışı bırakılabilir. Çalışma zamanı desteği başlıklı makaleyi inceleyin.

Firebase Extensions'ın yerini alacak bir özellik var mı?

Cloud Functions'a, uzantıların yerini alabilecek birçok özellik ekledik. En önemlisi, npm kullanılarak dağıtılabilen ve işlevlerin birden fazla örneğini dağıtmanıza olanak tanıyan işlev kitleridir. Bu, uzantıları tek bir projede birden fazla kez yüklemeye benzer.

Ancak, npm'de resmi bir işlev kiti değişimi yayınlamak isteyip istemediklerine her uzantı yayıncısı karar verir. Uzantılar açık kaynaklı olduğundan yayıncı resmi bir alternatif oluşturmak istemezse herhangi bir geliştirici, Node SDK'daki 2. nesil API'lerimizi kullanarak Cloud Functions ile resmi olmayan bir alternatif oluşturmak için uzantıyı çatallayabilir.

Değişiklik yapmak isteyen yayıncılar yayıncılar için taşıma kılavuzundaki talimatları uygulamalıdır.

Resmi değiştirme paketlerinden yararlanmak veya kendi değiştirmelerini oluşturmak isteyen kullanıcılar, kullanıcılar için taşıma kılavuzundaki talimatları uygulayabilir.

Uzantı kullanıcısı olarak ne yapmalıyım?

Uzantı kullanıcısıysanız ve yüklediğiniz uzantıları artık kullanmıyorsanız 31 Mart 2027'den önce bu uzantıları kaldırın.

Devre dışı bırakma işleminden sonra Firebase konsolundaki "Kaldır" düğmesi ve ilgili CLI komutları kaldırılacak. Google Cloud konsolunu kullanarak, tek tek Cloud Functions, Secret Manager sırları, Cloud Tasks kuyrukları ve özel IAM hizmet hesapları da dahil olmak üzere ilişkili tüm Google Cloud kaynaklarını manuel olarak silmeniz gerekir.

Ancak, yüklü uzantılarınızı aktif olarak kullanıyorsanız işlev kitlerine geçmenizi önemle tavsiye ederiz. İşlev kitlerine geçmek için kullanıcılar için geçiş rehberimizdeki talimatları uygulayın.

İşlev kitlerine geçmemeyi tercih edebilirsiniz. Bu durumda, tüm uzantılarınızı en son sürümlerine güncellemenizi, güncel tutmanızı ve daha sonra geçmek isterseniz mevcut uzantı yapılandırmalarınızı dışa aktarmanızı önemle tavsiye ederiz.

Uzantı yayıncısı olarak ne yapmalıyım?

Yayınlanmış uzantılarınızı npm'de yayınlanan işlev kitlerine taşımanızı öneririz. Öncelikle uzantınızı 2. nesil işlevlere taşıyarak başlayabilirsiniz. Bu, işlev kiti oluşturmak için ön koşuldur. Bu işlem, Cloud Functions v2 SDK'sını kullanarak uzantı mantığınızı paketlemeyi içerir. Cloud Functions v2 SDK'sını, bildirim temelli güvenlik ve yaşam döngüsü etkinlikleri gibi özelliklerin desteğiyle güncelledik. Artık mevcut uzantı kodunuzu temel işletme mantığınızda minimum değişiklikle 2. nesil bir işleve taşıyabilirsiniz. Bu işlevler, bir npm paketi kullanılarak yayınlanabilir. Ayrıntılar için yayıncılar için taşıma kılavuzumuza bakın.

Başka sorularım olursa ne yapmalıyım?

Soruları olan kullanıcılar kullanıcı taşıma rehberimizi inceleyebilir. Rehberi kullandıktan sonra hâlâ sorularınız varsa Firebase Destek Ekibi ile iletişime geçebilirsiniz.

Geçiş yapma konusunda soruları olan yayıncılar Firebase Extensions yayıncılar için geçiş kılavuzumuzu kullanabilir. Bu kılavuzda, güncellemelerden nasıl haberdar olabileceğiniz ve yayınlanmış uzantılarınıza alternatif sunma konusunda nasıl yardım alabileceğinizle ilgili talimatlar yer almaktadır.

Kullanılabilecek başlıca taşıma yolları nelerdir?

Firebase, Eylül 2026'dan itibaren resmi olarak iki temel taşıma yolunu destekleyecektir:

1. NPM'de paylaşılan bir işleve ("işlev kiti") geçiş yapın: Firestore'u BigQuery'ye aktarma ve npm'de kullanıma sunulan diğer işlev kitleri için önerilir. Temel mantık, Cloud Functions v2 SDK'sı kullanılarak standart bir NPM kitaplığı olarak paketlenir. Kullanıcılar standart bir Cloud Functions kod tabanı başlatır, paketi yükler, işlevleri yeniden dışa aktarır ve CLI'yı kullanarak bunları bağımsız olarak dağıtır.
2. Çatallayın ve Kendi Kendinize Yönetin: npm'de işlev kiti bulunmayan tüm uzantılar için önerilir. Kullanıcılar, açık kaynaklı uzantı kaynak kodunu kopyalar veya çatallandırır, tetikleyicileri en iyi çaba yapay zeka taşıma becerilerini ya da manuel kılavuzları kullanarak standart Firebase v2 işlevlerine yeniden düzenler ve kod tabanının ve devam eden bakımının tam sahipliğini alır.

Hangi uzantılar işlev kitlerine taşınıyor?

Stream Firestore to BigQuery uzantısı, npm paketi @firebase-function-kits/firestore-bigquery-export olarak kullanılabilen bir işlev kitine taşındı.

Taşıma işlemi için neden Cloud Functions v1'den v2'ye yükseltme yapılması gerekiyor?

Cloud Functions v1 standart desteği, Node.js 22 çalışma zamanıyla sona erer. Geliştiricilerin Firebase Extensions'den geçiş yaptıktan sonra eski çalışma zamanları kullanımdan kaldırıldığında ikinci bir manuel yeniden düzenlemeye zorlanacağı "çift geçiş" durumunu önlemek için Firebase, bu geçiş sırasında tüm taşınan işlevlerin hemen v2 SDK'ya yükseltilmesini önemle tavsiye eder. Bu, işlev kitleri için zorunludur.

Extensions kullanıcısı olarak, kullanıcı taşıma kılavuzunu kullanarak kendi işlev kitlerinizi de oluşturabilirsiniz.

Kendi kendine yönetilen Cloud Functions'ya geçiş, müşterinin faturalandırmasını etkiler mi?

Genellikle hayır. Dağıtılan uzantılar, müşterilerden tükettikleri temel Google Cloud kaynaklar (ör. Cloud Functions çağırmalar, Cloud Storage veya BigQuery depolama ve sorgular) için zaten ücret almaktadır. Ancak geçiş döneminde, güvenli bir geçiş sağlamak için hem eski Firebase Extensions hem de yeni dağıtılan yedek işlevi paralel olarak çalıştıran müşteriler küçük ve geçici bir ek maliyete maruz kalabilir.

Mandiant veya diğer özel kurumsal hesaplar için faturalandırma nasıl yapılır?

Bu desteğin sonlandırılması, tüm Firebase ve Google Cloud projelerini etkileyen platform genelinde bir değişikliktir. Standart faturalandırma ve abonelik düzenlemeleri bu durumdan etkilenmez. Müşteriler, desteğin sonlandırılması nedeniyle yaşanan hizmet dışı kalma süresi veya karmaşık faturalandırma istisnaları nedeniyle HDS kredisi talep ederse konuyu doğrudan normal faturalandırma destek kanalları üzerinden üst birime iletin.

Taşıma sırasında veri kaybı veya hizmet kesintisi riski var mı?

Yönetilen kaynakları kendi kendine yönetilen kod tabanlarına geçirmek, hizmet kesintisi veya etkinlik kaybı gibi küçük bir risk taşır.

• Tetikleyici Bozulması: Eski tetikleyiciler yenileri etkinleştirilmeden önce silinirse etkinliklerin (ör. Cloud Firestore belge yazma) kaçırıldığı ve kalıcı olarak kaybolduğu bir boşluk oluşur. Veri kaybını önlemek için uzantıyı kaldırmadan önce yedek kiti dağıtmanızı ve doğrulamanızı öneririz.
• İzin Boşlukları: Yeni dağıtılan kod tabanında gerekli IAM izinleri yoksa BigQuery konumuna yazma gibi işlemler sessizce başarısız olur veya çalışma zamanında kilitlenir. İşlevler için bildirim temelli güvenlik ekledik. Böylece, rolleri sorgulayabilen ve ayarlayabilen, hizmet hesabı oluşturabilen bir hesap tarafından yapılan ilk kit dağıtımı bu sorunu azaltmalıdır.

Önemli Cloud Firestore-to-BigQuery Export uzantısında veri kaybını nasıl önleyebiliriz?

Güvenli ve sıfır veri kaybıyla geçiş için destek ekibi, kullanıcılara boşluk tabanlı yerine çakışma tabanlı bir geçiş yapmalarını önermelidir. Bu, kitlere taşıma işleminde varsayılan olarak geçerlidir:

1. Uzantı yüklü ve çalışır durumdayken yedek işlev kitini dağıtın. Eventarc'ın tam olarak hazırlanması için birkaç dakika bekleyin.
2. İzlenen Cloud Firestore koleksiyonuna bir test dokümanı yazın ve yeni bağımsız yönetilen işlevin, BigQuery değişiklik günlüğü tablosuna (yeni bir etkinlik kimliği taşıyan) karşılık gelen bir satırı başarıyla yazdığını doğrulayın.
3. Yeni dağıtımın çalıştığı onaylandıktan sonra, çift yazma davranışını sonlandırmak için eski uzantıyı hemen kaldırın veya devre dışı bırakın.
4. Her yazma işleminin yinelenen işleme maliyetini ve ham BigQuery değişiklik günlüğünde yinelenen satır olasılığını en aza indirmek için çakışma aralığını mümkün olduğunca kısa tutun.
5. Çoğu durumda, Ham Değişiklik Günlüğü Tablosu (*_raw_changelog) yinelenen girişleri kaldırır. insertID Değişiklik günlüğünde yinelenen satırlar olsa bile tablonun en son görünümü (*_raw_latest) doğru olur.

Özellikle bu uzantıyı taşıma ve veri kaybını önleme hakkında daha fazla bilgiyi kit'in README.md dosyasında bulabilirsiniz.

Yaşam döngüsü hazırlama adımı başarısız olursa ne yapmalıyım?

Yönetilen hizmet kapsamında, kurulum görevleri (ör. BigQuery veri kümeleri, tablolar ve görünümler oluşturma) otomatik olarak gerçekleştiriliyordu. Kendi kendine yönetilen NPM modelinde bunlar, yaşam döngüsü görev sırası işlevi kullanılarak tetiklenir. Örneğin, firestore-bigquery-export içinde bu işlev initBigQuerySync olarak adlandırılır.

Bu adım başarısız olursa veya otomatik olarak çalışmazsa:

1. Cloud Functions çalışma zamanı hizmet hesabına gerekli IAM rollerinin verildiğini doğrulayın. Örneğin, firestore-bigquery-export için aşağıdakiler buna dahildir:

   • Kaynak oluşturmak ve satır eklemek için: roles/bigquery.dataEditor
   • İş çalıştırmak ve görünüm oluşturmak için: roles/bigquery.user
   • Hazırlama görevini sıraya almak için: roles/cloudtasks.enqueuer

2. Arayanın roles/cloudtasks.enqueuer izinlerine sahip olduğunu onaylayın.

3. Yaşam döngüsü başlatma komutunu KSA'yı kullanarak manuel olarak yeniden çalıştırın:

   firebase functions:lifecycle:run afterInstall KIT_INSTANCE_ID
   

4. İzin veya yapılandırma hatalarını teşhis etmek için hem tetikleyici işlevin hem de görev sırası yürütmesinin Cloud Logging günlüklerini kontrol edin.

Secret Manager kimlik bilgileri nasıl taşınır?

Yönetilen modelde, Secret Manager kaynakları otomatik olarak uzantı örneklerine bağlanıyordu. Uzantı yapılandırmanızı bir işlev kitine aktarmak için ext:migrate veya ext:export --mode functions komutlarını kullandığınızda, uzantı kaldırıldıktan sonra bu sırların projenizde kalması için uzantıların bu sırları yönetmesini durdururuz. Bu sırları gelecekte kaldırmak isterseniz bunu Google Cloud konsolunda manuel olarak yapmanız gerekir.

Kullanıcı, taşınan bir uzantının birden fazla örneğini çalıştırmak isterse ne olur?

Bir işlevin birden fazla örneğini desteklemek için işlev kitlerini kullanıma sunduk. Bu, bir uzantının birden fazla sürümüne sahip olmaya benzer. Her kite, kod tabanına benzer ve CLI komutlarında kod tabanlarıyla birbirinin yerine kullanılabilen benzersiz bir kit örneği kimliği atanır. Bir kit örneğinde dağıtılan tüm işlevlerin önüne kit-<instance-id>- öneki eklenir. Böylece, uzantılardaki ext-<extension-instance-id>- önekine benzer şekilde her işlevin benzersiz bir adı olur. Taşıma işleminin bir parçası olarak işlev kitlerini kullanma hakkında daha fazla bilgi edinmek için kullanıcı taşıma rehberimize göz atın.

Kit yüklemesi için npm kullanılır. Yarn veya Node ile uyumlu başka bir paket yöneticisi kullanmak istersem ne yapmalıyım?

Şu anda Yarn veya diğer paket yöneticilerini destekleme planımız yoktur. Kit kurulumu, ilk kurulumda kit kaynak kodu ayarlanırken npm komutlarını doğrudan çalıştırarak yapılır.

Alternatif olarak bir kaynak dizini oluşturabilir, kit npm paketini kendiniz yükleyebilir ve uygun derlemeler ve dışa aktarmalarla ayarlayabilirsiniz. index-kit TypeScript şablonlarımıza firebase-tools bölümünden göz atabilir veya örnek olarak npm ile yüklenen bir kiti inceleyebilirsiniz. Bu işlemi yaptıktan sonra, --package yerine --directory kullanarak yerel bir kit gibi yükleyebilirsiniz. Bundan sonra, kiti dizine veya kimliğe göre tanımlamanız gerekecek. Ancak örnek eklemek ve kaldırmak için kit komutlarını kullanabilirsiniz.

Uzantım, Docker deposunu veya KMS anahtarı gelişmiş sistem parametrelerini kullanıyor. Bunu işlev kitlerinde nasıl yapılandırabilirim?

Şu anda Cloud Functions içinde Firebase için bir Docker deposu veya KMS anahtarı yapılandırmayı desteklemiyoruz. Bu sistem parametrelerinin yapılandırıldığı bir uzantıdan taşıma yapıyorsanız ve bu işlevselliği korumak istiyorsanız gcloud CLI kullanarak parametreleri yeni kitinizin işlevlerine uygulayabilirsiniz.

Ön koşullar

1. İşlevlerin Google Cloud içinde bulunması için işlev kitinizi ilk olarak taşıma kılavuzlarını izleyerek dağıtın.

2. Ortam değişkenlerinizi terminalinizde tanımlayın:

   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. Derlenmiş derleme dosyalarının .gitignore tarafından yoksayılmaması için kitin kaynak kökünde .gcloudignore öğesini önceden oluşturun:

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

4. Gerekli IAM izinlerini verin:

   • KMS anahtarları için (hizmet aracılarına şifre çözme erişimi verir):

     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
     

   • Artifact Registry için (Cloud Build'ye yazma erişimi ve Cloud Run'ye okuma erişimi verir):

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

Ayarları gcloud CLI kullanarak uygulama

Kitinizdeki her işlev için gcloud functions deploy komutunu çalıştırı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}"

Bu geçici çözümün aşağıdaki koşullarda çalışmadığını unutmayın:

1. Yeni kit örnekleri: firebase.json içinde bir örnek eklemek, varsayılan olarak Google tarafından yönetilen anahtarları ve gcf-artifacts kullanan yeni bir Cloud Functions v2 kaynağı oluşturur. Her yeni örnek için gcloud çalıştırmanız gerekir.
2. İşlevin yeniden oluşturulması: Tetikleyici türünün değiştirilmesi (örneğin, HTTPS'den Cloud Firestore tetikleyiciye), giriş noktasının değiştirilmesi veya yeniden adlandırma, Firebase KSA'nın eski işlevi silip yeni bir işlev oluşturmasına neden olur. Yeni işlev, gcloud'yı tekrar çalıştırana kadar bu ayarları kaybeder.
3. Yapılandırma sapması: Firebase CLI, firebase functions:list veya diff günlüklerinde KMS ya da Docker deposu durumunu göstermediğinden altyapı denetimi zorlaşır.

Başarıyı doğrulama

Deponun ve şifreleme anahtarının uygulandığını onaylamak için aşağıdaki komutu çalıştırın:

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