Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

Firebase एक्सटेंशन बंद किए जाने के बारे में अक्सर पूछे जाने वाले सवाल

Firebase एक्सटेंशन सेवा बंद हो गई है. यह 31 मार्च, 2027 को बंद हो जाएगी. पहले से इंस्टॉल किए गए एक्सटेंशन हमेशा काम करते रहेंगे. हालांकि, इस तारीख के बाद से, कुंजी मैनेज करने से जुड़ी मुख्य सुविधाएं उपलब्ध नहीं होंगी. माइग्रेशन से जुड़ी ज़्यादा जानकारी और टूल, सितंबर 2026 में रिलीज़ किए जाएंगे.

एपीआई के बंद होने के बारे में खास जानकारी

हम Firebase Extensions को बंद क्यों कर रहे हैं?

हमारे Google Cloud इंफ़्रास्ट्रक्चर में होने वाले बदलावों और बंद होने वाली सुविधाओं की वजह से, हम मैनेज की गई Firebase Extensions सेवा को बंद कर देंगे.

क्या 31 मार्च, 2027 के बाद, पहले से डिप्लॉय किए गए एक्सटेंशन काम करना बंद कर देंगे?

नहीं. पहले से डिप्लॉय किए गए एक्सटेंशन, सीधे तौर पर स्टैंडर्ड Google Cloud इन्फ़्रास्ट्रक्चर (जैसे कि Cloud Functions, Eventarc, Cloud Run, और Cloud Tasks) पर चलते हैं. साथ ही, ये हमेशा काम करते रहेंगे.

हालांकि, 31 मार्च, 2027 के बाद, आपके पास Firebase कंसोल या सीएलआई के ज़रिए इन एक्सटेंशन को अपडेट, फिर से कॉन्फ़िगर या अनइंस्टॉल करने का विकल्प नहीं रहेगा. इसके अलावा, आपके पास अपने मौजूदा एक्सटेंशन कॉन्फ़िगरेशन डाउनलोड करने का विकल्प भी नहीं होगा. इससे आपको फ़ंक्शन किट पर माइग्रेट करने में मदद मिलती है. हमारा सुझाव है कि एक्सटेंशन के कॉन्फ़िगरेशन को 31 मार्च, 2027 तक माइग्रेट या एक्सपोर्ट कर लें.

अगर कोई उपयोगकर्ता कुछ नहीं करता है, तो क्या होगा?

अगर कोई उपयोगकर्ता कोई कार्रवाई नहीं करता है, तो उसके डिप्लॉय किए गए मौजूदा फ़ंक्शन, स्टैंडर्ड ऐसेट के तौर पर काम करते रहेंगे. हालांकि, 31 मार्च, 2027 के बाद:

वे कॉन्फ़िगरेशन पैरामीटर नहीं बदल सकते या एनवायरमेंट वैरिएबल अपडेट नहीं कर सकते.
वे गड़बड़ियों को ठीक करने वाले अपडेट, सुरक्षा पैच या डिपेंडेंसी अपग्रेड लागू नहीं कर सकते.
वे एक्सटेंशन कॉन्फ़िगरेशन डाउनलोड नहीं कर सकते, ताकि वे फ़ंक्शन किट को एक जैसा कॉन्फ़िगर कर सकें.
फ़िलहाल, ज़्यादातर एक्सटेंशन लेगसी Cloud Functions v1 SDK पर बनाए गए हैं. यह SDK, Node.js के पुराने रनटाइम से जुड़ा है. Google Cloud की ओर से इन लेगसी रनटाइम को पूरी तरह से बंद कर दिए जाने के बाद, हो सकता है कि फ़ंक्शन काम करना बंद कर दें या उन्हें बंद कर दिया जाए. रनटाइम सपोर्ट देखें.

क्या Firebase एक्सटेंशन की जगह कोई और सुविधा इस्तेमाल की जा सकती है?

