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

1. खास जानकारी

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

इस कोडलैब का मकसद, Python 2 App Engine डेवलपर को यह बताना है कि App Engine Memcache से Cloud Memorystore (Redis के लिए) पर कैसे माइग्रेट किया जाए. App Engine ndb से Cloud NDB में इंप्लिसिट माइग्रेशन भी होता है. हालांकि, इसके बारे में मुख्य तौर पर दूसरे मॉड्यूल के कोडलैब में बताया गया है. ज़्यादा जानकारी के लिए, इसे देखें.

आपको इनके बारे में जानकारी मिलेगी

  • Cloud Memorystore इंस्टेंस सेट अप करना (Cloud Console या gcloud टूल से)
  • Cloud Serverless VPC Access कनेक्टर सेट अप करें (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 की भी ज़रूरत होती है. खास तौर पर, सर्वर के बिना वीपीसी ऐक्सेस करने की सुविधा वाला कनेक्टर बनाना ज़रूरी है, ताकि App Engine ऐप्लिकेशन, Memorystore इंस्टेंस से उसके निजी आईपी पते के ज़रिए कनेक्ट हो सके. इस प्रोसेस को पूरा करने के बाद, ऐप्लिकेशन अपडेट हो जाएगा. इससे ऐप्लिकेशन पहले की तरह ही काम करेगा. हालांकि, Cloud Memorystore, App Engine की Memcache सेवा की जगह कैश मेमोरी की सेवा के तौर पर काम करेगा.

इस ट्यूटोरियल की शुरुआत, Python 2 में मौजूद मॉड्यूल 12 के सैंपल ऐप्लिकेशन से होती है. इसके बाद, Python 3 में अपग्रेड करने का एक और विकल्प दिया गया है. अगर आपको Python 3 App Engine SDK के ज़रिए, Python 3 से App Engine की बंडल की गई सेवाओं को ऐक्सेस करने के बारे में पहले से पता है, तो Module 12 के सैंपल ऐप्लिकेशन के Python 3 वर्शन का इस्तेमाल शुरू करें. ऐसा करने पर, एसडीके का इस्तेमाल बंद हो जाएगा. ऐसा इसलिए, क्योंकि Memorystore, App Engine की बंडल की गई सेवा नहीं है. इस ट्यूटोरियल में, Python 3 App Engine SDK टूल को इस्तेमाल करने का तरीका नहीं बताया गया है.

इस ट्यूटोरियल में, ये मुख्य चरण शामिल हैं:

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

3. सेटअप/पहले से किया गया काम

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

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

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

बेसलाइन सैंपल ऐप्लिकेशन पाना

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

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

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

अगर Python 2 वर्शन से शुरुआत की जा रही है, तो एक appengine_config.py फ़ाइल भी होगी. साथ ही, अगर आपने मॉड्यूल 12 का कोडलैब पूरा किया है, तो एक 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 एक स्टैंडअलोन Cloud प्रॉडक्ट है. इसमें मुफ़्त टियर नहीं होता. इसलिए, आगे बढ़ने से पहले Memorystore for Redis की कीमत के बारे में जानकारी ज़रूर देख लें. इस प्रोसेस की लागत को कम करने के लिए, हमारा सुझाव है कि आप कम से कम संसाधनों का इस्तेमाल करें: Basic सेवा टियर और 1 जीबी की क्षमता.

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

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

7eb35ebf7248c010.png

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

दोनों संसाधनों के ऑनलाइन होने के बाद, आपको app.yaml में काम की जानकारी जोड़नी होगी, ताकि आपका ऐप्लिकेशन कैश मेमोरी को ऐक्सेस कर सके. आधिकारिक दस्तावेज़ में, Python 2 या Python 3 की गाइड भी देखी जा सकती हैं. Cloud NDB माइग्रेशन पेज ( Python 2 या Python 3) पर मौजूद, डेटा कैश मेमोरी में सेव करने से जुड़ी गाइड भी देखी जा सकती है.

Cloud Memorystore इंस्टेंस बनाना

Cloud Memorystore में मुफ़्त टियर उपलब्ध नहीं है. इसलिए, हमारा सुझाव है कि कोडलैब को पूरा करने के लिए, कम से कम संसाधनों का इस्तेमाल करें. इन सेटिंग का इस्तेमाल करके, लागत को कम से कम रखा जा सकता है:

  • सबसे कम सेवा स्तर चुनें: Basic (कंसोल का डिफ़ॉल्ट: "Standard", gcloud का डिफ़ॉल्ट: "Basic").
  • सबसे कम स्टोरेज चुनें: 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 की तरह ही, Cloud Memorystore for Redis को चालू करना ज़रूरी है. 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 इंस्टेंस को कमांड भेजकर भी यह पुष्टि की जा सकती है कि वह काम कर रहा है. ध्यान दें कि वीएम का इस्तेमाल करने पर, आपसे शुल्क लिया जा सकता है. यह शुल्क, उन संसाधनों से अलग होगा जिनका इस्तेमाल पहले से किया जा रहा है.

सर्वर के बिना वीपीसी ऐक्सेस करने की सुविधा वाला कनेक्टर बनाना

Cloud Memorystore की तरह ही, Cloud Console या कमांड-लाइन पर सर्वरलेस Cloud VPC कनेक्टर बनाया जा सकता है. इसी तरह, Cloud VPC का कोई मुफ़्त टियर नहीं है. इसलिए, हम सुझाव देते हैं कि कोडलैब को पूरा करने के लिए, कम से कम संसाधनों का इस्तेमाल करें, ताकि लागत कम से कम रहे. ऐसा इन सेटिंग की मदद से किया जा सकता है:

  • सबसे कम संख्या में इंस्टेंस चुनें: 3 (कंसोल और gcloud डिफ़ॉल्ट: 10)
  • सबसे कम कीमत वाला मशीन टाइप चुनें: f1-micro (कंसोल का डिफ़ॉल्ट: e2-micro, कोई gcloud डिफ़ॉल्ट नहीं)

अगले सेक्शन में, ऊपर दी गई Cloud VPC सेटिंग का इस्तेमाल करके, Cloud Console से कनेक्टर बनाने का तरीका बताया गया है. अगर आपको कमांड-लाइन से ऐसा करना है, तो अगले सेक्शन पर जाएं.

Cloud Console से

Cloud Console में Cloud Networking "Serverless VPC access" पेज पर जाएं. आपसे बिलिंग की जानकारी मांगी जा सकती है. अगर आपने अब तक एपीआई चालू नहीं किया है, तो आपको ऐसा करने के लिए कहा जाएगा:

e3b9c0651de25e97.png

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

b74b49b9d73b7dcf.png

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

6b26b2aafa719f73.png

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

कमांड-लाइन से

VPC कनेक्टर बनाने से पहले, सर्वर के बिना वीपीसी ऐक्सेस करने की सुविधा वाले एपीआई को चालू करें. नीचे दिए गए कमांड को चलाने के बाद, आपको इससे मिलता-जुलता आउटपुट दिखेगा:

$ gcloud services enable vpcaccess.googleapis.com
Operation "operations/acf.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

एपीआई चालू होने पर, वीपीसी कनेक्टर को इस तरह के कमांड की मदद से बनाया जाता है:

gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
    --range 10.8.0.0/28 --region REGION --project PROJECT_ID

अपने कनेक्टर के लिए कोई नाम चुनें. साथ ही, ऐसा /28 सीआईडीआर ब्लॉक स्टार्टिंग आईपी पता चुनें जिसका इस्तेमाल न किया गया हो. इस ट्यूटोरियल में, इन बातों को माना गया है:

  • प्रोजेक्ट आईडी: my-project
  • वीपीसी कनेक्टर का नाम: demo-vpc
  • कम से कम इंस्टेंस: 2 (डिफ़ॉल्ट) और ज़्यादा से ज़्यादा इंस्टेंस: 3
  • उदाहरण का टाइप: f1-micro
  • रीजन: us-central1
  • IPv4 सीआईडीआर ब्लॉक: 10.8.0.0/28 (जैसा कि Cloud Console में सुझाया गया है)

अगर ऊपर दी गई शर्तों के हिसाब से, यहां दिया गया निर्देश लागू किया जाता है, तो आपको कुछ ऐसा आउटपुट मिलेगा:

$ 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].

