ऐप्लिकेशन होस्टिंग के बारे में जानें और इसके काम करने का तरीका जानें

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

अहम शब्द और उनकी परिभाषाएं

App Hosting फ़्लो की ज़्यादा जानकारी पाने के लिए, कुछ शब्दों की सटीक परिभाषाएं जानना ज़रूरी है. यहां कुछ अहम शब्द और उनकी परिभाषाएं दी गई हैं:

• बैकएंड: मैनेज किए गए संसाधनों का वह कलेक्शन जिसे App Hosting आपके वेब ऐप्लिकेशन को बनाने और चलाने के लिए बनाता है.
• बिल्ड: आपके ऐप्लिकेशन का कोई खास वर्शन, जो आम तौर पर git कमिट से लिंक होता है. बिल्ड बनाने की प्रोसेस में कई सब-प्रोसेस शामिल होती हैं. इनमें से खास हैं, Cloud Build में आपके ऐप्लिकेशन को बिल्ड करना, और Cloud Run में किसी वर्शन को डिप्लॉय करना (शुरुआत में, इसे 0% ट्रैफ़िक मिलता है. इसके बाद, इसे धीरे-धीरे ज़्यादा ट्रैफ़िक मिलता है).
• रोलआउट: किसी बिल्ड को ऐक्टिव तौर पर ट्रैफ़िक दिखाने के लिए सेट करना. git कमिट से अपने-आप ट्रिगर होने पर, App Hosting सबसे पहले आपकी लाइव ब्रांच का इस्तेमाल करके एक बिल्ड बनाता है. इसके बाद, लाइव ट्रैफ़िक को उस बिल्ड पर डायरेक्ट करने के लिए एक रोलआउट बनाता है.
• लाइव ब्रांच: आपकी GitHub रिपॉज़िटरी की वह ब्रांच जिसे आपके लाइव यूआरएल पर डिप्लॉय किया जाता है. अक्सर, यह वह ब्रांच होती है जिसमें फ़ीचर ब्रांच या डेवलपमेंट ब्रांच मर्ज की जाती हैं.

Google Cloud और App Hosting आर्किटेक्चर

App Hosting Google Cloud के कई प्रॉडक्ट को ऑर्केस्ट्रेट करता है, ताकि आपके वेब ऐप्लिकेशन को डिप्लॉय, सर्व, और मॉनिटर किया जा सके. ऐप्लिकेशन, Cloud Build की मदद से बनाए जाते हैं. इन्हें Cloud Run पर सर्व किया जाता है. साथ ही, इन्हें Cloud CDN में कैश किया जाता है. Cloud Secret Manager जैसी इंटिग्रेट की गई सेवाओं की मदद से, आपकी एपीआई कुंजियां सुरक्षित रहती हैं.

1. जब आपकी लाइव ब्रांच पर कोई कमिट पुश किया जाता है, तो Google Cloud Developer Connect एक इवेंट Firebase App Hosting को भेजता है.
2. इस इवेंट के जवाब में, Firebase App Hosting रिपॉज़िटरी से कनेक्ट किए गए बैकएंड के लिए एक नया बिल्ड बनाता है.
   1. सबसे पहले, Firebase App Hosting आपके कमिट के लिए Cloud Build का एक नया बिल्ड बनाता है. इस काम में, Google Cloud buildpacks यह तय करते हैं कि आपके ऐप्लिकेशन में किस फ़्रेमवर्क का इस्तेमाल किया जा रहा है. इसके बाद, वे आपके ऐप्लिकेशन के हिसाब से एक कंटेनर और कॉन्फ़िगरेशन (जिसमें एनवायरमेंट वैरिएबल, सीक्रेट, कम से कम या ज़्यादा से ज़्यादा इंस्टेंस, कॉनकरेंसी मेमोरी, सीपीयू, और वीपीसी कॉन्फ़िगरेशन शामिल हैं) बनाते हैं. ज़्यादा जानकारी के लिए, the App Hosting बिल्ड प्रोसेस देखें.
   2. जब Cloud Build काम पूरा हो जाता है, तो आपका कंटेनर, Firebase App Hosting के लिए बनी Artifact Registry रिपॉज़िटरी में सेव हो जाता है. Firebase App Hosting इसके बाद, आपकी इमेज और कॉन्फ़िगरेशन का इस्तेमाल करके, Cloud Run सेवा में Cloud Run का एक नया वर्शन जोड़ता है.
3. Cloud Run का वर्शन बनने और यह पुष्टि हो जाने के बाद कि वह सही तरीके से काम कर रहा है, Firebase App Hosting अपने ट्रैफ़िक कॉन्फ़िगरेशन में बदलाव करता है, ताकि सभी नए अनुरोधों को Cloud Run के नए वर्शन पर भेजा जा सके. इस समय, रोलआउट पूरा हो जाता है.
4. जब Firebase App Hosting पर होस्ट की गई किसी वेबसाइट पर कोई अनुरोध भेजा जाता है, तो उस अनुरोध को Cloud CDN की सुविधा चालू करके, Google Cloud Load Balancer की मदद से पूरा किया जाता है. कैश नहीं किए गए अनुरोधों को आपकी Cloud Run सेवा पर भेजा जाता है. Cloud CDN की मदद से परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के तरीके के बारे में जानने के लिए, ऐप्लिकेशन के कॉन्टेंट को कैश करना लेख पढ़ें.

फ़्रेमवर्क इंटिग्रेशन

App Hosting इन फ़्रेमवर्क में डेवलप किए गए वेब ऐप्लिकेशन के लिए, पहले से कॉन्फ़िगर किए गए बिल्ड और डिप्लॉय की सुविधा देता है:

• Next.js 13.5.x और इसके बाद के वर्शन
• Angular 18.2.x और इसके बाद के वर्शन