हमने Cloud Functions में कई सुविधाएं जोड़ी हैं, ताकि ये एक्सटेंशन की जगह ले सकें. खास तौर पर, फ़ंक्शन किट को npm का इस्तेमाल करके डिस्ट्रिब्यूट किया जा सकता है. इससे आपको फ़ंक्शन के कई इंस्टेंस डिप्लॉय करने की सुविधा मिलती है. यह सुविधा, एक ही प्रोजेक्ट में एक्सटेंशन को कई बार इंस्टॉल करने की सुविधा की तरह ही काम करती है.

हालांकि, यह हर एक्सटेंशन पब्लिशर पर निर्भर करता है कि वह npm पर, फ़ंक्शन किट के आधिकारिक तौर पर बदले गए वर्शन को पब्लिश करना चाहता है या नहीं. एक्सटेंशन ओपन सोर्स होते हैं. इसलिए, अगर पब्लिशर आधिकारिक तौर पर कोई दूसरा एक्सटेंशन उपलब्ध नहीं कराना चाहता है, तो कोई भी डेवलपर इसे फ़ोर्क करके, Cloud Functions में Node SDK में मौजूद 2nd gen एपीआई का इस्तेमाल करके, अनौपचारिक तौर पर कोई दूसरा एक्सटेंशन उपलब्ध करा सकता है.

अगर पब्लिशर को डिवाइस बदलना है, तो उन्हें पब्लिशर के लिए माइग्रेशन गाइड में दिए गए निर्देशों का पालन करना होगा.

अगर आपको आधिकारिक तौर पर उपलब्ध रिप्लेसमेंट पैकेज का फ़ायदा लेना है या अपना रिप्लेसमेंट पैकेज बनाना है, तो उपयोगकर्ताओं के लिए माइग्रेशन गाइड में दिए गए निर्देशों का पालन करें.

एक्सटेंशन का इस्तेमाल करने वाले व्यक्ति के तौर पर, मुझे क्या करना चाहिए?

अगर आपको एक्सटेंशन का इस्तेमाल नहीं करना है, तो उन्हें 31 मार्च, 2027 से पहले अनइंस्टॉल करें.

सेवा बंद होने के बाद, Firebase console में मौजूद "अनइंस्टॉल करें" बटन और इससे जुड़ी सीएलआई कमांड हटा दी जाएंगी. आपको Google Cloud कंसोल का इस्तेमाल करके, इससे जुड़ी सभी Google Cloud संसाधन मैन्युअल तरीके से मिटाने होंगे. इनमें Cloud Functions, Secret Manager सीक्रेट, Cloud Tasks कतारें, और कस्टम आईएएम सेवा खाते शामिल हैं.

हालांकि, अगर इंस्टॉल किए गए एक्सटेंशन का इस्तेमाल किया जाता है, तो हमारा सुझाव है कि आप फ़ंक्शन किट पर माइग्रेट करें. फ़ंक्शन किट पर माइग्रेट करने के लिए, उपयोगकर्ताओं के लिए माइग्रेशन गाइड में दिए गए निर्देशों का पालन करें.

आपके पास फ़ंक्शन किट पर माइग्रेट न करने का विकल्प होता है. ऐसे में, हमारा सुझाव है कि आप अपने सभी एक्सटेंशन को उनके नए वर्शन में अपडेट करें और उन्हें अपडेट रखें. साथ ही, एक्सटेंशन के मौजूदा कॉन्फ़िगरेशन एक्सपोर्ट करें, ताकि बाद में माइग्रेट किया जा सके.

एक्सटेंशन पब्लिशर के तौर पर मुझे क्या करना चाहिए?

हमारा सुझाव है कि पब्लिश किए गए अपने एक्सटेंशन को npm पर पब्लिश किए गए फ़ंक्शन किट पर माइग्रेट करें. सबसे पहले, अपने एक्सटेंशन को 2nd gen फ़ंक्शन पर माइग्रेट करें. फ़ंक्शन किट बनाने के लिए, यह ज़रूरी है. इसके लिए, आपको Cloud Functions v2 SDK का इस्तेमाल करके, एक्सटेंशन लॉजिक को पैकेज करना होगा. हमने Cloud Functions v2 SDK को अपडेट किया है. इसमें डिक्लेरेटिव सिक्योरिटी और लाइफ़साइकल इवेंट जैसी सुविधाएं काम करती हैं. अब अपने मौजूदा एक्सटेंशन कोड को दूसरी जनरेशन के फ़ंक्शन पर माइग्रेट किया जा सकता है. इसके लिए, आपको अपने मुख्य कारोबार के लॉजिक में बहुत कम बदलाव करने होंगे. इन फ़ंक्शन को npm पैकेज का इस्तेमाल करके पब्लिश किया जा सकता है. ज़्यादा जानकारी के लिए, पब्लिशर के लिए माइग्रेशन गाइड देखें.