ऊपर दिए गए निर्देश में, डिफ़ॉल्ट वैल्यू के बारे में नहीं बताया गया है. जैसे, कम से कम दो इंस्टेंस और default नाम का नेटवर्क. वीपीएसी कनेक्टर बनाने में कुछ समय लगता है.

कनेक्टर बनाए जाने की पुष्टि करना

प्रोसेस पूरी होने के बाद, यह पुष्टि करने के लिए कि यह बन गया है और इस्तेमाल के लिए तैयार है, यहां दी गई gcloud कमांड जारी करें. मान लें कि यह क्षेत्र us-central1 है:

$ 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 संसाधन बना लिए हैं. अब आपको ऐप्लिकेशन के कॉन्फ़िगरेशन को अपडेट करना होगा, ताकि उनका इस्तेमाल किया जा सके.

5. कॉन्फ़िगरेशन फ़ाइलें अपडेट करना

पहला चरण, कॉन्फ़िगरेशन फ़ाइलों में सभी ज़रूरी बदलाव करना है. इस कोडलैब का मुख्य मकसद, Python 2 का इस्तेमाल करने वाले लोगों को माइग्रेट करने में मदद करना है. हालांकि, इस कॉन्टेंट के बाद, आम तौर पर हर सेक्शन में Python 3 में पोर्ट करने के बारे में जानकारी दी जाती है.

