ماژول 4: از Google App Engine به Cloud Run با داکر مهاجرت کنید

۱. مرور کلی

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

این آموزش به شما آموزش می‌دهد که چگونه برنامه‌های App Engine را برای استقرار در سرویس کاملاً مدیریت‌شده Cloud Run با استفاده از Docker ، که یک پلتفرم شناخته‌شده در صنعت برای توسعه، ارسال و اجرای برنامه‌ها در کانتینرها است، کانتینرایز کنید. برای توسعه‌دهندگان پایتون ۲، این آموزش با نمونه برنامه Module 2 Cloud NDB App Engine شروع می‌شود در حالی که توسعه‌دهندگان پایتون ۳ با نمونه Module 3 Cloud Datastore شروع می‌کنند.

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

  • برنامه خود را با استفاده از Docker کانتینرایز کنید
  • تصاویر کانتینر را در Cloud Run مستقر کنید

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

نظرسنجی

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

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

۲. پیشینه

سیستم‌های PaaS مانند App Engine و Cloud Functions امکانات زیادی را برای تیم و برنامه شما فراهم می‌کنند. به عنوان مثال، این پلتفرم‌های بدون سرور، SysAdmin/Devops را قادر می‌سازند تا بر روی ساخت راه‌حل‌ها تمرکز کنند. برنامه شما می‌تواند در صورت نیاز به صورت خودکار مقیاس‌بندی شود، با پرداخت به ازای هر استفاده، مقیاس‌بندی به صفر برسد و به کنترل هزینه‌ها کمک کند و از انواع زبان‌های توسعه رایج استفاده می‌کند.

با این حال، انعطاف‌پذیری کانتینرها نیز جذاب است، امکان انتخاب هر زبان، هر کتابخانه، هر باینری. ارائه بهترین‌های هر دو جهان، راحتی بدون سرور در کنار انعطاف‌پذیری کانتینرها، همان چیزی است که Google Cloud Run در مورد آن صحبت می‌کند.

یادگیری نحوه استفاده از Cloud Run در محدوده این codelab نیست؛ این موضوع در مستندات Cloud Run پوشش داده شده است. هدف اینجا این است که شما بدانید چگونه برنامه App Engine خود را برای Cloud Run (یا سایر سرویس‌ها) کانتینرایز کنید. چند نکته وجود دارد که قبل از ادامه باید بدانید، در درجه اول اینکه تجربه کاربری شما کمی متفاوت خواهد بود، کمی سطح پایین‌تر، زیرا دیگر کد برنامه را دریافت و مستقر نخواهید کرد.

در عوض، باید چیزهایی در مورد کانتینرها، مثلاً نحوه ساخت و استقرار آنها، یاد بگیرید. همچنین می‌توانید تصمیم بگیرید که چه چیزی را می‌خواهید در تصویر کانتینر قرار دهید، از جمله یک وب سرور، زیرا دیگر از وب سرور App Engine استفاده نخواهید کرد. اگر ترجیح می‌دهید این مسیر را دنبال نکنید، نگه داشتن برنامه‌هایتان در App Engine گزینه بدی نیست.

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

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

  1. راه‌اندازی/پیش‌پردازش
  2. کانتینر کردن برنامه
    • جایگزینی فایل‌های پیکربندی
    • تغییر فایل‌های برنامه

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

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

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

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

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

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

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

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

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

اگر از کد ماژول ۲ (۲.x) خودتان استفاده می‌کنید، یک پوشه lib نیز خواهید داشت. نه lib و نه appengine_config.py برای پایتون ۳ استفاده نمی‌شوند، جایی که کد STARTing ماژول ۳ (۳.x) باید به این شکل باشد:

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

۳. (دوباره) استقرار برنامه پایه

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

  1. با ابزار خط فرمان gcloud دوباره آشنا شوید
  2. برنامه نمونه را با استفاده از gcloud app deploy دوباره مستقر کنید
  3. تأیید کنید که برنامه بدون مشکل در App Engine اجرا می‌شود.