अगर मेरे कुछ और सवाल हैं, तो क्या होगा?

जिन उपयोगकर्ताओं को सवाल पूछने हैं वे हमारी उपयोगकर्ता माइग्रेशन गाइड का इस्तेमाल कर सकते हैं. अगर आपको इस गाइड को पढ़ने के बाद भी कुछ पूछना है, तो Firebase की सहायता टीम से संपर्क करें.

अगर पब्लिशर को Firebase Extensions माइग्रेट करने के तरीके के बारे में कोई सवाल पूछना है, तो वे पब्लिशर के लिए माइग्रेशन गाइड का इस्तेमाल कर सकते हैं. इस गाइड में, अपडेट के बारे में जानकारी पाने और पब्लिश किए गए एक्सटेंशन के विकल्प के बारे में मदद पाने से जुड़े निर्देश दिए गए हैं.

माइग्रेशन के विकल्प और तकनीकी तरीके से माइग्रेशन करना

माइग्रेट करने के मुख्य तरीके कौनसे हैं?

सितंबर 2026 से, Firebase आधिकारिक तौर पर माइग्रेशन के दो मुख्य तरीकों के साथ काम करेगा:

NPM-शेयर्ड फ़ंक्शन ("फ़ंक्शन किट") पर माइग्रेट करें: यह Stream Firestore से BigQuery और npm पर उपलब्ध होने वाली किसी भी अन्य फ़ंक्शन किट के लिए सुझाव दिया जाता है. कोर लॉजिक को Cloud Functions v2 SDK का इस्तेमाल करके, स्टैंडर्ड NPM लाइब्रेरी के तौर पर पैकेज किया जाता है. उपयोगकर्ता, स्टैंडर्ड Cloud Functions कोड बेस को शुरू करते हैं, पैकेज इंस्टॉल करते हैं, फ़ंक्शन को फिर से एक्सपोर्ट करते हैं, और सीएलआई का इस्तेमाल करके उन्हें अलग से डिप्लॉय करते हैं.
फ़ोर्क और खुद मैनेज करें: यह उन सभी एक्सटेंशन के लिए सुझाया गया है जिनके लिए npm पर फ़ंक्शन किट उपलब्ध नहीं है. उपयोगकर्ता, ओपन-सोर्स एक्सटेंशन के सोर्स कोड को कॉपी या फ़ोर्क करते हैं. इसके बाद, ट्रिगर को स्टैंडर्ड Firebase v2 फ़ंक्शन में बदलते हैं. इसके लिए, एआई माइग्रेशन की सबसे अच्छी सुविधाओं या मैन्युअल गाइड का इस्तेमाल करते हैं. साथ ही, कोडबेस और उसके रखरखाव का पूरा मालिकाना हक लेते हैं.

कौनसे एक्सटेंशन, फ़ंक्शन किट में माइग्रेट किए जा रहे हैं?

Firestore से BigQuery में डेटा स्ट्रीम करने वाले एक्सटेंशन को फ़ंक्शन किट में माइग्रेट कर दिया गया है. यह npm पैकेज @firebase-function-kits/firestore-bigquery-export के तौर पर उपलब्ध है.

माइग्रेशन के लिए, Cloud Functions v1 से v2 पर अपग्रेड करना क्यों ज़रूरी है?