requirements.txt

इस सेक्शन में, हम Cloud Memorystore और Cloud NDB के साथ काम करने वाले पैकेज जोड़ रहे हैं. Cloud Memorystore for Redis के लिए, Python (redis) के लिए स्टैंडर्ड Redis क्लाइंट का इस्तेमाल करना काफ़ी है, क्योंकि Cloud Memorystore क्लाइंट लाइब्रेरी नहीं है. redis और google-cloud-ndb, दोनों को requirements.txt से जोड़ें. साथ ही, मॉड्यूल 12 से flask को जोड़ें:

flask
redis
google-cloud-ndb

इस requirements.txt फ़ाइल में कोई वर्शन नंबर नहीं है. इसका मतलब है कि सबसे नए वर्शन चुने गए हैं. अगर कोई समस्या आती है, तो काम करने वाले वर्शन को लॉक करने के लिए, वर्शन नंबर डालें.

app.yaml

जोड़ने के लिए नए सेक्शन

Python 2 App Engine रनटाइम को Cloud NDB जैसे Cloud API का इस्तेमाल करते समय, तीसरे पक्ष के कुछ खास पैकेज की ज़रूरत होती है. जैसे, grpcio और setuptools. Python 2 का इस्तेमाल करने वाले लोगों को, app.yaml में इन जैसी बिल्ट-इन लाइब्रेरी के साथ-साथ उपलब्ध वर्शन की सूची देनी होगी. अगर आपके पास अब तक कोई libraries सेक्शन नहीं है, तो एक सेक्शन बनाएं और उसमें दोनों लाइब्रेरी जोड़ें. जैसे:

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

अपने ऐप्लिकेशन को माइग्रेट करते समय, हो सकता है कि उसमें पहले से ही libraries सेक्शन मौजूद हो. अगर ऐसा होता है और grpcio और setuptools दोनों मौजूद नहीं हैं, तो उन्हें अपने मौजूदा libraries सेक्शन में जोड़ें.

इसके बाद, हमारे सैंपल ऐप्लिकेशन को Cloud Memorystore इंस्टेंस और वीपीसी कनेक्टर की जानकारी चाहिए. इसलिए, 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 रनटाइम के लिए ऐसे वेब फ़्रेमवर्क का इस्तेमाल करना ज़रूरी है जो खुद राउटिंग करते हैं. इसलिए, हमने डेवलपर को पहले मॉड्यूल में webp2 से Flask पर माइग्रेट करने का तरीका बताया है. इसलिए, सभी स्क्रिप्ट हैंडलर को auto में बदलना होगा. यह ऐप्लिकेशन कोई भी स्टैटिक फ़ाइल नहीं दिखाता है. इसलिए, हैंडलर की सूची देना "बेकार" है, क्योंकि वे सभी 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 और वीपीसी कनेक्टर के नए सेक्शन में मौजूद वैल्यू सिर्फ़ प्लेसहोल्डर हैं. कैपिटल लेटर में लिखी गई उन वैल्यू (YOUR_REDIS_HOST, YOUR_REDIS_PORT, PROJECT_ID, REGION, CONNECTOR_NAME) को उन वैल्यू से बदलें जिन्हें आपने पहले उन संसाधनों को बनाते समय सेव किया था. अपने Memorystore इंस्टेंस के लिए, HOST (RESERVED_IP नहीं) और PORT का इस्तेमाल करें. यहां कमांड-लाइन का इस्तेमाल करके, HOST और PORT पाने का तरीका बताया गया है. इसमें यह माना गया है कि इंस्टेंस का नाम demo-ms है और REGION, us-central1 है:

$ 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 में पोर्ट 6379 का इस्तेमाल कर रहा है. यह प्रोजेक्ट, us-central1 क्षेत्र में मौजूद है और इसके वीपीसी कनेक्टर का नाम demo-vpc है, तो 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 में बदलाव करें. अगर आपको यह जानकारी जानी-पहचानी लग रही है, तो इसकी वजह यह है कि मॉड्यूल 2 में, App Engine ndb से Cloud NDB पर माइग्रेट करते समय भी इसकी ज़रूरत पड़ी थी. इसके लिए, setuptools.pkg_resources वर्किंग सेट में lib फ़ोल्डर जोड़ना होगा:

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 का इस्तेमाल करता है. यहां उनके इंपोर्ट दिए गए हैं:

BEFORE:

from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb

Memorystore पर स्विच करने के लिए, एनवायरमेंट वैरिएबल को पढ़ना ज़रूरी होता है. इसका मतलब है कि हमें Python os मॉड्यूल के साथ-साथ Python Redis क्लाइंट redis की भी ज़रूरत होती है. Redis, Python ऑब्जेक्ट को कैश मेमोरी में सेव नहीं कर सकता. इसलिए, pickle का इस्तेमाल करके, हाल ही में देखी गई सूचियों को मार्शेल करें. इसके लिए, इसे भी इंपोर्ट करें. Memcache का एक फ़ायदा यह है कि इसमें ऑब्जेक्ट सीरियलाइज़ेशन अपने-आप होता है, जबकि Memorystore में यह "खुद करें" वाला काम है. आखिर में, App Engine ndb से Cloud NDB पर अपग्रेड करें. इसके लिए, google.appengine.ext.ndb को google.cloud.ndb से बदलें. इन बदलावों के बाद, आपके इंपोर्ट किए गए डेटा को अब इस तरह दिखना चाहिए:

AFTER:

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

शुरू करने की प्रोसेस अपडेट करना

मॉड्यूल 12 को शुरू करने के लिए, Flask ऐप्लिकेशन ऑब्जेक्ट app को इंस्टैंटिएट किया जाता है. साथ ही, एक घंटे के लिए कैश मेमोरी सेट की जाती है:

BEFORE:

app = Flask(__name__)
HOUR = 3600

Cloud API का इस्तेमाल करने के लिए क्लाइंट की ज़रूरत होती है. इसलिए, Flask के ठीक बाद Cloud NDB क्लाइंट को इंस्टैंशिएट करें. इसके बाद, app.yaml में सेट किए गए एनवायरमेंट वैरिएबल से, Memorystore इंस्टेंस का आईपी पता और पोर्ट नंबर पाएं. उस जानकारी के साथ, Redis क्लाइंट को इंस्टैंटिएट करें. अपडेट के बाद, आपका कोड ऐसा दिखेगा:

AFTER:

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

यह सेक्शन वैकल्पिक है. अगर आपने Module 12 ऐप्लिकेशन के Python 3 वर्शन से शुरुआत की है, तो आपको यह सेक्शन दिखेगा. ऐसा होने पर, इंपोर्ट और इनिशियलाइज़ेशन से जुड़े कई ज़रूरी बदलाव किए जाते हैं.

पहला, Memcache, App Engine की बंडल की गई सेवा है. इसलिए, Python 3 ऐप्लिकेशन में इसका इस्तेमाल करने के लिए, App Engine SDK की ज़रूरत होती है. खास तौर पर, WSGI ऐप्लिकेशन के साथ-साथ अन्य ज़रूरी कॉन्फ़िगरेशन को रैप करने के लिए:

BEFORE:

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 पर माइग्रेट कर रहे हैं. यह Memcache की तरह App Engine की बंडल की गई सेवा नहीं है. इसलिए, एसडीके टूल के इस्तेमाल को हटाना होगा. यह आसान है, क्योंकि आपको सिर्फ़ उस पूरी लाइन को मिटाना होगा जो memcache और wrap_wsgi_app, दोनों को इंपोर्ट करती है. साथ ही, wrap_wsgi_app() को कॉल करने वाली लाइन भी मिटा दें. इन अपडेट के बाद, ऐप्लिकेशन का यह हिस्सा (असल में, पूरा ऐप्लिकेशन) Python 2 वर्शन जैसा ही हो जाता है.