وقتی این مراحل را با موفقیت انجام دادید، آماده‌ی کانتینرایز کردن آن هستید.

۴. کانتینریزه کردن برنامه

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

اگر از قبل با کانتینرها و داکر آشنا هستید و می‌خواهید در مورد کانتینریزه کردن برنامه App Engine خود برای Cloud Run بیشتر بدانید، به جای درستی آمده‌اید. می‌توانید بعداً Codelab ماژول ۵ (مشابه این یکی اما با Cloud Buildpacks) را نیز انجام دهید. برنامه نمونه barebones ما به اندازه کافی سبک است تا از برخی از مشکلات Dockerfile که قبلاً ذکر شد، جلوگیری کند.

مراحل مهاجرت شامل جایگزینی فایل‌های پیکربندی App Engine و مشخص کردن نحوه شروع برنامه شما است. در زیر جدولی آمده است که فایل‌های پیکربندی مورد انتظار برای هر نوع پلتفرم را خلاصه می‌کند. ستون App Engine را با ستون Docker (و به صورت اختیاری Buildpacks) مقایسه کنید:

توضیحات

موتور برنامه

داکر

بسته‌های ساخت

پیکربندی عمومی

app.yaml

Dockerfile

( service.yaml )

کتابخانه‌های شخص ثالث

requirements.txt

requirements.txt

requirements.txt

پیکربندی شخص ثالث

app.yaml (به‌علاوه‌ی appengine_config.py و lib [فقط نسخه ۲.x])

(نامشخص)

(نامشخص)

استارتاپ

(ناموجود) یا app.yaml (در صورت استفاده entrypoint )

Dockerfile

Procfile

نادیده گرفتن فایل‌ها

.gcloudignore و .gitignore

.gcloudignore ‎، .gitignore ‎ و .dockerignore

.gcloudignore و .gitignore

پس از اینکه برنامه شما کانتینری شد، می‌توان آن را در Cloud Run مستقر کرد. سایر گزینه‌های پلتفرم کانتینر Google Cloud شامل Compute Engine ، GKE و Anthos است.

پیکربندی عمومی

مهاجرت از App Engine به معنای جایگزینی app.yaml با یک Dockerfile است که نحوه ساخت و اجرای کانتینر را شرح می‌دهد. App Engine به طور خودکار برنامه شما را اجرا می‌کند، اما Cloud Run این کار را نمی‌کند. دستورات ENTRYPOINT و CMD مربوط به Dockerfile برای همین کار هستند. برای کسب اطلاعات بیشتر در مورد Dockerfile به این صفحه مستندات Cloud Run مراجعه کنید و همچنین یک نمونه Dockerfile که gunicorn ایجاد می‌کند را ببینید.

یک جایگزین برای استفاده از ENTRYPOINT یا CMD در Dockerfile ، استفاده از Procfile است. در نهایت، یک .dockerignore به فیلتر کردن فایل‌های غیر برنامه‌ای کمک می‌کند تا اندازه کانتینر شما پایین بماند. در ادامه بیشتر در این مورد صحبت خواهیم کرد!

app.yaml حذف کنید و Dockerfile را ایجاد کنید

فایل app.yaml در کانتینرها استفاده نمی‌شود، بنابراین آن را حذف کنید . فایل پیکربندی کانتینر Dockerfile است و برنامه نمونه ما فقط به یک نسخه حداقلی از آن نیاز دارد. Dockerfile خود را با این محتوا ایجاد کنید و NNN با 2 یا 3 جایگزین کنید، بسته به اینکه از کدام نسخه پایتون استفاده می‌کنید:

FROM python:NNN-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
ENTRYPOINT ["python", "main.py"]