Cloud Functions v1 के लिए स्टैंडर्ड सहायता, Node.js 22 रनटाइम के साथ खत्म हो जाएगी. "डबल माइग्रेशन" को रोकने के लिए, Firebase का सुझाव है कि इस ट्रांज़िशन के दौरान, माइग्रेट किए गए सभी फ़ंक्शन को तुरंत v2 SDK पर अपग्रेड करें. "डबल माइग्रेशन" का मतलब है कि डेवलपर, Firebase Extensions से माइग्रेट करते हैं, लेकिन लेगसी रनटाइम बंद होने पर, उन्हें मैन्युअल तरीके से दूसरी बार रिफ़ैक्टर करना पड़ता है. यह फ़ंक्शन किट के लिए ज़रूरी है.

एक्सटेंशन के उपयोगकर्ता के तौर पर, उपयोगकर्ता माइग्रेशन गाइड का इस्तेमाल करके, अपने फ़ंक्शन किट भी बनाए जा सकते हैं.

बिलिंग और कीमत

क्या सेल्फ-मैनेज किए जाने वाले Cloud Functions पर माइग्रेट करने से, ग्राहक की बिलिंग में कोई बदलाव होगा?

आम तौर पर, नहीं. डिप्लॉय किए गए एक्सटेंशन, पहले से ही उन Google Cloud संसाधनों के लिए खरीदारों से शुल्क लेते हैं जिनका वे इस्तेमाल करते हैं. जैसे, Cloud Functions इनवोकेशन, Cloud Storage या BigQuery स्टोरेज और क्वेरी. हालांकि, माइग्रेशन विंडो के दौरान, ग्राहकों को कुछ समय के लिए अतिरिक्त शुल्क देना पड़ सकता है. ऐसा तब होता है, जब वे सुरक्षित तरीके से कटओवर करने के लिए, लेगसी Firebase Extensions और नई सुविधा, दोनों को एक साथ चलाते हैं.

Mandiant या अन्य खास एंटरप्राइज़ खातों के लिए बिलिंग कैसे मैनेज की जाती है?

यह बदलाव, पूरे प्लैटफ़ॉर्म पर लागू होगा. इससे सभी Firebase और Google Cloud प्रोजेक्ट पर असर पड़ेगा. स्टैंडर्ड बिलिंग और सदस्यता की व्यवस्था पर कोई असर नहीं पड़ता. अगर ग्राहक, सेवा बंद होने की वजह से एसएलए क्रेडिट का अनुरोध करते हैं या उन्हें बिलिंग से जुड़ी जटिल समस्याओं का सामना करना पड़ता है, तो बिलिंग से जुड़ी सहायता पाने के सामान्य चैनलों के ज़रिए सीधे तौर पर मामले की शिकायत करें.

समस्या हल करना और जोखिम कम करना

माइग्रेशन के दौरान, डेटा के नुकसान या सेवा के बंद होने का क्या खतरा है?

मैनेज किए गए संसाधनों को खुद मैनेज किए जाने वाले कोडबेस में बदलने से, सेवा में रुकावट आने या इवेंट के डेटा के नुकसान का मामूली जोखिम होता है.

ट्रिगर में रुकावट: अगर नए ट्रिगर चालू होने से पहले पुराने ट्रिगर मिटा दिए जाते हैं, तो एक ऐसा समय आ जाता है जब इवेंट (जैसे, Cloud Firestore दस्तावेज़ लिखना) छूट जाते हैं और हमेशा के लिए मिट जाते हैं. हमारा सुझाव है कि एक्सटेंशन हटाने से पहले, रिप्लेसमेंट किट को डिप्लॉय करें और उसकी पुष्टि करें, ताकि डेटा का नुकसान न हो.
अनुमति से जुड़ी समस्याएं: अगर नए कोडबेस में ज़रूरी IAM अनुमतियां नहीं हैं, तो BigQuery में लिखने जैसी कार्रवाइयां, बिना किसी सूचना के पूरी नहीं होंगी या रनटाइम के दौरान क्रैश हो जाएंगी. हमने फ़ंक्शन के लिए डिक्लेरेटिव सुरक्षा की सुविधा जोड़ी है. इसलिए, जिस खाते से पहली बार किट डिप्लॉय की गई है वह भूमिकाओं को क्वेरी और सेट कर सकता है. साथ ही, सेवा खाता जनरेट कर सकता है. इससे इस समस्या को कम किया जा सकता है.

