App Engine Memcache से Cloud Memorystore में माइग्रेट करना (मॉड्यूल 13)

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 पर माइग्रेट करें

आपको इनकी ज़रूरत होगी

सर्वे

इस ट्यूटोरियल का इस्तेमाल कैसे किया जाएगा?

सिर्फ़ इसे पढ़ें इसे पढ़ें और कसरतों को पूरा करें

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 टूल को इस्तेमाल करने का तरीका नहीं बताया गया है.

इस ट्यूटोरियल में ये मुख्य चरण बताए गए हैं:

  1. सेटअप/प्रीवर्क
  2. कैश मेमोरी में सेव करने की सेवाएं सेट अप करें
  3. कॉन्फ़िगरेशन फ़ाइलें अपडेट करना
  4. मुख्य ऐप्लिकेशन अपडेट करें

3. सेटअप/प्रीवर्क

Cloud प्रोजेक्ट तैयार करें

हमारा सुझाव है कि उसी प्रोजेक्ट को दोबारा इस्तेमाल करें जिसका इस्तेमाल आपने मॉड्यूल 12 कोडलैब को पूरा करने के लिए किया था. इसके अलावा, नया प्रोजेक्ट बनाया जा सकता है या किसी मौजूदा प्रोजेक्ट का फिर से इस्तेमाल किया जा सकता है. इस सीरीज़ के हर कोडलैब का एक "शुरू करें" होता है (इससे शुरू होने वाला बेसलाइन कोड) और "FINISH" (माइग्रेट किया गया ऐप्लिकेशन). FINISH कोड इसलिए दिया जाता है, ताकि किसी समस्या आने पर आप हमारे समाधान से तुलना कर सकें. अगर कुछ गलत हो जाता है, तो आप किसी भी समय START पर रोल बैक कर सकते हैं. इन चेकपॉइंट को यह पक्का करने के लिए डिज़ाइन किया गया है कि आपको माइग्रेशन करने का तरीका सीखने में सफलता मिले.

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

बेसलाइन ऐप्लिकेशन का नमूना डाउनलोड करें

हम जिस बेसलाइन मॉड्यूल 12 कोड से शुरुआत कर रहे हैं, उससे यह कोडलैब आपको माइग्रेशन के चरणों की सिलसिलेवार जानकारी देता है. यह प्रोसेस पूरी होने के बाद, आपको FINISH फ़ोल्डर में मौजूद कोड से मिलता-जुलता मॉड्यूल 13 ऐप्लिकेशन दिखेगा. इन संसाधनों की जानकारी यहां दी गई है:

START फ़ोल्डर में ये फ़ाइलें होनी चाहिए:

$ ls
README.md               app.yaml                main.py                 requirements.txt        templates                

अगर Python 2 वर्शन से शुरुआत की जा रही है, तो मॉड्यूल 12 कोडलैब पूरा करने पर आपको appengine_config.py फ़ाइल और lib फ़ोल्डर भी मिलेगा.

मॉड्यूल 12 ऐप्लिकेशन को दोबारा डिप्लॉय करें

प्रीवर्क के बाकी चरण:

  1. gcloud कमांड-लाइन टूल का इस्तेमाल करके, फिर से जानें (अगर ज़रूरी हो)
  2. 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 की तरह ही दिखता और काम करता है. यह एक ऐसा वेब ऐप्लिकेशन है जो विज़िट को ट्रैक करता है और एक ही उपयोगकर्ता के लिए उन्हें एक घंटे के लिए कैश मेमोरी में सेव करता है:

dfe56a02ae59ddd8.png

सबसे हाल की विज़िट को कैश मेमोरी में सेव किया जाता है. इसलिए, पेज रीफ़्रेश जल्दी लोड होते हैं.

4. कैश मेमोरी में सेव करने की सेवाएं सेट अप करें

