ماژول 3: مهاجرت از Google Cloud NDB به Cloud Datastore

۱. مرور کلی

این مجموعه از آزمایشگاه‌های کد (آموزش‌های عملی و خودآموز) با هدف کمک به توسعه‌دهندگان Google App Engine (محیط استاندارد) برای مدرن‌سازی برنامه‌هایشان، با راهنمایی آنها در طی یک سری مهاجرت‌ها ارائه شده است. مهم‌ترین گام، فاصله گرفتن از سرویس‌های همراه زمان اجرا (runtime bundled) اصلی است، زیرا زمان‌های اجرای نسل بعدی انعطاف‌پذیرتر هستند و گزینه‌های خدماتی متنوع‌تری را در اختیار کاربران قرار می‌دهند. انتقال به زمان اجرا (runtime) نسل جدیدتر، شما را قادر می‌سازد تا راحت‌تر با محصولات Google Cloud ادغام شوید، از طیف وسیع‌تری از سرویس‌های پشتیبانی‌شده استفاده کنید و از نسخه‌های فعلی زبان‌ها پشتیبانی کنید.

این آموزش اختیاری به توسعه‌دهندگان نشان می‌دهد که چگونه از Cloud NDB به Cloud Datastore به عنوان کتابخانه کلاینت برای ارتباط با سرویس Datastore مهاجرت کنند. توسعه‌دهندگانی که NDB را ترجیح می‌دهند می‌توانند با آن بمانند زیرا با پایتون ۳ سازگار است، به همین دلیل این مهاجرت اختیاری است. این مهاجرت فقط برای کسانی است که مایل به ایجاد یک پایگاه کد سازگار و کتابخانه‌های مشترک با سایر برنامه‌هایی هستند که از Cloud Datastore استفاده می‌کنند. این موضوع در بخش "پیشینه" توضیح داده شده است.

یاد خواهید گرفت که چگونه

  • استفاده از Cloud NDB (اگر با آن آشنا نیستید)
  • مهاجرت از Cloud NDB به Cloud Datastore
  • برنامه خود را بیشتر به پایتون ۳ منتقل کنید

آنچه نیاز دارید

  • یک پروژه پلتفرم ابری گوگل با یک حساب پرداخت فعال GCP
  • مهارت‌های پایه پایتون
  • آشنایی کامل با دستورات پایه لینوکس
  • دانش پایه در توسعه و استقرار برنامه‌های App Engine
  • یک برنامه‌ی ماژول ۲ موتور برنامه‌ی کاربردی ۲.x یا ۳.x.

نظرسنجی

چگونه از این آزمایشگاه کد استفاده خواهید کرد؟

فقط آن را بخوانید آن را بخوانید و تمرین‌ها را انجام دهید

۲. پیشینه

اگرچه Cloud NDB یک راهکار عالی برای Datastore برای توسعه‌دهندگان قدیمی App Engine است و به انتقال به پایتون ۳ کمک می‌کند، اما تنها راهی نیست که توسعه‌دهندگان App Engine می‌توانند به Datastore دسترسی داشته باشند. وقتی Datastore مربوط به App Engine در سال ۲۰۱۳ به محصول مستقل خود یعنی Google Cloud Datastore تبدیل شد، یک کتابخانه کلاینت جدید ایجاد شد تا همه کاربران بتوانند از Datastore استفاده کنند.

توسعه‌دهندگان موتور برنامه پایتون ۳ و غیر موتور برنامه به استفاده از Cloud Datastore (نه Cloud NDB) هدایت می‌شوند. به توسعه‌دهندگان موتور برنامه پایتون ۲ توصیه می‌شود از ndb به Cloud NDB مهاجرت کرده و از آنجا به پایتون ۳ منتقل شوند، اما می‌توانند مهاجرت بیشتر به Cloud Datastore را نیز انتخاب کنند. این یک تصمیم منطقی است، به خصوص برای توسعه‌دهندگانی که از قبل کدی با استفاده از Cloud Datastore دارند، مانند مواردی که ذکر شد، و مایل به ایجاد کتابخانه‌های مشترک در تمام برنامه‌های خود هستند. استفاده مجدد از کد و همچنین سازگاری کد، بهترین روش است و هر دو به کاهش کلی هزینه‌های نگهداری کمک می‌کنند، همانطور که در اینجا خلاصه شده است:

مهاجرت از Cloud NDB به Cloud Datastore

  • به توسعه‌دهندگان اجازه می‌دهد تا برای دسترسی به Datastore روی یک کدبیس واحد تمرکز کنند.
  • از نگهداری برخی کدها با استفاده از Cloud NDB و برخی دیگر با استفاده از Cloud Datastore جلوگیری می‌کند.
  • ثبات بیشتری در کدبیس و قابلیت استفاده مجدد بهتر از کد را فراهم می‌کند.
  • امکان استفاده از کتابخانه‌های مشترک/اشتراکی را فراهم می‌کند که به کاهش هزینه‌های کلی نگهداری کمک می‌کند.

این مهاجرت شامل این مراحل اولیه است:

  1. راه‌اندازی/پیش‌پردازش
  2. جایگزینی Cloud NDB با کتابخانه‌های کلاینت Cloud Datastore
  3. به‌روزرسانی برنامه

۳. تنظیمات/پیش‌پردازش

قبل از اینکه به بخش اصلی آموزش بپردازیم، بیایید پروژه خود را راه‌اندازی کنیم، کد را دریافت کنیم، سپس برنامه پایه را مستقر کنیم تا بدانیم که با کد کار را شروع کرده‌ایم.

۱. پروژه راه‌اندازی

اگر ماژول ۲ codelab را تکمیل کرده‌اید، توصیه می‌کنیم از همان پروژه (و کد) دوباره استفاده کنید. همچنین می‌توانید یک پروژه کاملاً جدید ایجاد کنید یا از یک پروژه موجود دیگر دوباره استفاده کنید. مطمئن شوید که پروژه دارای یک حساب صورتحساب فعال است و App Engine (برنامه) فعال است.

۲. نمونه برنامه پایه را دریافت کنید

یکی از پیش‌نیازها، داشتن یک نمونه برنامه ماژول ۲ است که کار کند. اگر آن آموزش را تکمیل کرده‌اید، از راه‌حل خود استفاده کنید. می‌توانید آن را اکنون تکمیل کنید (لینک بالا)، یا اگر می‌خواهید از آن صرف‌نظر کنید، مخزن ماژول ۲ (لینک زیر) را کپی کنید.

چه از کد خودتان استفاده کنید و چه از کد ما، کد ماژول ۲ جایی است که ما شروع خواهیم کرد. این آزمایشگاه کد ماژول ۳ شما را در هر مرحله راهنمایی می‌کند و پس از اتمام، باید شبیه کد در نقطه پایان باشد. نسخه‌های پایتون ۲ و ۳ از این آموزش وجود دارد، بنابراین مخزن کد صحیح را از زیر دریافت کنید.

پایتون ۲

دایرکتوری فایل‌های شروع پایتون ۲ ماژول ۲ (مال شما یا مال ما) باید به این شکل باشد:

$ 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 استفاده کنید تا از سردرگمی با پایتون ۳ جلوگیری شود.

پایتون ۳

دایرکتوری فایل‌های STARTING ماژول ۲ پایتون ۳ (فایل شما یا فایل ما) باید به شکل زیر باشد:

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

نه lib و نه appengine_config.py برای پایتون ۳ استفاده نمی‌شوند.

۳. (استقرار مجدد) ماژول ۲ برنامه

مراحل مقدماتی باقی مانده برای اجرا:

  1. دوباره با ابزار خط فرمان gcloud آشنا شوید (در صورت نیاز)
  2. کد ماژول ۱ را (در صورت نیاز) در App Engine (دوباره) مستقر کنید.

زمانی که این مراحل را با موفقیت انجام دادید و از عملیاتی بودن آن اطمینان حاصل کردید، در این آموزش با فایل‌های پیکربندی شروع خواهیم کرد.

۴. جایگزینی Cloud NDB با کتابخانه‌های کلاینت Cloud Datastore

تنها تغییر پیکربندی، یک تغییر جزئی در بسته‌ی نرم‌افزاری در فایل requirements.txt شماست.

۱. به‌روزرسانی requirements.txt

پس از تکمیل ماژول ۲، فایل requirements.txt شما به این شکل بود:

  • قبل (پایتون ۲ و ۳): 
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 که با پایتون ۲ سازگار است ۱.۱۵.۳ است:

  • بعد (پایتون ۲): 
Flask==1.1.2
google-cloud-datastore==1.15.3
  • بعد (پایتون ۳): 
Flask==1.1.2
google-cloud-datastore==2.1.0