खास वर्शन और सहायता के लेवल के बारे में ज़्यादा जानने के लिए, सहायता के शेड्यूल देखें.

Next.js और Angular के अलावा, App Hosting किसी भी ऐसे वेब फ़्रेमवर्क के साथ काम करता है जो हमारे आउटपुट बंडल की खास जानकारी के मुताबिक, बिल्ड आउटपुट दे सकता है. फ़्रेमवर्क, फ़्रेमवर्क अडैप्टर, और उनसे जुड़े टूल के बारे में ज़्यादा जानने के लिए, फ़्रेमवर्क और टूलिंग App Hosting लेख पढ़ें. App Hosting

रिपॉज़िटरी इंटिग्रेशन App Hosting कैसे काम करता है

आपकी GitHub रिपॉज़िटरी और App Hosting बैकएंड के बीच अहम कनेक्शन को Developer Connect हैंडल करता है. यह Google Cloud का कनेक्टिविटी प्लैटफ़ॉर्म है, जो तीसरे पक्ष के DevOps टूल के साथ काम करता है. जब इस कनेक्शन को सेट अप किया जाता है (आम तौर पर, App Hosting का बैकएंड बनाते समय), Developer Connect के यूज़र इंटरफ़ेस (यूआई) का वर्कफ़्लो, Firebase GitHub ऐप्लिकेशन को इंस्टॉल करने में आपकी मदद करता है. इस प्रोसेस के अहम चरण ये हैं:

1. आपने Developer Connect को Secret Manager के एडमिन की भूमिका दी है. इससे सिस्टम, क्रेडेंशियल को Cloud Secret Manager में "सीक्रेट" के तौर पर सुरक्षित तरीके से सेव कर पाता है.
2. आपने Firebase GitHub ऐप्लिकेशन को अपनी GitHub रिपॉज़िटरी ऐक्सेस करने की अनुमति दी है. सही रिपॉज़िटरी को ऐक्सेस करने के लिए, आपको GitHub की अन्य अनुमतियों की ज़रूरत पड़ सकती है.
3. Developer Connect, आपके प्रोजेक्ट की सीक्रेट मैनेजर रिपॉज़िटरी में, GitHub के लिए खास तौर पर बनाया गया ऑथराइज़ेशन टोकन सेव करता है. इस टोकन में बदलाव न करें या इसे मिटाएं नहीं.

इसके अलावा, App Hosting रोलआउट के लिए जांच की सुविधा देने के लिए, GitHub checks API के साथ इंटिग्रेट होता है. इस जांच की मदद से, GitHub में अपने रोलआउट का स्टेटस देखा जा सकता है. साथ ही, गड़बड़ी होने पर, डिप्लॉयमेंट प्रोसेस को डीबग किया जा सकता है.

Firebase और Google की अन्य सेवाओं के साथ इंटिग्रेशन

App Hosting आपके बिल्ड और रनटाइम एनवायरमेंट, दोनों को सेट अप करता है, ताकि Google Application Default Credentials की मदद से, Firebase Admin SDK को शुरू किया जा सके. इस तरह, आपका बैकएंड, बिल्ड और रन टाइम, दोनों में Firebase के अन्य प्रॉडक्ट के साथ कम्यूनिकेट कर सकता है. अपने ऐप्लिकेशन को शुरू करने और Firebase SDK से जुड़े अन्य विषयों के बारे में ज़्यादा जानने के लिए, अपने वेब ऐप्लिकेशन में Firebase SDK इंटिग्रेट करना लेख पढ़ें.

App Hosting जगहें

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

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

Firebase Firebaseकंसोल या Firebase Firebaseसीएलआई से, App Hosting का बैकएंड बनाते समय, इनमें से कोई भी रीजन चुना जा सकता है:

• us-central1 (आयोवा)
• us-east4 (एन. वर्जीनिया)
• us-east5 (कोलंबस)
• asia-east1 (ताइवान)
• asia-southeast1 (सिंगापुर)
• europe-west4 (नीदरलैंड्स)

App Hosting बैकएंड का सेवा खाता

बिल्ड के दौरान और रनटाइम में, आपका App Hosting बैकएंड, सेवा खाते की मदद से Google की अन्य सेवाओं के साथ पुष्टि करता है. इन कामों के लिए, डिफ़ॉल्ट सेवा खाता तब बनाया जाता है, जब किसी Firebase प्रोजेक्ट में पहली बार App Hosting की सुविधा चालू की जाती है:

firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com

यह सेवा खाता, डिफ़ॉल्ट तौर पर सभी बैकएंड पर लागू होता है. साथ ही, इसमें अनुमतियों का एक छोटा सेट होता है, ताकि आपके ऐप्लिकेशन को बनाया, चलाया, और मॉनिटर किया जा सके. इसके अलावा, इसमें Admin SDK की पुष्टि करने की अनुमति भी होती है. इसके लिए, Application Default Credentials का इस्तेमाल किया जाता है. इससे Cloud Firestore से डेटा लोड करने जैसे ऑपरेशन किए जा सकते हैं.Cloud Firestore Firebase की App Hostingभूमिकाएं देखें.

अगर आपके ऐप्लिकेशन को बिल्ड के दौरान या रनिंग बैकएंड से, Google की अन्य सेवाओं के साथ इंटरैक्ट करने की ज़रूरत है, तो भूमिकाएं जोड़कर, डिफ़ॉल्ट सेवा खाते को पसंद के मुताबिक बनाया जा सकता है. उदाहरण के लिए, अगर आपके ऐप्लिकेशन को Vertex AI के लिए अनुमतियों की ज़रूरत है, तो आपको जोड़ने की ज़रूरत पड़ सकती है roles/aiplatform.user या इससे जुड़ी कोई भूमिका.