Cloud Memorystore सर्वरलेस नहीं है. इंस्टेंस ज़रूरी है; इस मामले में एक Redis चल रहा है. Memcache के उलट, Memorystore एक स्टैंडअलोन क्लाउड प्रॉडक्ट है और इसमें फ़्री टियर नहीं है. इसलिए, आगे बढ़ने से पहले Redis के लिए Memorystore की कीमत की जानकारी देखना न भूलें. हमारा सुझाव है कि इस काम की लागत को कम करने के लिए, कम से कम संसाधनों का इस्तेमाल करें: बेसिक सर्विस टियर और 1 जीबी की क्षमता.

Memorystore इंस्टेंस, आपके App Engine ऐप्लिकेशन (इंस्टेंस) से अलग नेटवर्क पर है. इसलिए, बिना सर्वर वाले VPC ऐक्सेस कनेक्टर वाला एक नेटवर्क बनाना ज़रूरी है, ताकि App Engine आपके Memorystore के संसाधनों को ऐक्सेस कर सके. VPC की लागत कम करने के लिए, इंस्टेंस टाइप (f1-micro) और कम से कम इंस्टेंस का अनुरोध करने के लिए ऑप्ट इन करें. हमारा सुझाव है कि आप कम से कम दो और ज़्यादा से ज़्यादा तीन का इस्तेमाल करें. VPC की कीमत की जानकारी वाला पेज भी देखें.

हम इन सुझावों को, लागत कम करने के लिए दोहराते हैं. ऐसा इसलिए, क्योंकि हम हर ज़रूरी संसाधन को तैयार करने में आपकी मदद करते हैं. इसके अलावा, जब Cloud Console में Memorystore और VPC के संसाधन बनाए जाते हैं, तब आपको ऊपर दाएं कोने में हर प्रॉडक्ट का प्राइसिंग कैलकुलेटर दिखेगा. इससे आपको हर महीने की अनुमानित लागत की जानकारी मिलती है (नीचे दी गई इमेज देखें). अगर आपने विकल्प बदलते हैं, तो ये वैल्यू अपने-आप अडजस्ट हो जाती हैं. आम तौर पर, आपको यह जानकारी दिखेगी:

7eb35ebf7248c010.png

दोनों संसाधन ज़रूरी हैं. इससे कोई फ़र्क़ नहीं पड़ता कि आपने पहले कौनसा संसाधन बनाया है. अगर पहले 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 को चालू नहीं किया है, तो आपको ऐसा करने के लिए कहा जाएगा:

68318997e3105db6.png

इसे चालू करने के बाद (और बिलिंग के साथ), आप Memorystore डैशबोर्ड पर पहुंच जाएंगे. यहां आपको अपने प्रोजेक्ट में बनाए गए सभी इंस्टेंस दिखेंगे. नीचे दिखाए गए प्रोजेक्ट में कोई भी प्रोजेक्ट मौजूद नहीं है. इसलिए, आपको "डिसप्ले के लिए कोई लाइन नहीं है" दिखता है. Memorystore इंस्टेंस बनाने के लिए, सबसे ऊपर इंस्टेंस बनाएं पर क्लिक करें:

63547aa575838a36.png

इस पेज में एक फ़ॉर्म दिया गया है, जिसे Memorystore इंस्टेंस बनाने के लिए, आपकी मनचाही सेटिंग को पूरा करना होगा:

b77d927287fdf4c7.png

इस ट्यूटोरियल और इसके सैंपल ऐप्लिकेशन की कीमत कम रखने के लिए, ऊपर दिए गए सुझावों को अपनाएं. अपनी पसंद का विकल्प चुनने के बाद, बनाएं पर क्लिक करें. इसे बनाने में कुछ मिनट लगते हैं. इसके पूरा हो जाने पर, 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 डैशबोर्ड में यह इंस्टेंस दिखना चाहिए:

c5a6948ec1c056ed.png

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 ऐक्सेस करने की सुविधा" पर जाएं पेज पर जाएं (आपको बिलिंग जानकारी देने के लिए कहा जा सकता है). अगर आपने अब तक इस एपीआई को चालू नहीं किया है, तो आपको ऐसा करने के लिए कहा जाएगा:

e3b9c0651de25e97.png

एपीआई (और बिलिंग के साथ) को चालू करने के बाद, आपको एक डैशबोर्ड दिखेगा. इसमें बनाए गए सभी VPC कनेक्टर दिखेंगे. नीचे दिए गए स्क्रीनशॉट में इस्तेमाल किए गए प्रोजेक्ट में, कोई प्रोजेक्ट मौजूद नहीं है. इसलिए, इसमें "दिखाने के लिए कोई लाइन नहीं है" लिखा है. अपने कंसोल में, सबसे ऊपर कनेक्टर बनाएं पर क्लिक करें:

b74b49b9d73b7dcf.png

अपनी ज़रूरत के हिसाब से सेटिंग चुनकर फ़ॉर्म भरें:

6b26b2aafa719f73.png

अपने ऐप्लिकेशन के लिए सही सेटिंग चुनें. कम से कम ज़रूरतों वाले इस ट्यूटोरियल और इसके सैंपल ऐप्लिकेशन के लिए, खर्च को कम करना सही रहता है. इसलिए, पहले दिए गए सुझावों को अपनाएं. अपनी पसंद का विकल्प चुनने के बाद, बनाएं पर क्लिक करें. 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

इसी तरह, डैशबोर्ड में अब वह कनेक्टर दिखना चाहिए जो आपने अभी बनाया है:

e03db2c8140ed014.png

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 पर लागू करना है:

ec2bb027a67debb6.png

*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 के काम करने वाले सेट में जोड़ना है:

4140b3800694f77e.png

*Python 3 के अंतर

यह सेक्शन ज़रूरी नहीं है. ऐसा सिर्फ़ तब होता है, जब Python 3 में पोर्ट किया जा रहा हो. App Engine की दूसरी जनरेशन में हुए स्वागत बदलावों में से एक यह है कि अब तीसरे पक्ष के पैकेज (नॉन-बिल्ट-इन) को कॉपी करना (कभी-कभी "वेंडरिंग" भी कहा जाता है) और app.yaml में पहले से मौजूद तीसरे पक्ष के पैकेज को कॉपी करना अब ज़रूरी नहीं है. इसका मतलब है कि आप पूरी appengine_config.py फ़ाइल को मिटा सकते हैं.

6. ऐप्लिकेशन फ़ाइलें अपडेट करें

यहां सिर्फ़ एक ऐप्लिकेशन फ़ाइल है, main.py, इसलिए इस सेक्शन में किए गए सभी बदलाव सिर्फ़ उस फ़ाइल पर असर डालते हैं. हमने इस ऐप्लिकेशन को Cloud Memorystore में माइग्रेट करने के लिए किए जाने वाले बदलावों की फ़ोटो में, फ़ोटो शामिल की हैं. यह सिर्फ़ समझाने के मकसद से दिया गया है, न कि बारीकी से विश्लेषण करने के लिए. कोड में किए जाने वाले बदलावों पर ही सारा काम होता है.

5d043768ba7be742.png

चलिए, एक बार में इन सेक्शन पर काम करते हैं. सबसे ऊपर वाले सेक्शन से शुरू करते हैं.

इंपोर्ट अपडेट करें

मॉड्यूल 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 ऐप्लिकेशन की तरह ही काम करेगा:

मॉड्यूल 7 visitme ऐप्लिकेशन

यह चरण कोडलैब को पूरा करता है. हमारा सुझाव है कि आप अपडेट किए गए सैंपल ऐप्लिकेशन की तुलना, मॉड्यूल 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 डैशबोर्ड पर वापस जाएं और इंस्टेंस आईडी पर क्लिक करें:

