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

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

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

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

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

Firebase कंसोल

apphosting.yaml

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

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

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

आप 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 फ़ाइलों में सेट की गई वैल्यू को बदल देती हैं या उन पर प्राथमिकता लेती हैं.

अहम जानकारी: Firebase कंसोल में, किसी खास रोलआउट को चुनकर, उसकी जानकारी देखी जा सकती है. रोलआउट की जानकारी वाले पैनल में सबसे नीचे मौजूद, इस बिल्ड में एनवायरमेंट वैरिएबल पर जाएं. यहां आपको रोलआउट के दौरान इस्तेमाल किए गए एनवायरमेंट वैरिएबल और उनके सोर्स की सूची दिखेगी.

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

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 जीबी से ज़्यादा के लिए, कम से कम चार सीपीयू की ज़रूरत होती है
• 16 जीबी से ज़्यादा के लिए, कम से कम छह सीपीयू की ज़रूरत होती है
• 24 जीबी से ज़्यादा के लिए, कम से कम आठ सीपीयू की ज़रूरत होती है

इसी तरह, 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 आपके वेब ऐप्लिकेशन को बनाने और चलाने के लिए, इन संसाधनों को बनाता है.

प्रोजेक्ट के मालिक को

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

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