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

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

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

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

इस पेज पर बताए गए आर्किटेक्चर का डायग्राम.

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

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

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

  • Next.js 13+
  • Angular 17.2 और उसके बाद के वर्शन

App Hosting, आपकी रिपॉज़िटरी में मौजूद package-lock.json फ़ाइल या अन्य लॉक फ़ाइल की जांच करके, यह पता लगाता है कि कौनसा फ़्रेमवर्क इस्तेमाल किया जा रहा है. अगर किसी ऐसे Node.js ऐप्लिकेशन को डिप्लॉय करने की कोशिश की जाती है जिसमें लॉक फ़ाइल मौजूद नहीं है, तो App Hosting आपके ऐप्लिकेशन को बिल्ड और चला नहीं पाएगा. अपनी रूट डायरेक्ट्री में npm install चलाकर, package-lock.json बनाया जा सकता है.

फ़्रेमवर्क अडैप्टर

App Hosting फ़्रेमवर्क अडैप्टर की दो मुख्य भूमिकाएं होती हैं:

  1. ये आपके सोर्स कोड और फ़्रेमवर्क से जुड़ी किसी भी कॉन्फ़िगरेशन फ़ाइल (जैसे कि next.config.js) को पार्स करते हैं. साथ ही, एक आउटपुट बंडल जनरेट करते हैं, जिसे ऐप्लिकेशन होस्टिंग के बाकी इन्फ़्रास्ट्रक्चर से प्रोसेस किया जा सकता है.
  2. ये स्टैटिक एसेट जनरेट करने के लिए, आपके ऐप्लिकेशन के बिल्ड कमांड को चलाते हैं. साथ ही, प्रोडक्शन के लिए आपके ऐप्लिकेशन का ऑप्टिमाइज़ किया गया वर्शन बनाते हैं.

फ़्रेमवर्क अडैप्टर, npm run build की मदद से आपके Node.js ऐप्लिकेशन को बनाते हैं. ये हर फ़्रेमवर्क के लिए डिफ़ॉल्ट बिल्ड स्क्रिप्ट के साथ सबसे बेहतर तरीके से काम करते हैं: Next.js के लिए next build और Angular के लिए ng build. App Hosting, कस्टम बिल्ड कमांड की मदद से बिल्ड करने की कोशिश करेगा. हालांकि, इस बात की गारंटी नहीं दी जा सकती कि बिल्ड पूरा हो जाएगा.

Next.js और Angular अडैप्टर का सोर्स, firebase-framework-tools में उपलब्ध है.

अन्य फ़्रेमवर्क

Nextjs और Angular के अलावा, ऐप्लिकेशन होस्टिंग की सुविधा किसी भी ऐसे वेब फ़्रेमवर्क के साथ काम करती है जो हमारे आउटपुट बंडल की स्पेसिफ़िकेशन से मैच करने वाला बिल्ड आउटपुट दे सके. फ़्रेमवर्क बनाने वाले लोग, आउटपुट बंडल स्पेसिफ़िकेशन का फ़ायदा उठाकर यह पक्का कर सकते हैं कि उनके फ़्रेमवर्क के साथ ऐप्लिकेशन होस्टिंग की सुविधा काम करती है.

अगर आपको अन्य फ़्रेमवर्क इस्तेमाल करने हैं, तो कोई अडैप्टर बनाएं या फ़्रेमवर्क के मैनेजर से संपर्क करें. इससे, बिल्ड आउटपुट को ऐप्लिकेशन होस्टिंग फ़ॉर्मैट में बदला जा सकता है. Nextjs और Angular अडैप्टर, अडैप्टर बनाने वाले सभी लोगों के लिए अच्छे रेफ़रंस के उदाहरण हैं.

काम करने वाले फ़्रेमवर्क के बारे में जानने के लिए, Firebase ओपन सोर्स पर जाएं.

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 रिपॉज़िटरी को ऐक्सेस करने की अनुमति दी जाती है.
  3. Developer Connect, आपके प्रोजेक्ट के Secret Manager रिपॉज़िटरी में, GitHub से जुड़ा एक खास अनुमति टोकन सेव करता है. इस टोकन में बदलाव न करें या उसे मिटाएं नहीं.

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

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

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

