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

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 की सेवा कैसे उपलब्ध कराई जाए. Cloud Run सेवा के लिए उपलब्ध सेटिंग, runConfig ऑब्जेक्ट में दी गई हैं:

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

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

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

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

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

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

अगर आपको ऐप्लिकेशन शुरू करने के लिए, App Hosting-इनफ़र्ड कमांड से अलग कोई खास कमांड इस्तेमाल करनी है, तो रन कमांड ओवरराइड का इस्तेमाल करें.

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

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

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

include पैरामीटर, ऐप्लिकेशन की रूट डायरेक्ट्री से जुड़ी डायरेक्ट्री और फ़ाइलों की सूची लेता है. ये फ़ाइलें, ऐप्लिकेशन को डिप्लॉय करने के लिए ज़रूरी होती हैं. अगर आपको यह पक्का करना है कि सभी फ़ाइलें सेव की गई हैं, तो 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 की सभी सुविधाओं का इस्तेमाल करने के लिए, Cloud Secret Manager कंसोल का इस्तेमाल करें. ऐसा करने पर, आपको सीएलआई कमांड firebase apphosting:secrets:grantaccess का इस्तेमाल करके, अपने App Hosting बैकएंड को अनुमतियां देनी होंगी.

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

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

ऐक्सेस कॉन्फ़िगर करने के लिए, अपनी 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 कंसोल: Build मेन्यू में जाकर, App Hosting और फिर Get started चुनें.

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

firebase apphosting:backends:create --project PROJECT_ID

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

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

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

• लाइव ब्रांच सेट करना

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

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

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

• अपने बैकएंड को कोई नाम असाइन करें.

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

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

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

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

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

   firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID
   

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

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