1. खास जानकारी
कोडलैब की इस सीरीज़ (अपनी रफ़्तार से सीखने और खुद करके देखने वाले ट्यूटोरियल) का मकसद, Google App Engine (स्टैंडर्ड एनवायरमेंट) डेवलपर की मदद करना है. इससे वे अपने ऐप्लिकेशन को बेहतर बना पाएंगे. इसके लिए, उन्हें माइग्रेशन की सीरीज़ के बारे में जानकारी दी जाएगी. सबसे ज़रूरी कदम यह है कि ओरिजनल रनटाइम बंडल की गई सेवाओं को बंद कर दिया जाए. ऐसा इसलिए, क्योंकि अगली जनरेशन के रनटाइम ज़्यादा बेहतर होते हैं. इनसे उपयोगकर्ताओं को सेवा के ज़्यादा विकल्प मिलते हैं. नई जनरेशन के रनटाइम पर माइग्रेट करने से, Google Cloud के प्रॉडक्ट के साथ आसानी से इंटिग्रेट किया जा सकता है. साथ ही, ज़्यादा सेवाओं का इस्तेमाल किया जा सकता है और भाषा के मौजूदा वर्शन का इस्तेमाल किया जा सकता है.
यह वैकल्पिक ट्यूटोरियल, डेवलपर को Cloud NDB से Cloud Datastore पर माइग्रेट करने का तरीका दिखाता है. ऐसा इसलिए, ताकि वे Datastore सेवा से कम्यूनिकेट करने के लिए क्लाइंट लाइब्रेरी का इस्तेमाल कर सकें. जिन डेवलपर को NDB का इस्तेमाल करना है वे इसका इस्तेमाल जारी रख सकते हैं, क्योंकि यह Python 3 के साथ काम करता है. इसलिए, माइग्रेट करना ज़रूरी नहीं है. यह माइग्रेशन सिर्फ़ उन लोगों के लिए है जो Cloud Datastore का इस्तेमाल करने वाले अन्य ऐप्लिकेशन के साथ, एक जैसा कोडबेस और शेयर की गई लाइब्रेरी बनाना चाहते हैं. इस बारे में "बैकग्राउंड" सेक्शन में बताया गया है.
आपको इनके बारे में जानकारी मिलेगी
- Cloud NDB का इस्तेमाल करें (अगर आपको इसके बारे में जानकारी नहीं है)
- Cloud NDB से Cloud Datastore पर माइग्रेट करना
- अपने ऐप्लिकेशन को Python 3 पर माइग्रेट करना
आपको इन चीज़ों की ज़रूरत होगी
- Google Cloud Platform प्रोजेक्ट, जिसमें चालू GCP बिलिंग खाता हो
- Python की बुनियादी जानकारी
- Linux की बुनियादी कमांड के बारे में जानकारी होना
- App Engine ऐप्लिकेशन डेवलप और डिप्लॉय करने की बुनियादी जानकारी
- काम करने वाला Module 2 App Engine 2.x या 3.x ऐप्लिकेशन.
सर्वे
इस कोडलैब का इस्तेमाल कैसे किया जाएगा?
2. बैकग्राउंड
Cloud NDB, App Engine डेवलपर के लिए Datastore का एक बेहतरीन समाधान है. इससे Python 3 पर स्विच करने में भी मदद मिलती है. हालांकि, App Engine डेवलपर के पास Datastore को ऐक्सेस करने का सिर्फ़ यही तरीका नहीं है. जब App Engine के Datastore को 2013 में एक अलग प्रॉडक्ट के तौर पर लॉन्च किया गया, तब Google Cloud Datastore के लिए एक नई क्लाइंट लाइब्रेरी बनाई गई, ताकि सभी उपयोगकर्ता Datastore का इस्तेमाल कर सकें.
Python 3 App Engine और non-App Engine डेवलपर को Cloud Datastore (Cloud NDB नहीं) का इस्तेमाल करने के लिए कहा जाता है. Python 2 App Engine डेवलपर को ndb से Cloud NDB पर माइग्रेट करने और वहाँ से Python 3 पर पोर्ट करने का सुझाव दिया जाता है. हालाँकि, वे चाहें, तो Cloud Datastore पर भी माइग्रेट कर सकते हैं. यह एक सही फ़ैसला है. खास तौर पर, उन डेवलपर के लिए जिनके पास पहले से ही Cloud Datastore का इस्तेमाल करने वाला कोड है. जैसे, ऊपर बताए गए कोड. साथ ही, वे अपने सभी ऐप्लिकेशन में शेयर की गई लाइब्रेरी बनाना चाहते हैं. कोड को दोबारा इस्तेमाल करना और कोड में एकरूपता बनाए रखना, सबसे सही तरीका है. इससे रखरखाव की कुल लागत कम होती है. इसके बारे में यहां बताया गया है:
Cloud NDB से Cloud Datastore पर माइग्रेट करना
- इससे डेवलपर, Datastore को ऐक्सेस करने के लिए एक ही कोडबेस पर फ़ोकस कर पाते हैं
- Cloud NDB का इस्तेमाल करके कुछ कोड और Cloud Datastore का इस्तेमाल करके अन्य कोड को बनाए रखने से बचाता है
- इससे कोडबेस में ज़्यादा एकरूपता मिलती है और कोड को फिर से इस्तेमाल करने की सुविधा बेहतर होती है
- इससे सामान्य/शेयर की गई लाइब्रेरी का इस्तेमाल किया जा सकता है. इससे रखरखाव की कुल लागत कम हो जाती है
इस माइग्रेशन में ये मुख्य चरण शामिल हैं:
- सेटअप/प्रीवर्क
- Cloud NDB को Cloud Datastore की क्लाइंट लाइब्रेरी से बदलना
- ऐप्लिकेशन अपडेट करें
3. सेटअप/प्रीवर्क
ट्यूटोरियल के मुख्य हिस्से को शुरू करने से पहले, आइए हम अपना प्रोजेक्ट सेट अप करें, कोड पाएं, और फिर बेसलाइन ऐप्लिकेशन को डिप्लॉय करें. इससे हमें पता चलेगा कि हमने काम करने वाले कोड से शुरुआत की है.
1. प्रोजेक्ट सेट अप करना
अगर आपने Module 2 codelab पूरा कर लिया है, तो हमारा सुझाव है कि आप उसी प्रोजेक्ट और कोड का फिर से इस्तेमाल करें. इसके अलावा, एक नया प्रोजेक्ट बनाया जा सकता है या किसी मौजूदा प्रोजेक्ट का फिर से इस्तेमाल किया जा सकता है. पक्का करें कि प्रोजेक्ट में, बिलिंग के लिए ऐक्टिव खाता हो और App Engine (ऐप्लिकेशन) चालू हो.
2. बेसलाइन सैंपल ऐप्लिकेशन पाना
ज़रूरी शर्तों में से एक यह है कि आपके पास मॉड्यूल 2 का सैंपल ऐप्लिकेशन होना चाहिए. अगर आपने वह ट्यूटोरियल पूरा कर लिया है, तो अपने समाधान का इस्तेमाल करें. इसे अभी पूरा किया जा सकता है (ऊपर दिया गया लिंक) या अगर आपको इसे छोड़ना है, तो मॉड्यूल 2 की रेपो कॉपी करें (नीचे दिया गया लिंक).
चाहे आपने अपना कोड इस्तेमाल किया हो या हमारा, हम मॉड्यूल 2 के कोड से शुरुआत करेंगे. इस तीसरे मॉड्यूल के कोडलैब में, आपको हर चरण के बारे में बताया गया है. इसे पूरा करने के बाद, यह कोड FINISH पॉइंट पर मौजूद कोड जैसा दिखना चाहिए. इस ट्यूटोरियल के Python 2 और 3 वर्शन उपलब्ध हैं. इसलिए, नीचे दिए गए सही कोड रिपो को चुनें.
Python 2
- START: Module 2 code
- पूरा करें: मॉड्यूल 3 का कोड
- पूरी रीपो (क्लोन करने या ZIP फ़ाइल डाउनलोड करने के लिए)
Python 2 Module 2 की STARTing फ़ाइलों (आपकी या हमारी) की डायरेक्ट्री ऐसी दिखनी चाहिए:
$ ls
README.md appengine_config.py requirements.txt
app.yaml main.py templates
अगर आपने मॉड्यूल 2 का ट्यूटोरियल पूरा कर लिया है, तो आपके पास Flask और उसकी डिपेंडेंसी वाला lib फ़ोल्डर भी होगा. अगर आपके पास lib फ़ोल्डर नहीं है, तो pip install -t lib -r requirements.txt कमांड का इस्तेमाल करके इसे बनाएं, ताकि हम अगले चरण में इस बेसलाइन ऐप्लिकेशन को डिप्लॉय कर सकें. अगर आपने Python 2 और 3, दोनों इंस्टॉल किए हैं, तो हमारा सुझाव है कि Python 3 के साथ भ्रम से बचने के लिए, pip के बजाय pip2 का इस्तेमाल करें.
Python 3
- शुरू करें: मॉड्यूल 2 की रेपो
- पूरा करें: मॉड्यूल 3 की रेपो
- पूरी रीपो (क्लोन करने या ZIP फ़ाइल डाउनलोड करने के लिए)
Python 3 Module 2 की STARTing फ़ाइलों (आपकी या हमारी) की डायरेक्ट्री ऐसी दिखनी चाहिए:
$ ls
README.md main.py templates
app.yaml requirements.txt
Python 3 के लिए, न तो lib और न ही appengine_config.py का इस्तेमाल किया जाता है.
3. मॉड्यूल 2 ऐप्लिकेशन को (फिर से) डिप्लॉय करना
अब आपको ये काम करने हैं:
gcloudकमांड-लाइन टूल के बारे में फिर से जानें (अगर ज़रूरी हो)- App Engine पर मॉड्यूल 1 कोड को (फिर से) डिप्लॉय करें (अगर ज़रूरी हो)
इन चरणों को पूरा करने और यह पुष्टि करने के बाद कि यह काम कर रहा है, हम इस ट्यूटोरियल में आगे बढ़ेंगे. हम कॉन्फ़िगरेशन फ़ाइलों से शुरुआत करेंगे.
4. Cloud NDB को Cloud Datastore की क्लाइंट लाइब्रेरी से बदलना
कॉन्फ़िगरेशन में सिर्फ़ एक छोटा सा बदलाव किया गया है. आपकी requirements.txt फ़ाइल में पैकेज बदला गया है.
1. requirements.txt को अपडेट करें
मॉड्यूल 2 पूरा करने के बाद, आपकी requirements.txt फ़ाइल ऐसी दिख रही थी:
- पहले (Python 2 और 3):
Flask==1.1.2
google-cloud-ndb==1.7.1
Cloud NDB लाइब्रेरी (google-cloud-ndb) को Cloud Datastore लाइब्रेरी (google-cloud-datastore) के नए वर्शन से बदलकर, requirements.txt को अपडेट करें. Flask के लिए एंट्री को वैसे ही रहने दें. ध्यान रखें कि Cloud Datastore का आखिरी वर्शन, Python 2 के साथ काम करने वाला 1.15.3 है:
- AFTER (Python 2):
Flask==1.1.2
google-cloud-datastore==1.15.3
- AFTER (Python 3):
Flask==1.1.2
google-cloud-datastore==2.1.0
ध्यान रखें कि इस ट्यूटोरियल के मुकाबले, रेपो को ज़्यादा बार अपडेट किया जाता है. इसलिए, ऐसा हो सकता है कि requirements.txt फ़ाइल में नए वर्शन दिखें. हमारा सुझाव है कि हर लाइब्रेरी के नए वर्शन का इस्तेमाल करें. हालांकि, अगर वे काम नहीं करते हैं, तो पुराने वर्शन पर वापस जाया जा सकता है. ऊपर दिए गए वर्शन नंबर, इस कोडलैब को आखिरी बार अपडेट किए जाने के समय के हिसाब से सबसे नए हैं.
2. अन्य कॉन्फ़िगरेशन फ़ाइलें
अन्य कॉन्फ़िगरेशन फ़ाइलों, app.yaml और appengine_config.py में पिछले माइग्रेशन चरण के मुकाबले कोई बदलाव नहीं होना चाहिए:
app.yamlको अब भी तीसरे पक्ष के बंडल किए गए पैकेजgrpcioऔरsetuptoolsका रेफ़रंस देना होगा.appengine_config.pyकोlibमें मौजूद तीसरे पक्ष के संसाधनों के लिए,pkg_resourcesऔरgoogle.appengine.ext.vendorको अब भी पॉइंट करना चाहिए.
अब ऐप्लिकेशन फ़ाइलों पर जाते हैं.
5. ऐप्लिकेशन की फ़ाइलें अपडेट करना
template/index.html में कोई बदलाव नहीं हुआ है. हालांकि, main.py के लिए कुछ अपडेट उपलब्ध हैं.
1. आयात
इंपोर्ट सेक्शन का शुरुआती कोड ऐसा दिखना चाहिए:
- BEFORE:
from flask import Flask, render_template, request
from google.cloud import ndb
google.cloud.ndb इंपोर्ट को Cloud Datastore के लिए इंपोर्ट से बदलें: google.cloud.datastore. Datastore क्लाइंट लाइब्रेरी, किसी इकाई में टाइमस्टैंप फ़ील्ड के अपने-आप बनने की सुविधा के साथ काम नहीं करती है. इसलिए, इसे मैन्युअल तरीके से बनाने के लिए, स्टैंडर्ड लाइब्रेरी datetime मॉड्यूल भी इंपोर्ट करें. परंपरा के मुताबिक, स्टैंडर्ड लाइब्रेरी के इंपोर्ट, तीसरे पक्ष के पैकेज के इंपोर्ट से ऊपर जाते हैं. ये बदलाव करने के बाद, यह इस तरह दिखेगा:
- AFTER:
from datetime import datetime
from flask import Flask, render_template, request
from google.cloud import datastore
2. डेटा मॉडल और उसे शुरू करना
Flask को शुरू करने के बाद, मॉड्यूल 2 का सैंपल ऐप्लिकेशन, NDB डेटा मॉडल क्लास और उसके फ़ील्ड इस तरह दिखते हैं:
- BEFORE:
app = Flask(__name__)
ds_client = ndb.Client()
class Visit(ndb.Model):
visitor = ndb.StringProperty()
timestamp = ndb.DateTimeProperty(auto_now_add=True)
Cloud Datastore लाइब्रेरी में ऐसी कोई क्लास नहीं है. इसलिए, Visit क्लास के एलान को मिटा दें. Datastore से कम्यूनिकेट करने के लिए, आपको अब भी क्लाइंट की ज़रूरत होगी. इसलिए, ndb.Client() को datastore.Client() में बदलें. Datastore लाइब्रेरी ज़्यादा "लचीली" है. इससे NDB की तरह, स्ट्रक्चर को "पहले से तय किए बिना" इकाइयां बनाई जा सकती हैं. इस अपडेट के बाद, main.py का यह हिस्सा ऐसा दिखेगा:
- AFTER:
app = Flask(__name__)
ds_client = datastore.Client()
3. Datastore का ऐक्सेस
Cloud Datastore पर माइग्रेट करने के लिए, आपको Datastore इकाइयों को बनाने, सेव करने, और क्वेरी करने के तरीके में बदलाव करना होगा. यह बदलाव उपयोगकर्ता-लेवल पर करना होगा. आपके ऐप्लिकेशन के लिए, इस माइग्रेशन की मुश्किल काफ़ी हद तक इस बात पर निर्भर करती है कि आपका Datastore कोड कितना जटिल है. हमारे सैंपल ऐप्लिकेशन में, हमने अपडेट को जितना हो सके उतना आसान बनाने की कोशिश की है. यहां हमारा शुरुआती कोड दिया गया है:
- BEFORE:
def store_visit(remote_addr, user_agent):
with ds_client.context():
Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()
def fetch_visits(limit):
with ds_client.context():
return (v.to_dict() for v in Visit.query().order(
-Visit.timestamp).fetch_page(limit)[0])
Cloud Datastore की मदद से, एक सामान्य इकाई बनाएं. इसमें "key" का इस्तेमाल करके, अपनी इकाई में ग्रुप किए गए ऑब्जेक्ट की पहचान करें. की-वैल्यू पेयर के JSON ऑब्जेक्ट (Python dict) के साथ डेटा रिकॉर्ड बनाएं. इसके बाद, इसे Datastore में put() के साथ लिखें. क्वेरी करने का तरीका एक जैसा होता है, लेकिन Datastore में यह ज़्यादा आसान होता है. यहां देखें कि Datastore का मिलता-जुलता कोड किस तरह अलग है:
- AFTER:
def store_visit(remote_addr, user_agent):
entity = datastore.Entity(key=ds_client.key('Visit'))
entity.update({
'timestamp': datetime.now(),
'visitor': '{}: {}'.format(remote_addr, user_agent),
})
ds_client.put(entity)
def fetch_visits(limit):
query = ds_client.query(kind='Visit')
query.order = ['-timestamp']
return query.fetch(limit=limit)
ऊपर दिए गए तरीके से, store_visit() और fetch_visits() के फ़ंक्शन बॉडी को अपडेट करें. साथ ही, यह ध्यान रखें कि उनके सिग्नेचर पिछले वर्शन के जैसे ही हों. मुख्य हैंडलर root() में कोई बदलाव नहीं किया गया है. ये बदलाव करने के बाद, आपका ऐप्लिकेशन अब Cloud Datastore का इस्तेमाल कर सकता है और टेस्ट करने के लिए तैयार है.
6. खास जानकारी/सफ़ाई
ऐप्लिकेशन डिप्लॉय करना
gcloud app deploy की मदद से, अपने ऐप्लिकेशन को फिर से डिप्लॉय करें. साथ ही, पुष्टि करें कि ऐप्लिकेशन काम कर रहा है. आपका कोड अब Module 3 repo फ़ोल्डर में मौजूद कोड से मेल खाना चाहिए:
अगर आपने इस सीरीज़ में, पहले के किसी भी कोडलैब को पूरा किए बिना हिस्सा लिया है, तो ऐप्लिकेशन में कोई बदलाव नहीं होता. यह मुख्य वेब पेज (/) पर आने वाले सभी लोगों को रजिस्टर करता है. साइट पर कई बार जाने के बाद, यह इस तरह दिखता है:

तीसरे मॉड्यूल का कोडलैब पूरा करने के लिए बधाई. अब आपको पता है कि Datastore को ऐक्सेस करने के लिए, Cloud NDB और Cloud Datastore, दोनों क्लाइंट लाइब्रेरी का इस्तेमाल किया जा सकता है. बाद वाले वर्शन पर माइग्रेट करने से, अब आपको शेयर की गई लाइब्रेरी, सामान्य कोड, और कोड को फिर से इस्तेमाल करने के फ़ायदे मिल सकते हैं. इससे, एक जैसा अनुभव मिलता है और रखरखाव की लागत कम हो जाती है.
ज़रूरी नहीं: साफ़ करना
जब तक आप माइग्रेशन के अगले कोडलैब पर जाने के लिए तैयार नहीं हो जाते, तब तक बिलिंग से बचने के लिए क्या किया जा सकता है? मौजूदा डेवलपर के तौर पर, आपको App Engine की कीमत से जुड़ी जानकारी के बारे में पहले से ही पता होगा.
ज़रूरी नहीं: ऐप्लिकेशन बंद करना
अगर आपको अभी अगले ट्यूटोरियल पर नहीं जाना है, तो शुल्क से बचने के लिए अपने ऐप्लिकेशन को बंद करें. जब आपको अगले कोडलैब पर जाना हो, तब इसे फिर से चालू किया जा सकता है. जब आपका ऐप्लिकेशन बंद होता है, तब उसे कोई ट्रैफ़िक नहीं मिलता. इसलिए, आपसे कोई शुल्क नहीं लिया जाता. हालांकि, अगर मुफ़्त कोटे से ज़्यादा Datastore का इस्तेमाल किया जाता है, तो आपसे शुल्क लिया जा सकता है. इसलिए, इतना डेटा मिटाएं कि वह सीमा के अंदर आ जाए.
दूसरी ओर, अगर आपको माइग्रेशन जारी नहीं रखना है और आपको सब कुछ पूरी तरह से मिटाना है, तो अपना प्रोजेक्ट बंद करें.
अगले चरण
यहां से, माइग्रेशन के इन अगले मॉड्यूल को एक्सप्लोर करें:
- मॉड्यूल 3 का बोनस: बोनस सेक्शन पर जाकर, Python 3 और App Engine के नए जनरेशन के रनटाइम पर पोर्ट करने का तरीका जानें.
- मॉड्यूल 7: App Engine की पुश टास्क कतारें (अगर [push] टास्क कतारों का इस्तेमाल किया जाता है, तो यह ज़रूरी है)
- App Engine
taskqueueपुश टास्क को Module 1 ऐप्लिकेशन में जोड़ता है - यह मॉड्यूल, उपयोगकर्ताओं को मॉड्यूल 8 में Cloud Tasks पर माइग्रेट करने के लिए तैयार करता है
- App Engine
- मॉड्यूल 4: Docker का इस्तेमाल करके Cloud Run पर माइग्रेट करना
- Docker की मदद से, अपने ऐप्लिकेशन को कंटेनर में बदलें, ताकि उसे Cloud Run पर चलाया जा सके
- इससे Python 2 पर बने रहने की अनुमति मिलती है
- पांचवां मॉड्यूल: Cloud Buildpacks की मदद से Cloud Run पर माइग्रेट करना
- Cloud Buildpacks की मदद से, अपने ऐप्लिकेशन को कंटेनर में बदलें, ताकि उसे Cloud Run पर चलाया जा सके
- Docker, कंटेनर या
Dockerfileके बारे में कुछ भी जानने की ज़रूरत नहीं है - इसके लिए, यह ज़रूरी है कि आपने अपने ऐप्लिकेशन को पहले ही Python 3 पर माइग्रेट कर लिया हो
- मॉड्यूल 6: Cloud Firestore पर माइग्रेट करना
- Firebase की सुविधाओं को ऐक्सेस करने के लिए, Cloud Firestore पर माइग्रेट करना
- Cloud Firestore, Python 2 के साथ काम करता है. हालांकि, यह कोडलैब सिर्फ़ Python 3 में उपलब्ध है.
7. बोनस: Python 3 पर माइग्रेट करना
हमारा सुझाव है कि App Engine के नए रनटाइम और सुविधाओं का ऐक्सेस पाने के लिए, Python 3 पर माइग्रेट करें. हमारे सैंपल ऐप्लिकेशन में, हमने सिर्फ़ Datastore का इस्तेमाल किया था. यह एक बिल्ट-इन सेवा है. अब हम ndb से Cloud NDB पर माइग्रेट हो गए हैं. इसलिए, अब हम App Engine के Python 3 रनटाइम पर पोर्ट कर सकते हैं.
खास जानकारी
Python 3 में पोर्ट करने का तरीका, Google Cloud के ट्यूटोरियल में शामिल नहीं है. हालांकि, इस कोडलैब के इस हिस्से से डेवलपर को यह पता चलता है कि Python 3 App Engine रनटाइम, Python 2 App Engine रनटाइम से किस तरह अलग है. अगली जनरेशन के रनटाइम की एक खास सुविधा यह है कि तीसरे पक्ष के पैकेज को आसानी से ऐक्सेस किया जा सकता है: app.yaml में बिल्ट-इन पैकेज के बारे में बताने की ज़रूरत नहीं है. साथ ही, नॉन-बिल्ट-इन लाइब्रेरी को कॉपी या अपलोड करने की भी ज़रूरत नहीं है. requirements.txt में लिस्ट होने पर, ये अपने-आप इंस्टॉल हो जाती हैं.
हमारा सैंपल बहुत बुनियादी है और Cloud Datastore, Python 2-3 के साथ काम करता है. इसलिए, किसी भी ऐप्लिकेशन कोड को 3.x में पोर्ट करने की ज़रूरत नहीं है: ऐप्लिकेशन, 2.x और 3.x पर बिना किसी बदलाव के चलता है. इसका मतलब है कि इस मामले में, सिर्फ़ कॉन्फ़िगरेशन में बदलाव करने की ज़रूरत है:
- Python 3 को रेफ़रंस देने और बंडल की गई तीसरे पक्ष की लाइब्रेरी के रेफ़रंस को हटाने के लिए,
app.yamlको आसान बनाया गया है. appengine_config.pyऔरlibफ़ोल्डर को मिटा दें, क्योंकि अब इनकी ज़रूरत नहीं है.
main.py और templates/index.html ऐप्लिकेशन फ़ाइलों में कोई बदलाव नहीं किया जाता.
requirements.txt को अपडेट करें
Python 2 के साथ काम करने वाला Cloud Datastore का आखिरी वर्शन 1.15.3 है. requirements.txt को Python 3 के नए वर्शन में अपडेट करें. ऐसा हो सकता है कि अब यह नया वर्शन उपलब्ध हो. जब यह ट्यूटोरियल लिखा गया था, तब इसका नया वर्शन 2.1.0 था. इसलिए, उस लाइन में बदलाव करके उसे इस तरह बनाएं (या जो भी नया वर्शन हो):
google-cloud-datastore==2.1.0
app.yaml को आसान बनाएं
BEFORE:
इस सैंपल ऐप्लिकेशन में सिर्फ़ एक बदलाव किया गया है. इसमें app.yaml को छोटा किया गया है. आपको याद दिलाने के लिए, यहां बताया गया है कि app.yaml में मॉड्यूल 3 के आखिर में क्या था:
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
AFTER:
Python 3 में, threadsafe, api_version, और libraries डायरेक्टिव अब काम नहीं करते. सभी ऐप्लिकेशन को थ्रेडसेफ़ माना जाता है और Python 3 में api_version का इस्तेमाल नहीं किया जाता. App Engine की सेवाओं पर, तीसरे पक्ष के पहले से इंस्टॉल किए गए पैकेज अब उपलब्ध नहीं हैं. इसलिए, libraries को भी बंद कर दिया गया है. इन बदलावों के बारे में ज़्यादा जानने के लिए, app.yaml में हुए बदलावों के बारे में जानकारी देने वाला दस्तावेज़ देखें. इसलिए, आपको app.yaml से इन तीनों को मिटा देना चाहिए. साथ ही, Python 3 के ऐसे वर्शन पर अपडेट करना चाहिए जिस पर यह सुविधा काम करती है. इसके बारे में यहां बताया गया है.
ज़रूरी नहीं: handlers डायरेक्टिव का इस्तेमाल करना
इसके अलावा, handlers डायरेक्टिव को भी बंद कर दिया गया है. यह डायरेक्टिव, App Engine ऐप्लिकेशन पर ट्रैफ़िक को रीडायरेक्ट करता है. नेक्स्ट-जनरेशन रनटाइम को वेब फ़्रेमवर्क से ऐप्लिकेशन राउटिंग मैनेज करने की उम्मीद होती है. इसलिए, सभी "हैंडलर स्क्रिप्ट" को "auto" में बदलना होगा. ऊपर दिए गए बदलावों को मिलाकर, आपको यह app.yaml मिलता है:
runtime: python38
handlers:
- url: /.*
script: auto
app.yaml रेफ़रंस पेज पर जाकर, script: auto के बारे में ज़्यादा जानें.
handlers डायरेक्टिव हटाया जा रहा है
handlers का इस्तेमाल अब नहीं किया जा सकता. इसलिए, पूरे सेक्शन को भी हटाया जा सकता है. इसके बाद, सिर्फ़ एक लाइन वाला app.yaml दिखेगा:
runtime: python38
डिफ़ॉल्ट रूप से, इससे Gunicorn WSGI वेब सर्वर लॉन्च होगा. यह सभी ऐप्लिकेशन के लिए उपलब्ध है. अगर आपको gunicorn के बारे में पता है, तो यह कमांड तब लागू होती है, जब इसे डिफ़ॉल्ट रूप से app.yaml के साथ शुरू किया जाता है:
gunicorn main:app --workers 2 -c /config/gunicorn.py
ज़रूरी नहीं: entrypoint डायरेक्टिव का इस्तेमाल करना
हालांकि, अगर आपके ऐप्लिकेशन को शुरू करने के लिए किसी खास कमांड की ज़रूरत है, तो उसे entrypoint डायरेक्टिव के साथ तय किया जा सकता है. इससे app.yaml इस तरह दिखेगा:
runtime: python38
entrypoint: python main.py
इस उदाहरण में, खास तौर पर gunicorn के बजाय Flask डेवलपमेंट सर्वर का इस्तेमाल करने का अनुरोध किया गया है. डेवलपमेंट सर्वर को शुरू करने वाले कोड को भी आपके ऐप्लिकेशन में जोड़ा जाना चाहिए, ताकि इसे पोर्ट 8080 पर 0.0.0.0 इंटरफ़ेस पर लॉन्च किया जा सके. इसके लिए, main.py के सबसे नीचे यह छोटा सेक्शन जोड़ें:
if __name__ == '__main__':
app.run(host='0.0.0.0', port=8080, debug=True)
app.yaml रेफ़रंस पेज पर जाकर, entrypoint के बारे में ज़्यादा जानें. ज़्यादा उदाहरण और सबसे सही तरीके, App Engine स्टैंडर्ड एनवायरमेंट के स्टार्टअप दस्तावेज़ और App Engine फ़्लेक्सिबल एनवायरमेंट के स्टार्टअप दस्तावेज़ में देखे जा सकते हैं.
appengine_config.py और lib मिटाएं
appengine_config.py फ़ाइल और lib फ़ोल्डर मिटाएं. Python 3 पर माइग्रेट करते समय, App Engine, requirements.txt में दिए गए पैकेज को हासिल करता है और उन्हें इंस्टॉल करता है.
appengine_config.py कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल, तीसरे पक्ष की लाइब्रेरी/पैकेज की पहचान करने के लिए किया जाता है. भले ही, आपने उन्हें खुद कॉपी किया हो या App Engine सर्वर पर पहले से उपलब्ध (बिल्ट-इन) लाइब्रेरी/पैकेज का इस्तेमाल किया हो. Python 3 पर माइग्रेट करते समय, मुख्य बदलावों की खास जानकारी यहां दी गई है:
- कॉपी की गई तीसरे पक्ष की लाइब्रेरी (
requirements.txtमें दी गई) को बंडल नहीं किया गया हो pip installकोlibफ़ोल्डर में नहीं ले जाया जा सकता. इसका मतलब है किlibफ़ोल्डर नहीं बनाया जा सकताapp.yamlमें, तीसरे पक्ष की कोई भी लाइब्रेरी शामिल नहीं है- ऐप्लिकेशन को तीसरे पक्ष की लाइब्रेरी से जोड़ने की ज़रूरत नहीं है. इसलिए, कोई
appengine_config.pyफ़ाइल नहीं है
requirements.txt में तीसरे पक्ष की सभी ज़रूरी लाइब्रेरी की सूची देना ही काफ़ी है.
ऐप्लिकेशन डिप्लॉय करना
अपने ऐप्लिकेशन को फिर से डिप्लॉय करें, ताकि यह पक्का किया जा सके कि वह काम कर रहा है. यह भी पुष्टि की जा सकती है कि आपका समाधान, मॉड्यूल 3 के सैंपल Python 3 कोड के कितना करीब है. Python 2 के साथ अंतर देखने के लिए, कोड की तुलना इसके Python 2 वर्शन से करें.
मॉड्यूल 3 में बोनस चरण पूरा करने के लिए बधाई! Python 3 रनटाइम के लिए कॉन्फ़िगरेशन फ़ाइलें तैयार करने से जुड़े दस्तावेज़ पढ़ें. आखिर में, ऊपर दी गई खास जानकारी देखें. इससे आपको अगले चरणों और डेटा को हटाने के बारे में पता चलेगा.
आपके आवेदन को तैयार किया जा रहा है
जब आपके ऐप्लिकेशन को माइग्रेट करने का समय आएगा, तब आपको अपनी main.py और अन्य ऐप्लिकेशन फ़ाइलों को 3.x पर पोर्ट करना होगा. इसलिए, सबसे सही तरीका यह है कि आप अपने 2.x ऐप्लिकेशन को ज़्यादा से ज़्यादा "फ़ॉरवर्ड-कंपैटिबल" बनाने की पूरी कोशिश करें.
इंटरनेट पर ऐसे कई संसाधन उपलब्ध हैं जिनसे आपको यह काम पूरा करने में मदद मिल सकती है. हालांकि, यहां कुछ अहम सलाह दी गई हैं:
- पक्का करें कि ऐप्लिकेशन की सभी डिपेंडेंसी, 3.x वर्शन के साथ पूरी तरह से काम करती हों
- पक्का करें कि आपका ऐप्लिकेशन कम से कम 2.6 (बेहतर होगा कि 2.7) पर काम करता हो
- पक्का करें कि ऐप्लिकेशन, टेस्ट के सभी चरणों को पूरा करता हो. साथ ही, कम से कम 80% कवरेज देता हो
six, Future, और/या Modernize जैसी कंपैटिबिलिटी लाइब्रेरी का इस्तेमाल करें- 2.x और 3.x वर्शन के बीच के मुख्य अंतरों के बारे में जानें
- किसी भी I/O से, यूनिकोड बनाम बाइट स्ट्रिंग से जुड़ी समस्याएं हो सकती हैं
इस सैंपल ऐप्लिकेशन को इन सभी बातों को ध्यान में रखकर डिज़ाइन किया गया है. इसलिए, यह ऐप्लिकेशन 2.x और 3.x पर तुरंत काम करता है, ताकि हम आपको यह दिखा सकें कि अगली जनरेशन के प्लैटफ़ॉर्म का इस्तेमाल करने के लिए, क्या बदलाव करने होंगे.
8. अन्य संसाधन
App Engine माइग्रेशन मॉड्यूल कोडलैब से जुड़ी समस्याएं/सुझाव/राय
अगर आपको इस कोडलैब में कोई समस्या मिलती है, तो कृपया शिकायत दर्ज करने से पहले अपनी समस्या खोजें. नई समस्याएं खोजने और बनाने के लिए लिंक:
माइग्रेशन के लिए उपलब्ध संसाधन
मॉड्यूल 2 (START) और मॉड्यूल 3 (FINISH) के लिए, रेपो फ़ोल्डर के लिंक यहां दी गई टेबल में देखे जा सकते हैं. इन्हें App Engine के सभी माइग्रेशन के लिए उपलब्ध रिपॉजिटरी से भी ऐक्सेस किया जा सकता है. इसे क्लोन किया जा सकता है या इसकी ZIP फ़ाइल डाउनलोड की जा सकती है.
कोडलैब | Python 2 | Python 3 |
Module 3 |
App Engine के संसाधन
इस माइग्रेशन के बारे में ज़्यादा जानकारी के लिए, यहां दिए गए संसाधन देखें:
- Python Cloud NDB और Cloud Datastore के रेफ़रंस
- Python 3 और GAE के अगली जनरेशन के रनटाइम पर माइग्रेट करना
- सामान्य