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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

apphosting.yaml बनाना और उसमें बदलाव करना

बेहतर कॉन्फ़िगरेशन के लिए, आपको अपने ऐप्लिकेशन की रूट डायरेक्ट्री में 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

बिल्ड और रन स्क्रिप्ट को बदलना

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

scripts:
  buildCommand: next build --no-lint
  runCommand: node dist/index.js

'बिल्ड कमांड बदलें', किसी भी अन्य 'बिल्ड कमांड' के मुकाबले प्राथमिकता पाता है. साथ ही, यह आपके ऐप्लिकेशन को फ़्रेमवर्क अडैप्टर से हटा देता है और App Hosting के फ़्रेमवर्क के हिसाब से ऑप्टिमाइज़ेशन को बंद कर देता है. इसका इस्तेमाल तब करना सबसे अच्छा होता है, जब अडैप्टर आपके ऐप्लिकेशन की सुविधाओं के साथ ठीक से काम न करते हों. अगर आपको अपनी बिल्ड कमांड बदलनी है, लेकिन हमारे दिए गए अडैप्टर का इस्तेमाल करना है, तो App Hosting फ़्रेमवर्क अडैप्टर में बताए गए तरीके के बजाय, अपनी बिल्ड स्क्रिप्ट को package.json में सेट करें.

जब आपको अपने ऐप्लिकेशन को शुरू करने के लिए, App Hosting-inferred command से अलग कोई खास निर्देश इस्तेमाल करना हो, तो 'रन कमांड बदलें' सुविधा का इस्तेमाल करें.

बिल्ड आउटपुट कॉन्फ़िगर करना

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

outputFiles:
  serverApp:
    include: [dist, server.js]

include पैरामीटर, ऐप्लिकेशन की रूट डायरेक्ट्री से जुड़ी उन डायरेक्ट्री और फ़ाइलों की सूची लेता है जो आपके ऐप्लिकेशन को डिप्लॉय करने के लिए ज़रूरी हैं. अगर आपको पक्का करना है कि सभी फ़ाइलें सेव रहें, तो 'शामिल करें' को [.] पर सेट करें. ऐसा करने पर, सभी फ़ाइलें डिप्लॉय हो जाएंगी.

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

एपीआई पासकोड जैसी संवेदनशील जानकारी को गुप्त के तौर पर सेव किया जाना चाहिए. सोर्स कंट्रोल में संवेदनशील जानकारी की जांच करने से बचने के लिए, 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 बैकएंड को अनुमतियां देनी होंगी.

VPC ऐक्सेस कॉन्फ़िगर करना

आपका App Hosting बैकएंड, वर्चुअल प्राइवेट क्लाउड (VPC) नेटवर्क से कनेक्ट हो सकता है. ज़्यादा जानकारी और उदाहरण के लिए, Firebase App Hosting को VPC नेटवर्क से कनेक्ट करना लेख पढ़ें.

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

runConfig:
  vpcAccess:
    egress: PRIVATE_RANGES_ONLY # Default value
    networkInterfaces:
      # Specify at least one of network and/or subnetwork
      - network: my-network-id
        subnetwork: my-subnetwork-id

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

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

बैकएंड बनाना

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

Firebase कंसोल: सेटिंग मेन्यू में जाकर, बैकएंड मिटाएं को चुनें.

सीएलआई: (13.15.4 या इसके बाद का वर्शन)

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 प्रोजेक्ट के दूसरे बैकएंड या अन्य पहलुओं में न किया जा रहा हो.