بیشتر Dockerfile نحوه ایجاد کانتینر را مشخص می‌کند، به جز ENTRYPOINT که نحوه شروع کانتینر را مشخص می‌کند، در این حالت python main.py برای اجرای سرور توسعه Flask فراخوانی می‌کند. اگر در Docker تازه‌کار هستید، دستورالعمل FROM نشان دهنده تصویر پایه برای شروع است و "slim" به توزیع حداقلی پایتون اشاره دارد. برای اطلاعات بیشتر به صفحه تصاویر پایتون Docker مراجعه کنید.

مجموعه میانی دستورات، دایرکتوری کاری ( /app ) را ایجاد می‌کند، فایل‌های برنامه را در آن کپی می‌کند، سپس pip install اجرا می‌کند تا کتابخانه‌های شخص ثالث را به کانتینر بیاورد. WORKDIR دستورات mkdir و cd لینوکس را با هم ترکیب می‌کند؛ برای اطلاعات بیشتر به مستندات WORKDIR مراجعه کنید. دستورالعمل‌های COPY و RUN نیازی به توضیح ندارند.

کتابخانه‌های شخص ثالث

فایل requirements.txt می‌تواند ثابت بماند؛ Flask باید به همراه کتابخانه کلاینت Datastore شما (Cloud Datastore یا Cloud NDB) آنجا باشد. اگر می‌خواهید از یک سرور HTTP سازگار با WSGI دیگر مانند Gunicorn استفاده کنید - نسخه فعلی در زمان نوشتن این مطلب 20.0.4 است - سپس gunicorn==20.0.4 به requirements.txt اضافه کنید.

پیکربندی شخص ثالث

توسعه‌دهندگان App Engine پایتون ۲ می‌دانند که کتابخانه‌های شخص ثالث یا در پوشه lib کپی می‌شوند، در requirements.txt به آنها ارجاع داده می‌شود، در app.yaml به صورت جزء به جزء ذکر می‌شوند و توسط appengine_config.py پشتیبانی می‌شوند. کانتینرها، مانند برنامه‌های App Engine پایتون ۳، فقط از requirements.txt استفاده می‌کنند، بنابراین همه موارد دیگر قابل حذف هستند، به این معنی که اگر یک برنامه App Engine پایتون ۲.x دارید، appengine_config.py و هر پوشه lib دیگری را اکنون حذف کنید .

استارتاپ

کاربران پایتون ۲ وب سرور App Engine را راه‌اندازی نمی‌کنند، اما هنگام انتقال به یک کانتینر، باید این کار را انجام دهید. این کار با اضافه کردن یک دستورالعمل CMD یا ENTRYPOINT در Dockerfile شما انجام می‌شود که نحوه شروع برنامه شما را مشخص می‌کند و این کار در زیر به همان روشی که برای کاربران پایتون ۳ توضیح داده شد، توضیح داده شده است.

کاربران پایتون ۳ می‌توانند فایل‌های app.yaml خود را طوری تغییر دهند که به جای دستورالعمل‌های script: auto در بخش handlers ، یک entrypoint داشته باشند. اگر entrypoint در app.yaml پایتون ۳ خود استفاده کنید، چیزی شبیه به این خواهد بود:

runtime: python38
entrypoint: python main.py

دستورالعمل entrypoint به App Engine می‌گوید که چگونه سرور شما را راه‌اندازی کند. می‌توانید آن را تقریباً مستقیماً به Dockerfile خود (یا Procfile در صورت استفاده از Buildpacks [به ماژول 5 مراجعه کنید] برای کانتینرایز کردن برنامه خود) منتقل کنید. خلاصه اینکه یک دستورالعمل entrypoint بین هر دو پلتفرم کجا قرار می‌گیرد:

  • داکر: خط در Dockerfile : ENTRYPOINT ["python", "main.py"]
  • بسته‌های ساخت: خط در Procfile : web: python main.py

