App Hosting की बिल्ड प्रोसेस

Firebase App Hosting, आपके ऐप्लिकेशन के सोर्स कोड को कंटेनर वाले फ़ॉर्मैट में बदलने के लिए Cloud Build का इस्तेमाल करता है. इससे, Cloud Run पर ऐप्लिकेशन को डिप्लॉय करना आसान हो जाता है.

बिल्ड प्रोसेस इन मुख्य चरणों में पूरी होती है:

  1. ubuntu: Workspace initialization.

  2. preparer: यह आपके ऐप्लिकेशन के सोर्स कोड और कॉन्फ़िगरेशन को इकट्ठा करता है.

  3. pre-buildpack: यह बिल्डपैक एनवायरमेंट तैयार करता है.

  4. build: यह डिपेंडेंसी इंस्टॉल करता है और आपका ऐप्लिकेशन बनाता है.

  5. publisher: प्रोडक्शन Cloud Run कंटेनर को फ़ाइनल करता है.

ये पांच चरण, Google Cloud कंसोल में Cloud Build में दिखाए गए बिल्ड चरणों से सीधे तौर पर जुड़े हैं:

Cloud Build के चरणों को दिखाने वाले Google Cloud Console के व्यू का स्क्रीन कैप्चर

Workspace Initialization

यह स्टेज, Ubuntu के बिल्ड स्टेप से जुड़ी है. यह बिल्ड वर्कस्पेस को शुरू करता है. साथ ही, यह पक्का करता है कि बिल्ड के बाद के चरणों में इस्तेमाल की जाने वाली डायरेक्ट्री के लिए, फ़ाइल की सही अनुमतियां सेट की गई हों.

तैयार करने वाला

यह स्टेज, पहले से बनाए गए लॉजिक को मैनेज करने के लिए ज़िम्मेदार होती है. यह उपयोगकर्ता के हिसाब से तय किए गए एनवायरमेंट वैरिएबल को पढ़ता है, उन्हें सुरक्षित करता है, और लिखता है. यह apphosting.yaml फ़ाइल में बताए गए किसी भी सीक्रेट को डीरेफ़रेंस और पिन भी करता है.

Pre-buildpack

इस चरण में, Cloud Native Buildpacks के लाइफ़साइकल के लिए एनवायरमेंट तैयार किया जाता है. इसमें एक शिम चलाने की प्रोसेस शामिल होती है. यह शिम, पिछले चरण में तैयार किए गए कॉन्फ़िगरेशन और एनवायरमेंट वैरिएबल को CNB टूल के लिए ज़रूरी फ़ॉर्मैट में बदलता है.

बनाएं

यह बिल्ड प्रोसेस का मुख्य हिस्सा है. इसकी मदद से, चलाने लायक कंटेनर इमेज और bundle.yaml फ़ाइल जनरेट की जाती है. इस फ़ाइल में, आपके बिल्ड कॉन्फ़िगरेशन की जानकारी होती है. यह ऐप्लिकेशन को बेहतर तरीके से पैकेज करने के लिए, Cloud Native Buildpacks और लाइफ़साइकल क्रिएटर बाइनरी का इस्तेमाल करता है. bundle.yaml फ़ाइल के बारे में ज़्यादा जानकारी, GitHub पर मिल सकती है.

बिल्डपैक, आपके ऐप्लिकेशन के सोर्स कोड को प्रोडक्शन के लिए तैयार कंटेनर इमेज में बदलने का काम करते हैं. Firebase App Hosting, बिल्ड प्रोसेस को पूरा करने के लिए कई बिल्डपैक को एक साथ जोड़ता है:

  1. रनटाइम बिल्डपैक: यह पक्का करता है कि Node.js के किसी बुनियादी ऐप्लिकेशन को चलाने के लिए, सभी ज़रूरी कॉम्पोनेंट शामिल किए गए हों और डिपेंडेंसी इंस्टॉल की गई हों.
  2. Monorepo Buildpack: यह अलग-अलग monorepo स्थितियों को मैनेज करने के लिए, बाद के buildpack को कॉन्फ़िगर करता है.

  3. फ़्रेमवर्क बिल्डपैक: यह सही फ़्रेमवर्क अडैप्टर (जैसे कि Angular या Next.js) इंस्टॉल करता है और इसके बाद के बिल्डपैक तैयार करता है.

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

  4. Package Manager Buildpack: यह npm, yarn या pnpm का इस्तेमाल करके, डिपेंडेंसी इंस्टॉल करता है और ऐप्लिकेशन बनाता है.

  5. आउटपुट बंडल बिल्डपैक: यह रन कमांड तय करता है और एक्ज़ीक्यूशन के लिए आउटपुट बंडल तैयार करता है.

प्रकाशक

इस आखिरी चरण में, ऐप्लिकेशन के सोर्स कोड से निकाली गई सभी जानकारी को पैकेज किया जाता है. साथ ही, बिल्ड कंटेनर इमेज को भी पैकेज किया जाता है. इसके बाद, इसे App Hostingबैकएंड को भेजा जाता है. इसके बाद, App Hosting बैकएंड इस जानकारी का इस्तेमाल करके, सही कॉन्फ़िगरेशन के साथ Cloud Run सेट अप करता है.

सफ़ाई से जुड़ी नीति बनाना

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

App Hosting, फ़िलहाल चालू ट्रैफ़िक स्प्लिट में मौजूद या रोलआउट की प्रोसेस में शामिल किसी भी बिल्ड को कभी नहीं मिटाएगा या हटाएगा.

जब पुरानी बिल्ड, रखरखाव की इन सीमाओं से ज़्यादा हो जाती हैं, तो उनकी इंटरनल स्थिति को EXPIRED के तौर पर अपडेट कर दिया जाता है. EXPIRED बिल्ड को तुरंत रोल बैक नहीं किया जा सकता. साथ ही, इन बिल्ड पर रोल बैक करने का विकल्प, Firebase कंसोल से हटा दिया जाएगा. इसके बजाय, आपको उसी सोर्स को टारगेट करने वाला नया बिल्ड बनाना होगा. इसके लिए, git कमिट, Artifact Registry में मौजूद कंटेनर या Google Cloud Storage बकेट का इस्तेमाल किया जा सकता है. इसके बाद, आपको उस बिल्ड को रोल आउट करना होगा.

बिल्ड रिसॉर्स को बचाने का एक तरीका यह है कि ऑटोमैटिक रोलआउट को कितनी बार ट्रिगर किया जाए, इसे कंट्रोल किया जाए. अपने-आप रोल आउट होने की सुविधा को मैनेज करना लेख पढ़ें.

ज़्यादा जानें

App Hosting की पूरी बिल्ड प्रोसेस ओपन सोर्स है.