App Hosting जगहें

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

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

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

  • us-central1 (आयोवा)
  • asia-east1 (ताइवान)
  • europe-west4 (नीदरलैंड्स)

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

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

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

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

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

मुख्य शब्द और परिभाषाएं

  • बैकएंड: मैनेज किए जा रहे संसाधनों का कलेक्शन, जिसे App Hosting आपके वेब ऐप्लिकेशन को बनाने और चलाने के लिए बनाया जाता है.
  • रोल आउट: आपके लाइव ऐप्लिकेशन का कोई खास वर्शन, जो किसी Git कमिट से जुड़ा हो.
  • लाइव ब्रांच: यह आपके GitHub रिपॉज़िटरी की वह ब्रांच होती है जिसे आपके लाइव यूआरएल पर डिप्लॉय किया जाता है. आम तौर पर, यह वह शाखा होती है जिसमें सुविधा वाली शाखाएं या डेवलपमेंट शाखाएं मर्ज की जाती हैं.

पहले से मालूम समस्याएं और सीमाएं

App Hosting की झलक देखने की सुविधा की कुछ सीमाएं हैं:

  • कुछ मामलों में, App Hosting बैकएंड आपके ऐप्लिकेशन के यूआरएल पर Intermittent connection error मैसेज दिखा सकता है. इस समस्या को ठीक करने के लिए, अगले वर्शन में अपडेट उपलब्ध कराया जाएगा.
  • CDN कैश मेमोरी को 60 सेकंड तक सीमित करने के लिए, कैश-कंट्रोल हेडर में बदलाव किए गए हैं. आने वाले समय में, जब App Hosting के पास डिप्लॉय करने पर कैश मेमोरी को तुरंत मिटाने की सुविधा होगी, तब यह सीमा हटा दी जाएगी.
  • इमेज ऑप्टिमाइज़ेशन, डिफ़ॉल्ट रूप से Cloud Run में किया जाता है. साथ ही, ऑप्टिमाइज़ की गई इमेज सेव नहीं की जातीं. हमारा सुझाव है कि बेहतर समाधान उपलब्ध होने तक, इमेज ऑप्टिमाइज़ेशन की सुविधा बंद करें या लोडर को मैन्युअल तरीके से तय करें.
  • प्रतिशत में एन्कोड किए गए वर्णों वाले यूआरएल पाथ को Cloud Run डिकोड करता है. इससे उन सुविधाओं में समस्याएं आ सकती हैं जिनमें सिर्फ़ एन्क्रिप्ट किए गए यूआरएल पाथ की ज़रूरत होती है. जैसे, Next.js पैरलल रूटिंग.
  • कैश मेमोरी में सेव नहीं की गई स्टैटिक फ़ाइलें Cloud Run से भेजी जाती हैं. आने वाले समय में, बेहतर परफ़ॉर्मेंस के लिए, इन्हें App Hosting ऑरिजिन से सेव और भेजा जाएगा.
  • App Hosting ऐसा हो सकता है कि SKU, Firebase कंसोल में बैकएंड के इस्तेमाल वाले पेज पर न दिखें. ये सुविधाएं, आने वाले समय में रिलीज़ होने वाले नए वर्शन में उपलब्ध होंगी.
  • Firebase कंसोल, बैकएंड बनाने पर "बिल्ड नहीं मिला और वह अमान्य है" गड़बड़ी दिखा सकता है.
  • एक ही प्रोजेक्ट के सभी बैकएंड, GitHub का एक ही संगठन/खाता शेयर करते हैं. उन्हें उस संगठन/खाते के तहत मौजूद अलग-अलग रिपॉज़िटरी से कनेक्ट किया जा सकता है. अलग-अलग GitHub खातों से कनेक्ट किए गए बैकएंड बनाने के लिए, उन्हें अलग-अलग प्रोजेक्ट में डालें.
  • Next.js मिडलवेयर, रीराइट, और रीडायरेक्ट, CDN के पीछे Cloud Run में लागू किए जाते हैं. ये कैश मेमोरी में सेव किए गए रिस्पॉन्स को सुरक्षित नहीं रखेंगे. इसलिए, रेंडर किए जा रहे कॉन्टेंट के लिए, ज़रूरी कंट्रोल डायरेक्टिव सेट करना न भूलें.