استفاده از سرور توسعه Flask برای آزمایش مناسب است، اما اگر از یک سرور عملیاتی مانند gunicorn برای برنامه خود استفاده می‌کنید، حتماً دستورالعمل ENTRYPOINT یا CMD خود را مانند نمونه Cloud Run Quickstart به آن ارجاع دهید.

نادیده گرفتن فایل‌ها

توصیه می‌کنیم یک فایل .dockerignore ایجاد کنید تا اندازه کانتینر خود را کاهش دهید و تصویر کانتینر خود را با فایل‌های اضافی مانند این‌ها شلوغ نکنید:

*.md
*.pyc
*.pyo
.git/
.gitignore
__pycache__

فایل‌های برنامه

تمام برنامه‌های ماژول ۲ یا ماژول ۳ کاملاً با پایتون ۲-۳ سازگار هستند، به این معنی که هیچ تغییری در اجزای اصلی main.py ایجاد نمی‌شود؛ ما فقط چند خط کد راه‌اندازی اضافه خواهیم کرد. برای شروع سرور توسعه، دو خط در پایین main.py اضافه کنید زیرا Cloud Run برای فراخوانی برنامه شما به پورت ۸۰۸۰ نیاز دارد:

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

۵. ساخت و استقرار

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

سرویس‌ها در مقابل اپلیکیشن‌ها

اگرچه App Engine در درجه اول برای میزبانی برنامه‌ها ایجاد شده است، اما بستری برای میزبانی سرویس‌های وب یا برنامه‌هایی است که از مجموعه‌ای از میکروسرویس‌ها تشکیل شده‌اند . در Cloud Run، همه چیز یک سرویس است، چه یک سرویس واقعی باشد و چه یک برنامه با رابط وب، بنابراین استفاده از آن را به عنوان استقرار یک سرویس در نظر بگیرید نه یک برنامه.

مگر اینکه برنامه App Engine شما از چندین سرویس تشکیل شده باشد، در غیر این صورت واقعاً نیازی به نامگذاری هنگام استقرار برنامه‌های خود نداشتید. این موضوع با Cloud Run تغییر می‌کند، جایی که باید نام سرویس را انتخاب کنید. در حالی که دامنه appspot.com یک App Engine شامل شناسه پروژه آن است، مثلاً https://PROJECT_ID.appspot.com ، و شاید مخفف شناسه منطقه آن باشد، مثلاً http://PROJECT_ID.REGION_ID.r.appspot.com .

با این حال، دامنه سرویس Cloud Run شامل نام سرویس ، مخفف شناسه منطقه و یک هش است، اما شناسه پروژه را شامل نمی‌شود، مثلاً https://SVC_NAME-HASH-REG_ABBR.a.run.app . در نهایت، از همین حالا به فکر نام سرویس باشید!

استقرار سرویس

دستور زیر را اجرا کنید تا تصویر کانتینر خود را بسازید و در Cloud Run مستقر کنید. در صورت درخواست، منطقه خود را انتخاب کنید و برای آزمایش آسان‌تر، اتصالات غیرمجاز را مجاز کنید و منطقه خود را به صورت مناسب انتخاب کنید که در آن SVC_NAME نام سرویسی است که شما مستقر می‌کنید.

$ gcloud beta run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Dockerfile and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying new service... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision... Deploying Revision.
  ✓ Routing traffic...
  ✓ Setting IAM Policy...
Done.
Service [SVC_NAME] revision [SVC_NAME-00001-vos] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

برای تأیید موفقیت‌آمیز بودن استقرار، با مرورگر خود به آدرس اینترنتی مشخص شده مراجعه کنید!

همانطور که دستور gcloud نشان می‌دهد، کاربران می‌توانند تنظیمات پیش‌فرض مختلفی را برای کاهش خروجی و تعامل، همانطور که در بالا نشان داده شده است، تنظیم کنند. به عنوان مثال، برای جلوگیری از هرگونه تعامل، می‌توانید از دستور deploy تک‌خطی زیر استفاده کنید:

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