हम Cloud Firestore-से-BigQuery एक्सपोर्ट एक्सटेंशन के लिए डेटा के नुकसान को कैसे रोकते हैं?

डेटा के नुकसान के बिना सुरक्षित तरीके से ट्रांज़िशन करने के लिए, सहायता टीम को उपयोगकर्ताओं को यह सलाह देनी चाहिए कि वे ओवरलैप पर आधारित कटओवर का इस्तेमाल करें, न कि अंतर पर आधारित कटओवर का. किट पर माइग्रेट करने के बाद, यह डिफ़ॉल्ट रूप से उपलब्ध होता है:

एक्सटेंशन के इंस्टॉल और चालू रहने के दौरान, फ़ंक्शन किट को बदलें. Eventarc के पूरी तरह से चालू होने में कुछ मिनट लगेंगे.
वॉच की गई Cloud Firestore कलेक्शन में एक टेस्ट दस्तावेज़ लिखें. साथ ही, पुष्टि करें कि सेल्फ़-मैनेज किए गए नए फ़ंक्शन ने, BigQuery बदलाव के लॉग वाली टेबल में एक नई लाइन (जिसमें नया इवेंट आईडी है) लिख दी है.
जब यह पुष्टि हो जाए कि नया डिप्लॉयमेंट काम कर रहा है, तो लेगसी एक्सटेंशन को तुरंत अनइंस्टॉल करें या बंद करें. इससे, दो बार डेटा लिखने की सुविधा बंद हो जाएगी.
ओवरलैप विंडो को जितना हो सके उतना छोटा रखें, ताकि रॉ BigQuery चेंजलॉग में डुप्लीकेट पंक्तियों की संख्या कम हो.
माइग्रेशन विंडो के दौरान डुअल राइटिंग की वजह से, Raw Changelog Table (*_raw_changelog) में दो लाइनें दिखेंगी. इनमें एक ही दस्तावेज़ का डेटा और Cloud Firestore कमिट टाइमस्टैंप होगा. हालांकि, टेबल का नया व्यू (*_raw_latest) सही होगा.

ध्यान दें: उपभोक्ताओं की ज़्यादातर क्वेरी, BigQuery के मौजूदा वर्शन पर आधारित होती हैं. इसमें दस्तावेज़ के आईडी और टाइमस्टैंप के हिसाब से डुप्लीकेट डेटा हटाया जाता है. इससे डुप्लीकेट डेटा वाली रॉ फ़ाइलें, डाउनस्ट्रीम ऐप्लिकेशन के लिए नुकसानदेह नहीं होती हैं.

इस एक्सटेंशन को माइग्रेट करने और डेटा के नुकसान से उबरने के तरीके के बारे में ज़्यादा जानकारी, kit's README.md में दी गई है.

अगर लाइफ़साइकल प्रोविज़निंग का चरण पूरा नहीं होता है, तो मुझे क्या करना चाहिए?

मैनेज की जा रही सेवा में, सेटअप से जुड़े टास्क (जैसे कि BigQuery डेटासेट, टेबल, और व्यू बनाना) अपने-आप हैंडल हो जाते थे. सेल्फ़-मैनेज किए जाने वाले एनपीएम मॉडल में, इन्हें लाइफ़साइकल टास्क क्यू फ़ंक्शन का इस्तेमाल करके ट्रिगर किया जाता है. उदाहरण के लिए, firestore-bigquery-export में इसे initBigQuerySync कहा जाता है.

अगर यह चरण पूरा नहीं होता है या अपने-आप नहीं चलता है, तो:

पुष्टि करें कि Cloud Functions रनटाइम सेवा खाते को ज़रूरी आईएएम भूमिकाएं दी गई हों. उदाहरण के लिए, firestore-bigquery-export के लिए इसमें यह शामिल है:
- संसाधन बनाने और पंक्तियां शामिल करने के लिए: roles/bigquery.dataEditor
- जॉब चलाने और व्यू बनाने के लिए: roles/bigquery.user
- प्रोविज़निंग टास्क को कतार में जोड़ने के लिए: roles/cloudtasks.enqueuer
पुष्टि करें कि कॉल करने वाले के पास roles/cloudtasks.enqueuer अनुमतियां हों.
सीएलआई का इस्तेमाल करके, लाइफ़साइकल शुरू करने के लिए इस्तेमाल की जाने वाली कमांड को मैन्युअल तरीके से फिर से चलाएं:
```
firebase functions:lifecycle:run afterInstall KIT_INSTANCE_ID
```
अनुमति या कॉन्फ़िगरेशन से जुड़ी किसी भी गड़बड़ी का पता लगाने के लिए, ट्रिगर फ़ंक्शन और टास्क क्यू के एक्ज़ीक्यूशन, दोनों के लिए Cloud Logging लॉग देखें.

Secret Manager क्रेडेंशियल कैसे माइग्रेट किए जाते हैं?

मैनेज किए गए मॉडल में, Secret Manager संसाधन एक्सटेंशन इंस्टेंस से अपने-आप जुड़ जाते थे. एक्सटेंशन के कॉन्फ़िगरेशन को फ़ंक्शनकिट में एक्सपोर्ट करने के लिए, ext:migrate या ext:export --mode functions कमांड का इस्तेमाल करने पर, हम एक्सटेंशन को इन सीक्रेट को मैनेज करने से रोक देते हैं. इससे, एक्सटेंशन अनइंस्टॉल होने के बाद भी ये सीक्रेट आपके प्रोजेक्ट में बने रहते हैं. अगर आपको आने वाले समय में इन सीक्रेट को हटाना है, तो आपको Google Cloud कंसोल में जाकर, इन्हें मैन्युअल तरीके से हटाना होगा.

अगर कोई उपयोगकर्ता, माइग्रेट किए गए एक्सटेंशन के एक से ज़्यादा इंस्टेंस चलाना चाहता है, तो क्या होगा?

हमने फ़ंक्शन किट को इस तरह से पेश किया है कि एक फ़ंक्शन के कई इंस्टेंस इस्तेमाल किए जा सकें. यह ठीक उसी तरह काम करता है जैसे एक्सटेंशन के कई वर्शन इस्तेमाल किए जा सकते हैं. हर किट को एक यूनीक किट इंस्टेंस आईडी मिलेगा. यह कोडबेस की तरह होता है और इसका इस्तेमाल, सीएलआई कमांड में कोडबेस के साथ किया जा सकता है. डप्लॉय किए जाने पर, किट इंस्टेंस में मौजूद सभी फ़ंक्शन के नाम के आगे kit-<instance-id>- प्रीफ़िक्स जोड़ा जाएगा. इससे यह पक्का किया जा सकेगा कि हर फ़ंक्शन का नाम यूनीक हो. यह एक्सटेंशन में मौजूद ext-<extension-instance-id>- प्रीफ़िक्स की तरह ही होता है. माइग्रेट करने के दौरान फ़ंक्शन किट इस्तेमाल करने के तरीके के बारे में ज़्यादा जानने के लिए, उपयोगकर्ता माइग्रेशन गाइड देखें.

Kit इंस्टॉल करने के लिए npm का इस्तेमाल किया जाता है. अगर मुझे Yarn या Node के साथ काम करने वाले किसी दूसरे पैकेज मैनेजर का इस्तेमाल करना है, तो क्या होगा?

फ़िलहाल, हमारा Yarn या अन्य पैकेज मैनेजर के साथ काम करने का कोई प्लान नहीं है. पहली बार इंस्टॉल करने पर, किट के सोर्स कोड को सेट अप करते समय, npm कमांड को सीधे तौर पर लागू करके किट इंस्टॉल की जाती है.

