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

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

एनवायरमेंट वैरिएबल सेट और अपडेट करना

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

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

env:
-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app

वैरिएबल अपडेट करना

आप Firebase कंसोल या अपने apphosting.yaml का इस्तेमाल करके, एनवायरमेंट वैरिएबल जोड़े, उनमें बदलाव किए या मिटाए जा सकते हैं:

• Firebase कंसोल:

  1. Firebase कंसोल में, होस्टिंग और सर्वरलेस > App Hosting पर जाएं.

  2. बैकएंड देखें > सेटिंग > एनवायरमेंट पर जाएं.

  3. एनवायरमेंट वैरिएबल जोड़ें, उनमें बदलाव करें या मिटाएं.

• apphosting.yaml:

  फ़ाइल को मैन्युअल तरीके से बनाने और उसमें बदलाव करने का तरीका जानें.

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

वैरिएबल की उपलब्धता सेट करना

Firebase कंसोल में बनाए गए एनवायरमेंट वैरिएबल, बिल्ड टाइम और रन टाइम, दोनों में उपलब्ध होते हैं. यह apphosting.yaml में तय किए गए वैरिएबल के लिए भी डिफ़ॉल्ट स्थिति है. हालांकि, अगर आपने availability प्रॉपर्टी का इस्तेमाल करके, उस स्कोप को सीमित कर दिया है, तो यह स्थिति लागू नहीं होगी. apphosting.yaml में (कंसोल में नहीं), किसी एनवायरमेंट वैरिएबल को सिर्फ़ बिल्ड एनवायरमेंट के लिए उपलब्ध होने या सिर्फ़ रनटाइम एनवायरमेंट के लिए उपलब्ध होने तक सीमित किया जा सकता है.

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

Next.js के लिए dotenv फ़ाइलें

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

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

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

KEY1=value1
KEY2=value2
KEY3=value3

किसी भी फ़्रेमवर्क के साथ, एनवायरमेंट वैरिएबल को बेहतर तरीके से कंट्रोल करने के लिए, हम सुझाव देते हैं कि apphosting.yamlका इस्तेमाल करें.

एनवायरमेंट वैरिएबल अपने-आप भरना

कुछ एनवायरमेंट वैरिएबल ऐसे होते हैं जो अपने-आप भर जाते हैं App Hosting. इनमें, Google Cloud से भरे जाने वाले वैरिएबल के साथ-साथ,Google Cloud Firebase के लिए खास एनवायरमेंट वैरिएबल भी शामिल हैं. ये वैरिएबल, सेटअप के दौरान बैकएंड पर appId सेट होने पर भरते हैं:

• FIREBASE_CONFIG: (बिल्ड और रनटाइम एनवायरमेंट में उपलब्ध) Firebase प्रोजेक्ट के कॉन्फ़िगरेशन की यह जानकारी देता है:

  {
    "databaseURL": 'https://DATABASE_NAME.firebaseio.com',
    "storageBucket": 'PROJECT_ID.firebasestorage.app',
    "projectId": 'PROJECT_ID'
  }
  

  जब Firebase Admin SDK को बिना किसी आर्ग्युमेंट के शुरू किया जाता है, तो यह कॉन्फ़िगरेशन अपने-आप लागू हो जाता है.

• FIREBASE_WEBAPP_CONFIG: (सिर्फ़ बिल्ड एनवायरमेंट में उपलब्ध) Firebase प्रोजेक्ट के कॉन्फ़िगरेशन की यह जानकारी देता है:

  {
    "apiKey": 'API_KEY',
    "appId": 'APP_ID',
    "authDomain": 'AUTH_DOMAIN.firebaseapp.com',
    "databaseURL": 'https://DATABASE_NAME.firebaseio.com',
    "messagingSenderId": 'PROJECT_NUMBER',
    "projectId": 'PROJECT_ID',
    "storageBucket": 'PROJECT_ID.firebasestorage.app',
  }
  

  Firebase JS SDK, बिल्ड के दौरान पोस्टइंस्टॉल स्क्रिप्ट में, इस FIREBASE_WEBAPP_CONFIG एनवायरमेंट वैरिएबल की जांच अपने-आप करता है. इससे, क्लाइंट SDK को बिना किसी आर्ग्युमेंट के भी शुरू किया जा सकता है.

SDK को शुरू करने के लिए, इन एनवायरमेंट वैरिएबल का इस्तेमाल करने के तरीके के बारे में ज़्यादा जानने के लिए, Firebase Admin SDK और वेब SDK को अपने-आप शुरू करना लेख पढ़ें.

ध्यान दें कि आपके Firebase के असली कॉन्फ़िगरेशन में मौजूद वैल्यू, आपके प्रोजेक्ट में उपलब्ध कराए गए खास संसाधनों से मेल खाएंगी.

वैरिएबल हैरारकी

Firebase App Hosting, आपके वैरिएबल को उनके सोर्स के आधार पर प्राथमिकता के क्रम में लागू करता है. उदाहरण के लिए, Firebase कंसोल में सेट की गई वैल्यू हमेशा apphosting.yaml और dotenv फ़ाइलों में सेट की गई वैल्यू को बदल देती हैं या उन पर प्राथमिकता लेती हैं.

यहां प्राथमिकता का पूरा क्रम दिया गया है:

1. Firebase कंसोल → कंसोल में सेट किए गए वैरिएबल
2. apphosting.<env>.yaml → एनवायरमेंट के लिए खास yaml फ़ाइल में तय किए गए वैरिएबल, जैसे कि apphosting.staging.yaml (एक से ज़्यादा एनवायरमेंट डिप्लॉय करना देखें)
3. apphosting.yaml → apphosting.yaml फ़ाइल में तय किए गए वैरिएबल
4. Firebase सिस्टम → Firebase की ओर से सेट किए गए वैरिएबल. इनमें firebase_config json या firebase_webapp_config के लिए वैल्यू के साथ-साथ, SSR ऐप्लिकेशन के लिए होस्टनेम और पोर्ट सेट करने वाले एनवायरमेंट वैरिएबल शामिल हैं. इन्हें `bundle.yaml` में App Hosting अडैप्टर सेट करते हैं bundle.yaml

रिज़र्व किए गए नाम और सीमाएं

कंटेनर रनटाइम कॉन्ट्रैक्ट में तय किए गए एनवायरमेंट वैरिएबल रिज़र्व किए जाते हैं. इन्हें सेट नहीं किया जा सकता.Cloud Run

एनवायरमेंट की ओर से उपलब्ध कराए गए एनवायरमेंट वैरिएबल, जो अपने-आप सेट नहीं होते, वे आने वाले रनटाइम वर्शन में बदल सकते हैं. हमारा सुझाव है कि आप ऐसे किसी भी एनवायरमेंट वैरिएबल पर निर्भर न रहें या उसमें बदलाव न करें जिसे आपने साफ़ तौर पर सेट नहीं किया है. साथ ही, टकराव से बचने के लिए, किसी भी एनवायरमेंट वैरिएबल के साथ कोई यूनीक कुंजी प्रीफ़िक्स के तौर पर इस्तेमाल करें.

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

• खाली स्ट्रिंग ("")
• ऐसी कुंजियां जिनमें "=" शामिल है
• X_FIREBASE_, X_GOOGLE_ या CLOUD_RUN_ से शुरू होने वाली कुंजियां
• PORT
• K_SERVICE
• K_REVISION
• K_CONFIGURATION
• डुप्लीकेट कुंजियां

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 RunrunConfig

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

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

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

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

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

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

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

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

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

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

वीपीसी ऐक्सेस कॉन्फ़िगर करना

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

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

वीपीसी से सीधे बाहर निकलने की सुविधा का कॉन्फ़िगरेशन (apphosting.yaml):

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

सर्वरलेस कनेक्टर का कॉन्फ़िगरेशन (apphosting.yaml):

runConfig:
  vpcAccess:
    egress: ALL_TRAFFIC
    connector: connector-id

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

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

बैकएंड बनाना

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

Firebase कंसोल: होस्टिंग और सर्वरलेस > App Hosting पर जाएं. इसके बाद, बैकएंड बनाएं पर क्लिक करें. अगर यह आपके Firebase प्रोजेक्ट का पहला बैकएंड है, तो शुरू करें पर क्लिक करें.

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

firebase apphosting:backends:create --project PROJECT_ID

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

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

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

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

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

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

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

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

• अपना रनटाइम एनवायरमेंट चुनें. डिफ़ॉल्ट रूप से, Node.j के सबसे नए सुझाए गए वर्शन को आपके लिए पहले से चुना गया होता है.

  • बेस इमेज के अपडेट अपने-आप होने की सुविधा (एबीआईयू) कॉन्फ़िगर करें. एबीआईयू, डिफ़ॉल्ट रूप से चालू होती है और आपके एनवायरमेंट में सुरक्षा पैच अपने-आप लागू करती है. अपने रनटाइम के लिए "तय नहीं किया गया" विकल्प चुनकर, एबीआईयू से ऑप्ट आउट किया जा सकता है.

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

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

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

Firebase CLI: (v13.15.4 या उसके बाद का वर्शन)

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

   firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID
   

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

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