ऐप्लिकेशन होस्टिंग बैकएंड कॉन्फ़िगर और मैनेज करें

App Hosting को इस्तेमाल करने में आसानी हो और इसे मैनेज करने में कम समय लगे, इसके लिए इसे डिज़ाइन किया गया है. साथ ही, इसमें ज़्यादातर मामलों के हिसाब से डिफ़ॉल्ट सेटिंग को ऑप्टिमाइज़ किया गया है. साथ ही, App Hosting आपको ऐसे टूल भी उपलब्ध कराता है जिनकी मदद से, अपनी ज़रूरतों के हिसाब से बैकएंड को मैनेज और कॉन्फ़िगर किया जा सकता है. इस गाइड में उन टूल और प्रोसेस के बारे में बताया गया है.

बैकएंड कॉन्फ़िगर करना

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

apphosting.yaml बनाने के लिए, यह कमांड चलाएं:

firebase init apphosting

इससे, उदाहरण के तौर पर कॉन्फ़िगरेशन (टिप्पणी के साथ) वाली बुनियादी स्टार्टर apphosting.yaml फ़ाइल बनती है. बदलाव करने के बाद, एक सामान्य apphosting.yaml फ़ाइल कुछ इस तरह दिख सकती है. इसमें बैकएंड की Cloud Run सेवा की सेटिंग, कुछ एनवायरमेंट वैरिएबल, और Cloud Secret Manager से मैनेज किए जा रहे कुछ सीक्रेट के रेफ़रंस शामिल हैं:

# Settings for Cloud Run
runConfig:
  minInstances: 2
  maxInstances: 100
  concurrency: 100
  cpu: 2
  memoryMiB: 1024

# Environment variables and secrets
env:
  - variable: STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
      - BUILD
      - RUNTIME

  - variable: API_KEY
    secret: myApiKeySecret

    # Same as API_KEY above but with a pinned version.
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

    # Same as API_KEY above but with the long form secret reference as defined by Cloud Secret Manager.
  - variable: VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID

    # Same as API_KEY above but with the long form secret reference with pinned version.
  - variable: PINNED_VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID/versions/5

इस गाइड के बाकी हिस्से में, उदाहरण के तौर पर दी गई सेटिंग के बारे में ज़्यादा जानकारी और संदर्भ दिया गया है.

Cloud Run सेवा की सेटिंग कॉन्फ़िगर करें

apphosting.yaml सेटिंग की मदद से, यह कॉन्फ़िगर किया जा सकता है कि आपकी Cloud Run सेवा कैसे उपलब्ध कराई जाए. runConfig ऑब्जेक्ट में, Cloud Run सेवा के लिए उपलब्ध सेटिंग दी गई हैं:

• cpu – हर सर्विंग इंस्टेंस के लिए इस्तेमाल किए गए सीपीयू की संख्या (डिफ़ॉल्ट रूप से 0).
• memoryMiB – हर सर्विंग इंस्टेंस के लिए, एमबी में मेमोरी का ऐलोकेशन (डिफ़ॉल्ट तौर पर 512)
• maxInstances – एक बार में ज़्यादा से ज़्यादा कितने कंटेनर चलाए जा सकते हैं (डिफ़ॉल्ट रूप से 100 और कोटा के हिसाब से मैनेज किए जाते हैं)
• minInstances – हमेशा चालू रखने के लिए कंटेनर की संख्या (डिफ़ॉल्ट रूप से 0).
• concurrency – हर सर्विंग इंस्टेंस को ज़्यादा से ज़्यादा कितने अनुरोध मिल सकते हैं (डिफ़ॉल्ट तौर पर 80).

cpu और memoryMiB के बीच के अहम संबंध पर ध्यान दें; मेमोरी को 128 से 32,768 के बीच किसी भी पूर्णांक वैल्यू पर सेट किया जा सकता है. हालांकि, मेमोरी की सीमा बढ़ाने के लिए, सीपीयू की सीमाओं को बढ़ाना पड़ सकता है:

• 4 जीबी से ज़्यादा के लिए, कम से कम दो सीपीयू की ज़रूरत होती है
• 8 जीबी से ज़्यादा के लिए, कम से कम चार सीपीयू की ज़रूरत होती है
• 16 जीबी से ज़्यादा के लिए, कम से कम छह सीपीयू की ज़रूरत होती है
• 24 जीबी से ज़्यादा डेटा के लिए, कम से कम आठ सीपीयू की ज़रूरत होती है

इसी तरह, cpu की वैल्यू का असर, एक साथ कई काम करने की सेटिंग पर पड़ता है. अगर आपने एक सीपीयू से कम वैल्यू सेट की है, तो आपको एक साथ कई टास्क करने की सुविधा को एक पर सेट करना होगा. साथ ही, सीपीयू सिर्फ़ अनुरोध प्रोसेस करने के दौरान ही दिया जाएगा.

बिल्ड एनवायरमेंट को कॉन्फ़िगर करना

