1. खास जानकारी
कोडलैब के बिना सर्वर वाले माइग्रेशन स्टेशन की सीरीज़ (अपने हिसाब से इस्तेमाल किए जाने वाले ट्यूटोरियल) और मिलते-जुलते वीडियो का मकसद, Google Cloud के बिना सर्वर वाले डेवलपर को अपने ऐप्लिकेशन को आधुनिक बनाने में मदद करना है. ऐसा करने के लिए, उन्हें लेगसी सेवाओं का इस्तेमाल बंद करना होगा. ऐसा करने के लिए, उन्हें एक या एक से ज़्यादा माइग्रेशन में मदद मिलेगी. ऐसा करने से, आपके ऐप्लिकेशन ज़्यादा पोर्टेबल बन जाते हैं. साथ ही, आपको ज़्यादा विकल्प और सुविधाएं भी मिलती हैं. इससे, क्लाउड प्रॉडक्ट की बड़ी रेंज को इंटिग्रेट किया जा सकता है और उन्हें ऐक्सेस किया जा सकता है. साथ ही, नई भाषाओं में रिलीज़ किए जाने वाले ऐप्लिकेशन पर आसानी से अपग्रेड किया जा सकता है. शुरुआत में App Engine (स्टैंडर्ड एनवायरमेंट) वाले डेवलपर पर ध्यान दिया जाता है. हालांकि, यह सीरीज़ इतनी बड़ी है कि इसमें Cloud Functions और Cloud Run जैसे बिना सर्वर वाले प्लैटफ़ॉर्म या लागू होने पर, उन्हें शामिल किया जा सकता है.
इस कोडलैब का मकसद Python 2 App Engine के डेवलपर को यह बताना है कि App Engine Memcache से Cloud Memorystore (Redis के लिए) में कैसे माइग्रेट करें. App Engine ndb
से Cloud NDB पर एक इंप्लिसिट माइग्रेशन भी है, लेकिन इसकी जानकारी मुख्य रूप से मॉड्यूल 2 कोडलैब में दी गई है; इसके बारे में सिलसिलेवार जानकारी पाने के लिए इसे देखें.
आपको इनके बारे में जानकारी मिलेगी
- Cloud Memorystore इंस्टेंस सेट अप करना (Cloud Console या
gcloud
टूल से) - क्लाउड सर्वर के बिना VPC ऐक्सेस करने की सुविधा कनेक्टर सेट अप करना (Cloud Console या
gcloud
टूल से) - App Engine Memcache से Cloud Memorystore में माइग्रेट करें
- सैंपल ऐप्लिकेशन में Cloud Memorystore की मदद से कैश मेमोरी में सेव करने की सुविधा लागू करें
- App Engine
ndb
से Cloud NDB पर माइग्रेट करें
आपको इनकी ज़रूरत होगी
- आपके पास चालू बिलिंग खाते वाला Google Cloud प्रोजेक्ट हो. यह बिना किसी शुल्क के कोडलैब नहीं है
- Python के बुनियादी हुनर
- सामान्य Linux कमांड के बारे में काम करने की जानकारी
- App Engine ऐप्लिकेशन डेवलप करने और डिप्लॉय करने की बुनियादी जानकारी
- चालू मॉड्यूल 12 App Engine ऐप्लिकेशन (मॉड्यूल 12 कोडलैब पूरा करें [सुझाया गया] या रेपो से मॉड्यूल 12 ऐप्लिकेशन को कॉपी करें)
सर्वे
इस ट्यूटोरियल का इस्तेमाल कैसे किया जाएगा?
Python के साथ अपने अनुभव को आप कितनी रेटिंग देंगे?
Google Cloud की सेवाएं इस्तेमाल करने का आपका अनुभव कैसा रहा?
2. बैकग्राउंड
यह कोडलैब, सैंपल ऐप्लिकेशन को App Engine Memcache (और NDB) से Cloud Memorystore (और Cloud NDB) में माइग्रेट करने का तरीका बताता है. इस प्रोसेस में, App Engine की बंडल की गई सेवाओं पर डिपेंडेंसी बदलना शामिल है. इससे, आपके ऐप्लिकेशन ज़्यादा पोर्टेबल बन जाते हैं. आप App Engine का इस्तेमाल जारी रखने या ऊपर बताए गए किसी भी विकल्प का इस्तेमाल करने का विकल्प चुन सकते हैं.
इस सीरीज़ में मौजूद दूसरे प्लैटफ़ॉर्म की तुलना में, डेटा को दूसरी जगह भेजने में ज़्यादा मेहनत करनी पड़ती है. App Engine Memcache के बजाय Cloud Memorystore इस्तेमाल करने का सुझाव दिया जाता है, जो पूरी तरह से मैनेज की जाने वाली क्लाउड-आधारित कैश मेमोरी सेवा है. Memorystore में लोकप्रिय ओपन सोर्स कैशिंग इंजन, Redis और Memcached का जोड़ा जा सकता है. माइग्रेशन के लिए यह मॉड्यूल Cloud Memorystore for Redis का इस्तेमाल करता है. आप Memorystore और Redis की खास जानकारी में ज़्यादा जानकारी पा सकते हैं.
Memorystore के लिए एक चालू सर्वर की ज़रूरत होती है, इसलिए Cloud VPC की भी ज़रूरत होती है. खास तौर पर, सर्वर के बिना VPC ऐक्सेस करने की सुविधा वाला कनेक्टर बनाना ज़रूरी है, ताकि App Engine ऐप्लिकेशन अपने निजी आईपी पते के ज़रिए, Memorystore इंस्टेंस से कनेक्ट कर सके. इस एक्सरसाइज़ को पूरा करने के बाद, आपने ऐप्लिकेशन को अपडेट कर दिया होगा, ताकि जबकि वह पहले की तरह काम करे, लेकिन App Engine की Memcache सेवा की जगह Cloud Memorystore कैश मेमोरी में सेव करने वाली सेवा बन जाएगी.
यह ट्यूटोरियल Python 2 में मॉड्यूल 12 सैंपल ऐप्लिकेशन से शुरू होता है. इसके बाद, Python 3 में एक अतिरिक्त, वैकल्पिक, मामूली अपग्रेड किया जाता है. अगर आपने पहले से ही Python 3 App Engine SDK टूल के ज़रिए, Python 3 की बंडल की गई सेवाओं में App Engine को ऐक्सेस करने के बारे में जाना है, तो आप मॉड्यूल 12 सैंपल ऐप्लिकेशन के Python 3 वर्शन का इस्तेमाल कर सकते हैं. ऐसा करने पर SDK टूल का इस्तेमाल हटा दिया जाएगा, क्योंकि Memorystore, App Engine की बंडल की गई सेवा नहीं है. इस ट्यूटोरियल में, Python 3 App Engine SDK टूल को इस्तेमाल करने का तरीका नहीं बताया गया है.
इस ट्यूटोरियल में ये मुख्य चरण बताए गए हैं:
- सेटअप/प्रीवर्क
- कैश मेमोरी में सेव करने की सेवाएं सेट अप करें
- कॉन्फ़िगरेशन फ़ाइलें अपडेट करना
- मुख्य ऐप्लिकेशन अपडेट करें
3. सेटअप/प्रीवर्क
Cloud प्रोजेक्ट तैयार करें
हमारा सुझाव है कि उसी प्रोजेक्ट को दोबारा इस्तेमाल करें जिसका इस्तेमाल आपने मॉड्यूल 12 कोडलैब को पूरा करने के लिए किया था. इसके अलावा, नया प्रोजेक्ट बनाया जा सकता है या किसी मौजूदा प्रोजेक्ट का फिर से इस्तेमाल किया जा सकता है. इस सीरीज़ के हर कोडलैब का एक "शुरू करें" होता है (इससे शुरू होने वाला बेसलाइन कोड) और "FINISH" (माइग्रेट किया गया ऐप्लिकेशन). FINISH कोड इसलिए दिया जाता है, ताकि किसी समस्या आने पर आप हमारे समाधान से तुलना कर सकें. अगर कुछ गलत हो जाता है, तो आप किसी भी समय START पर रोल बैक कर सकते हैं. इन चेकपॉइंट को यह पक्का करने के लिए डिज़ाइन किया गया है कि आपको माइग्रेशन करने का तरीका सीखने में सफलता मिले.
आप चाहे किसी भी Cloud प्रोजेक्ट का इस्तेमाल करें, पक्का करें कि उसके पास एक चालू बिलिंग खाता हो. यह भी पक्का करें कि App Engine चालू है. इन ट्यूटोरियल को देखें और पक्का करें कि आपको इन ट्यूटोरियल को बनाने से जुड़े सामान्य खर्च के बारे में पता है. हालांकि, इस सीरीज़ में मौजूद अन्य प्लैटफ़ॉर्म के उलट, यह कोडलैब उन क्लाउड के संसाधनों का इस्तेमाल करता है जिनमें फ़्री टियर नहीं होता. इसलिए, इस काम को पूरा करने में कुछ खर्च करना होगा. कम इस्तेमाल के सुझावों के साथ ही लागत की और सटीक जानकारी दी जाएगी. इसमें बिलिंग शुल्क को कम करने के लिए संसाधनों को रिलीज़ करने के बारे में निर्देश भी दिए जाएंगे.
बेसलाइन ऐप्लिकेशन का नमूना डाउनलोड करें
हम जिस बेसलाइन मॉड्यूल 12 कोड से शुरुआत कर रहे हैं, उससे यह कोडलैब आपको माइग्रेशन के चरणों की सिलसिलेवार जानकारी देता है. यह प्रोसेस पूरी होने के बाद, आपको FINISH फ़ोल्डर में मौजूद कोड से मिलता-जुलता मॉड्यूल 13 ऐप्लिकेशन दिखेगा. इन संसाधनों की जानकारी यहां दी गई है:
- START: मॉड्यूल 12 Python 2 (
mod12
) या Python 3 (mod12b
) ऐप्लिकेशन - FINISH: Module 13 Python 2 (
mod13a
) या Python 3 (mod13b
) ऐप्लिकेशन - माइग्रेशन का पूरा डेटा (क्लोन या ZIP डाउनलोड करें)
START फ़ोल्डर में ये फ़ाइलें होनी चाहिए:
$ ls README.md app.yaml main.py requirements.txt templates
अगर Python 2 वर्शन से शुरुआत की जा रही है, तो मॉड्यूल 12 कोडलैब पूरा करने पर आपको appengine_config.py
फ़ाइल और lib
फ़ोल्डर भी मिलेगा.
मॉड्यूल 12 ऐप्लिकेशन को दोबारा डिप्लॉय करें
प्रीवर्क के बाकी चरण:
gcloud
कमांड-लाइन टूल का इस्तेमाल करके, फिर से जानें (अगर ज़रूरी हो)- App Engine पर मॉड्यूल 12 कोड को फिर से डिप्लॉय करें (अगर ज़रूरी हो)
Python 2 के उपयोगकर्ताओं को lib
फ़ोल्डर को मिटाकर, इन निर्देशों का इस्तेमाल करके फिर से इंस्टॉल करना चाहिए:
rm -rf ./lib; pip install -t lib -r requirements.txt
अब सभी (Python 2 और 3 उपयोगकर्ताओं) को इस निर्देश के साथ App Engine पर कोड अपलोड करना चाहिए:
gcloud app deploy
डिप्लॉय होने के बाद, पुष्टि करें कि ऐप्लिकेशन, मॉड्यूल 12 की तरह ही दिखता और काम करता है. यह एक ऐसा वेब ऐप्लिकेशन है जो विज़िट को ट्रैक करता है और एक ही उपयोगकर्ता के लिए उन्हें एक घंटे के लिए कैश मेमोरी में सेव करता है:
सबसे हाल की विज़िट को कैश मेमोरी में सेव किया जाता है. इसलिए, पेज रीफ़्रेश जल्दी लोड होते हैं.
4. कैश मेमोरी में सेव करने की सेवाएं सेट अप करें
Cloud Memorystore सर्वरलेस नहीं है. इंस्टेंस ज़रूरी है; इस मामले में एक Redis चल रहा है. Memcache के उलट, Memorystore एक स्टैंडअलोन क्लाउड प्रॉडक्ट है और इसमें फ़्री टियर नहीं है. इसलिए, आगे बढ़ने से पहले Redis के लिए Memorystore की कीमत की जानकारी देखना न भूलें. हमारा सुझाव है कि इस काम की लागत को कम करने के लिए, कम से कम संसाधनों का इस्तेमाल करें: बेसिक सर्विस टियर और 1 जीबी की क्षमता.
Memorystore इंस्टेंस, आपके App Engine ऐप्लिकेशन (इंस्टेंस) से अलग नेटवर्क पर है. इसलिए, बिना सर्वर वाले VPC ऐक्सेस कनेक्टर वाला एक नेटवर्क बनाना ज़रूरी है, ताकि App Engine आपके Memorystore के संसाधनों को ऐक्सेस कर सके. VPC की लागत कम करने के लिए, इंस्टेंस टाइप (f1-micro
) और कम से कम इंस्टेंस का अनुरोध करने के लिए ऑप्ट इन करें. हमारा सुझाव है कि आप कम से कम दो और ज़्यादा से ज़्यादा तीन का इस्तेमाल करें. VPC की कीमत की जानकारी वाला पेज भी देखें.
हम इन सुझावों को, लागत कम करने के लिए दोहराते हैं. ऐसा इसलिए, क्योंकि हम हर ज़रूरी संसाधन को तैयार करने में आपकी मदद करते हैं. इसके अलावा, जब Cloud Console में Memorystore और VPC के संसाधन बनाए जाते हैं, तब आपको ऊपर दाएं कोने में हर प्रॉडक्ट का प्राइसिंग कैलकुलेटर दिखेगा. इससे आपको हर महीने की अनुमानित लागत की जानकारी मिलती है (नीचे दी गई इमेज देखें). अगर आपने विकल्प बदलते हैं, तो ये वैल्यू अपने-आप अडजस्ट हो जाती हैं. आम तौर पर, आपको यह जानकारी दिखेगी:
दोनों संसाधन ज़रूरी हैं. इससे कोई फ़र्क़ नहीं पड़ता कि आपने पहले कौनसा संसाधन बनाया है. अगर पहले Memorystore इंस्टेंस बनाया जाता है, तो VPC कनेक्टर के बिना, आपका App Engine ऐप्लिकेशन उस तक नहीं पहुंच सकता. इसी तरह, अगर आपने पहले VPC कनेक्टर बनाया है, तो आपके App Engine ऐप्लिकेशन से बात करने के लिए, उस VPC नेटवर्क में कुछ भी नहीं होगा. इस ट्यूटोरियल में Memorystore इंस्टेंस बनाने का काम किया गया है. इसके बाद, पहले VPC कनेक्टर किया गया है.
दोनों संसाधनों के ऑनलाइन होने पर, आपको app.yaml
में काम की जानकारी जोड़नी होगी, ताकि आपका ऐप्लिकेशन कैश मेमोरी को ऐक्सेस कर सके. आधिकारिक दस्तावेज़ में, Python 2 या Python 3 गाइड का भी रेफ़रंस दिया जा सकता है. Cloud NDB माइग्रेशन पेज ( Python 2 या Python 3) पर मौजूद डेटा कैश मेमोरी में सेव करने वाली गाइड का इस्तेमाल करना भी फ़ायदेमंद है.
Cloud Memorystore इंस्टेंस बनाएं
Cloud Memorystore में कोई फ़्री टियर नहीं है. इसलिए, हमारा सुझाव है कि कोडलैब को पूरा करने के लिए, कम से कम संसाधन उपलब्ध कराएं. इन सेटिंग का इस्तेमाल करके, लागतों को कम से कम रखा जा सकता है:
- सबसे कम सेवा स्तर चुनें: बेसिक (कंसोल डिफ़ॉल्ट: "स्टैंडर्ड",
gcloud
डिफ़ॉल्ट: "बेसिक"). - स्टोरेज के लिए कम से कम स्टोरेज चुनें: 1 जीबी (कंसोल डिफ़ॉल्ट: 16 जीबी,
gcloud
डिफ़ॉल्ट: 1 जीबी). - आम तौर पर, किसी भी सॉफ़्टवेयर के सबसे नए वर्शन के लिए बहुत ज़्यादा संसाधनों की ज़रूरत होती है, लेकिन शायद सबसे पुराने वर्शन को चुनने का सुझाव भी नहीं दिया जाता. फ़िलहाल, दूसरा नया वर्शन Redis वर्शन 5.0 है (कंसोल डिफ़ॉल्ट: 6.x)
इन सेटिंग को ध्यान में रखते हुए, अगले सेक्शन में आपको Cloud Console से इंस्टेंस बनाने का तरीका बताया जाएगा. अगर आपको इसे कमांड-लाइन से करना है, तो आगे बढ़ें.
Cloud Console से
Cloud Console में Cloud Memorystore पेज पर जाएं. आपको बिलिंग की जानकारी देने के लिए कहा जा सकता है. अगर आपने अभी तक Memorystore को चालू नहीं किया है, तो आपको ऐसा करने के लिए कहा जाएगा:
इसे चालू करने के बाद (और बिलिंग के साथ), आप Memorystore डैशबोर्ड पर पहुंच जाएंगे. यहां आपको अपने प्रोजेक्ट में बनाए गए सभी इंस्टेंस दिखेंगे. नीचे दिखाए गए प्रोजेक्ट में कोई भी प्रोजेक्ट मौजूद नहीं है. इसलिए, आपको "डिसप्ले के लिए कोई लाइन नहीं है" दिखता है. Memorystore इंस्टेंस बनाने के लिए, सबसे ऊपर इंस्टेंस बनाएं पर क्लिक करें:
इस पेज में एक फ़ॉर्म दिया गया है, जिसे Memorystore इंस्टेंस बनाने के लिए, आपकी मनचाही सेटिंग को पूरा करना होगा:
इस ट्यूटोरियल और इसके सैंपल ऐप्लिकेशन की कीमत कम रखने के लिए, ऊपर दिए गए सुझावों को अपनाएं. अपनी पसंद का विकल्प चुनने के बाद, बनाएं पर क्लिक करें. इसे बनाने में कुछ मिनट लगते हैं. इसके पूरा हो जाने पर, app.yaml
में जोड़ने के लिए इंस्टेंस का आईपी पता और पोर्ट नंबर को कॉपी करें.
कमांड-लाइन से
Cloud Console से Memorystore इंस्टेंस बनाने से, विज़ुअल तौर पर जानकारी मिलती है, लेकिन कुछ लोग कमांड-लाइन का इस्तेमाल करना पसंद करते हैं. आगे बढ़ने से पहले, यह पक्का कर लें कि आपने gcloud
को इंस्टॉल कर लिया हो और शुरू हो चुका हो.
Cloud Console की तरह ही, Redis के लिए Cloud Memorystore चालू होना ज़रूरी है. gcloud services enable redis.googleapis.com
निर्देश दें और इसके पूरा होने का इंतज़ार करें, जैसे कि:
$ gcloud services enable redis.googleapis.com Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.
अगर सेवा पहले से ही चालू है, तो (फिर से) निर्देश चलाने का कोई (नेगेटिव) खराब असर नहीं पड़ेगा. सेवा चालू होने पर, Memorystore इंस्टेंस बनाएं. वह निर्देश इस तरह से दिखेगा:
gcloud redis instances create NAME --redis-version VERSION \ --region REGION --project PROJECT_ID
अपने Memorystore इंस्टेंस के लिए कोई नाम चुनें; यह लैब "demo-ms
" का इस्तेमाल करती है "my-project
" के प्रोजेक्ट आईडी के साथ नाम डालें. सैंपल के तौर पर दिए गए इस ऐप्लिकेशन का क्षेत्र us-central1
है (us-central
के बराबर), लेकिन अगर इंतज़ार का समय कोई परेशानी है, तो अपने नज़दीकी ऐप का इस्तेमाल किया जा सकता है. आपको वही क्षेत्र चुनना होगा जो आपका App Engine ऐप्लिकेशन में है. आप अपनी पसंद के किसी भी Redis वर्शन को चुन सकते हैं, लेकिन हम पहले सुझाए गए वर्शन 5 का इस्तेमाल कर रहे हैं. इन सेटिंग को देखते हुए, आपको यह निर्देश देना होगा (असोसिएट किए गए आउटपुट के साथ):
$ gcloud redis instances create demo-ms --region us-central1 \ --redis-version redis_5_0 --project my-project Create request issued for: [demo-ms] Waiting for operation [projects/my-project/locations/us-central1/operations/operation-xxxx] to complete...done. Created instance [demo-ms].
Cloud Console की डिफ़ॉल्ट सेटिंग से अलग, gcloud
कम से कम संसाधनों को डिफ़ॉल्ट रूप से सेट करता है. इसका नतीजा यह हुआ कि उस कमांड में न तो सर्विस टियर की ज़रूरत पड़ी और न ही स्टोरेज में. Memorystore इंस्टेंस बनाने में कुछ मिनट लगते हैं. इसके बाद, इंस्टेंस के आईपी पते और पोर्ट नंबर पर ध्यान दें, क्योंकि उन्हें जल्द ही app.yaml
में जोड़ दिया जाएगा.
इंस्टेंस बनाने की पुष्टि करें
Cloud Console या कमांड-लाइन से
आपने अपना इंस्टेंस चाहे Cloud Console से बनाया हो या कमांड-लाइन से, आप इस बात की पुष्टि कर सकते हैं कि वह उपलब्ध है और इस निर्देश की मदद से इस्तेमाल के लिए तैयार है: gcloud redis instances list --region REGION
यहां us-central1
क्षेत्र में इंस्टेंस की जांच करने के लिए निर्देश दिया गया है. साथ ही, अनुमानित आउटपुट के साथ वह इंस्टेंस दिखाया गया है जो हमने अभी-अभी बनाया है:
$ gcloud redis instances list --region us-central1 INSTANCE_NAME VERSION REGION TIER SIZE_GB HOST PORT NETWORK RESERVED_IP STATUS CREATE_TIME demo-ms REDIS_5_0 us-central1 BASIC 1 10.aa.bb.cc 6379 default 10.aa.bb.dd/29 READY 2022-01-28T09:24:45
जब आपसे इंस्टेंस की जानकारी मांगी जाए या अपने ऐप्लिकेशन को कॉन्फ़िगर करने के लिए कहा जाए, तब HOST
और PORT
का इस्तेमाल करें (न कि RESERVED_IP
). अब Cloud Console में मौजूद Cloud Memorystore डैशबोर्ड में यह इंस्टेंस दिखना चाहिए:
Compute Engine वर्चुअल मशीन से
अगर आपके पास Compute Engine वर्चुअल मशीन (वीएम) है, तो Memorystore इंस्टेंस को वीएम से डायरेक्ट कमांड भेजें, ताकि यह पुष्टि की जा सके कि यह काम कर रहा है. ध्यान रखें, वर्चुअल मशीन (वीएम) के इस्तेमाल की लागत आपके मौजूदा संसाधनों से अलग हो सकती है.
सर्वर के बिना VPC ऐक्सेस करने की सुविधा वाला कनेक्टर बनाएं
Cloud Memorystore की तरह, Cloud Console में या कमांड-लाइन पर बिना सर्वर वाला क्लाउड VPC कनेक्टर बनाया जा सकता है. इसी तरह, Cloud VPC में कोई फ़्री टियर नहीं है. इसलिए, हमारा सुझाव है कि कोडलैब को पूरा करने के लिए, कम से कम संसाधन उपलब्ध कराएं. इससे, कोडलैब की लागत को कम से कम रखा जा सकेगा. ऐसा इन सेटिंग की मदद से किया जा सकता है:
- इंस्टेंस की सबसे कम संख्या चुनें: 3 (कंसोल और
gcloud
डिफ़ॉल्ट: 10) - सबसे कम कीमत वाली मशीन टाइप चुनें:
f1-micro
(कंसोल डिफ़ॉल्ट:e2-micro
, कोईgcloud
डिफ़ॉल्ट नहीं)
अगले सेक्शन में, आपको ऊपर दी गई Cloud VPC सेटिंग का इस्तेमाल करके, Cloud Console से कनेक्टर बनाने का तरीका पता चलेगा. अगर आपको इसे कमांड लाइन से करना है, तो सीधे अगले सेक्शन पर जाएं.
Cloud Console से
क्लाउड नेटवर्किंग "सर्वर के बिना VPC ऐक्सेस करने की सुविधा" पर जाएं पेज पर जाएं (आपको बिलिंग जानकारी देने के लिए कहा जा सकता है). अगर आपने अब तक इस एपीआई को चालू नहीं किया है, तो आपको ऐसा करने के लिए कहा जाएगा:
एपीआई (और बिलिंग के साथ) को चालू करने के बाद, आपको एक डैशबोर्ड दिखेगा. इसमें बनाए गए सभी VPC कनेक्टर दिखेंगे. नीचे दिए गए स्क्रीनशॉट में इस्तेमाल किए गए प्रोजेक्ट में, कोई प्रोजेक्ट मौजूद नहीं है. इसलिए, इसमें "दिखाने के लिए कोई लाइन नहीं है" लिखा है. अपने कंसोल में, सबसे ऊपर कनेक्टर बनाएं पर क्लिक करें:
अपनी ज़रूरत के हिसाब से सेटिंग चुनकर फ़ॉर्म भरें:
अपने ऐप्लिकेशन के लिए सही सेटिंग चुनें. कम से कम ज़रूरतों वाले इस ट्यूटोरियल और इसके सैंपल ऐप्लिकेशन के लिए, खर्च को कम करना सही रहता है. इसलिए, पहले दिए गए सुझावों को अपनाएं. अपनी पसंद का विकल्प चुनने के बाद, बनाएं पर क्लिक करें. VPC कनेक्टर की अनुरोध प्रक्रिया को पूरा होने में कुछ मिनट लगेंगे.
कमांड-लाइन से
VPC कनेक्टर बनाने से पहले, बिना सर्वर वाले VPC Access API को चालू करें. यह निर्देश जारी करने के बाद, आपको मिलता-जुलता आउटपुट दिखेगा:
$ gcloud services enable vpcaccess.googleapis.com Operation "operations/acf.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.
एपीआई चालू होने पर, एक निर्देश के साथ एक VPC कनेक्टर बन जाता है, जो कुछ ऐसा दिखता है:
gcloud compute networks vpc-access connectors create CONNECTOR_NAME \ --range 10.8.0.0/28 --region REGION --project PROJECT_ID
अपने कनेक्टर के लिए कोई नाम चुनें. साथ ही, शुरुआती आईपी पते के लिए, इस्तेमाल न किया गया /28
सीआईडीआर ब्लॉक चुनें. इस ट्यूटोरियल में ये अनुमान लगाए गए हैं:
- प्रोजेक्ट आईडी:
my-project
- VPC कनेक्टर का नाम:
demo-vpc
- कम से कम इंस्टेंस: 2 (डिफ़ॉल्ट) और ज़्यादा से ज़्यादा इंस्टेंस: 3
- इंस्टेंस टाइप:
f1-micro
- क्षेत्र:
us-central1
- IPv4 सीआईडीआर ब्लॉक:
10.8.0.0/28
(जैसा कि क्लाउड कंसोल में सुझाया गया है)
अगर ऊपर दिए गए अनुमान को ध्यान में रखते हुए, नीचे दिए गए निर्देश को एक्ज़ीक्यूट किया जाता है, तो आपको यहां दिख रहे आउटपुट से मिलते-जुलते नतीजे मिल सकते हैं:
$ gcloud compute networks vpc-access connectors create demo-vpc \ --max-instances 3 --range 10.8.0.0/28 --machine-type f1-micro \ --region us-central1 --project my-project Create request issued for: [demo-vpc] Waiting for operation [projects/my-project/locations/us-central1/operations/xxx] to complete...done. Created connector [demo-vpc].
ऊपर दिए गए निर्देश डिफ़ॉल्ट वैल्यू तय नहीं करते हैं, जैसे कि 2 के कम से कम इंस्टेंस और default
नाम का नेटवर्क. VPC कनेक्टर बनाने में कुछ मिनट लगते हैं.
कनेक्टर बनाए जाने की पुष्टि करें
प्रोसेस पूरी होने के बाद, यह मान लेते हुए कि यह क्षेत्र us-central1
है, यहां दिए गए gcloud
निर्देश को जारी करें, ताकि यह पुष्टि की जा सके कि इसे बना लिया गया है और इसका इस्तेमाल किया जा सकता है:
$ gcloud compute networks vpc-access connectors list --region us-central1 CONNECTOR_ID REGION NETWORK IP_CIDR_RANGE SUBNET SUBNET_PROJECT MIN_THROUGHPUT MAX_THROUGHPUT STATE demo-vpc us-central1 default 10.8.0.0/28 200 300 READY
इसी तरह, डैशबोर्ड में अब वह कनेक्टर दिखना चाहिए जो आपने अभी बनाया है:
Cloud प्रोजेक्ट आईडी, VPC कनेक्टर का नाम, और क्षेत्र को नोट करें.
अब आपने ज़रूरी क्लाउड संसाधन बना लिए हैं, चाहे वे कमांड-लाइन से हों या कंसोल में, अब ऐप्लिकेशन के कॉन्फ़िगरेशन को अपडेट करने का समय है, ताकि उन्हें इनका इस्तेमाल करने में मदद मिल सके.
5. कॉन्फ़िगरेशन फ़ाइलें अपडेट करना
सबसे पहले, कॉन्फ़िगरेशन फ़ाइलों में सभी ज़रूरी अपडेट किए जाते हैं. इस कोडलैब का मुख्य मकसद, Python 2 के उपयोगकर्ताओं को माइग्रेट करने में मदद करना है. हालांकि, आम तौर पर नीचे दिए गए हर सेक्शन में, कॉन्टेंट को Python 3 में पोर्ट करने से जुड़ी जानकारी दी जाती है.
requirements.txt
इस सेक्शन में हम Cloud Memorystore के साथ-साथ Cloud NDB के साथ काम करने के लिए पैकेज जोड़ रहे हैं. Redis के लिए Cloud Memorystore के लिए, Python (redis
) के लिए स्टैंडर्ड Redis क्लाइंट का इस्तेमाल करना ही काफ़ी होगा. इसकी वजह यह है कि हर सर्वर के लिए Cloud Memorystore क्लाइंट लाइब्रेरी उपलब्ध नहीं है. मॉड्यूल 12 से flask
को जोड़ते हुए, redis
और google-cloud-ndb
, दोनों को requirements.txt
में जोड़ें:
flask
redis
google-cloud-ndb
इस requirements.txt
फ़ाइल में कोई वर्शन नंबर मौजूद नहीं है. इसका मतलब है कि नए वर्शन चुने गए हैं. अगर कोई गड़बड़ी आती है, तो काम करने वाले वर्शन में लॉक करने के लिए, वर्शन नंबर डालें.
app.yaml
जोड़ने के लिए नए सेक्शन
Cloud NDB जैसे क्लाउड एपीआई, जैसे कि grpcio
और setuptools
का इस्तेमाल करते समय, Python 2 App Engine रनटाइम को तीसरे पक्ष के खास पैकेज की ज़रूरत होती है. Python 2 के उपयोगकर्ताओं को, app.yaml
में उपलब्ध वर्शन के साथ-साथ, इन जैसी पहले से मौजूद लाइब्रेरी की सूची बनानी होगी. अगर आपके पास अब तक कोई libraries
सेक्शन नहीं है, तो एक सेक्शन बनाएं और यहां दी गई दोनों लाइब्रेरी की तरह दोनों लाइब्रेरी जोड़ें:
libraries:
- name: grpcio
version: latest
- name: setuptools
version: latest
अपने ऐप्लिकेशन को माइग्रेट करते समय, हो सकता है कि उसमें पहले से एक libraries
सेक्शन मौजूद हो. अगर ऐसा होता है और grpcio
और setuptools
मौजूद नहीं हैं, तो उन्हें अपने मौजूदा libraries
सेक्शन में जोड़ें.
इसके बाद, हमारे सैंपल ऐप्लिकेशन को Cloud Memorystore इंस्टेंस और VPC कनेक्टर की जानकारी की ज़रूरत होगी. इसलिए, app.yaml
में ये दो नए सेक्शन जोड़ें, भले ही आप किसी भी Python रनटाइम का इस्तेमाल कर रहे हों:
env_variables:
REDIS_HOST: 'YOUR_REDIS_HOST'
REDIS_PORT: 'YOUR_REDIS_PORT'
vpc_access_connector:
name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR
जहां तक ज़रूरी अपडेट लागू होते हैं, बस इतना ही. आपका अपडेट किया गया app.yaml
अब ऐसा दिखना चाहिए:
runtime: python27
threadsafe: yes
api_version: 1
handlers:
- url: /.*
script: main.app
libraries:
- name: grpcio
version: 1.0.0
- name: setuptools
version: 36.6.0
env_variables:
REDIS_HOST: 'YOUR_REDIS_HOST'
REDIS_PORT: 'YOUR_REDIS_PORT'
vpc_access_connector:
name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR
नीचे "पहले और बाद में" दिया गया है उन अपडेट के बारे में जानकारी जिन्हें आपको app.yaml
पर लागू करना है:
*Python 3 के अंतर
यह सेक्शन ज़रूरी नहीं है. ऐसा सिर्फ़ तब होता है, जब Python 3 में पोर्ट किया जा रहा हो. ऐसा करने के लिए, आपको अपने Python 2 कॉन्फ़िगरेशन में कई बदलाव करने होंगे. अगर आप अभी अपग्रेड नहीं कर रहे हैं, तो इस सेक्शन को छोड़ दें.
Python 3 रनटाइम के लिए, न तो threadsafe
का इस्तेमाल किया जाता है और न ही api_version
का. इसलिए, इन दोनों सेटिंग को मिटाएं. App Engine के नए रनटाइम में, पहले से मौजूद तीसरे पक्ष की लाइब्रेरी और पहले से मौजूद नहीं की गई लाइब्रेरी को कॉपी करने की सुविधा काम नहीं करती. तीसरे पक्ष के पैकेज को सिर्फ़ requirements.txt
में लिस्ट करना ज़रूरी है. इस वजह से, app.yaml
का पूरा libraries
सेक्शन मिटाया जा सकता है.
इसके बाद, Python 3 रनटाइम को ऐसे वेब फ़्रेमवर्क का इस्तेमाल करने की ज़रूरत होती है जो अपनी खुद की रूटिंग करते हैं. इसलिए, हमने डेवलपर को मॉड्यूल 1 में webp2 से फ़्लास्क में माइग्रेट करने का तरीका दिखाया. इस वजह से, सभी स्क्रिप्ट हैंडलर को auto
में बदलना ज़रूरी है. यह ऐप्लिकेशन किसी भी स्टैटिक फ़ाइल को उपलब्ध नहीं कराता है. इसलिए, यह "बेमतलब" है हैंडलर की सूची बनानी होगी (क्योंकि वे सभी auto
हैं), इसलिए पूरे handlers
सेक्शन को भी हटाया जा सकता है. इसलिए, Python 3 के लिए बदले गए आपके नए, छोटे किए गए app.yaml
को इस तरह छोटा किया जाना चाहिए:
runtime: python39
env_variables:
REDIS_HOST: 'YOUR_REDIS_HOST'
REDIS_PORT: 'YOUR_REDIS_PORT'
vpc_access_connector:
name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR
Python 3 में पोर्ट करते समय, app.yaml
के अंतरों के बारे में खास जानकारी:
threadsafe
औरapi_version
सेटिंग मिटाएंlibraries
सेक्शन मिटाएंhandlers
सेक्शन मिटाएं (या अगर आपका ऐप्लिकेशन स्टैटिक फ़ाइलें दिखाता है, तो सिर्फ़script
हैंडलर) मिटाएं
वैल्यू बदलें
Memorystore और VPC कनेक्टर के नए सेक्शन में मौजूद वैल्यू, सिर्फ़ प्लेसहोल्डर हैं. कैपिटल लेटर वाली उन वैल्यू (YOUR_REDIS_HOST, YOUR_REDIS_PORT, PROJECT_ID, REGION, CONNECTOR_NAME
) को उन वैल्यू से बदलें जो आपने पहले उन वैल्यू को बनाते समय सेव की थीं. अपने Memorystore इंस्टेंस के लिए, पक्का करें कि आपने HOST
(RESERVED_IP
नहीं) और PORT
का इस्तेमाल किया हो. यह मानते हुए कि demo-ms
का इंस्टेंस नाम और REGION
है, us-central1
को पाने के लिए यहां HOST
और PORT
पाने का क्विक कमांड-लाइन तरीका दिया गया है:
$ gcloud redis instances describe demo-ms --region us-central1 \ --format "value(host,port)" 10.251.161.51 6379
अगर हमारे उदाहरण Redis इंस्टेंस का आईपी पता 10.10.10.10
था, जो हमारे प्रोजेक्ट my-project
में मौजूद है, जो demo-vpc
के VPC कनेक्टर के नाम के साथ us-central1
में मौजूद प्रोजेक्ट में 6379
पोर्ट का इस्तेमाल करता है, तो app.yaml
में ये सेक्शन इस तरह दिखेंगे:
env_variables:
REDIS_HOST: '10.10.10.10'
REDIS_PORT: '6379'
vpc_access_connector:
name: projects/my-project/locations/us-central1/connectors/demo-vpc
appengine_config.py बनाएं या अपडेट करें
पहले से मौजूद तीसरे पक्ष की लाइब्रेरी के लिए सहायता जोड़ना
हमने app.yaml
के साथ जो किया था, ठीक उसी तरह इसमें grpcio
और setuptools
लाइब्रेरी के इस्तेमाल को भी जोड़ा गया. पहले से मौजूद तीसरे पक्ष की लाइब्रेरी के साथ काम करने के लिए, appengine_config.py
में बदलाव करें. ऐसा इसलिए है, क्योंकि App Engine ndb
से Cloud NDB में माइग्रेट करते समय, मॉड्यूल 2 में भी इसकी ज़रूरत थी. ठीक वही बदलाव करना है जो lib
फ़ोल्डर को setuptools.pkg_resources
के काम करने वाले सेट में जोड़ना है:
*Python 3 के अंतर
यह सेक्शन ज़रूरी नहीं है. ऐसा सिर्फ़ तब होता है, जब Python 3 में पोर्ट किया जा रहा हो. App Engine की दूसरी जनरेशन में हुए स्वागत बदलावों में से एक यह है कि अब तीसरे पक्ष के पैकेज (नॉन-बिल्ट-इन) को कॉपी करना (कभी-कभी "वेंडरिंग" भी कहा जाता है) और app.yaml
में पहले से मौजूद तीसरे पक्ष के पैकेज को कॉपी करना अब ज़रूरी नहीं है. इसका मतलब है कि आप पूरी appengine_config.py
फ़ाइल को मिटा सकते हैं.
6. ऐप्लिकेशन फ़ाइलें अपडेट करें
यहां सिर्फ़ एक ऐप्लिकेशन फ़ाइल है, main.py
, इसलिए इस सेक्शन में किए गए सभी बदलाव सिर्फ़ उस फ़ाइल पर असर डालते हैं. हमने इस ऐप्लिकेशन को Cloud Memorystore में माइग्रेट करने के लिए किए जाने वाले बदलावों की फ़ोटो में, फ़ोटो शामिल की हैं. यह सिर्फ़ समझाने के मकसद से दिया गया है, न कि बारीकी से विश्लेषण करने के लिए. कोड में किए जाने वाले बदलावों पर ही सारा काम होता है.
चलिए, एक बार में इन सेक्शन पर काम करते हैं. सबसे ऊपर वाले सेक्शन से शुरू करते हैं.
इंपोर्ट अपडेट करें
मॉड्यूल 12 के लिए, main.py
में मौजूद इंपोर्ट सेक्शन में, Cloud NDB और Cloud Tasks का इस्तेमाल किया गया है; यहां उनके इंपोर्ट दिए गए हैं:
पहले:
from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb
Memorystore पर स्विच करने के लिए, रीडिंग एनवायरमेंट वैरिएबल की ज़रूरत होती है. इसका मतलब है कि हमें Python os
मॉड्यूल और redis
, Python Redis क्लाइंट की ज़रूरत पड़ती है. Redis Python ऑब्जेक्ट को कैश नहीं कर सकता. इसलिए, pickle
का इस्तेमाल करके सबसे हाल की विज़िट की सूची को मार्शल करें. इसलिए, उसे भी इंपोर्ट करें. Memcache का एक फ़ायदा यह है कि ऑब्जेक्ट को क्रम में लगाने की प्रक्रिया अपने-आप होती है, जबकि Memorystore "DIY" से थोड़ा ज़्यादा होता है. आखिर में, google.appengine.ext.ndb
को google.cloud.ndb
से बदलकर, App Engine ndb
से Cloud NDB पर अपग्रेड करें. इन बदलावों के बाद, आपके इंपोर्ट अब कुछ इस तरह दिखेंगे:
बाद में:
import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis
अपडेट शुरू करने की प्रोसेस
मॉड्यूल 12 को शुरू करने में, फ़्लास्क ऐप्लिकेशन ऑब्जेक्ट app
को इंस्टैंशिएट करना और एक घंटे के कैश मेमोरी का कॉन्स्टेंट सेट करना शामिल है:
पहले:
app = Flask(__name__)
HOUR = 3600
Cloud API का इस्तेमाल करने के लिए, क्लाइंट की ज़रूरत होती है. इसलिए, Flask के तुरंत बाद Cloud NDB क्लाइंट को इंस्टैंशिएट करें. इसके बाद, app.yaml
में सेट किए गए एनवायरमेंट वैरिएबल से Memorystore इंस्टेंस का आईपी पता और पोर्ट नंबर पाएं. इस जानकारी के साथ, Redis क्लाइंट इंस्टैंशिएट करें. इन अपडेट के बाद आपका कोड ऐसा दिखेगा:
बाद में:
app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)
*Python 3 का माइग्रेशन
अगर आपको मॉड्यूल 12 ऐप्लिकेशन के Python 3 वर्शन से शुरुआत करनी है, तो इस सेक्शन को इस्तेमाल करना ज़रूरी नहीं है. अगर ऐसा है, तो इंपोर्ट और शुरू करने से जुड़े कई ज़रूरी बदलाव करने होंगे.
सबसे पहले, Memcache एक App Engine बंडल की गई सेवा है, इसलिए Python 3 ऐप्लिकेशन में इसके इस्तेमाल के लिए App Engine SDK टूल की ज़रूरत होती है. इसमें, खास तौर पर WSGI ऐप्लिकेशन (साथ ही अन्य ज़रूरी कॉन्फ़िगरेशन) को रैप करना होता है:
पहले:
from flask import Flask, render_template, request
from google.appengine.api import memcache, wrap_wsgi_app
from google.appengine.ext import ndb
app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
HOUR = 3600
हम Cloud Memorystore (न कि App Engine बंडल की गई सेवा, जैसे कि Memcache) पर माइग्रेट कर रहे हैं. इसलिए, SDK टूल के इस्तेमाल को हटाना ज़रूरी है. यह आसान है, क्योंकि आपको बस वह पूरी लाइन मिटानी होगी जो memcache
और wrap_wsgi_app
, दोनों से इंपोर्ट करती है. साथ ही wrap_wsgi_app()
को कॉल करने वाली लाइन हटाएं. ये अपडेट, ऐप्लिकेशन के इस हिस्से (असल में, पूरा ऐप्लिकेशन) को Python 2 वर्शन के जैसा ही छोड़ देते हैं.
बाद में:
import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis
app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)
आखिर में, app.yaml
(लाइन मिटाएं: app_engine_apis: true
) और requirements.txt
(लाइन मिटाएं: appengine-python-standard
) से SDK टूल का इस्तेमाल हटा दें.
Cloud Memorystore (और Cloud NDB) पर माइग्रेट करें
Cloud NDB के डेटा मॉडल को, App Engine ndb
के साथ काम करने के लिए बनाया गया है. इसका मतलब है कि Visit
ऑब्जेक्ट के डेटा में कोई बदलाव नहीं होगा. मॉड्यूल 2 को Cloud NDB पर माइग्रेट करने से, store_visit()
और fetch_visits()
में सभी Datastore कॉल बेहतर हो जाते हैं और एक नए with
ब्लॉक में एम्बेड हो जाते हैं. ऐसा इसलिए होता है, क्योंकि Cloud NDB कॉन्टेक्स्ट मैनेजर का इस्तेमाल करना ज़रूरी है. बदलाव से पहले के कॉल की जानकारी यहां दी गई है:
पहले:
def store_visit(remote_addr, user_agent):
'create new Visit entity in Datastore'
Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()
def fetch_visits(limit):
'get most recent visits'
return Visit.query().order(-Visit.timestamp).fetch(limit)
दोनों फ़ंक्शन में with ds_client.context()
ब्लॉक जोड़ें और डेटास्टोर कॉल को अंदर (और इंडेंट किया हुआ) रखें. इस मामले में, कॉल में किसी तरह का बदलाव करने की ज़रूरत नहीं है:
बाद में:
def store_visit(remote_addr, user_agent):
'create new Visit entity in Datastore'
with ds_client.context():
Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()
def fetch_visits(limit):
'get most recent visits'
with ds_client.context():
return Visit.query().order(-Visit.timestamp).fetch(limit)
आइए, अब कैश मेमोरी में होने वाले बदलावों पर नज़र डालते हैं. मॉड्यूल 12 का main()
फ़ंक्शन यहां दिया गया है:
पहले:
@app.route('/')
def root():
'main application (GET) handler'
# check for (hour-)cached visits
ip_addr, usr_agt = request.remote_addr, request.user_agent
visitor = '{}: {}'.format(ip_addr, usr_agt)
visits = memcache.get('visits')
# register visit & run DB query if cache empty or new visitor
if not visits or visits[0].visitor != visitor:
store_visit(ip_addr, usr_agt)
visits = list(fetch_visits(10))
memcache.set('visits', visits, HOUR) # set() not add()
return render_template('index.html', visits=visits)
Redis के पास "पाएं" हैं और "सेट करें" कॉल करता है, बिलकुल Memcache की तरह. हम बस इससे जुड़ी क्लाइंट लाइब्रेरी को स्वैप करते हैं, है न? करीब-करीब. जैसा कि पहले बताया गया है, हम Redis के साथ Python सूची को कैश मेमोरी में नहीं डाल सकते (क्योंकि पहले उसे क्रम से लगाना ज़रूरी होता है, Memcache ऐसा तरीके से अपने-आप हो जाता है), इसलिए set()
कॉल में " पिकर" का इस्तेमाल करें pickle.dumps()
वाली स्ट्रिंग में विज़िट. इसी तरह, कैश मेमोरी से विज़िट की जानकारी हासिल करने के लिए, आपको get()
के ठीक बाद, pickle.loads()
का इस्तेमाल करके उसे अनपिन करना होगा. इन बदलावों को लागू करने के बाद, मुख्य हैंडलर की जानकारी यहां दी गई है:
बाद में:
@app.route('/')
def root():
'main application (GET) handler'
# check for (hour-)cached visits
ip_addr, usr_agt = request.remote_addr, request.user_agent
visitor = '{}: {}'.format(ip_addr, usr_agt)
rsp = REDIS.get('visits')
visits = pickle.loads(rsp) if rsp else None
# register visit & run DB query if cache empty or new visitor
if not visits or visits[0].visitor != visitor:
store_visit(ip_addr, usr_agt)
visits = list(fetch_visits(10))
REDIS.set('visits', pickle.dumps(visits), ex=HOUR)
return render_template('index.html', visits=visits)
इसके बाद, main.py
में ज़रूरी बदलाव लागू होते हैं, ताकि सैंपल ऐप्लिकेशन के Memcache के इस्तेमाल को Cloud Memorystore में बदला जा सके. एचटीएमएल टेंप्लेट और Python 3 में पोर्ट करने का क्या तरीका है?
क्या आपको एचटीएमएल टेंप्लेट फ़ाइल और पोर्ट को Python 3 में अपडेट करना है?
सरप्राइज़! यहां कुछ करने की ज़रूरत नहीं है, क्योंकि इस ऐप्लिकेशन को इस तरह डिज़ाइन किया गया है कि यह Python 2 और 3, दोनों पर बिना किसी कोड बदलाव और कम्पैटबिलटी लाइब्रेरी के चलने के लिए तैयार किया गया हो. आपको main.py
मिलेगा. mod13a
(2.x) और mod13b
(3.x) में एक जैसा "FINISH" फ़ोल्डर. वर्शन नंबर (अगर इस्तेमाल किया गया है) के अंतर को छोड़कर , requirements.txt
पर भी यही बात लागू होती है. यूज़र इंटरफ़ेस में कोई बदलाव नहीं हुआ है. इसलिए, templates/index.html
के लिए कोई अपडेट नहीं है.
Python 3 App Engine पर इस ऐप्लिकेशन को चलाने के लिए ज़रूरी सभी चीज़ें कॉन्फ़िगरेशन में पहले पूरी कर ली गई थीं: app.yaml
से ग़ैर-ज़रूरी निर्देश हटा दिए गए थे. साथ ही, appengine_config.py
और lib
फ़ोल्डर, दोनों Python 3 में इस्तेमाल न होने की वजह से मिटा दिए गए थे.
7. खास जानकारी/क्लीनअप
यह सेक्शन, कोडलैब के इस मॉड्यूल को रैप करके पूरा करता है. इसके लिए, ऐप्लिकेशन को डिप्लॉय किया जाता है. साथ ही, यह पुष्टि की जाती है कि यह सही तरीके से और किसी भी नतीजे पर दिखने वाले आउटपुट के हिसाब से काम करता है या नहीं. ऐप्लिकेशन की पुष्टि करने के बाद, सभी क्लीनअप करें और आगे की कार्रवाई करें.
ऐप्लिकेशन डिप्लॉय करें और उसकी पुष्टि करें
आखिरी जांच हमेशा यह होती है कि सैंपल ऐप्लिकेशन को डिप्लॉय किया जाए. Python 2 डेवलपर: lib
को मिटाएं और नीचे दिए गए निर्देशों का इस्तेमाल करके फिर से इंस्टॉल करें. (अगर आपके सिस्टम पर Python 2 और 3 दोनों इंस्टॉल किए गए हैं, तो आपको इसके बजाय साफ़ तौर पर pip2
चलाना पड़ सकता है.)
rm -rf ./lib pip install -t lib -r requirements.txt
Python 2 और 3, दोनों के डेवलपर को अब अपने ऐप्लिकेशन को इनके साथ डिप्लॉय करना चाहिए:
gcloud app deploy
आपने कैश मेमोरी में सेव की जाने वाली एक अलग तरह की सेवा के लिए, चीज़ों को बेहतर तरीके से सेव किया है. इसलिए, यह ऐप्लिकेशन अपने मॉड्यूल 12 ऐप्लिकेशन की तरह ही काम करेगा:
यह चरण कोडलैब को पूरा करता है. हमारा सुझाव है कि आप अपडेट किए गए सैंपल ऐप्लिकेशन की तुलना, मॉड्यूल 13 फ़ोल्डर, mod13a
(Python 2) या mod13b
(Python 3) में से किसी एक से करें.
व्यवस्थित करें
सामान्य
अगर आपका काम अभी हो गया है, तो हमारा सुझाव है कि आप बिलिंग से बचने के लिए अपना App Engine ऐप्लिकेशन बंद कर दें. हालांकि, अगर आपको कुछ और टेस्ट या एक्सपेरिमेंट करना है, तो App Engine प्लैटफ़ॉर्म का एक मुफ़्त कोटा है. अगर इस्तेमाल के टीयर को पार नहीं किया जा रहा है, तो आपसे शुल्क नहीं लिया जाएगा. यह कंप्यूट के लिए है. हालांकि, काम के App Engine की सेवाओं के लिए भी शुल्क लिया जा सकता है. इसलिए, ज़्यादा जानकारी के लिए इसका कीमत पेज देखें. अगर इस माइग्रेशन में क्लाउड की अन्य सेवाएं शामिल हैं, तो उनका बिल अलग से भेजा जाता है. दोनों ही मामलों में, अगर लागू हो, तो "इस कोडलैब के लिए खास" सेक्शन देखें सेक्शन देखें.
अगर आपको पूरी जानकारी देनी है, तो App Engine जैसे Google Cloud के बिना सर्वर वाले कंप्यूट प्लैटफ़ॉर्म पर डिप्लॉय करने पर, मामूली बनाने और स्टोरेज का खर्च उठाना पड़ता है. Cloud Storage की तरह Cloud Build का अपना अलग कोटा होता है. उस इमेज का स्टोरेज, उसके कुछ हिस्से का इस्तेमाल करता है. हालांकि, हो सकता है कि आप किसी ऐसे क्षेत्र में हों जहां ऐसा कोई फ़्री टीयर उपलब्ध न हो. इसलिए, संभावित लागत को कम करने के लिए, अपने स्टोरेज के इस्तेमाल को ध्यान में रखें. Cloud Storage के लिए तय किए गए "फ़ोल्डर" तो आपको इन चीज़ों की समीक्षा करनी चाहिए:
console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
- ऊपर दिए गए स्टोरेज लिंक, आपके
PROJECT_ID
और *LOC
*ेशन के हिसाब से होते हैं. जैसे, "us
" अगर आपका ऐप्लिकेशन अमेरिका में होस्ट किया जाता है.
दूसरी ओर, अगर आपको इस ऐप्लिकेशन या इससे जुड़े दूसरे माइग्रेशन कोडलैब का इस्तेमाल नहीं करना है और सब कुछ पूरी तरह से मिटाना है, तो अपना प्रोजेक्ट बंद कर दें.
इस कोडलैब के लिए खास
नीचे दी गई सेवाएं, इस कोडलैब के लिए यूनीक हैं. ज़्यादा जानकारी के लिए हर प्रॉडक्ट के दस्तावेज़ देखें:
- Cloud Memorystore के लिए इंस्टेंस की ज़रूरत होती है और इसके पास फ़्री टियर नहीं है; इस्तेमाल करने के शुल्क के बारे में ज़्यादा जानने के लिए, इसका शुल्क पेज देखें.
- Cloud सर्वर के बिना VPC ऐक्सेस करने की सुविधा कनेक्टर के लिए इंस्टेंस की ज़रूरत होती है और उसके पास फ़्री टियर नहीं होता है; इस्तेमाल की कीमतों के बारे में ज़्यादा जानने के लिए, Cloud VPC की कीमत तय करने वाले पेज पर इसका सेक्शन देखें.
- Cloud Datastore (Datastore मोड में Cloud Firestore) में एक फ़्री टियर है; ज़्यादा जानकारी के लिए, इसकी कीमत वाला पेज देखें.
इस ट्यूटोरियल में क्लाउड के चार प्रॉडक्ट के इस्तेमाल के बारे में बताया गया है:
- App Engine
- Cloud Datastore
- Cloud Memorystore
- क्लाउड VPC
नीचे इन संसाधनों को जारी करने और बिलिंग शुल्कों से बचने/कम करने के निर्देश दिए गए हैं.
Memorystore इंस्टेंस और VPC कनेक्टर को शटडाउन करें
ये प्रॉडक्ट फ़्री टीयर बिना उपलब्ध हैं. इसलिए, अभी आपके लिए बिलिंग की जा रही है. अगर अपने Cloud प्रोजेक्ट को शट डाउन नहीं किया जाता है (अगला सेक्शन देखें), तो बिलिंग रोकने के लिए, आपको अपने Memorystore इंस्टेंस और VPC कनेक्टर को मिटाना होगा. जिस तरह आपने इन संसाधनों को बनाया था उसी तरह इन्हें Cloud Console या कमांड लाइन से भी रिलीज़ किया जा सकता है.
Cloud Console से
Memorystore इंस्टेंस मिटाने के लिए, Memorystore डैशबोर्ड पर वापस जाएं और इंस्टेंस आईडी पर क्लिक करें:
उस इंस्टेंस की ज़्यादा जानकारी वाले पेज पर जाने के बाद, "मिटाएं" पर क्लिक करें और पुष्टि करें:
VPC कनेक्टर को मिटाने के लिए, इसके डैशबोर्ड पर जाएं. इसके बाद, जिस कनेक्टर को मिटाना है उसके बगल में मौजूद चेकबॉक्स को चुनें. इसके बाद, "मिटाएं" पर क्लिक करें और पुष्टि करें:
कमांड लाइन से
नीचे दिए गए gcloud
निर्देशों की जोड़ी, Memorystore इंस्टेंस और VPC कनेक्टर को मिटा देती है:
gcloud redis instances delete INSTANCE --region REGION
gcloud compute networks vpc-access connectors delete CONNECTOR --region REGION
अगर आपने gcloud config set project
के साथ अपना प्रोजेक्ट आईडी सेट नहीं किया है, तो आपको --project PROJECT_ID
देना पड़ सकता है. अगर आपके Memorystore इंस्टेंस को demo-ms
कहा जाता है और VPC कनेक्टर को demo-vpc
कहा जाता है और दोनों क्षेत्र us-central1
में हैं, तो नीचे दिए गए कमांड जारी करके पुष्टि करें:
$ gcloud redis instances delete demo-ms --region us-central1 You are about to delete instance [demo-ms] in [us-central1]. Any associated data will be lost. Do you want to continue (Y/n)? Delete request issued for: [demo-ms] Waiting for operation [projects/PROJECT/locations/REGION/operations/operation-aaaaa-bbbbb-ccccc-ddddd] to complete...done. Deleted instance [demo-ms]. $ $ gcloud compute networks vpc-access connectors delete demo-vpc --region us-central1 You are about to delete connector [demo-vpc] in [us-central1]. Any associated data will be lost. Do you want to continue (Y/n)? Delete request issued for: [demo-vpc] Waiting for operation [projects/PROJECT/locations/REGION/operations/aaaaa-bbbb-cccc-dddd-eeeee] to complete...done. Deleted connector [demo-vpc].
हर अनुरोध को पूरा होने में कुछ मिनट लगते हैं. अगर आपने अपने पूरे Cloud प्रोजेक्ट को बंद करने का विकल्प चुना है, तो आपको यह तरीका अपनाना नहीं होगा, जैसा कि ऊपर बताया गया है. हालांकि, जब तक शट डाउन की प्रोसेस पूरी नहीं हो जाती, तब तक आपको बिलिंग की रकम चुकानी होगी.
अगले चरण
इस ट्यूटोरियल के अलावा, बंडल की गई लेगसी सेवाओं का इस्तेमाल बंद करने पर फ़ोकस करने वाले अन्य माइग्रेशन मॉड्यूल में ये शामिल हैं:
- मॉड्यूल 2: App Engine
ndb
से Cloud NDB पर माइग्रेट करें - मॉड्यूल 7-9: App Engine टास्क सूची से पुश टास्क को क्लाउड टास्क में माइग्रेट करें
- मॉड्यूल 12-13: App Engine Memcache से Cloud Memorystore में माइग्रेट करना
- मॉड्यूल 15-16: App Engine Blobstore से Cloud Storage में माइग्रेट करना
- मॉड्यूल 18-19: App Engine टास्क सूची (टास्क पुल करें) से Cloud Pub/Sub में माइग्रेट करें
Google Cloud में, अब सिर्फ़ बिना सर्वर वाला प्लैटफ़ॉर्म App Engine है. अगर आपके पास कोई छोटा App Engine ऐप्लिकेशन है या कोई ऐसा ऐप्लिकेशन है जिसमें सीमित सुविधाएं हैं और आपको उसे स्टैंडअलोन माइक्रोसर्विस में बदलना है या किसी मोनोलिथिक ऐप्लिकेशन को फिर से इस्तेमाल किए जा सकने वाले कई कॉम्पोनेंट में बांटना है, तो Cloud Functions का इस्तेमाल करने के बारे में सोचें. अगर कंटेनराइज़ेशन आपके ऐप्लिकेशन डेवलपमेंट वर्कफ़्लो का हिस्सा बन गया है, तो खास तौर पर अगर उसमें CI/CD (लगातार इंटिग्रेशन/लगातार डिलीवरी या डिप्लॉयमेंट) पाइपलाइन शामिल है, तो Cloud Run पर माइग्रेट करें. इन स्थितियों की जानकारी यहां दिए गए मॉड्यूल में दी गई है:
- App Engine से Cloud Functions पर माइग्रेट करना: मॉड्यूल 11 देखें
- App Engine से Cloud Run पर माइग्रेट करना: अपने ऐप्लिकेशन को Docker के साथ कंटेनर बनाने के लिए, मॉड्यूल 4 देखें. इसके अलावा, कंटेनर, Docker नॉलेज या
Dockerfile
s के बिना ऐसा करने के लिए मॉड्यूल 5 पर जाएं
बिना सर्वर वाले किसी दूसरे प्लैटफ़ॉर्म पर स्विच करना ज़रूरी नहीं है. हमारा सुझाव है कि कोई भी बदलाव करने से पहले, अपने ऐप्लिकेशन और इस्तेमाल के उदाहरण देखने के लिए सबसे सही विकल्प चुनें.
आप आगे चाहे किसी माइग्रेशन मॉड्यूल पर जाएं, सर्वरलेस माइग्रेशन स्टेशन का पूरा कॉन्टेंट (कोडलैब, वीडियो, सोर्स कोड [जब उपलब्ध हो]) उसके ओपन सोर्स रेपो से ऐक्सेस किया जा सकता है. डेटा स्टोर करने की जगह के README
में, यह भी बताया गया है कि किस माइग्रेशन पर विचार करना चाहिए. साथ ही, इसमें किसी "ऑर्डर" के बारे में भी बताया गया है. में तय किया गया है.
8. अन्य संसाधन
डेवलपर के लिए, इस या इससे जुड़े माइग्रेशन मॉड्यूल के साथ-साथ इससे जुड़े अन्य प्रॉडक्ट को एक्सप्लोर करने के लिए, यहां कुछ अतिरिक्त संसाधन दिए गए हैं. इसमें ऐसी जगहें शामिल हैं जहां इस कॉन्टेंट पर सुझाव, शिकायत या राय दी जा सकती है. साथ ही, कोड के लिंक और दस्तावेज़ के ऐसे अलग-अलग हिस्से शामिल हैं जो आपके काम आ सकते हैं.
कोड लैब से जुड़ी समस्याएं/सुझाव
अगर आपको इस कोडलैब के साथ कोई समस्या मिलती है, तो कृपया आवेदन करने से पहले अपनी समस्या का पता लगाएं. खोजने और नई समस्याएं बनाने के लिए लिंक:
माइग्रेशन के लिए संसाधन
यहां दी गई टेबल में, मॉड्यूल 12 (START) और मॉड्यूल 13 (FINISH) के रेपो फ़ोल्डर के लिंक दिए गए हैं. उन्हें सभी App Engine कोडलैब माइग्रेशन के लिए रेपो से भी ऐक्सेस किया जा सकता है, जिसका क्लोन बनाया जा सकता है या किसी ZIP फ़ाइल को डाउनलोड किया जा सकता है.
Codelab | Python 2 | Python 3 |
मॉड्यूल 13 (यह कोडलैब) |
ऑनलाइन रेफ़रंस
नीचे कुछ ऑनलाइन संसाधन दिए गए हैं, जो इस ट्यूटोरियल के लिए काम के हो सकते हैं:
App Engine
- App Engine दस्तावेज़
- Python 2 App Engine (स्टैंडर्ड एनवायरमेंट) रनटाइम
- Python 2 App Engine पर App Engine की बिल्ट-इन लाइब्रेरी का इस्तेमाल करना
- Python 3 App Engine (स्टैंडर्ड एनवायरमेंट) रनटाइम
- Python 2 और Python 2 के बीच अंतर तीन App Engine (स्टैंडर्ड एनवायरमेंट) रनटाइम
- Python 2 से 3 App Engine (स्टैंडर्ड एनवायरमेंट) माइग्रेशन गाइड
- App Engine की कीमत और कोटा की जानकारी
App Engine NDB और Cloud NDB
- App Engine NDB के बारे में खास जानकारी
- App Engine NDB Datastore का इस्तेमाल
- Google Cloud NDB के दस्तावेज़
- Google Cloud NDB रेपो
- Cloud Datastore की कीमत की जानकारी
App Engine Memcache और Cloud Memorystore
- App Engine Memcache की खास जानकारी
- Python 2 App Engine
memcache
के बारे में जानकारी - Python 3 App Engine
memcache
के बारे में जानकारी - App Engine
memcache
से Cloud Memorystore में माइग्रेट करने की गाइड - Cloud Memorystore के दस्तावेज़
- Cloud Memorystore for Redis के दस्तावेज़
- Redis के शुल्क की जानकारी के लिए Cloud Memorystore
- Cloud Memorystore पर काम करने वाले Redis वर्शन
- Cloud Memorystore का होम पेज
- Cloud Console में नया Memorystore इंस्टेंस बनाएं
- Python Redis क्लाइंट होम पेज
- Python Redis क्लाइंट लाइब्रेरी से जुड़े दस्तावेज़
क्लाउड VPC
- Google Cloud VPC के दस्तावेज़
- Google Cloud VPC का होम पेज
- Cloud VPC की कीमत की जानकारी
- Cloud Console में सर्वर के बिना VPC ऐक्सेस करने की सुविधा वाला नया कनेक्टर बनाना
क्लाउड से जुड़ी अन्य जानकारी
- Google Cloud Platform पर Python
- Google Cloud Python क्लाइंट लाइब्रेरी
- Google Cloud "हमेशा मुफ़्त" टियर
- Google Cloud SDK (
gcloud
कमांड-लाइन टूल) - Google Cloud के सभी दस्तावेज़
लाइसेंस
इस काम को क्रिएटिव कॉमंस एट्रिब्यूशन 2.0 जेनरिक लाइसेंस के तहत लाइसेंस मिला है.