اگر از این مورد استفاده می‌کنید، حتماً نام سرویس SVC_NAME و نام REGION مورد نظر را انتخاب کنید، نه انتخاب منوی فهرست‌بندی شده که به صورت تعاملی در بالا انجام دادیم.

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

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

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

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

اختیاری: تمیز کردن

در مورد پاکسازی برای جلوگیری از پرداخت هزینه تا زمانی که آماده انتقال به آزمایشگاه کد مهاجرت بعدی هستید، چطور؟ از آنجایی که اکنون از محصول دیگری استفاده می‌کنید، حتماً راهنمای قیمت‌گذاری Cloud Run را مرور کنید.

اختیاری: غیرفعال کردن سرویس

اگر هنوز آماده رفتن به آموزش بعدی نیستید، سرویس خود را غیرفعال کنید تا از هزینه‌های اضافی جلوگیری شود. وقتی آماده رفتن به آزمایشگاه کد بعدی شدید، می‌توانید دوباره آن را فعال کنید. در حالی که برنامه شما غیرفعال است، هیچ ترافیکی دریافت نمی‌کند که هزینه‌ای داشته باشد، با این حال مورد دیگری که ممکن است برای آن هزینه دریافت کنید، استفاده از Datastore شما در صورت تجاوز از سهمیه رایگان است، بنابراین به اندازه‌ای حذف کنید که زیر آن محدودیت قرار گیرد.

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

مراحل بعدی

تبریک می‌گویم، شما برنامه خود را کانتینرایز کرده‌اید، که این آموزش را به پایان می‌رساند! از اینجا به بعد، مرحله بعدی یادگیری نحوه انجام همین کار با Cloud Buildpacks در آزمایشگاه کد ماژول ۵ (لینک زیر) یا کار از طریق مهاجرت App Engine دیگر است:

  • اگر هنوز به پایتون ۳ مهاجرت نکرده‌اید، به آن مهاجرت کنید . برنامه نمونه از قبل با نسخه‌های ۲.x و ۳.x سازگار است، بنابراین تنها تغییر این است که کاربران داکر، Dockerfile خود را برای استفاده از تصویر پایتون ۳ به‌روزرسانی کنند.
  • ماژول 5: مهاجرت به Cloud Run با Cloud Buildpacks
    • با استفاده از Cloud Buildpacks، برنامه خود را برای اجرا در Cloud Run کانتینرایز کنید
    • نیازی نیست چیزی در مورد داکر، کانتینرها یا Dockerfile بدانید
    • مستلزم آن است که برنامه خود را از قبل به پایتون ۳ منتقل کرده باشید
  • ماژول 7: صف‌های وظیفه Push Engine App (در صورت استفاده از صف‌های وظیفه [push] الزامی است)
    • وظایف ارسالی صف taskqueue موتور برنامه را به ماژول ۱ برنامه اضافه می‌کند.
    • کاربران را برای مهاجرت به وظایف ابری در ماژول ۸ آماده می‌کند.
  • ماژول ۳:
    • دسترسی به Datastore را از Cloud NDB به Cloud Datastore مدرن کنید
    • این کتابخانه‌ای است که برای برنامه‌های App Engine پایتون ۳ و برنامه‌های غیر App Engine استفاده می‌شود.
  • ماژول 6: مهاجرت به Cloud Firestore
    • برای دسترسی به ویژگی‌های فایربیس به کلود فایراستور مهاجرت کنید
    • در حالی که Cloud Firestore از پایتون ۲ پشتیبانی می‌کند، این codelab فقط در پایتون ۳ موجود است.

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

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

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

منابع مهاجرت

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

کدلب

پایتون ۲

پایتون ۳

ماژول ۲

کد

( کد )

ماژول ۳

( کد )

کد

ماژول ۴

کد

کد

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

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