2b09baf1aa2e0a25.png

उस इंस्टेंस की ज़्यादा जानकारी वाले पेज पर जाने के बाद, "मिटाएं" पर क्लिक करें और पुष्टि करें:

f9d9eb1c1d4c6107.png

VPC कनेक्टर को मिटाने के लिए, इसके डैशबोर्ड पर जाएं. इसके बाद, जिस कनेक्टर को मिटाना है उसके बगल में मौजूद चेकबॉक्स को चुनें. इसके बाद, "मिटाएं" पर क्लिक करें और पुष्टि करें:

ca5fbd9f4c7c9b60.png

कमांड लाइन से

नीचे दिए गए 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 नॉलेज या Dockerfiles के बिना ऐसा करने के लिए मॉड्यूल 5 पर जाएं

बिना सर्वर वाले किसी दूसरे प्लैटफ़ॉर्म पर स्विच करना ज़रूरी नहीं है. हमारा सुझाव है कि कोई भी बदलाव करने से पहले, अपने ऐप्लिकेशन और इस्तेमाल के उदाहरण देखने के लिए सबसे सही विकल्प चुनें.

आप आगे चाहे किसी माइग्रेशन मॉड्यूल पर जाएं, सर्वरलेस माइग्रेशन स्टेशन का पूरा कॉन्टेंट (कोडलैब, वीडियो, सोर्स कोड [जब उपलब्ध हो]) उसके ओपन सोर्स रेपो से ऐक्सेस किया जा सकता है. डेटा स्टोर करने की जगह के README में, यह भी बताया गया है कि किस माइग्रेशन पर विचार करना चाहिए. साथ ही, इसमें किसी "ऑर्डर" के बारे में भी बताया गया है. में तय किया गया है.

8. अन्य संसाधन

डेवलपर के लिए, इस या इससे जुड़े माइग्रेशन मॉड्यूल के साथ-साथ इससे जुड़े अन्य प्रॉडक्ट को एक्सप्लोर करने के लिए, यहां कुछ अतिरिक्त संसाधन दिए गए हैं. इसमें ऐसी जगहें शामिल हैं जहां इस कॉन्टेंट पर सुझाव, शिकायत या राय दी जा सकती है. साथ ही, कोड के लिंक और दस्तावेज़ के ऐसे अलग-अलग हिस्से शामिल हैं जो आपके काम आ सकते हैं.

कोड लैब से जुड़ी समस्याएं/सुझाव

अगर आपको इस कोडलैब के साथ कोई समस्या मिलती है, तो कृपया आवेदन करने से पहले अपनी समस्या का पता लगाएं. खोजने और नई समस्याएं बनाने के लिए लिंक:

माइग्रेशन के लिए संसाधन

यहां दी गई टेबल में, मॉड्यूल 12 (START) और मॉड्यूल 13 (FINISH) के रेपो फ़ोल्डर के लिंक दिए गए हैं. उन्हें सभी App Engine कोडलैब माइग्रेशन के लिए रेपो से भी ऐक्सेस किया जा सकता है, जिसका क्लोन बनाया जा सकता है या किसी ZIP फ़ाइल को डाउनलोड किया जा सकता है.

Codelab

Python 2

Python 3

मॉड्यूल 12

कोड

कोड

मॉड्यूल 13 (यह कोडलैब)

कोड

कोड

ऑनलाइन रेफ़रंस

नीचे कुछ ऑनलाइन संसाधन दिए गए हैं, जो इस ट्यूटोरियल के लिए काम के हो सकते हैं:

App Engine

App Engine NDB और Cloud NDB

App Engine Memcache और Cloud Memorystore

क्लाउड VPC

क्लाउड से जुड़ी अन्य जानकारी

लाइसेंस

इस काम को क्रिएटिव कॉमंस एट्रिब्यूशन 2.0 जेनरिक लाइसेंस के तहत लाइसेंस मिला है.