कभी-कभी आपको अपनी बिल्ड प्रोसेस के लिए अतिरिक्त कॉन्फ़िगरेशन की ज़रूरत पड़ सकती है, जैसे कि तीसरे पक्ष की एपीआई कुंजियां या ट्यून करने लायक सेटिंग. App Hosting, आपके प्रोजेक्ट के लिए इस तरह के डेटा को सेव और फिर से पाने के लिए, apphosting.yaml में एनवायरमेंट कॉन्फ़िगरेशन की सुविधा देता है.

env:
-   variable: STORAGE_BUCKET
    value: mybucket.appspot.com

Next.js ऐप्लिकेशन के लिए, एनवायरमेंट वैरिएबल वाली dotenv फ़ाइलें भी App Hosting के साथ काम करेंगी. हमारा सुझाव है कि किसी भी फ़्रेमवर्क के साथ, बेहतर तरीके से एनवायरमेंट वैरिएबल कंट्रोल करने के लिए, apphosting.yaml का इस्तेमाल करें.

apphosting.yaml में, availability प्रॉपर्टी का इस्तेमाल करके यह तय किया जा सकता है कि किन प्रोसेस के पास आपके एनवायरमेंट वैरिएबल का ऐक्सेस है. किसी एनवायरमेंट वैरिएबल को सिर्फ़ बिल्ड एनवायरमेंट या सिर्फ़ रनटाइम एनवायरमेंट के लिए उपलब्ध कराने की पाबंदी लगाई जा सकती है. डिफ़ॉल्ट रूप से, यह सुविधा दोनों के लिए उपलब्ध होती है.

env:
-   variable: STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
    -   BUILD
    -   RUNTIME

Next.js ऐप्लिकेशन के लिए, NEXT_PUBLIC_ प्रीफ़िक्स का इस्तेमाल उसी तरह किया जा सकता है जिस तरह ब्राउज़र में वैरिएबल को ऐक्सेस करने के लिए, dotenv फ़ाइल में किया जाता है.

env:
-   variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
    -   BUILD
    -   RUNTIME

मान्य वैरिएबल की में A से Z तक के वर्ण या अंडरस्कोर होते हैं. एनवायरमेंट वैरिएबल की कुछ कुंजियों को अंदरूनी इस्तेमाल के लिए रिज़र्व किया गया है. अपनी कॉन्फ़िगरेशन फ़ाइलों में इनमें से किसी भी पासकी का इस्तेमाल न करें:

• X_FIREBASE_ से शुरू होने वाला कोई भी वैरिएबल
• PORT
• K_SERVICE
• K_REVISION
• K_CONFIGURATION

सीक्रेट पैरामीटर सेव और ऐक्सेस करना

एपीआई पासकोड जैसी संवेदनशील जानकारी को सीक्रेट के तौर पर सेव किया जाना चाहिए. सोर्स कंट्रोल में संवेदनशील जानकारी की जांच करने से बचने के लिए, apphosting.yaml में सीक्रेट का रेफ़रंस दिया जा सकता है.

secret टाइप के पैरामीटर, ऐसे स्ट्रिंग पैरामीटर के बारे में बताते हैं जिनकी वैल्यू Cloud Secret Manager में स्टोर की गई होती है. सीक्रेट पैरामीटर, सीधे वैल्यू पाने के बजाय Cloud हुआ सीक्रेट मैनेजर में मौजूद होने की जांच करते हैं और रोल आउट के दौरान वैल्यू लोड करते हैं.

  -   variable: API_KEY
      secret: myApiKeySecret

Cloud Secret Manager में मौजूद सीक्रेट के कई वर्शन हो सकते हैं. डिफ़ॉल्ट रूप से, आपके लाइव बैकएंड के लिए उपलब्ध किसी सीक्रेट पैरामीटर की वैल्यू, बैकएंड बनाने के समय सीक्रेट के सबसे नए वर्शन पर पिन की जाती है. अगर आपको पैरामीटर के वर्शन और लाइफ़साइकल मैनेजमेंट की ज़रूरी शर्तें पूरी करनी हैं, तो Cloud Secret Manager की मदद से किसी खास वर्शन पर पिन किया जा सकता है. उदाहरण के लिए, वर्शन 5 पर पिन करने के लिए:

  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

सीएलआई कमांड firebase apphosting:secrets:set का इस्तेमाल करके सीक्रेट बनाए जा सकते हैं. इसके बाद, आपसे ज़रूरी अनुमतियां जोड़ने के लिए कहा जाएगा. इस फ़्लो की मदद से, apphosting.yaml में गुप्त रेफ़रंस अपने-आप जोड़ा जा सकता है.

Cloud Secret Manager की सभी सुविधाओं का इस्तेमाल करने के लिए, इसके कंसोल का इस्तेमाल करें. ऐसा करने के लिए, आपको सीएलआई कमांड firebase apphosting:secrets:grantaccess की मदद से, अपने App Hosting बैकएंड को अनुमतियां देनी होंगी.

Firebase पुष्टि की स्थिति सिंक करें