AFTER:

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).

Cloud Memorystore (और Cloud NDB) पर माइग्रेट करना

Cloud NDB का डेटा मॉडल, App Engine ndb के साथ काम करता है. इसका मतलब है कि ndb ऑब्जेक्ट की परिभाषा एक जैसी रहती है.Visit मॉड्यूल 2 को Cloud NDB पर माइग्रेट करने की तरह ही, store_visit() और fetch_visits() में मौजूद सभी Datastore कॉल को बढ़ाया जाता है और उन्हें नए with ब्लॉक में एम्बेड किया जाता है. ऐसा इसलिए, क्योंकि Cloud NDB कॉन्टेक्स्ट मैनेजर का इस्तेमाल करना ज़रूरी है. बदलाव से पहले के कॉल यहां दिए गए हैं:

BEFORE:

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() ब्लॉक जोड़ें. इसके बाद, Datastore कॉल को इसके अंदर (और इंडेंट किया गया) रखें. इस मामले में, कॉल में कोई बदलाव करने की ज़रूरत नहीं है:

AFTER:

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() फ़ंक्शन यहां दिया गया है:

BEFORE:

@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 की तरह ही "get" और "set" कॉल होते हैं. हमें सिर्फ़ क्लाइंट लाइब्रेरी बदलनी है, है न? करीब-करीब. जैसा कि हमने पहले बताया था, Redis के साथ Python लिस्ट को कैश मेमोरी में सेव नहीं किया जा सकता. ऐसा इसलिए, क्योंकि इसे पहले क्रमबद्ध करना होता है. यह काम Memcache अपने-आप करता है. इसलिए, set() कॉल में, pickle.dumps() की मदद से विज़िट को स्ट्रिंग में "pickle" करें. इसी तरह, कैश मेमोरी से विज़िट की जानकारी वापस पाने के लिए, आपको get() के ठीक बाद pickle.loads() का इस्तेमाल करके, उसे अनपिकल करना होगा. उन बदलावों को लागू करने के बाद, मुख्य हैंडलर यहां दिया गया है:

AFTER:

@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

आपने सिर्फ़ कैश मेमोरी की सेवा को पूरी तरह से अलग तरीके से रीवायर किया है. इसलिए, ऐप्लिकेशन को आपके Module 12 ऐप्लिकेशन की तरह ही काम करना चाहिए:

Module 7 visitme app

इस चरण के बाद, कोडलैब पूरा हो जाता है. हमारा सुझाव है कि आप अपने अपडेट किए गए सैंपल ऐप्लिकेशन की तुलना, मॉड्यूल 13 के इन फ़ोल्डर से करें: mod13a (Python 2) या mod13b (Python 3).

व्यवस्थित करें

सामान्य

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

पूरी जानकारी के लिए बता दें कि App Engine जैसे Google Cloud के सर्वरलेस कंप्यूट प्लैटफ़ॉर्म पर डिप्लॉय करने से, बिल्ड और स्टोरेज के लिए मामूली शुल्क लगता है. Cloud Build का अपना मुफ़्त कोटा होता है. साथ ही, Cloud Storage का भी अपना मुफ़्त कोटा होता है. उस इमेज को सेव करने के लिए, स्टोरेज कोटा का कुछ हिस्सा इस्तेमाल किया जाता है. हालांकि, ऐसा हो सकता है कि आपके देश/इलाके में बिना किसी शुल्क के स्टोरेज इस्तेमाल करने की सुविधा उपलब्ध न हो. इसलिए, स्टोरेज के इस्तेमाल पर नज़र रखें, ताकि संभावित लागत को कम किया जा सके. 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*ation पर निर्भर करते हैं. उदाहरण के लिए, अगर आपका ऐप्लिकेशन अमेरिका में होस्ट किया गया है, तो "us" दिखेगा.

दूसरी ओर, अगर आपको इस ऐप्लिकेशन या माइग्रेशन से जुड़े अन्य कोडलैब का इस्तेमाल नहीं करना है और आपको सब कुछ पूरी तरह से मिटाना है, तो अपना प्रोजेक्ट बंद करें.

इस कोडलैब के लिए खास तौर पर

