۱. مرور کلی
این مجموعه از آزمایشگاههای کد (آموزشهای عملی و خودآموز) با هدف کمک به توسعهدهندگان Google App Engine (استاندارد) برای مدرنسازی برنامههایشان با راهنمایی آنها در طی یک سری مهاجرتها ارائه شده است. مهمترین گام، فاصله گرفتن از سرویسهای همراه زمان اجرا (runtime bundled) اصلی است، زیرا زمانهای اجرای نسل بعدی انعطافپذیرتر هستند و گزینههای خدماتی متنوعتری را در اختیار کاربران قرار میدهند. انتقال به زمان اجرا (runtime) نسل جدیدتر به شما این امکان را میدهد که راحتتر با محصولات Google Cloud ادغام شوید، از طیف وسیعتری از سرویسهای پشتیبانیشده استفاده کنید و از نسخههای فعلی زبانها پشتیبانی کنید.
این آموزش به شما آموزش میدهد که چگونه از کتابخانه کلاینت ndb (Next Database) داخلی App Engine به کتابخانه کلاینت Cloud NDB مهاجرت کنید.
یاد خواهید گرفت که چگونه
- استفاده از کتابخانه App Engine
ndb(اگر با آن آشنا نیستید) - مهاجرت از
ndbبه Cloud NDB - برنامه خود را بیشتر به پایتون ۳ منتقل کنید
آنچه نیاز دارید
- یک پروژه پلتفرم ابری گوگل با:
- مهارتهای پایه پایتون
- آشنایی کامل با دستورات رایج لینوکس
- دانش پایه در توسعه و استقرار برنامههای App Engine
- یک برنامه کاربردی ماژول ۱ موتور برنامه
نظرسنجی
چگونه از این آزمایشگاه کد استفاده خواهید کرد؟
۲. پیشینه
در ماژول ۱، ما چارچوبهای وب را از webapp2 داخلی App Engine به Flask منتقل کردیم. در این آزمایشگاه کد، ما با تغییر از کتابخانه ndb در App Engine به Google Cloud NDB ، به فاصله گرفتن از سرویسهای داخلی App Engine ادامه میدهیم.
با تکمیل این مهاجرت، میتوانید:
- مهاجرت به پایتون ۳ و رانتایم نسل بعدی App Engine
- مهاجرت به Cloud Datastore (کتابخانه کلاینت برای برنامههای غیر App Engine)
- برنامه پایتون ۲ (یا ۳) خود را کانتینرایز کنید و به Cloud Run مهاجرت کنید
- استفاده از صفهای وظایف App Engine (push) را اضافه کنید و سپس به Cloud Tasks مهاجرت کنید.
اما هنوز به آنجا نرسیدهایم. قبل از بررسی مراحل بعدی، این آزمایشگاه کد را تمام کنید. مهاجرت این آموزش شامل این مراحل اولیه است:
- راهاندازی/پیشپردازش
- کتابخانه Cloud NDB را اضافه کنید
- بهروزرسانی فایلهای برنامه
۳. تنظیمات/پیشپردازش
قبل از اینکه به بخش اصلی آموزش بپردازیم، بیایید پروژه خود را راهاندازی کنیم، کد را دریافت کنیم، سپس برنامه پایه را مستقر کنیم تا بدانیم که با کد کار را شروع کردهایم.
۱. پروژه راهاندازی
اگر ماژول ۱ codelab را تکمیل کردهاید، توصیه میکنیم از همان پروژه (و کد) دوباره استفاده کنید. همچنین میتوانید یک پروژه کاملاً جدید ایجاد کنید یا از یک پروژه موجود دیگر دوباره استفاده کنید. مطمئن شوید که پروژه دارای یک حساب صورتحساب فعال است و App Engine فعال است.
۲. نمونه برنامه پایه را دریافت کنید
یکی از پیشنیازها، داشتن یک نمونه برنامه ماژول ۱ است که کار کند. اگر آن آموزش را تکمیل کردهاید، از راهحل خود استفاده کنید. میتوانید آن را اکنون تکمیل کنید (لینک بالا)، یا اگر میخواهید از آن صرفنظر کنید، مخزن ماژول ۱ (لینک زیر) را کپی کنید.
چه از کد خودتان استفاده کنید و چه از کد ما، کد ماژول ۱ جایی است که ما شروع خواهیم کرد. این آزمایشگاه کد ماژول ۲ شما را در هر مرحله راهنمایی میکند و پس از تکمیل، باید شبیه کد در نقطه پایان باشد (شامل یک انتقال «اضافی» اختیاری از پایتون ۲ به ۳):
- شروع: کد ماژول ۱
- پایان: کد پایتون ۲ ماژول ۲ ( کد پایتون ۳ به عنوان جایزه)
- کل مخزن (برای کلون کردن یا دانلود فایل زیپ)
پوشه کد STARTING Module 1 شما باید حاوی محتویات زیر باشد:
$ ls
README.md appengine_config.py requirements.txt
app.yaml main.py templates
اگر آموزش ماژول ۱ را تکمیل کرده باشید، یک پوشه lib نیز با Flask و وابستگیهای آن خواهید داشت. اگر پوشه lib ندارید، آن را با دستور pip install -t lib -r requirements.txt ایجاد کنید تا بتوانیم این برنامه پایه را در مرحله بعدی مستقر کنیم. اگر هم پایتون ۲ و هم پایتون ۳ را نصب کردهاید، توصیه میکنیم pip2 به جای pip استفاده کنید تا از سردرگمی با پایتون ۳ جلوگیری شود.
۳. (دوباره) استقرار ماژول ۱ برنامه
مراحل مقدماتی باقی مانده برای اجرا:
- دوباره با ابزار خط فرمان
gcloudآشنا شوید (در صورت نیاز) - کد ماژول ۱ را (در صورت نیاز) در App Engine (دوباره) مستقر کنید.
زمانی که این مراحل را با موفقیت انجام دادید و از عملیاتی بودن آن اطمینان حاصل کردید، در این آموزش با فایلهای پیکربندی شروع خواهیم کرد.
۴. بهروزرسانی فایلهای پیکربندی (افزودن کتابخانه Cloud NDB)
بسیاری از سرویسهای داخلی اصلی App Engine به محصولات خود تبدیل شدهاند و Datastore یکی از آنهاست. امروزه برنامههای غیر App Engine میتوانند از Cloud Datastore استفاده کنند. برای کاربران قدیمی ndb ، تیم Google Cloud کتابخانه کلاینت Cloud NDB را برای ارتباط با Cloud Datastore ایجاد کرده است. این کتابخانه هم برای پایتون ۲ و هم برای پایتون ۳ در دسترس است.
بیایید فایلهای تأیید را بهروزرسانی کنیم تا App Engine ndb با Cloud NDB جایگزین کنیم، سپس برنامه خود را تغییر دهیم.
۱. بهروزرسانی requirements.txt
در ماژول ۱، تنها وابستگی خارجی برای برنامه ما Flask بود. اکنون Cloud NDB را اضافه خواهیم کرد. فایل 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
وقتی این codelab نوشته میشد، آخرین نسخه توصیهشده ۱.۷.۱ بود، اما requirements.txt موجود در مخزن ممکن است نسخه جدیدتری داشته باشد. ما آخرین نسخههای هر کتابخانه را توصیه میکنیم، اما اگر کار نکردند، میتوانید به نسخه قدیمیتر برگردید.
اگر پوشه lib دارید و آن را در بالا ایجاد نکردهاید، آن را حذف کنید. اکنون کتابخانههای بهروز شده را با دستور pip install -t lib -r requirements.txt (دوباره) نصب کنید، در صورت لزوم از pip2 به جای pip استفاده کنید.
۲. بهروزرسانی app.yaml
افزودن کتابخانههای کلاینت گوگل کلود مانند google-cloud-ndb چند الزام دارد که همگی حول گنجاندن کتابخانههای «داخلی» و بستههای شخص ثالث موجود در سرورهای گوگل میچرخند. شما آنها را در requirements.txt فهرست نمیکنید و آنها را با pip install کپی نمیکنید. تنها الزامات:
- کتابخانههای داخلی را در
app.yamlمشخص کنید - آنها را به کتابخانههای شخص ثالث کپیشدهای که ممکن است با آنها کار کنند (در
lib) راهنمایی کنید.
فایل شروع app.yaml از ماژول ۱ به صورت زیر است:
- قبل از:
runtime: python27
threadsafe: yes
api_version: 1
handlers:
- url: /.*
script: main.app
اکنون خطوط زیر را به app.yaml اضافه کنید تا به یک جفت بستهی همراه شخص ثالث اشاره کنید: grpcio و setuptools در یک بخش جدید libraries :
libraries:
- name: grpcio
version: 1.0.0
- name: setuptools
version: 36.6.0
چرا از این کتابخانههای داخلی استفاده کنیم؟ gRPC یک چارچوب RPC باز است که توسط همه کتابخانههای کلاینت Google Cloud ، از جمله google-cloud-ndb استفاده میشود. کتابخانه grpcio آداپتور 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
۳. بهروزرسانی appengine_config.py
ابزار pkg_resources ، بخشی از کتابخانه setuptools ، برای دسترسی کتابخانههای شخص ثالث داخلی به کتابخانههای همراه استفاده میشود. appengine_config.py را بهروزرسانی کنید تا از pkg_resources برای اشاره به کتابخانههای همراه در 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)
۵. بهروزرسانی فایلهای برنامه
با انجام تشریفات مربوط به فایل پیکربندی، اکنون میتوانید از ndb به Cloud NDB مهاجرت کنید. برای تکمیل مهاجرت، کتابخانههای وارد شده را بهروزرسانی کنید و استفاده از مدیریت زمینه را در main.py اضافه کنید.
۱. واردات
دستور زیر را برای import swap در main.py اجرا کنید:
- قبل از
from google.appengine.ext import ndb
- بعد از:
from google.cloud import ndb
تغییر از یک کتابخانه App Engine به یک کتابخانه Google Cloud گاهی اوقات به اندازه این مثال ظریف است. برای سرویسهای داخلی که به محصولات کامل Google Cloud تبدیل شدهاند، به جای google.appengine ، ویژگیها را از google.cloud وارد خواهید کرد.
۲. دسترسی به پایگاه داده
برای اینکه بتوانید از کتابخانه Cloud NDB استفاده کنید، برنامه شما باید از مدیران زمینه پایتون استفاده کند. هدف آنها "دروازه" کردن دسترسی به منابع است به طوری که قبل از استفاده، باید آنها را بدست آورد. مدیران زمینه بر اساس تکنیک کنترل علوم کامپیوتر معروف به Resource Allocation Is Initialization (یا RAII) هستند . مدیران زمینه با فایلهای پایتون (که باید قبل از دسترسی باز شوند) و همزمانی استفاده میشوند، " قفلهای چرخش " باید قبل از اجرای کد در " بخش بحرانی " بدست آیند.
به طور مشابه، Cloud NDB قبل از اینکه هرگونه دستور Datastore بتواند اجرا شود، از شما میخواهد که زمینه یک کلاینت را برای برقراری ارتباط با Datastore به دست آورید. ابتدا، با اضافه کردن ds_client = ndb.Client() در main.py درست پس از مقداردهی اولیه Flask، یک کلاینت ( ndb.Client() ) ایجاد کنید:
app = Flask(__name__)
ds_client = ndb.Client()
دستور with پایتون صرفاً برای بدست آوردن محتوای یک شیء استفاده میشود. هر بلوک کدی که به Datastore دسترسی دارد را با دستورات with پوشش دهید.
در زیر همان توابع ماژول ۱ برای نوشتن یک موجودیت جدید در 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))
برنامه درایور اصلی مشابه آنچه در ماژول ۱ داشتیم باقی میماند، زیرا هیچ کد 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)
بهترین روش این است که از تمایز واضح بین کد برنامه و دسترسی به دادهها اطمینان حاصل کنید. به این ترتیب، کد اصلی برنامه شما هنگام تغییر مکانیسم ذخیرهسازی دادههای زیربنایی، همانطور که در این مهاجرت انجام دادیم، تغییر نمیکند.
۶. خلاصه/پاکسازی
استقرار برنامه
برنامه خود را با gcloud app deploy دوباره مستقر کنید و تأیید کنید که برنامه کار میکند. اکنون کد شما باید با آنچه در مخزن Module 2 وجود دارد مطابقت داشته باشد.
اگر بدون انجام هیچ یک از آزمایشهای کد قبلی وارد این مجموعه شده باشید، خود برنامه تغییری نمیکند؛ تمام بازدیدها از صفحه وب اصلی ( / ) را ثبت میکند و پس از بازدید کافی از سایت، به این شکل درمیآید:
تبریک بابت تکمیل این آزمایشگاه کد ماژول ۲. شما همین الان از خط پایان عبور کردهاید، زیرا این آخرین مورد از مهاجرتهای اکیداً توصیهشده در این مجموعه در مورد Datastore است.
اختیاری: تمیز کردن
در مورد پاکسازی برای جلوگیری از پرداخت هزینه تا زمانی که آماده انتقال به آزمایشگاه کد مهاجرت بعدی باشید، چطور؟ به عنوان توسعهدهندگان فعلی، احتمالاً از قبل از اطلاعات قیمتگذاری App Engine مطلع هستید.
اختیاری: غیرفعال کردن برنامه
اگر هنوز آماده رفتن به آموزش بعدی نیستید، برنامه خود را غیرفعال کنید تا از پرداخت هزینه جلوگیری شود. وقتی آماده رفتن به آزمایشگاه کد بعدی شدید، میتوانید دوباره آن را فعال کنید. در حالی که برنامه شما غیرفعال است، هیچ ترافیکی دریافت نمیکند که هزینهای داشته باشد، با این حال مورد دیگری که ممکن است برای آن هزینه دریافت کنید، استفاده از Datastore شما در صورت تجاوز از سهمیه رایگان است، بنابراین به اندازهای حذف کنید که زیر آن محدودیت قرار گیرد.
از طرف دیگر، اگر قصد ادامهی مهاجرتها را ندارید و میخواهید همه چیز را به طور کامل حذف کنید، میتوانید پروژهی خود را خاموش کنید .
مراحل بعدی
از اینجا به بعد، در مورد حرکت بعدی شما انعطافپذیری وجود دارد. هر یک از این گزینهها را انتخاب کنید:
- ماژول ۲ اضافی: در ادامه به بخش اضافی این آموزش بروید تا انتقال به پایتون ۳ و نسل بعدی App Engine runtime را بررسی کنید.
- ماژول 7: صفهای وظیفه Push Engine App (در صورت استفاده از صفهای وظیفه [push] الزامی است)
- وظایف ارسالی صف
taskqueueموتور برنامه را به ماژول ۱ برنامه اضافه میکند. - کاربران را برای مهاجرت به وظایف ابری در ماژول ۸ آماده میکند.
- وظایف ارسالی صف
- ماژول 4: مهاجرت به Cloud Run با Docker
- برنامه خود را برای اجرا در Cloud Run با Docker کانتینریزه کنید
- به شما امکان میدهد روی پایتون ۲ بمانید
- ماژول 5: مهاجرت به Cloud Run با Cloud Buildpacks
- با استفاده از Cloud Buildpacks، برنامه خود را برای اجرا در Cloud Run کانتینرایز کنید
- نیازی نیست چیزی در مورد داکر، کانتینرها یا
Dockerfileبدانید - مستلزم آن است که برنامه خود را از قبل به پایتون ۳ منتقل کرده باشید
- ماژول ۳:
- دسترسی به Datastore را از Cloud NDB به Cloud Datastore مدرن کنید
- این کتابخانهای است که برای برنامههای App Engine پایتون ۳ و برنامههای غیر App Engine استفاده میشود.
۷. نکتهی اضافه: مهاجرت به پایتون ۳
برای دسترسی به جدیدترین نسخه زمان اجرا و ویژگیهای App Engine، توصیه میکنیم به پایتون ۳ مهاجرت کنید. در برنامه نمونه ما، Datastore تنها سرویس داخلی بود که ما استفاده کردیم و از آنجایی که ما از ndb به Cloud NDB مهاجرت کردهایم، اکنون میتوانیم آن را به زمان اجرا پایتون ۳ App Engine منتقل کنیم.
نمای کلی
اگرچه انتقال به پایتون ۳ در محدوده آموزش Google Cloud نیست، اما این بخش از codelab به توسعهدهندگان ایدهای از تفاوتهای زمان اجرای موتور برنامه پایتون ۳ میدهد. یکی از ویژگیهای برجسته زمان اجرای نسل بعدی، دسترسی ساده به بستههای شخص ثالث است؛ نیازی به مشخص کردن بستههای داخلی در app.yaml نیست و همچنین نیازی به کپی یا آپلود کتابخانههای غیر داخلی نیست؛ آنها به طور ضمنی از فهرست شدن در requirements.txt نصب میشوند.
از آنجا که نمونه ما بسیار ابتدایی است و Cloud NDB با پایتون ۲-۳ سازگار است، نیازی نیست هیچ کد برنامهای به صراحت به ۳.x منتقل شود؛ برنامه روی ۲.x و ۳.x بدون تغییر اجرا میشود، به این معنی که در این مورد تنها تغییرات مورد نیاز در پیکربندی هستند:
-
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
بعد از:
در پایتون ۳، دستورالعملهای threadsafe ، api_version و libraries منسوخ شدهاند؛ فرض بر این است که همه برنامهها threadsafe هستند و api_version در پایتون ۳ استفاده نمیشود. دیگر بستههای شخص ثالث داخلی از پیش نصب شده روی سرویسهای App Engine وجود ندارد، بنابراین libraries نیز منسوخ شدهاند. برای اطلاعات بیشتر در مورد این تغییرات، مستندات مربوط به تغییرات app.yaml را بررسی کنید. در نتیجه، باید هر سه را از app.yaml حذف کرده و به نسخه پشتیبانی شده پایتون ۳ بهروزرسانی کنید (به زیر مراجعه کنید).
اختیاری: استفاده از دستورالعمل handlers
علاوه بر این، دستورالعمل handlers که ترافیک را به برنامههای App Engine هدایت میکند نیز منسوخ شده است. از آنجایی که نسل بعدی runtime از چارچوبهای وب انتظار دارد که مسیریابی برنامه را مدیریت کنند، همه "scripts handler" باید به " auto " تغییر کنند. با ترکیب تغییرات بالا، به app.yaml زیر میرسید:
runtime: python38
handlers:
- url: /.*
script: auto
برای کسب اطلاعات بیشتر در مورد script: auto به صفحه مستندات آن مراجعه کنید.
حذف دستورالعملهای handlers
از آنجایی که handlers منسوخ شده است، میتوانید کل بخش را نیز حذف کنید و یک app.yaml تکخطی باقی بگذارید:
runtime: python38
به طور پیشفرض، این دستور ، وب سرور Gunicorn WSGI را که برای همه برنامهها در دسترس است، اجرا میکند. اگر با gunicorn آشنا هستید، این دستوری است که هنگام شروع پیشفرض آن با barebones app.yaml اجرا میشود:
gunicorn main:app --workers 2 -c /config/gunicorn.py
اختیاری: استفاده از دستورالعمل entrypoint
با این حال، اگر برنامه شما به یک دستور راهاندازی خاص نیاز دارد، میتوان آن را با یک دستورالعمل entrypoint مشخص کرد که در آن app.yaml شما به این شکل خواهد بود:
runtime: python38
entrypoint: python main.py
این مثال بهطور خاص درخواست میکند که از سرور توسعه Flask به جای gunicorn استفاده شود. کدی که سرور توسعه را شروع میکند نیز باید به برنامه شما اضافه شود تا روی رابط 0.0.0.0 روی پورت 8080 با اضافه کردن این بخش کوچک به انتهای main.py اجرا شود:
if __name__ == '__main__':
app.run(host='0.0.0.0', port=8080, debug=True)
برای کسب اطلاعات بیشتر در مورد entrypoint به صفحه مستندات آن مراجعه کنید. مثالها و بهترین شیوههای بیشتر را میتوانید در مستندات راهاندازی App Engine Standard و همچنین مستندات راهاندازی App Engine Flexible بیابید.
appengine_config.py و lib را حذف کنید
فایل appengine_config.py و پوشه lib را حذف کنید. در مهاجرت به پایتون ۳، App Engine بستههای ذکر شده در requirements.txt را دریافت و نصب میکند.
فایل پیکربندی appengine_config.py برای شناسایی کتابخانهها/بستههای شخص ثالث استفاده میشود، چه خودتان آنها را کپی کرده باشید و چه از آنهایی که از قبل روی سرورهای App Engine (داخلی) موجود هستند استفاده کنید. هنگام انتقال به پایتون ۳، خلاصهای از تغییرات بزرگ عبارتند از:
- عدم نیاز به بستهبندی کتابخانههای کپیشدهی شخص ثالث (که در
requirements.txtذکر شده است) - بدون
pip installدر پوشهlib، به این معنی که دوره پوشهlibوجود ندارد - عدم فهرستبندی کتابخانههای شخص ثالث داخلی در
app.yaml - نیازی به ارجاع برنامه به کتابخانههای شخص ثالث نیست، بنابراین نیازی به فایل
appengine_config.pyنیست.
تنها کاری که لازم است، فهرست کردن تمام کتابخانههای شخص ثالث مورد نیاز در requirements.txt است.
استقرار برنامه
برنامه خود را دوباره مستقر کنید تا مطمئن شوید که کار میکند. همچنین میتوانید تأیید کنید که راهحل شما چقدر به کد نمونه پایتون ۳ ماژول ۲ نزدیک است. برای تجسم تفاوتها با پایتون ۲، کد را با نسخه پایتون ۲ آن مقایسه کنید.
تبریک میگویم که مرحلهی اضافی در ماژول ۲ را به پایان رساندید! به مستندات مربوط به آمادهسازی فایلهای پیکربندی برای زمان اجرای پایتون ۳ مراجعه کنید. در نهایت، برای مراحل بعدی و پاکسازی، صفحهی (قبلی) خلاصه/پاکسازی را مرور کنید.
آمادهسازی درخواست شما
وقتی زمان مهاجرت برنامهتان فرا برسد، باید main.py و سایر فایلهای برنامهتان را به نسخه ۳.x منتقل کنید، بنابراین بهترین روش این است که تمام تلاش خود را بکنید تا برنامه ۲.x شما تا حد امکان «سازگار با نسخههای قبلی» باشد.
منابع آنلاین زیادی برای کمک به شما در انجام این کار وجود دارد، اما برخی از نکات کلیدی:
- اطمینان حاصل کنید که تمام وابستگیهای برنامه کاملاً با نسخه ۳.x سازگار هستند.
- مطمئن شوید که برنامه شما حداقل روی نسخه ۲.۶ (ترجیحاً ۲.۷) اجرا میشود.
- اطمینان حاصل کنید که برنامه از کل مجموعه تست (و حداقل 80٪ پوشش) عبور میکند.
- از کتابخانههای سازگاری مانند
six، Future و/یا Modernize استفاده کنید - در مورد تفاوتهای کلیدی ناسازگاری نسخههای ۲.x و ۳.x با نسخههای قبلی، اطلاعات کسب کنید.
- هرگونه ورودی/خروجی احتمالاً منجر به ناسازگاری یونیکد در مقابل رشته بایت خواهد شد.
برنامه نمونه با در نظر گرفتن همه این موارد طراحی شده است، به همین دلیل است که برنامه از همان ابتدا روی نسخه ۲.x و ۳.x اجرا میشود تا بتوانیم روی نشان دادن آنچه که برای استفاده از پلتفرم نسل بعدی باید تغییر کند، تمرکز کنیم.
۸. منابع اضافی
مشکلات/بازخورد ماژول مهاجرت موتور برنامه در codelabs
اگر در این آزمایشگاه کد مشکلی پیدا کردید، لطفاً قبل از ثبت، ابتدا مشکل خود را جستجو کنید. لینکهای جستجو و ایجاد مشکلات جدید:
منابع مهاجرت
لینکهای پوشههای مخزن ماژول ۱ (START) و ماژول ۲ (FINISH) را میتوانید در جدول زیر پیدا کنید. همچنین میتوانید از مخزن تمام مهاجرتهای Codelab مربوط به App Engine که میتوانید آنها را کلون کنید یا یک فایل ZIP دانلود کنید، به آنها دسترسی داشته باشید.
کدلب | پایتون ۲ | پایتون ۳ |
(نامشخص) | ||
ماژول ۲ |
منابع موتور برنامه
در زیر منابع بیشتری در مورد این مهاجرت خاص آمده است:
- ارجاعات NDB پایتون
- (قدیمی) مهاجرت از پایتون ۲.۵ و
webappبه ۲.۷ وwebapp2 - مهاجرت به پایتون ۳ و محیط اجرایی نسل بعدی GAE
- عمومی