Firebase Auth का इस्तेमाल करने वाले ऐप्लिकेशन को Firebase वेब SDK टूल का इस्तेमाल करना चाहिए, ताकि क्लाइंट और सर्वर के बीच पुष्टि की स्थिति सिंक रह सके. इसे आसान बनाने के लिए, FirebaseServerApp को सेवा वर्कर के साथ लागू करें. टास्क का बुनियादी फ़्लो यह है:

1. सर्वर के अनुरोधों पर, अपने ऐप्लिकेशन के लिए सही हेडर जोड़ने वाला सर्विस वर्कर लागू करें.
2. सर्वर पर अनुरोध से हेडर पाएं और उसे FirebaseServerApp की मदद से, पुष्टि करने वाले उपयोगकर्ता में बदलें.

बैकएंड मैनेज करना

App Hosting बैकएंड के बुनियादी मैनेजमेंट के लिए कमांड, Firebase सीएलआई में दिए गए हैं. कुछ कार्रवाइयां, Firebase कंसोल में भी उपलब्ध हैं. इस सेक्शन में, मैनेजमेंट से जुड़े कुछ सामान्य टास्क के बारे में बताया गया है. जैसे, बैकएंड बनाना और मिटाना.

बैकएंड बनाना

App Hosting बैकएंड, मैनेज किए जा रहे संसाधनों का कलेक्शन होता है. App Hosting इसे आपके वेब ऐप्लिकेशन को बनाने और चलाने के लिए बनाया जाता है. Firebase कंसोल या Firebase सीएलआई का इस्तेमाल करके, App Hosting बैकएंड बनाए और उनकी सूची बनाई जा सकती है.

Firebase कंसोल: बिल्ड मेन्यू में जाकर, ऐप्लिकेशन होस्टिंग चुनें. इसके बाद, शुरू करें को चुनें.

सीएलआई: (13.15.4 या उसके बाद का वर्शन) बैकएंड बनाने के लिए, अपनी लोकल प्रोजेक्ट डायरेक्ट्री के रूट से यह कमांड चलाएं. इसके लिए, आर्ग्युमेंट के तौर पर अपना projectID और पसंदीदा region डालें:

firebase apphosting:backends:create --project PROJECT_ID --location us-central1

कंसोल या सीएलआई, दोनों के लिए, अपने बैकएंड को नाम असाइन करने के लिए, स्क्रीन पर दिए गए निर्देशों का पालन करें. साथ ही, GitHub कनेक्शन सेट अप करने और डिप्लॉयमेंट की इन बुनियादी सेटिंग को कॉन्फ़िगर करने के लिए, स्क्रीन पर दिए गए निर्देशों का पालन करें:

• अपने ऐप्लिकेशन की रूट डायरेक्ट्री सेट करें (डिफ़ॉल्ट रूप से / पर सेट होती है)

  आम तौर पर, आपकी package.json फ़ाइल यहां सेव होती है.

• लाइव शाखा सेट करना

  यह GitHub रिपॉज़िटरी की वह ब्रांच है जिसे आपके लाइव यूआरएल पर डिप्लॉय किया जाता है. आम तौर पर, यह वह शाखा होती है जिसमें सुविधा वाली शाखाएं या डेवलपमेंट वाली शाखाएं मर्ज की जाती हैं.

• अपने-आप रोल आउट होने की सुविधा को स्वीकार या अस्वीकार करना

  अपने-आप रोल आउट होने की सुविधा डिफ़ॉल्ट रूप से चालू रहती है. बैकएंड बनाने के बाद, आपके पास अपने ऐप्लिकेशन को App Hosting पर तुरंत डिप्लॉय करने का विकल्प होता है.

बैकएंड को मिटाना

बैकएंड को पूरी तरह से हटाने के लिए, पहले Firebase सीएलआई का इस्तेमाल करें. इसके बाद, मिलती-जुलती ऐसेट को मैन्युअल तरीके से हटाएं. इस बात का खास ध्यान रखें कि ऐसा कोई भी संसाधन न मिटाया जाए जिसका इस्तेमाल आपके Firebase प्रोजेक्ट के दूसरे बैकएंड या दूसरे पहलुओं में हो सकता है.

1. App Hosting बैकएंड मिटाने के लिए, यह कमांड चलाएं. इससे आपके बैकएंड के सभी डोमेन बंद हो जाएंगे और उससे जुड़ी Cloud Run सेवा मिट जाएगी:

   firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID --location us-central1
   

2. (ज़रूरी नहीं) Artifact Registry के लिए Google Cloud Console टैब में, "firebaseapphosting-images" में अपने बैकएंड की इमेज मिटाएं.

3. Cloud Secret Manager में, गुप्त नाम में "apphosting" वाले सभी सीक्रेट मिटाएं. इस बात का खास ध्यान रखें कि इन सीक्रेट का इस्तेमाल किसी दूसरे बैकएंड या आपके Firebase प्रोजेक्ट के अन्य पहलुओं में न किया जाए.