यहां दी गई सेवाएं, इस कोड सीखने की लैब के लिए खास तौर पर बनाई गई हैं. ज़्यादा जानकारी के लिए, हर प्रॉडक्ट का दस्तावेज़ देखें:

  • Cloud Memorystore के लिए इंस्टेंस की ज़रूरत होती है. साथ ही, इसका इस्तेमाल बिना किसी शुल्क के नहीं किया जा सकता. इस्तेमाल करने पर लगने वाले शुल्क के बारे में ज़्यादा जानने के लिए, इसका कीमत वाला पेज देखें.
  • क्लाउड सर्वर के बिना वीपीसी ऐक्सेस करने की सुविधा वाले कनेक्टर के लिए इंस्टेंस की ज़रूरत होती है. साथ ही, इसके लिए कोई मुफ़्त टियर उपलब्ध नहीं है. इस्तेमाल करने के शुल्क के बारे में ज़्यादा जानने के लिए, Cloud VPC की कीमत वाले पेज पर इसका सेक्शन देखें.
  • Cloud Datastore (Cloud Firestore in Datastore mode) का इस्तेमाल बिना किसी शुल्क के किया जा सकता है. ज़्यादा जानकारी के लिए, कीमत की जानकारी देने वाला पेज देखें.

इस ट्यूटोरियल में, चार Cloud प्रॉडक्ट का इस्तेमाल किया गया है:

  • App Engine
  • Cloud Datastore
  • Cloud Memorystore
  • Cloud VPC

इन संसाधनों को रिलीज़ करने और बिलिंग के शुल्क से बचने/उसे कम करने के लिए, यहां दिए गए निर्देशों का पालन करें.

Memorystore इंस्टेंस और वीपीसी कनेक्टर बंद करना

ये ऐसे प्रॉडक्ट हैं जिनके लिए फ़्री टियर उपलब्ध नहीं है. इसलिए, आपको अभी बिलिंग का सामना करना पड़ रहा है. अगर आपको अपना Cloud प्रोजेक्ट बंद नहीं करना है, तो बिलिंग रोकने के लिए आपको अपना Memorystore इंस्टेंस और वीपीसी कनेक्टर, दोनों मिटाने होंगे. इसके बारे में अगले सेक्शन में बताया गया है. इन संसाधनों को बनाने के दौरान, आपने इन्हें जिस तरह से रिलीज़ किया था उसी तरह से इन्हें Cloud Console या कमांड-लाइन से भी रिलीज़ किया जा सकता है.

Cloud Console से

Memorystore इंस्टेंस को मिटाने के लिए, Memorystore डैशबोर्ड पर वापस जाएं और इंस्टेंस आईडी पर क्लिक करें:

2b09baf1aa2e0a25.png

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

f9d9eb1c1d4c6107.png

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

ca5fbd9f4c7c9b60.png

कमांड-लाइन से

gcloud की यहां दी गई कमांड के पेयर से, Memorystore इंस्टेंस और वीपीसी कनेक्टर, दोनों मिट जाते हैं:

  • 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 है और वीपीसी कनेक्टर का नाम 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 प्रोजेक्ट बंद करना है, तो इन चरणों को पूरा करना ज़रूरी नहीं है. हालांकि, प्रोजेक्ट बंद होने तक आपसे बिलिंग की जाएगी.

अगले चरण

इस ट्यूटोरियल के अलावा, माइग्रेशन के अन्य मॉड्यूल भी उपलब्ध हैं. इनमें लेगसी बंडल की गई सेवाओं से माइग्रेट करने पर फ़ोकस किया गया है. इनमें ये शामिल हैं:

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

  • App Engine से Cloud Functions पर माइग्रेट करना: मॉड्यूल 11 देखें
  • App Engine से Cloud Run पर माइग्रेट करना: Docker की मदद से अपने ऐप्लिकेशन को कंटेनर में बदलने के लिए, मॉड्यूल 4 देखें. इसके अलावा, कंटेनर, Docker की जानकारी या Dockerfile के बिना ऐसा करने के लिए, मॉड्यूल 5 देखें

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

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

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

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

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

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

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

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

कोडलैब

Python 2

Python 3

Module 12

code

code

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

code

code

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

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

App Engine

App Engine NDB और Cloud NDB

App Engine Memcache और Cloud Memorystore

Cloud VPC

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

लाइसेंस

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