1. खास जानकारी
कोडलैब (अपने हिसाब से इस्तेमाल किए जाने वाले टूल) की इस सीरीज़ का मकसद, Google App Engine (स्टैंडर्ड) डेवलपर की मदद करना है, ताकि वे माइग्रेशन की सीरीज़ के ज़रिए अपने ऐप्लिकेशन को आधुनिक बनाने में उनका मार्गदर्शन करें. सबसे ज़रूरी चरण है, बंडल की गई ओरिजनल सेवाओं का इस्तेमाल न करना, क्योंकि अगली-पीढ़ी की टेक्नोलॉजी के रनटाइम ज़्यादा सुविधाजनक होते हैं. इससे उपयोगकर्ताओं को सेवाओं के कई विकल्प मिलते हैं. रनटाइम के नए वर्शन का इस्तेमाल करने पर, Google Cloud के प्रॉडक्ट के साथ आसानी से इंटिग्रेट किया जा सकता है. इसके अलावा, अलग-अलग तरह की सेवाओं का इस्तेमाल किया जा सकता है और मौजूदा भाषाओं में इसका इस्तेमाल किया जा सकता है.
इस ट्यूटोरियल में आपको App Engine की पहले से मौजूद ndb
(अगला डेटाबेस) क्लाइंट लाइब्रेरी से Cloud NDB क्लाइंट लाइब्रेरी में माइग्रेट करने का तरीका बताया गया है.
आपको इनके बारे में जानकारी मिलेगी
- App Engine
ndb
लाइब्रेरी का इस्तेमाल करें (अगर आप इससे अनजान हैं) ndb
से Cloud NDB पर माइग्रेट करें- इसके बाद, अपने ऐप्लिकेशन को Python 3 पर माइग्रेट करें
आपको इन चीज़ों की ज़रूरत होगी
- Python के बुनियादी हुनर
- सामान्य Linux कमांड के बारे में काम करने की जानकारी
- App Engine ऐप्लिकेशन डेवलप करने और डिप्लॉय करने की बुनियादी जानकारी
- चालू मॉड्यूल 1 App Engine ऐप्लिकेशन
सर्वे
इस कोडलैब का इस्तेमाल कैसे किया जाएगा?
2. बैकग्राउंड
मॉड्यूल 1 में, हमने वेब फ़्रेमवर्क को App Engine के बिल्ट-इन webapp2
से Flask पर माइग्रेट किया है. इस कोडलैब में, हम App Engine की ndb
लाइब्रेरी से Google Cloud NDB पर स्विच करके, App Engine में पहले से मौजूद सेवाओं का इस्तेमाल बंद करना जारी रखते हैं.
इस माइग्रेशन को पूरा करके, ये काम किए जा सकते हैं:
- Python 3 और अगली पीढ़ी के App Engine रनटाइम पर माइग्रेट करें
- Cloud Datastore पर माइग्रेट करना (गैर-App Engine ऐप्लिकेशन के लिए क्लाइंट लाइब्रेरी)
- अपने Python 2 (या 3) ऐप्लिकेशन को कंटेनर बनाना और Cloud Run पर माइग्रेट करना
- App Engine (पुश) टास्क की सूचियों का इस्तेमाल जोड़ें, फिर क्लाउड टास्क में माइग्रेट करें
लेकिन, अभी तक हमारी तरफ़ से कोई मदद नहीं मिली. अगले चरणों पर विचार करने से पहले, यह कोडलैब पूरा करें. इस ट्यूटोरियल के माइग्रेशन में ये मुख्य चरण शामिल हैं:
- सेटअप/प्रीवर्क
- Cloud NDB लाइब्रेरी जोड़ें
- ऐप्लिकेशन फ़ाइलें अपडेट करें
3. सेटअप/प्रीवर्क
ट्यूटोरियल के मुख्य हिस्से पर काम शुरू करने से पहले, आइए अपना प्रोजेक्ट सेटअप करें, कोड पाएं, और फिर बेसलाइन ऐप्लिकेशन डिप्लॉय करें, ताकि हमें पता चल सके कि हमने काम करने वाला कोड इस्तेमाल करना शुरू किया है.
1. प्रोजेक्ट सेटअप करें
अगर आपने मॉड्यूल 1 कोडलैब पूरा कर लिया है, तो हमारा सुझाव है कि आप उसी प्रोजेक्ट (और कोड) का फिर से इस्तेमाल करें. इसके अलावा, नया प्रोजेक्ट बनाया जा सकता है या किसी मौजूदा प्रोजेक्ट का फिर से इस्तेमाल किया जा सकता है. पक्का करें कि प्रोजेक्ट में एक चालू बिलिंग खाता हो और App Engine चालू हो.
2. बेसलाइन ऐप्लिकेशन का नमूना डाउनलोड करें
इसके लिए, ज़रूरी है कि आपके पास मॉड्यूल 1 का सैंपल ऐप्लिकेशन हो. अगर आपने यह ट्यूटोरियल पूरा कर लिया है, तो अपने समाधान का इस्तेमाल करें. इस प्रोसेस को अभी पूरा करें (ऊपर दिया गया लिंक) या अगर आपको इसे छोड़ना है, तो मॉड्यूल 1 रेपो को कॉपी करें (लिंक नीचे दिया गया है).
चाहे आप अपने या हमारे कोड का इस्तेमाल करें, हम मॉड्यूल 1 कोड का इस्तेमाल करके शुरुआत करेंगे. यह मॉड्यूल 2 कोडलैब आपको हर चरण पर ले जाता है. कोडलैब का यह मॉड्यूल पूरा हो जाने पर, यह FINISH पॉइंट पर मौजूद कोड जैसा होना चाहिए. इसमें Python 2 से 3 तक का वैकल्पिक "बोनस" पोर्ट भी शामिल है:
- START: मॉड्यूल 1 कोड
- FINISH: मॉड्यूल 2 Python 2 कोड (BONUS: Python 3 कोड)
- पूरा रेपो (क्लोन करने या ZIP डाउनलोड करने के लिए)
आपके STARTing Module 1 कोड फ़ोल्डर में निम्न सामग्री होनी चाहिए:
$ ls
README.md appengine_config.py requirements.txt
app.yaml main.py templates
अगर आपने मॉड्यूल 1 ट्यूटोरियल पूरा कर लिया है, तो आपके पास फ़्लास्क और उसकी डिपेंडेंसी के साथ एक lib
फ़ोल्डर भी होगा. अगर आपके पास कोई lib
फ़ोल्डर नहीं है, तो इसे pip install -t lib -r requirements.txt
निर्देश का इस्तेमाल करके बनाएं. इससे हम अगले चरण में इस बेसलाइन ऐप्लिकेशन को डिप्लॉय कर सकेंगे. अगर आपने Python 2 और 3, दोनों वर्शन इंस्टॉल किए हैं, तो हमारा सुझाव है कि आप pip
के बजाय pip2
का इस्तेमाल करें. इससे, Python 3 के साथ किसी तरह की भ्रम पैदा नहीं होती.
3. मॉड्यूल 1 ऐप्लिकेशन को फिर से डिप्लॉय करें
कार्रवाई से पहले, इन चरणों को पूरा करें:
gcloud
कमांड-लाइन टूल (अगर ज़रूरी हो) का इस्तेमाल करके खुद को फिर से जानें- (अगर ज़रूरी हो, तो) मॉड्यूल 1 कोड को App Engine पर फिर से डिप्लॉय करें
इन चरणों को पूरा करने और इसके काम होने की पुष्टि करने के बाद, हम इस ट्यूटोरियल में कॉन्फ़िगरेशन फ़ाइलों के बारे में बताएंगे.
4. कॉन्फ़िगरेशन फ़ाइलें अपडेट करें (Cloud NDB लाइब्रेरी जोड़ें)
कई मूल App Engine पहले से मौजूद सेवाएं उनके खुद के प्रॉडक्ट में बदल गई हैं और Datastore उनमें से एक है. फ़िलहाल, App Engine के अलावा अन्य ऐप्लिकेशन Cloud Datastore का इस्तेमाल कर सकते हैं. लंबे समय से ndb
का इस्तेमाल करने वाले लोगों के लिए, Google Cloud की टीम ने Cloud NDB क्लाइंट लाइब्रेरी बनाई है, ताकि Cloud Datastore से बात की जा सके. यह Python 2 और 3, दोनों के लिए उपलब्ध है.
आइए, पुष्टि करने वाली फ़ाइलों को अपडेट करते हैं, ताकि App Engine ndb
को Cloud NDB से बदला जा सके. इसके बाद, अपने ऐप्लिकेशन में बदलाव करें.
1. requirements.txt
को अपडेट करें
मॉड्यूल 1 में, हमारे ऐप्लिकेशन के लिए सिर्फ़ 'फ़्लास्क' ही बाहरी डिपेंडेंसी थी. अब हम Cloud NDB को जोड़ेंगे. मॉड्यूल 1 के आखिर में आपकी requirements.txt
फ़ाइल कुछ इस तरह दिखती थी:
- पहले:
Flask==1.1.2
App Engine ndb
से माइग्रेट करने के लिए, Cloud NDB लाइब्रेरी (google-cloud-ndb
) की ज़रूरत होती है. इसलिए, इसके पैकेज को requirements.txt
में जोड़ें.
- इसके बाद:
Flask==1.1.2
google-cloud-ndb==1.7.1
जब यह कोडलैब लिखा गया था, तब सबसे नया सुझाया गया वर्शन 1.7.1 है, लेकिन रेपो में requirements.txt
का नया वर्शन हो सकता है. हम हर लाइब्रेरी के सबसे नए वर्शन का सुझाव देते हैं. अगर वे काम नहीं करते हैं, तो किसी पुरानी रिलीज़ पर रोल बैक किया जा सकता है.
अगर आपके पास कोई फ़ोल्डर है और आपने अभी-अभी इसे ऊपर नहीं बनाया है, तो अपना lib
फ़ोल्डर मिटाएं. अब ज़रूरत के हिसाब से pip
के बजाय pip2
का इस्तेमाल करके, अपडेट की गई लाइब्रेरी को pip install -t lib -r requirements.txt
निर्देश की मदद से फिर से इंस्टॉल करें.
2. app.yaml
को अपडेट करें
google-cloud-ndb
जैसी Google Cloud क्लाइंट लाइब्रेरी को जोड़ने के लिए कुछ ज़रूरी शर्तें पूरी करनी होंगी. इसमें "पहले से मौजूद" सुविधा को शामिल करने के बारे में बताया गया है लाइब्रेरी, तीसरे पक्ष के पैकेज Google सर्वर पर पहले से ही उपलब्ध हैं. इन्हें requirements.txt
में लिस्ट नहीं किया जाता और न ही pip install
का इस्तेमाल करके कॉपी किया जाता है. सिर्फ़ ज़रूरी शर्तें:
app.yaml
में पहले से मौजूद लाइब्रेरी के बारे में बताएं- उन्हें तीसरे पक्ष की कॉपी की गई उन लाइब्रेरी पर ले जाएं जिनके साथ वे काम कर सकते हैं (
lib
में)
मॉड्यूल 1 की शुरुआत में app.yaml
यहां दिया गया है:
- पहले:
runtime: python27
threadsafe: yes
api_version: 1
handlers:
- url: /.*
script: main.app
अब तीसरे पक्ष के बंडल किए गए पैकेज के जोड़े का रेफ़रंस देने के लिए, app.yaml
में ये लाइनें जोड़ें: libraries
के नए सेक्शन में, grpcio
और setuptools
:
libraries:
- name: grpcio
version: 1.0.0
- name: setuptools
version: 36.6.0
पहले से मौजूद इन लाइब्रेरी का इस्तेमाल क्यों करना चाहिए? gRPC एक ओपन आरपीसी फ़्रेमवर्क है. इसका इस्तेमाल Google Cloud की सभी क्लाइंट लाइब्रेरी में किया जाता है. इसमें google-cloud-ndb
भी शामिल है. grpcio
लाइब्रेरी, Python gRPC अडैप्टर है और इसलिए यह ज़रूरी है. setuptools
को शामिल करने की वजह बताई जा रही है.
- इसके बाद:
ऊपर दिए गए बदलावों के साथ, आपका अपडेट किया गया 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
3. appengine_config.py
को अपडेट करें
pkg_resources
टूल, setuptools
लाइब्रेरी का हिस्सा है. इसका इस्तेमाल, पहले से मौजूद तीसरे पक्ष की लाइब्रेरी को बंडल किए गए आइटम ऐक्सेस करने की अनुमति देने के लिए किया जाता है. pkg_resources
का इस्तेमाल करने के लिए, appengine_config.py
को अपडेट करें, ताकि उन्हें lib
में बंडल की गई लाइब्रेरी पर भेजा जा सके. यह बदलाव करने के बाद, पूरी फ़ाइल इस तरह दिखेगी:
import pkg_resources
from google.appengine.ext import vendor
# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)
5. ऐप्लिकेशन फ़ाइलें अपडेट करें
कॉन्फ़िगरेशन फ़ाइल की फ़ॉर्मैटिंग खत्म होने की वजह से, अब ndb
से Cloud NDB पर माइग्रेट किया जा सकता है. इस प्रोसेस को पूरा करने के लिए, इंपोर्ट की गई लाइब्रेरी अपडेट करें और main.py
में कॉन्टेक्स्ट मैनेजमेंट का इस्तेमाल जोड़ें.
1. आयात
main.py
में निम्न आयात स्वैप करें:
- पहले
from google.appengine.ext import ndb
- इसके बाद:
from google.cloud import ndb
App Engine लाइब्रेरी से Google Cloud लाइब्रेरी में बदलाव करना, कभी-कभी इस इंस्टेंस जितना ही आसान होता है. पहले से मौजूद जिन सेवाओं में Google Cloud के सभी प्रॉडक्ट उपलब्ध हैं, उनके लिए एट्रिब्यूट को google.appengine
के बजाय, google.cloud
से इंपोर्ट किया जाएगा.
2. डेटास्टोर का ऐक्सेस
Cloud NDB लाइब्रेरी का इस्तेमाल करने के लिए, आपके ऐप्लिकेशन को Python कॉन्टेक्स्ट मैनेजर का इस्तेमाल करना होगा. उनका मकसद है "गेट" संसाधनों का ऐक्सेस, ताकि इस्तेमाल करने से पहले उन्हें हासिल किया जा सके. कॉन्टेक्स्ट मैनेजर, कंप्यूटर साइंस की कंट्रोल तकनीक पर आधारित होते हैं. इस तकनीक को रिसॉर्स ऐलोकेशन इज़ इनिशलाइज़ेशन (या आरएआईआई) कहा जाता है. कॉन्टेक्स्ट मैनेजर का इस्तेमाल Python फ़ाइलों और "स्पिन लॉक" के साथ किया जाता है. इन फ़ाइलों को ऐक्सेस करने से पहले खोला जाना ज़रूरी है "अहम सेक्शन" में मौजूद कोड से पहले का होना ज़रूरी है इस्तेमाल किया जा सकता है.
इसी तरह, Cloud NDB के लिए यह ज़रूरी है कि किसी भी Datastore कमांड के काम करने से पहले, आपको Datastore से संपर्क करने के लिए, क्लाइंट का संदर्भ हासिल करना होगा. सबसे पहले, फ़्लास्क शुरू करने के ठीक बाद main.py
में ds_client = ndb.Client()
जोड़कर क्लाइंट (ndb.Client()
) बनाएं:
app = Flask(__name__)
ds_client = ndb.Client()
Pythonwith
कमांड का इस्तेमाल, सिर्फ़ किसी ऑब्जेक्ट के कॉन्टेक्स्ट का पता लगाने के लिए किया जाता है. Datastore को ऐक्सेस करने वाले किसी भी कोड ब्लॉक को with
स्टेटमेंट से रैप करें.
नीचे वे ही फ़ंक्शन दिए गए हैं जो मॉड्यूल 1 में Datastore में नई इकाई लिखने और हाल ही में जोड़ी गई इकाइयों को देखने के लिए दिए गए हैं:
- पहले:
बिना कॉन्टेक्स्ट मैनेजमेंट के ओरिजनल कोड यहां दिया गया है:
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 (v.to_dict() for v in Visit.query().order(
-Visit.timestamp).fetch(limit))
- इसके बाद:
अब with ds_client.context():
जोड़ें और अपने Datastore के ऐक्सेस कोड को with
ब्लॉक में ले जाएं:
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 (v.to_dict() for v in Visit.query().order(
-Visit.timestamp).fetch(limit))
मुख्य ड्राइवर ऐप्लिकेशन, मॉड्यूल 1 से मिले डेटा की तरह ही है, क्योंकि यहां ndb
(न ही Cloud NDB) कोड नहीं दिया गया है:
@app.route('/')
def root():
'main application (GET) handler'
store_visit(request.remote_addr, request.user_agent)
visits = fetch_visits(10)
return render_template('index.html', visits=visits)
सबसे सही तरीका यह है कि ऐप्लिकेशन कोड और डेटा ऐक्सेस के बीच साफ़ तौर पर अंतर दिखाया जाए. इस तरह, मौजूदा डेटा स्टोरेज मैकेनिज़्म बदलने पर आपका मुख्य ऐप्लिकेशन कोड नहीं बदलता, जैसा कि हमने इस माइग्रेशन में किया था.
6. खास जानकारी/क्लीनअप
ऐप्लिकेशन डिप्लॉय करें
gcloud app deploy
के साथ अपने ऐप्लिकेशन को फिर से डिप्लॉय करें और पक्का करें कि ऐप्लिकेशन काम कर रहा हो. अब आपका कोड, मॉड्यूल 2 रेपो में मौजूद कोड से मेल खाना चाहिए.
अगर आपने कोई भी पिछले कोडलैब का इस्तेमाल किए बिना इस सीरीज़ में शामिल होना शुरू कर दिया है, तो ऐप्लिकेशन में कोई बदलाव नहीं होगा; यह मुख्य वेब पेज (/
) पर की जाने वाली सभी विज़िट को रजिस्टर कर लेता है. साथ ही, जब आप साइट पर कई बार आ चुके होते हैं, तो यह ऐसा दिखता है:
मॉड्यूल 2 कोडलैब का यह मॉड्यूल पूरा करने के लिए बधाई. आपने अभी-अभी फ़िनिश लाइन को पार कर लिया है, क्योंकि Datastore के मामले में इस सीरीज़ में सबसे ज़्यादा सुझाया गया माइग्रेशन है.
ज़रूरी नहीं: स्टोरेज खाली करें
जब तक आप अगले माइग्रेशन कोडलैब पर जाने के लिए तैयार नहीं हो जाते, तब तक बिलिंग से बचने के लिए क्लीन अप करने के बारे में क्या करें? मौजूदा डेवलपर के तौर पर, आपको App Engine की कीमत की जानकारी के बारे में अप-टू-डेट जानकारी है.
ज़रूरी नहीं: ऐप्लिकेशन बंद करना
अगर आप अभी अगले ट्यूटोरियल पर जाने के लिए तैयार नहीं हैं, तो शुल्क देने से बचने के लिए, अपना ऐप्लिकेशन बंद करें. जब आप अगले कोडलैब पर जाने के लिए तैयार हों, तो उसे फिर से चालू किया जा सकता है. बंद होने पर, आपके ऐप्लिकेशन को शुल्क देने के लिए कोई ट्रैफ़िक नहीं मिलेगा. हालांकि, डेटा स्टोर के इस्तेमाल को तब भी खर्च किया जा सकता है, जब इसका शुल्क मुफ़्त में मिलने वाले कोटा से ज़्यादा हो. इसलिए, इसे इतना मिटा दें कि इस सीमा के अंदर आने में आपको कोई परेशानी न हो.
दूसरी ओर, अगर आपको माइग्रेशन जारी नहीं रखना है और सब कुछ पूरी तरह से मिटाना है, तो अपना प्रोजेक्ट बंद करें.
अगले चरण
इसके बाद, आपकी अगली गतिविधि पर किसी भी तरह का बदलाव किया जा सकता है. इनमें से कोई विकल्प चुनें:
- मॉड्यूल 2 बोनस: Python 3 और अगली-पीढ़ी की टेक्नोलॉजी के App Engine रनटाइम में पोर्ट करने के बारे में जानने के लिए, इस ट्यूटोरियल के बोनस वाले हिस्से के नीचे जाएं.
- मॉड्यूल 7: App Engine पुश टास्क की सूचियां (अगर आप [push] टास्क की सूची का इस्तेमाल करते हैं, तो यह ज़रूरी है)
- मॉड्यूल 1 ऐप्लिकेशन में App Engine
taskqueue
पुश टास्क जोड़ता है - उपयोगकर्ताओं को मॉड्यूल 8 में, Cloud Tasks पर माइग्रेट करने के लिए तैयार करता है
- मॉड्यूल 1 ऐप्लिकेशन में App Engine
- मॉड्यूल 4: Docker के साथ क्लाउड रन पर माइग्रेट करें
- Docker के साथ Cloud Run पर चलाने के लिए, अपने ऐप्लिकेशन को कंटेनर में रखें
- आपको Python 2 पर बने रहने देता है
- मॉड्यूल 5: Cloud Buildpack के साथ Cloud Run पर माइग्रेट करना
- Cloud Buildpack की मदद से, अपने ऐप्लिकेशन को Cloud Run पर चलाने के लिए कंटेनर बनाएं
- आपको Docker, कंटेनर या
Dockerfile
के बारे में कुछ भी जानने की ज़रूरत नहीं है - यह ज़रूरी है कि आपने अपने ऐप्लिकेशन को पहले ही Python 3 पर माइग्रेट कर लिया हो
- मॉड्यूल 3:
- Cloud NDB से Cloud Datastore में डेटास्टोर के ऐक्सेस को मॉडर्न बनाएं
- यह लाइब्रेरी Python 3 App Engine ऐप्लिकेशन और बिना ऐप्लिकेशन इंजन वाले ऐप्लिकेशन के लिए इस्तेमाल की जाती है
7. BONUS: Python 3 पर माइग्रेट करना
App Engine के नए रनटाइम और सुविधाओं को ऐक्सेस करने के लिए, हमारा सुझाव है कि आप Python 3 पर माइग्रेट करें. सैंपल के तौर पर उपलब्ध हमारे ऐप्लिकेशन में, सिर्फ़ Datastore ही पहले से मौजूद सेवा का इस्तेमाल करता था. हम ndb
से Cloud NDB पर माइग्रेट कर चुके हैं. इसलिए, अब हम App Engine के Python 3 रनटाइम में पोर्ट कर सकते हैं.
खास जानकारी
Python 3 में पोर्ट करना Google Cloud ट्यूटोरियल के दायरे में नहीं आता. हालांकि, कोडलैब के इस हिस्से से डेवलपर को यह जानने में मदद मिलती है कि Python 3 App Engine का रनटाइम किस तरह अलग होता है. अगली पीढ़ी के रनटाइम की एक बेहतरीन सुविधा है, तीसरे पक्ष के पैकेज को आसानी से ऐक्सेस करना; app.yaml
में बिल्ट-इन पैकेज तय करने की ज़रूरत नहीं है. साथ ही, पहले से मौजूद नहीं लाइब्रेरी को कॉपी या अपलोड करने की ज़रूरत नहीं है; वे requirements.txt
में शामिल होने से साफ़ तौर पर इंस्टॉल हो जाते हैं.
हमारा सैंपल बहुत बुनियादी है और Cloud NDB, Python 2-3 के साथ काम करता है. इसलिए, किसी भी ऐप्लिकेशन कोड को साफ़ तौर पर 3.x पर पोर्ट करने की ज़रूरत नहीं है; यह ऐप्लिकेशन बिना किसी बदलाव के 2.x और 3.x पर चलता है. इसका मतलब है कि इस मामले में सिर्फ़ कॉन्फ़िगरेशन में ही ज़रूरी बदलाव किए गए हैं:
- Python 3 का रेफ़रंस देने और तीसरे पक्ष की लाइब्रेरी हटाने के लिए,
app.yaml
को आसान बनाएं. appengine_config.py
औरlib
फ़ोल्डर को मिटा दें, क्योंकि अब इनकी ज़रूरत नहीं है.
main.py
के अलावा, requirements.txt
और templates/index.html
फ़ाइलों में कोई बदलाव नहीं होगा.
app.yaml
को आसान बनाएं
पहले:
सैंपल के तौर पर इस्तेमाल होने वाले इस ऐप्लिकेशन में, सिर्फ़ app.yaml
को काफ़ी छोटा करना ही अहम है. आपको याद दिला दें कि मॉड्यूल 2 के आखिर में 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
इसके बाद:
Python 3 में, threadsafe
, api_version
, और libraries
डायरेक्टिव सभी काम नहीं करते; सभी ऐप्लिकेशन को थ्रेडसुरक्षित मान लिया गया है और Python 3 में api_version
का इस्तेमाल नहीं किया जाता. App Engine की सेवाओं पर अब पहले से मौजूद, तीसरे पक्ष के पैकेज पहले से इंस्टॉल नहीं हैं. इसलिए, libraries
को भी बंद कर दिया गया है. इन बदलावों के बारे में ज़्यादा जानकारी के लिए, app.yaml
में हुए बदलावों से जुड़े दस्तावेज़ देखें. इसलिए, आपको app.yaml
से इन तीनों को मिटा देना चाहिए और काम करने वाले Python 3 वर्शन पर अपडेट करना चाहिए (नीचे देखें).
ज़रूरी नहीं: handlers
डायरेक्टिव का इस्तेमाल करना
इसके अलावा, App Engine ऐप्लिकेशन पर ट्रैफ़िक भेजने वाले handlers
डायरेक्टिव को भी हटा दिया गया है. अगली पीढ़ी के रनटाइम के लिए ज़रूरी है कि वेब फ़्रेमवर्क, ऐप्लिकेशन रूटिंग को मैनेज करें. इसलिए, सभी "हैंडलर स्क्रिप्ट" इसे "auto
" में बदला जाना चाहिए. ऊपर बताए गए बदलावों को जोड़ने पर, आप इस app.yaml
पर पहुंचते हैं:
runtime: python38
handlers:
- url: /.*
script: auto
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
के बजाय फ़्लास्क डेवलपमेंट सर्वर का इस्तेमाल करने का अनुरोध करता है. डेवलपमेंट सर्वर को शुरू करने वाला कोड भी आपके ऐप्लिकेशन में जोड़ा जाना चाहिए. इससे पोर्ट 8080 पर 0.0.0.0
इंटरफ़ेस पर लॉन्च किया जा सकता है. इसके लिए, इस छोटे से सेक्शन को main.py
में सबसे नीचे जोड़ना होगा:
if __name__ == '__main__':
app.run(host='0.0.0.0', port=8080, debug=True)
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
में दी गई सूची) lib
फ़ोल्डर में कोईpip install
नहीं है. इसका मतलब है किlib
फ़ोल्डर में कोई पीरियड नहीं हैapp.yaml
में तीसरे पक्ष की कोई लाइब्रेरी पहले से मौजूद नहीं है- ऐप्लिकेशन को तीसरे पक्ष की लाइब्रेरी से रेफ़रंस लेने की ज़रूरत नहीं है. इसलिए,
appengine_config.py
फ़ाइल का इस्तेमाल नहीं किया जाता
requirements.txt
में तीसरे पक्ष की सभी ज़रूरी लाइब्रेरी की सूची बनाना ज़रूरी है.
ऐप्लिकेशन डिप्लॉय करें
अपने ऐप्लिकेशन को फिर से डिप्लॉय करें, ताकि यह पक्का किया जा सके कि वह सही तरीके से काम करे. यह पुष्टि भी की जा सकती है कि आपका सलूशन, मॉड्यूल 2 सैंपल Python 3 कोड के कितना करीब है. Python 2 के साथ अंतर को समझने के लिए, इसके Python 2 वर्शन से कोड की तुलना करें.
मॉड्यूल 2 में बोनस स्टेप पूरा करने पर बधाई! 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 माइग्रेशन मॉड्यूल कोडलैब से जुड़ी समस्याएं/सुझाव
अगर आपको इस कोडलैब के साथ कोई समस्या मिलती है, तो कृपया आवेदन करने से पहले अपनी समस्या का पता लगाएं. खोजने और नई समस्याएं बनाने के लिए लिंक:
माइग्रेशन के लिए संसाधन
यहां दी गई टेबल में, मॉड्यूल 1 (START) और मॉड्यूल 2 (FINISH) के रेपो फ़ोल्डर के लिंक दिए गए हैं. उन्हें सभी App Engine कोडलैब माइग्रेशन के लिए रेपो से भी ऐक्सेस किया जा सकता है, जिसका क्लोन बनाया जा सकता है या किसी ZIP फ़ाइल को डाउनलोड किया जा सकता है.
Codelab | Python 2 | Python 3 |
(लागू नहीं) | ||
मॉड्यूल 2 |
App Engine के संसाधन
इस खास माइग्रेशन से जुड़े अतिरिक्त संसाधन नीचे दिए गए हैं:
- Python NDB के रेफ़रंस
- (पुराना) Python 2.5 और
webapp
से 2.7 औरwebapp2
पर माइग्रेट करना - Python 3 और GAE की अगली-पीढ़ी की टेक्नोलॉजी वाले रनटाइम पर माइग्रेट करना
- सामान्य