इसके अलावा, सोर्स डायरेक्ट्री बनाई जा सकती है. साथ ही, npm की किट को खुद इंस्टॉल किया जा सकता है. इसके बाद, इसे सही बिल्ड और एक्सपोर्ट के साथ सेट अप किया जा सकता है. हमारे TypeScript index-kit टेंप्लेट firebase-tools में देखें या npm से इंस्टॉल किए गए किट को उदाहरण के तौर पर देखें. ऐसा करने के बाद, इसे --package के बजाय --directory का इस्तेमाल करके, लोकल किट की तरह इंस्टॉल किया जा सकता है. आगे से, आपको डायरेक्ट्री या आईडी के हिसाब से किट की पहचान करनी होगी. हालांकि, किट के इंस्टेंस जोड़ने और हटाने के लिए, किट के कमांड इस्तेमाल किए जा सकते हैं.

मेरा एक्सटेंशन, Docker रिपॉज़िटरी या KMS कुंजी के बेहतर सिस्टम पैरामीटर का इस्तेमाल करता है. मैं इसे फ़ंक्शन किट में कैसे कॉन्फ़िगर करूं?

फ़िलहाल, हम Firebase के लिए Cloud Functions में Docker रिपॉज़िटरी या KMS कुंजी कॉन्फ़िगर करने की सुविधा नहीं देते. अगर आपको ऐसे एक्सटेंशन से माइग्रेट करना है जिसमें ये सिस्टम पैरामीटर कॉन्फ़िगर किए गए हैं और आपको इस सुविधा को बनाए रखना है, तो gcloud CLI का इस्तेमाल करके, अपने नए किट के फ़ंक्शन में पैरामीटर लागू किए जा सकते हैं.

ज़रूरी शर्तें

माइग्रेशन गाइड में दिए गए निर्देशों का पालन करके, फ़ंक्शन किट को शुरू में ही डिप्लॉय करें, ताकि फ़ंक्शन Google Cloud में मौजूद हों.

अपने टर्मिनल में एनवायरमेंट वैरिएबल तय करें:

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

किट के सोर्स रूट में .gcloudignore को पहले से बना लें, ताकि कंपाइल की गई बिल्ड फ़ाइलों को .gitignore अनदेखा न करे:
```
cat << 'EOF' > "${SOURCE_DIR}/.gcloudignore"
.gcloudignore
.git
.gitignore

node_modules
#!include:.gitignore
!lib/**
EOF
```

ज़रूरी IAM अनुमतियां दें:

KMS कुंजियों के लिए (इससे सेवा एजेंटों को डिक्रिप्ट करने का ऐक्सेस मिलता है):

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 के लिए (इससे Cloud Build को बदलाव करने का ऐक्सेस और 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"

gcloud CLI का इस्तेमाल करके सेटिंग लागू करना

अपने किट में मौजूद हर फ़ंक्शन के लिए, gcloud functions deploy चलाएं:

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

ध्यान दें कि यह तरीका इन स्थितियों में काम नहीं करता:

किट के नए इंस्टेंस: firebase.json में कोई इंस्टेंस जोड़ने पर, एक नया Cloud Functions v2 संसाधन बनता है. यह डिफ़ॉल्ट रूप से, Google-मैनेज की गई कुंजियों और gcf-artifacts पर सेट होता है. आपको हर नए इंस्टेंस के लिए, gcloud चलाना होगा.
फ़ंक्शन को फिर से बनाना: ट्रिगर टाइप बदलने (उदाहरण के लिए, एचटीटीपीएस से Cloud Firestore ट्रिगर पर स्विच करना), एंट्री पॉइंट में बदलाव करने या नाम बदलने से, Firebase सीएलआई पुराने फ़ंक्शन को मिटा देता है और एक नया फ़ंक्शन बना देता है. gcloud को फिर से चलाने तक, नई सुविधा के लिए ये सेटिंग लागू नहीं होंगी.
कॉन्फ़िगरेशन में अंतर: Firebase CLI, firebase functions:list या अंतर वाले लॉग में KMS या Docker रिपॉज़िटरी का स्टेटस नहीं दिखाता है. इससे बुनियादी ढांचे की ऑडिटिंग करना मुश्किल हो जाता है.

पुष्टि करना कि माइग्रेशन पूरा हो गया है

यह पुष्टि करने के लिए कि रिपॉज़िटरी और एन्क्रिप्शन कुंजी लागू की गई है, यह कमांड चलाएं:

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