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

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 कंसोल में, होस्टिंग और सर्वरलेस > ऐप्लिकेशन होस्टिंग पर जाएं.

  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 से पॉप्युलेट होने वाले वैरिएबल शामिल हैं. इसके अलावा, सेटअप के दौरान बैकएंड पर appId सेट होने पर, Firebase के लिए खास एनवायरमेंट वैरिएबल भी शामिल हैं:

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

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

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

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

Firebase ऐप्लिकेशन होस्टिंग, आपके वैरिएबल को प्राथमिकता के क्रम में लागू करती है. यह क्रम, उनके सोर्स पर आधारित होता है. उदाहरण के लिए, 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 अडैप्टर सेट करते हैं

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

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

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

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

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

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

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

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

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

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

आपका App Hosting बैकएंड, वर्चुअल प्राइवेट क्लाउड (VPC) नेटवर्क से कनेक्ट हो सकता है. ज़्यादा जानकारी और उदाहरण के लिए, 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 console: होस्टिंग और सर्वरलेस > ऐप्लिकेशन होस्टिंग पर जाएं. इसके बाद, बैकएंड बनाएं पर क्लिक करें. अगर यह आपके Firebase प्रोजेक्ट में पहला बैकएंड है, तो शुरू करें पर क्लिक करें.

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

firebase apphosting:backends:create --project PROJECT_ID

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

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

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

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

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

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

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

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

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

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

किसी बैकएंड को मिटाना

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

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

Firebase सीएलआई: (v13.15.4 या उसके बाद का वर्शन)

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

   firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID
   

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

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