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

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 सीएलआई से, App Hosting का बैकएंड बनाते समय, इनमें से कोई भी रीजन चुना जा सकता है:FirebaseFirebase

• 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 से डेटा लोड करने जैसे ऑपरेशन किए जा सकते हैं. Firebase की भूमिकाएं देखें.App Hosting

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