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

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

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

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

• स्टैंडर्ड एनवायरमेंट वैरिएबल: इनका इस्तेमाल, संवेदनशील जानकारी न रखने वाले और सादे टेक्स्ट वाले कॉन्फ़िगरेशन के लिए किया जाता है. जैसे, सार्वजनिक एपीआई यूआरएल, फ़ीचर फ़्लैग या बिल्ड टारगेट. वैल्यू, प्रोजेक्ट के सभी सदस्यों को दिखती हैं.
• सीक्रेट: इनका इस्तेमाल संवेदनशील पैरामीटर के लिए किया जाता है. जैसे, OAuth क्लाइंट सीक्रेट, एपीआई टोकन या डेटाबेस पासवर्ड. सीक्रेट, Cloud Secret Manager में सेव किए जाते हैं. सीक्रेट वैल्यू सुरक्षित होती हैं और इन्हें Firebase कंसोल में कभी भी सादे टेक्स्ट में नहीं दिखाया जाता. इसके बजाय, कंसोल में डीप लिंक दिए जाते हैं, ताकि Cloud Secret Manager में सीक्रेट वैल्यू को सीधे तौर पर देखा और मैनेज किया जा सके.

एनवायरमेंट पैरामीटर को तय और मैनेज करने के लिए, इन दो तरीकों का इस्तेमाल किया जा सकता है:

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

• कोड-फ़र्स्ट (apphosting.yaml): वर्शन-कंट्रोल वाले डिप्लॉयमेंट के लिए, अपनी रिपॉज़िटरी की कॉन्फ़िगरेशन फ़ाइल में एनवायरमेंट वैरिएबल और सीक्रेट रेफ़रंस का एलान करें. इसके अलावा, अलग-अलग एनवायरमेंट के लिए अलग-अलग वैल्यू सेट करने के लिए, apphosting.<env>.yaml का इस्तेमाल करें.

env:
  - variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
  - variable: API_KEY
    secret: myApiKeySecret

Firebase कंसोल में वैरिएबल और सीक्रेट मैनेज करना

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

बैकएंड बनाने के दौरान वैरिएबल और सीक्रेट सेट अप करना

Firebase कंसोल में नया App Hosting बैकएंड बनाते समय, सेटअप विज़र्ड के बैकएंड को कॉन्फ़िगर करें चरण के दौरान, स्टैंडर्ड एनवायरमेंट वैरिएबल और सीक्रेट कॉन्फ़िगर किए जा सकते हैं:

1. Firebase कंसोल में, होस्टिंग और सर्वरलेस > App Hosting पर जाएं और बैकएंड बनाएं पर क्लिक करें.
2. विज़र्ड के शुरुआती चरणों को पूरा करके, अपना मुख्य इलाका और कोड रिपॉज़िटरी चुनें.
3. अपना बैकएंड कॉन्फ़िगर करें सेक्शन में, एनवायरमेंट वैरिएबल और सीक्रेट के लिए, छोटा किए जा सकने वाले कार्ड ढूंढें. यहां स्टैंडर्ड वैरिएबल जोड़े जा सकते हैं और सीक्रेट अटैच किए जा सकते हैं.
4. बैकएंड बनाने के विज़र्ड को पूरा करें और पूरा करें और डिप्लॉय करें पर क्लिक करें.

बैकएंड सेटिंग में वैरिएबल और सीक्रेट मैनेज करना

बैकएंड सेटिंग डैशबोर्ड से, चालू बैकएंड के लिए एनवायरमेंट वैरिएबल और सीक्रेट देखे जा सकते हैं, जोड़े जा सकते हैं, उनमें बदलाव किए जा सकते हैं या उन्हें मिटाया जा सकता है:

1. Firebase कंसोल में, अपना App Hosting बैकएंड चुनें. इसके बाद, सेटिंग > एनवायरमेंट पर जाएं.
2. एनवायरमेंट वैरिएबल टेबल में, मौजूदा कॉन्फ़िगरेशन देखें:
   • स्टैंडर्ड वैरिएबल: वैल्यू, कॉपी किए जा सकने वाले कोड ब्लॉक में सादे टेक्स्ट के तौर पर दिखती हैं.
   • सीक्रेट: यह क्लिक किए जा सकने वाले लिंक के तौर पर दिखता है. इसमें सीक्रेट का नाम दिखता है. इस पर क्लिक करने से, Google Cloud कंसोल में Cloud Secret Manager खुलता है. साथ ही, इसमें टारगेट किया गया वर्शन भी दिखता है. जैसे, latest या कोई खास वर्शन नंबर, जैसे कि 2.
3. कोई वैरिएबल या सीक्रेट जोड़ने के लिए:
   1. नया जोड़ें पर क्लिक करें.
   2. पहला चरण: टाइप चुनें में जाकर, स्टैंडर्ड एनवायरमेंट वैरिएबल (प्रोजेक्ट के सभी सदस्यों को दिखने वाले सामान्य डेटा के लिए) या सीक्रेट (एपीआई पासकोड और संवेदनशील क्रेडेंशियल के लिए, जिनका ऐक्सेस सीमित है) चुनें. इसके बाद, आगे बढ़ें पर क्लिक करें.
   3. दूसरा चरण: सेटिंग कॉन्फ़िगर करें में, कुंजी का नाम और सादे टेक्स्ट वाली वैल्यू (स्टैंडर्ड वैरिएबल के लिए) डालें या सीक्रेट आईडी और वर्शन (सीक्रेट के लिए) चुनें.
   4. इनमें से किसी एक विकल्प का इस्तेमाल करके, अपने बदलावों को सेव करें:
      • सेव और डिप्लॉय करें: इससे बैकएंड कॉन्फ़िगरेशन तुरंत अपडेट हो जाता है. साथ ही, एक नया बिल्ड और रोलआउट ट्रिगर होता है.
      • सिर्फ़ सेव करें (सेव करें और डिप्लॉय करें के बगल में मौजूद ड्रॉप-डाउन ऐरो से): इससे कॉन्फ़िगरेशन में किए गए बदलाव सेव हो जाते हैं, लेकिन तुरंत रोल आउट नहीं होते. अपडेट की गई सेटिंग, आपके अगले डिप्लॉयमेंट पर लागू होती हैं.
4. किसी मौजूदा एंट्री में बदलाव करने या उसे मिटाने के लिए, पंक्ति के आखिर में मौजूद ज़्यादा कार्रवाइयां (...) मेन्यू पर क्लिक करें:
   • कुंजी, वैल्यू, सीक्रेट मैपिंग या वर्शन में बदलाव करने के लिए, बदलाव करें को चुनें. इसके बाद, सेव करें और डिप्लॉय करें या सिर्फ़ सेव करें पर क्लिक करें.
   • मिटाएं को चुनें. इसके बाद, डायलॉग बॉक्स में जाकर, हटाने की पुष्टि करें.

dotenv फ़ाइलों से वैरिएबल ट्रांसफ़र करें

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

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

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

KEY1=value1
KEY2=value2
KEY3=value3

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

apphosting.yaml में वैरिएबल और सीक्रेट मैनेज करना

कोड-फ़र्स्ट वर्कफ़्लो के लिए, अपनी प्रोजेक्ट रिपॉज़िटरी की apphosting.yaml कॉन्फ़िगरेशन फ़ाइल में, env: कुंजी के तहत स्टैंडर्ड एनवायरमेंट वैरिएबल और सीक्रेट रेफ़रंस का एलान करें (apphosting.yaml बनाना और उसमें बदलाव करना देखें).

env:
  # Standard environment variables
  - variable: PUBLIC_API_URL
    value: https://api.example.com
    availability:
      - BUILD
      - RUNTIME
  - variable: FEATURE_FLAG_NEW_UI
    value: "true"

  # Secret references backed by Cloud Secret Manager
  - variable: DATABASE_URL
    secret: projects/PROJECT_ID/secrets/db-connection-string/versions/latest
  - variable: GEMINI_API_KEY
    secret: myGeminiApiKeySecret@1

env: में मौजूद हर एंट्री में ये फ़ील्ड इस्तेमाल किए जा सकते हैं:

• variable: एनवायरमेंट वैरिएबल का नाम, जो आपके ऐप्लिकेशन की प्रोसेस को दिखता है.
• value: स्टैंडर्ड एनवायरमेंट वैरिएबल के लिए, सादे टेक्स्ट वाली स्ट्रिंग वैल्यू.
• secret: Cloud Secret Manager का सीक्रेट रेफ़रंस (सीक्रेट के लिए). सीक्रेट के छोटे नाम (जैसे, myGeminiApiKeySecret या पिन किया गया myGeminiApiKeySecret@1) या पूरे रिसॉर्स पाथ (projects/PROJECT_ID/secrets/SECRET_ID/versions/VERSION) का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, सीक्रेट पैरामीटर सेव करना और उन्हें ऐक्सेस करना लेख पढ़ें.
• availability: इससे यह कंट्रोल किया जाता है कि वैरिएबल या सीक्रेट को BUILD फ़ेज़ के दौरान, RUNTIME पर या दोनों पर ऐक्सेस किया जा सकता है या नहीं.

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

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

ऐप्लिकेशन कोड में वैरिएबल और सीक्रेट ऐक्सेस करना

चाहे Firebase कंसोल में कॉन्फ़िगर किया गया हो या apphosting.yaml में, एनवायरमेंट वैरिएबल और सीक्रेट, आपके ऐप्लिकेशन रनटाइम के लिए स्टैंडर्ड एनवायरमेंट वैरिएबल के तौर पर दिखते हैं. उदाहरण के लिए, Node.js में process.env.

// Accessing a standard environment variable
const apiUrl = process.env.PUBLIC_API_URL;

// Accessing a secret
const apiKey = process.env.GEMINI_API_KEY;

export async function fetchData() {
  const response = await fetch(`${apiUrl}/data`, {
    headers: {
      'Authorization': `Bearer ${apiKey}`
    }
  });
  return response.json();
}

• सर्वर-साइड ऐक्सेस: सभी एनवायरमेंट वैरिएबल और सीक्रेट, सर्वर-साइड एक्ज़ीक्यूशन कॉन्टेक्स्ट में सुरक्षित तरीके से ऐक्सेस किए जा सकते हैं. जैसे, Next.js सर्वर कॉम्पोनेंट, एपीआई रूट या Node.js बैकएंड हैंडलर.

• क्लाइंट-साइड एक्सपोज़र: Next.js जैसे फ़्रेमवर्क में ब्राउज़र को स्टैंडर्ड एनवायरमेंट वैरिएबल दिखाने के लिए, पक्का करें कि वैरिएबल की कुंजी, फ़्रेमवर्क के नियमों का पालन करती हो. उदाहरण के लिए, प्रीफ़िक्स के तौर पर NEXT_PUBLIC_ का इस्तेमाल किया गया हो.

  env:
    - variable: NEXT_PUBLIC_STORAGE_BUCKET
      value: mybucket.firebasestorage.app
      availability:
        - BUILD
        - RUNTIME
  

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

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

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

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

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

कुछ एनवायरमेंट वैरिएबल, 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"
  }</span>
  

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

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

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

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

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

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

1. Firebase console → कंसोल में सेट किए गए वैरिएबल
2. apphosting.<env>.yaml → एनवायरमेंट के हिसाब से बनाई गई yaml फ़ाइल में तय किए गए वैरिएबल, जैसे कि apphosting.staging.yaml (एक से ज़्यादा एनवायरमेंट डिप्लॉय करना देखें)
3. apphosting.yaml → apphosting.yaml फ़ाइल में बताए गए वैरिएबल
4. Firebase सिस्टम → Firebase से सेट किए गए वैरिएबल, जिनमें firebase_config json या firebase_webapp_config की वैल्यू शामिल होती हैं. साथ ही, इनमें ऐसे एनवायरमेंट वैरिएबल भी शामिल होते हैं जो एसएसआर ऐप्लिकेशन के लिए होस्टनेम और पोर्ट सेट करते हैं. इन्हें 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 Run सेवा के लिए उपलब्ध सेटिंग, runConfig ऑब्जेक्ट में दी गई हैं:

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

ध्यान दें कि cpu, memoryMiB, और concurrency की सीमाएं एक-दूसरे पर निर्भर करती हैं. उदाहरण के लिए, ज़्यादा मेमोरी कॉन्फ़िगरेशन के लिए, सीपीयू की ज़्यादा से ज़्यादा सीमाएं ज़रूरी हैं. साथ ही, फ़्रैक्शनल सीपीयू के लिए, 1 की कॉनकरंसी ज़रूरी है. मान्य रेंज और ज़रूरी कॉम्बिनेशन के लिए, सीपीयू की सीमाओं और मेमोरी की सीमाओं के बारे में Cloud Run दस्तावेज़ देखें.

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

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 को [.] पर सेट करें. इससे सभी फ़ाइलें डिप्लॉय हो जाएंगी.

सीक्रेट पैरामीटर सेव करना और उन्हें ऐक्सेस करना

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

secret टाइप के पैरामीटर, स्ट्रिंग पैरामीटर होते हैं. इनकी वैल्यू Cloud Secret Manager में सेव होती है. सीक्रेट पैरामीटर, वैल्यू को सीधे तौर पर नहीं लेते. इसके बजाय, वे Cloud Secret Manager में मौजूद वैल्यू की जांच करते हैं और रोल आउट के दौरान वैल्यू लोड करते हैं.

env:
  - variable: API_KEY
    secret: myApiKeySecret

Cloud Secret Manager में मौजूद सीक्रेट के कई वर्शन हो सकते हैं. डिफ़ॉल्ट रूप से, आपके लाइव बैकएंड के लिए उपलब्ध सीक्रेट पैरामीटर की वैल्यू, बैकएंड बनाते समय सीक्रेट के सबसे नए उपलब्ध वर्शन पर पिन की जाती है. अगर आपको पैरामीटर के वर्शन और लाइफ़साइकल को मैनेज करना है, तो Firebase कंसोल या apphosting.yaml में जाकर, खास वर्शन पिन किए जा सकते हैं. उदाहरण के लिए, apphosting.yaml में वर्शन 5 को पिन करने के लिए:

env:
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

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

Cloud Secret Manager का ऐक्सेस देना

बिल्ड और रनटाइम रोलआउट के दौरान, App Hosting को सीक्रेट वैल्यू फ़ेच करने के लिए, App Hosting बैकएंड सेवा खाते के पास Cloud Secret Manager को ऐक्सेस करने की अनुमति होनी चाहिए.

अगर आपने firebase apphosting:secrets:set के बजाय, Cloud Secret Manager कंसोल या gcloud सीएलआई का इस्तेमाल करके सीक्रेट बनाए हैं, तो Firebase सीएलआई का इस्तेमाल करके अपने बैकएंड को ऐक्सेस दें:

firebase apphosting:secrets:grantaccess SECRET_NAME

इसके अलावा, gcloud सीएलआई का इस्तेमाल करके, App Hosting सेवा एजेंट (service-PROJECT_NUMBER@gcp-sa-apphosting.iam.gserviceaccount.com) या अपने बैकएंड के रनटाइम सेवा खाते को Secret Manager Secret Accessor की भूमिका (roles/secretmanager.secretAccessor) दी जा सकती है:

gcloud secrets add-iam-policy-binding SECRET_NAME \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-apphosting.iam.gserviceaccount.com" \
    --role="roles/secretmanager.secretAccessor"

Console का ऐक्सेस और भूमिका के हिसाब से अनुमतियां

Firebase कंसोल, उपयोगकर्ता को मिली आईएएम अनुमतियों के आधार पर, एनवायरमेंट और Secret Manager की सुविधाओं को डाइनैमिक तौर पर सीमित करता है:

• दर्शक की भूमिका: जिन उपयोगकर्ताओं के पास प्रोजेक्ट के लिए सिर्फ़ रीड-ओनली ऐक्सेस है वे मौजूदा कॉन्फ़िगरेशन सेटिंग देख सकते हैं. हालांकि, वे इनमें बदलाव नहीं कर सकते.
  • बैकएंड बनाने के दौरान, बैकएंड बनाएं बटन बंद रहता है.
  • बैकएंड सेटिंग > एनवायरमेंट में, नया जोड़ें बटन बंद है और ज़्यादा कार्रवाइयां (...) लाइन मेन्यू छिपे हुए हैं.
• Secret Manager की अनुमतियां मौजूद नहीं हैं: जिन उपयोगकर्ताओं के पास Cloud Secret Manager के साथ इंटरैक्ट करने के लिए आईएएम की अनुमतियां नहीं हैं उन्हें कंसोल में चेतावनी वाला मैसेज दिखता है (सीक्रेट जोड़ने की अनुमति के लिए, प्रोजेक्ट के मालिक से कहें):
  • बैकएंड बनाने के दौरान, सीक्रेट कार्ड बंद रहता है.
  • बैकएंड सेटिंग > एनवायरमेंट में, नया जोड़ें पर क्लिक करने पर, सीक्रेट विकल्प बंद हो जाता है. साथ ही, ज़्यादा कार्रवाइयां (...) वाली लाइन के मेन्यू में मौजूद कुछ विकल्प, सीक्रेट एंट्री पर छिपे होते हैं.

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

आपका 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 सीएलआई में दिए गए हैं. इस सेक्शन में, मैनेजमेंट से जुड़े कुछ सामान्य टास्क के बारे में बताया गया है. इनमें बैकएंड बनाना और मिटाना शामिल है.

बैकएंड बनाना

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.js का सुझाया गया सबसे नया वर्शन पहले से चुना होता है.

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

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

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