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

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

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

एनवायरमेंट वैरिएबल या रनटाइम सेटिंग जैसे ऐडवांस कॉन्फ़िगरेशन के लिए जैसे कि कॉनक्सीरी, सीपीयू, और मेमोरी की सीमाओं जैसी सुविधाओं का इस्तेमाल करके, 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 – MiB में हर सर्विंग इंस्टेंस के लिए तय की गई मेमोरी (डिफ़ॉल्ट 512)
  • maxInstances – एक बार में चलाए जाने वाले कंटेनर की ज़्यादा से ज़्यादा संख्या (डिफ़ॉल्ट) 100 में से 100 वर्शन और कोटे से मैनेज किए जाते हैं)
  • minInstances – हमेशा ऐक्टिव रखने वाले कंटेनर की संख्या (डिफ़ॉल्ट 0).
  • concurrency – हर कार्रवाई इंस्टेंस से किए जा सकने वाले अनुरोधों की ज़्यादा से ज़्यादा संख्या पाएं (डिफ़ॉल्ट 80).

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

  • 4GiB से ज़्यादा चलने वाले डिवाइस के लिए, कम से कम दो सीपीयू ज़रूरी हैं
  • 8GiB से ज़्यादा चलने वाले डिवाइस के लिए, कम से कम 4 सीपीयू ज़रूरी हैं
  • 16GiB से ज़्यादा चलने वाले डिवाइस के लिए, कम से कम 6 सीपीयू ज़रूरी हैं
  • 24GiB से ज़्यादा चलने वाले डिवाइस के लिए, कम से कम 8 सीपीयू ज़रूरी हैं

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

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

कभी-कभी आपको अपनी बिल्ड प्रोसेस के लिए अतिरिक्त कॉन्फ़िगरेशन की ज़रूरत पड़ेगी, जैसे कि तीसरे पक्ष की एपीआई कुंजियां या ट्यून करने लायक सेटिंग. 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 के सीक्रेट के कई वर्शन हो सकते हैं. डिफ़ॉल्ट रूप से, आपके लाइव बैकएंड के लिए उपलब्ध किसी सीक्रेट पैरामीटर की वैल्यू बैकएंड के बनने के समय, सीक्रेट का सबसे नया वर्शन उपलब्ध था. अगर आपको पैरामीटर के वर्शन और लाइफ़साइकल मैनेजमेंट की ज़रूरी शर्तें पूरी करना चाहते हैं, तो क्लाउड सीक्रेट मैनेजर की मदद से खास वर्शन पर पिन करें. उदाहरण के लिए, वर्शन 5:

  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

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

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

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

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

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

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

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

बैकएंड बनाएं

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

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

सीएलआई: (वर्शन 3.9 या इसके बाद का वर्शन) बैकएंड बनाने के लिए, यह कमांड चलाएं स्थानीय प्रोजेक्ट डायरेक्ट्री के रूट से निकाला जा सकता है, प्रोजेक्ट आईडी का इस्तेमाल आर्ग्युमेंट के तौर पर करें (झलक देखने के लिए, केवल us-central1 क्षेत्र समर्थित हैं):

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 प्रोजेक्ट के अन्य पहलुओं के बारे में भी बताएंगे.