एनवायरमेंट वैरिएबल या रनटाइम सेटिंग (जैसे कि एक ही मुद्रा, सीपीयू, और मेमोरी की सीमाओं) जैसे ऐडवांस कॉन्फ़िगरेशन के लिए, आपको अपने ऐप्लिकेशन की रूट डायरेक्ट्री में apphosting.yaml
फ़ाइल बनानी होगी और उसमें बदलाव करना होगा. यह फ़ाइल, Cloud Secret Manager की मदद से मैनेज किए जा रहे सीक्रेट के रेफ़रंस के साथ भी काम करती है, जिससे सोर्स कंट्रोल में जांच करना सुरक्षित हो जाता है.
बैकएंड की Cloud Run सेवा की सेटिंग, कुछ एनवायरमेंट वैरिएबल, और Cloud Secret Manager से मैनेज किए जाने वाले सीक्रेट के कुछ रेफ़रंस के साथ, आम तौर पर एक apphosting.yaml
फ़ाइल कुछ इस तरह दिख सकती है:
# 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.appspot.com
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 से ज़्यादा चलने वाले डिवाइस के लिए, कम से कम 4 सीपीयू ज़रूरी हैं
- 16GiB से ज़्यादा चलने वाले डिवाइस के लिए, कम से कम 6 सीपीयू ज़रूरी हैं
- 24GiB से ज़्यादा चलने वाले डिवाइस के लिए, कम से कम 8 सीपीयू ज़रूरी हैं
इसी तरह, cpu
की वैल्यू का असर, एक साथ कई काम करने की सेटिंग पर पड़ता है. अगर आपने एक से कम सीपीयू की वैल्यू सेट की है, तो आपको एक साथ 1 पर सेट करना होगा. इसके अलावा, सीपीयू का इस्तेमाल सिर्फ़ अनुरोध प्रोसेस करने के दौरान किया जाएगा.
बिल्ड एनवायरमेंट को कॉन्फ़िगर करना
कभी-कभी आपको अपनी बिल्ड प्रोसेस के लिए अतिरिक्त कॉन्फ़िगरेशन की ज़रूरत पड़ सकती है, जैसे कि
तीसरे पक्ष की एपीआई कुंजियां या ट्यून करने लायक सेटिंग. ऐप्लिकेशन होस्टिंग की मदद से, apphosting.yaml
में एनवायरमेंट कॉन्फ़िगरेशन की सुविधा मिलती है. इससे आपके प्रोजेक्ट के लिए इस तरह का डेटा स्टोर और वापस पाया जा सकता है.
env:
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
Next.js ऐप्लिकेशन के लिए, एनवायरमेंट वैरिएबल वाली dotenv फ़ाइलें भी ऐप्लिकेशन होस्टिंग के साथ काम करेंगी. हमारा सुझाव है कि किसी भी फ़्रेमवर्क के साथ बेहतर एनवायरमेंट वैरिएबल कंट्रोल के लिए, apphosting.yaml
का इस्तेमाल करें.
apphosting.yaml
में, availability
प्रॉपर्टी का इस्तेमाल करके यह तय किया जा सकता है कि किन प्रोसेस के पास आपके एनवायरमेंट वैरिएबल का ऐक्सेस है. किसी एनवायरमेंट वैरिएबल को सिर्फ़ बिल्ड एनवायरमेंट में या सिर्फ़ रनटाइम एनवायरमेंट में उपलब्ध होने तक सीमित किया जा सकता है. डिफ़ॉल्ट रूप से, यह दोनों के लिए उपलब्ध होता है.
env:
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
availability:
- BUILD
- RUNTIME
Next.js ऐप्लिकेशन के लिए, NEXT_PUBLIC_
प्रीफ़िक्स को ठीक उसी तरह इस्तेमाल किया जा सकता है जिस तरह
आप अपनी dotenv फ़ाइल में करते हैं, ताकि किसी वैरिएबल को ब्राउज़र में ऐक्सेस किया जा सके.
env:
- variable: NEXT_PUBLIC_STORAGE_BUCKET
value: mybucket.appspot.com
availability:
- BUILD
- RUNTIME
मान्य वैरिएबल की में A से Z तक के वर्ण या अंडरस्कोर होते हैं. एनवायरमेंट वैरिएबल की कुछ कुंजियों को अंदरूनी इस्तेमाल के लिए रिज़र्व किया गया है. अपनी कॉन्फ़िगरेशन फ़ाइलों में, इनमें से किसी भी कुंजी का इस्तेमाल न करें:
X_FIREBASE_
से शुरू होने वाला कोई भी वैरिएबलPORT
K_SERVICE
K_REVISION
K_CONFIGURATION
सीक्रेट पैरामीटर सेव और ऐक्सेस करना
एपीआई पासकोड जैसी संवेदनशील जानकारी को सीक्रेट के तौर पर सेव किया जाना चाहिए. सोर्स कंट्रोल में संवेदनशील जानकारी की जांच करने से बचने के लिए, apphosting.yaml
में सीक्रेट रेफ़रंस दिए जा सकते हैं.
secret
टाइप के पैरामीटर, ऐसे स्ट्रिंग पैरामीटर के बारे में बताते हैं जिनकी वैल्यू Cloud Secret Manager में स्टोर की गई होती है.
सीक्रेट पैरामीटर, सीधे तौर पर वैल्यू पाने के बजाय, Cloud हुआ सीक्रेट मैनेजर में मौजूद होने की जांच करते हैं और रोल आउट के दौरान वैल्यू को लोड करते हैं.
- variable: API_KEY
secret: myApiKeySecret
Cloud Secret Manager के सीक्रेट के कई वर्शन हो सकते हैं. डिफ़ॉल्ट रूप से, आपके लाइव बैकएंड के लिए उपलब्ध सीक्रेट पैरामीटर की वैल्यू, बैकएंड बनाए जाते समय सीक्रेट के सबसे नए वर्शन पर पिन की जाती है. अगर आपको पैरामीटर के वर्शन और लाइफ़साइकल मैनेजमेंट की ज़रूरी शर्तें पूरी करनी हैं, तो Cloud Secret Manager की मदद से किसी खास वर्शन पर पिन किया जा सकता है. उदाहरण के लिए, वर्शन 5 पर पिन करने के लिए:
- variable: PINNED_API_KEY
secret: myApiKeySecret@5
सीएलआई कमांड firebase apphosting:secrets:set
का इस्तेमाल करके, सीक्रेट बनाए जा सकते हैं. इसके बाद, आपको ज़रूरी अनुमतियां जोड़ने के लिए कहा जाएगा. इस फ़्लो की मदद से, apphosting.yaml
में सीक्रेट रेफ़रंस अपने-आप जुड़ जाता है.
Cloud Secret Manager की सुविधाओं के फ़ुल सुइट का इस्तेमाल करने के लिए, Cloud Secret Manager कंसोल का इस्तेमाल किया जा सकता है. ऐसा करने पर, आपको सीएलआई कमांड firebase
apphosting:secrets:grantaccess
का इस्तेमाल करके, अपने ऐप्लिकेशन होस्टिंग बैकएंड को अनुमतियां देनी होंगी.
Firebase पुष्टि की स्थिति सिंक करें
Firebase पुष्टि करने की सुविधा का इस्तेमाल करने वाले ऐप्लिकेशन को Firebase वेब SDK टूल इस्तेमाल करना चाहिए. इससे क्लाइंट और सर्वर के बीच पुष्टि की स्थिति सिंक रखने में मदद मिलेगी. सर्विस वर्कर के साथ FirebaseServerApp
लागू करके, ऐसा किया जा सकता है. इस तरह का बुनियादी
टास्क फ़्लो है:
- सर्विस वर्कर का इस्तेमाल करें, जो सर्वर को भेजे जाने वाले अनुरोधों पर आपके ऐप्लिकेशन के लिए सही हेडर जोड़ता है.
- सर्वर पर मौजूद अनुरोध के हेडर पाएं और उन्हें
FirebaseServerApp
की मदद से, पुष्टि करने वाले उपयोगकर्ता में बदलें.