به خاطر داشته باشید که این مخزن به طور منظم‌تری نسبت به این آموزش نگهداری می‌شود، بنابراین ممکن است فایل requirements.txt نسخه‌های جدیدتر را منعکس کند. توصیه می‌کنیم از آخرین نسخه‌های هر کتابخانه استفاده کنید، اما اگر کار نکردند، می‌توانید به نسخه قدیمی‌تر برگردید. شماره نسخه‌های بالا آخرین شماره‌هایی هستند که این codelab آخرین بار به‌روزرسانی کرده است.

۲. سایر فایل‌های پیکربندی

سایر فایل‌های پیکربندی، app.yaml و appengine_config.py ، باید از مرحله مهاجرت قبلی بدون تغییر باقی بمانند:

  • app.yaml باید (هنوز) به بسته‌های همراه شخص ثالث grpcio و setuptools ارجاع دهد.
  • appengine_config.py باید (هنوز) pkg_resources و google.appengine.ext.vendor را به منابع شخص ثالث در lib ارجاع دهد.

حالا بریم سراغ فایل‌های برنامه.

۵. به‌روزرسانی فایل‌های برنامه

هیچ تغییری در template/index.html ایجاد نشده است، اما چند به‌روزرسانی برای main.py وجود دارد.

۱. واردات

کد شروع برای بخش import باید به صورت زیر باشد:

  • قبل از: 
from flask import Flask, render_template, request
from google.cloud import ndb

دستور import google.cloud.ndb را با دستوری برای Cloud Datastore جایگزین کنید: google.cloud.datastore . از آنجا که کتابخانه کلاینت Datastore از ایجاد خودکار فیلد timestamp در یک Entity پشتیبانی نمی‌کند، ماژول datetime کتابخانه استاندارد را نیز برای ایجاد دستی آن وارد کنید. طبق قرارداد، importهای کتابخانه استاندارد بالاتر از importهای بسته‌های شخص ثالث قرار می‌گیرند. وقتی این تغییرات را انجام دادید، باید به این شکل باشد:

  • بعد از: 
from datetime import datetime
from flask import Flask, render_template, request
from google.cloud import datastore

۲. مقداردهی اولیه و مدل داده

پس از مقداردهی اولیه Flask، ماژول ۲ برنامه نمونه، یک کلاس مدل داده NDB ایجاد می‌کند و فیلدهای آن به صورت زیر نمایش داده می‌شوند:

  • قبل از: 
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 "انعطاف‌پذیرتر" است و به شما امکان می‌دهد Entities را بدون "از پیش تعریف کردن" ساختار آنها مانند NDB ایجاد کنید. پس از این به‌روزرسانی، این بخش از main.py باید به شکل زیر باشد:

  • بعد از: 
app = Flask(__name__)
ds_client = datastore.Client()

۳. دسترسی به پایگاه داده

مهاجرت به Cloud Datastore نیازمند تغییر نحوه ایجاد، ذخیره و پرس‌وجو از موجودیت‌های Datastore (در سطح کاربر) است. برای برنامه‌های شما، سختی این مهاجرت به میزان پیچیدگی کد Datastore شما بستگی دارد. در برنامه نمونه ما، تلاش کردیم به‌روزرسانی را تا حد امکان ساده کنیم. کد شروع ما در اینجا آمده است:

  • قبل از: 
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، یک موجودیت عمومی ایجاد کنید و اشیاء گروه‌بندی شده در موجودیت خود را با یک "کلید" مشخص کنید. رکورد داده را با یک شیء JSON ( dict پایتون) از جفت‌های کلید-مقدار ایجاد کنید، سپس آن را با put() مورد انتظار در Datastore بنویسید. پرس‌وجو با Datastore مشابه اما ساده‌تر است. در اینجا می‌توانید تفاوت کد معادل Datastore را ببینید:

  • بعد از: 
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 مجهز شده و آماده آزمایش است.

۶. خلاصه/پاکسازی

استقرار برنامه

برنامه خود را با استفاده از gcloud app deploy دوباره مستقر کنید و تأیید کنید که برنامه کار می‌کند. اکنون کد شما باید با آنچه در پوشه‌های مخزن ماژول ۳ وجود دارد، مطابقت داشته باشد:

اگر بدون انجام هیچ یک از آزمایش‌های کد قبلی وارد این مجموعه شده باشید، خود برنامه تغییری نمی‌کند؛ تمام بازدیدها از صفحه وب اصلی ( / ) را ثبت می‌کند و پس از بازدید کافی از سایت، به این شکل درمی‌آید:

اپلیکیشن ویزیت می

تبریک بابت تکمیل این آزمایشگاه کد ماژول ۳. اکنون می‌دانید که می‌توانید از هر دو کتابخانه کلاینت Cloud NDB و Cloud Datastore برای دسترسی به 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 ندارید
    • مستلزم آن است که برنامه خود را از قبل به پایتون ۳ منتقل کرده باشید
  • ماژول 6: مهاجرت به Cloud Firestore
    • برای دسترسی به ویژگی‌های فایربیس به کلود فایراستور مهاجرت کنید
    • در حالی که Cloud Firestore از پایتون ۲ پشتیبانی می‌کند، این codelab فقط در پایتون ۳ موجود است.

۷. نکته‌ی اضافه: مهاجرت به پایتون ۳

برای دسترسی به جدیدترین نسخه زمان اجرا و ویژگی‌های App Engine، توصیه می‌کنیم به پایتون ۳ مهاجرت کنید. در برنامه نمونه ما، Datastore تنها سرویس داخلی بود که ما استفاده کردیم و از آنجایی که ما از ndb به Cloud NDB مهاجرت کرده‌ایم، اکنون می‌توانیم آن را به زمان اجرا پایتون ۳ App Engine منتقل کنیم.

نمای کلی

اگرچه انتقال به پایتون ۳ در محدوده آموزش Google Cloud نیست، اما این بخش از codelab به توسعه‌دهندگان ایده‌ای از تفاوت‌های زمان اجرای موتور برنامه پایتون ۳ می‌دهد. یکی از ویژگی‌های برجسته زمان اجرای نسل بعدی، دسترسی ساده به بسته‌های شخص ثالث است: نیازی به مشخص کردن بسته‌های داخلی در app.yaml یا کپی یا آپلود کتابخانه‌های غیر داخلی نیست؛ آنها به طور ضمنی از فهرست شدن در requirements.txt نصب می‌شوند.

از آنجا که نمونه ما بسیار ابتدایی است و Cloud Datastore با پایتون ۲-۳ سازگار است، نیازی نیست هیچ کد برنامه‌ای به صراحت به ۳.x منتقل شود: برنامه روی ۲.x و ۳.x بدون تغییر اجرا می‌شود، به این معنی که در این مورد تنها تغییرات مورد نیاز در پیکربندی هستند:

  1. app.yaml طوری ساده کنید که به پایتون ۳ ارجاع دهد و ارجاع به کتابخانه‌های شخص ثالث همراه آن را حذف کند.
  2. appengine_config.py و پوشه lib را حذف کنید زیرا دیگر نیازی به آنها نیست.

فایل‌های برنامه main.py و templates/index.html بدون تغییر باقی می‌مانند.

requirements.txt به‌روزرسانی.txt

نسخه نهایی Cloud Datastore که از پایتون ۲ پشتیبانی می‌کند، ۱.۱۵.۳ است. requirements.txt را با آخرین نسخه پایتون ۳ (که ممکن است اکنون جدیدتر باشد) به‌روزرسانی کنید. در زمان نگارش این آموزش، آخرین نسخه ۲.۱.۰ بود، بنابراین آن خط را به این شکل (یا هر نسخه دیگری که آخرین نسخه است) ویرایش کنید: 

google-cloud-datastore==2.1.0

ساده‌سازی app.yaml

قبل از:

تنها تغییر واقعی برای این برنامه نمونه، کوتاه‌تر کردن قابل توجه app.yaml است. به عنوان یادآوری، این چیزی است که ما در پایان ماژول 3 در 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 به صفحه مرجع app.yaml مراجعه کنید.

حذف دستورالعمل‌های 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.yaml مراجعه کنید. مثال‌ها و بهترین شیوه‌های بیشتر را می‌توانید در اسناد راه‌اندازی محیط استاندارد App Engine و همچنین اسناد راه‌اندازی محیط انعطاف‌پذیر App Engine بیابید.

appengine_config.py و lib را حذف کنید

فایل appengine_config.py و پوشه lib را حذف کنید. در مهاجرت به پایتون ۳، App Engine بسته‌های ذکر شده در requirements.txt را دریافت و نصب می‌کند.

