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

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

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

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

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

Firebase कंसोल

एनवायरमेंट वैरिएबल जोड़ने के लिए, Firebase कंसोल के डायलॉग बॉक्स का स्क्रीन कैप्चर

apphosting.yaml 

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

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

आप Firebase कंसोल या अपने 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से भरे जाते हैं. इनमें, 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 अडैप्टर सेट करते हैं

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

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 के बीच किसी भी पूर्णांक वैल्यू पर सेट किया जा सकता है. हालांकि, मेमोरी की सीमा बढ़ाने के लिए, सीपीयू की सीमाएं बढ़ानी पड़ सकती हैं:

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