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

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.firebasestorage.app
    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.firebasestorage.app

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

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

env:
-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
    -   BUILD
    -   RUNTIME

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

env:
-   variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
    -   BUILD
    -   RUNTIME

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

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

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

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

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

  -   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 Auth की स्थिति सिंक करना

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

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

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

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

बैकएंड बनाना

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

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

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

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

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

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

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

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

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

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

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

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

किसी बैकएंड को पूरी तरह से हटाने के लिए, पहले Firebase CLI का इस्तेमाल करें. इसके बाद, उससे जुड़ी एसेट को मैन्युअल तरीके से हटाएं. इस दौरान, इस बात का खास ध्यान रखें कि ऐसे किसी भी संसाधन को न मिटाएं जिसका इस्तेमाल, अन्य बैकएंड या आपके 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 प्रोजेक्ट के दूसरे बैकएंड या अन्य पहलुओं में न किया जा रहा हो.