فایل پیکربندی appengine_config.py برای شناسایی کتابخانه‌ها/بسته‌های شخص ثالث استفاده می‌شود، چه خودتان آنها را کپی کرده باشید و چه از آنهایی که از قبل روی سرورهای App Engine (داخلی) موجود هستند استفاده کنید. هنگام انتقال به پایتون ۳، خلاصه‌ای از تغییرات بزرگ عبارتند از:

  1. عدم نیاز به بسته‌بندی کتابخانه‌های کپی‌شده‌ی شخص ثالث (که در requirements.txt ذکر شده است)
  2. بدون pip install در پوشه lib ، به این معنی که دوره پوشه lib وجود ندارد
  3. عدم فهرست‌بندی کتابخانه‌های شخص ثالث داخلی در app.yaml
  4. نیازی به ارجاع برنامه به کتابخانه‌های شخص ثالث نیست، بنابراین نیازی به فایل appengine_config.py نیست.

تنها کاری که لازم است، فهرست کردن تمام کتابخانه‌های شخص ثالث مورد نیاز در requirements.txt است.

استقرار برنامه

برنامه خود را دوباره مستقر کنید تا مطمئن شوید که کار می‌کند. همچنین می‌توانید تأیید کنید که راه‌حل شما چقدر به کد پایتون ۳ نمونه ماژول ۳ نزدیک است. برای تجسم تفاوت‌ها با پایتون ۲، کد را با نسخه پایتون ۲ آن مقایسه کنید.

تبریک می‌گویم که مرحله‌ی اضافی در ماژول ۳ را به پایان رساندید! به مستندات مربوط به آماده‌سازی فایل‌های پیکربندی برای زمان اجرای پایتون ۳ مراجعه کنید. در نهایت، خلاصه‌ی قبلی بالا را برای مراحل بعدی و پاکسازی مرور کنید.

آماده‌سازی درخواست شما

وقتی زمان مهاجرت برنامه‌تان فرا برسد، باید main.py و سایر فایل‌های برنامه‌تان را به نسخه ۳.x منتقل کنید، بنابراین بهترین روش این است که تمام تلاش خود را بکنید تا برنامه ۲.x شما تا حد امکان «سازگار با نسخه‌های قبلی» باشد.

منابع آنلاین زیادی برای کمک به شما در انجام این کار وجود دارد، اما برخی از نکات کلیدی:

  1. اطمینان حاصل کنید که تمام وابستگی‌های برنامه کاملاً با نسخه ۳.x سازگار هستند.
  2. مطمئن شوید که برنامه شما حداقل روی نسخه ۲.۶ (ترجیحاً ۲.۷) اجرا می‌شود.
  3. اطمینان حاصل کنید که برنامه از کل مجموعه تست (و حداقل 80٪ پوشش) عبور می‌کند.
  4. از کتابخانه‌های سازگاری مانند six ، Future و/یا Modernize استفاده کنید
  5. در مورد تفاوت‌های کلیدی ناسازگاری نسخه‌های ۲.x و ۳.x با نسخه‌های قبلی، اطلاعات کسب کنید.
  6. هرگونه ورودی/خروجی احتمالاً منجر به ناسازگاری یونیکد در مقابل رشته بایت خواهد شد.

برنامه نمونه با در نظر گرفتن همه این موارد طراحی شده است، به همین دلیل است که برنامه از همان ابتدا روی نسخه ۲.x و ۳.x اجرا می‌شود تا بتوانیم روی نشان دادن آنچه که برای استفاده از پلتفرم نسل بعدی باید تغییر کند، تمرکز کنیم.

۸. منابع اضافی

مشکلات/بازخورد ماژول مهاجرت موتور برنامه در codelabs

اگر در این آزمایشگاه کد مشکلی پیدا کردید، لطفاً قبل از ثبت، ابتدا مشکل خود را جستجو کنید. لینک‌های جستجو و ایجاد مشکلات جدید:

منابع مهاجرت

لینک‌های پوشه‌های مخزن ماژول ۲ (START) و ماژول ۳ (FINISH) را می‌توانید در جدول زیر پیدا کنید. همچنین می‌توانید از مخزن مربوط به همه مهاجرت‌های App Engine که می‌توانید آن‌ها را کلون کنید یا یک فایل ZIP دانلود کنید، به آن‌ها دسترسی داشته باشید.

کدلب

پایتون ۲

پایتون ۳

ماژول ۲

کد

کد

ماژول ۳

کد

کد

منابع موتور برنامه

در زیر منابع بیشتری در مورد این مهاجرت خاص آمده است: