ماژول 5: مهاجرت از Google App Engine به Cloud Run با Cloud Buildpacks

۱. مرور کلی

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

این آموزش به شما آموزش می‌دهد که چگونه برنامه‌های App Engine را برای استقرار در سرویس کاملاً مدیریت‌شده Cloud Run با استفاده از Cloud Buildpacks ، جایگزینی برای Docker، کانتینرایز کنید. Cloud Buildpacks برنامه‌های شما را بدون مدیریت فایل‌های Dockerfile یا حتی دانستن چیزی در مورد Docker کانتینرایز می‌کند.

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

توجه: Cloud Buildpacks فقط از پایتون ۳.۷+ (به‌علاوه Go 1.10+، Node.js 10+، جاوا ۸ و ۱۱ و .NET Core 3.1+) پشتیبانی می‌کند، به این معنی که برنامه‌های Python 2 App Engine باید قبل از استفاده از Cloud Buildpacks به ۳.x منتقل شوند. اگر می‌خواهید یک برنامه ۲.x را کانتینرایز کنید، باید از Docker استفاده کنید. توصیه می‌کنیم فعلاً از این آموزش صرف‌نظر کنید و به آزمایشگاه کد ماژول ۴ بروید: از Google App Engine به Cloud Run با Docker مهاجرت کنید .

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

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

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

• یک پروژه پلتفرم ابری گوگل با:
  • یک حساب صورتحساب فعال GCP
  • موتور برنامه فعال شد
• مهارت‌های پایه پایتون
• آشنایی کامل با دستورات رایج لینوکس
• دانش پایه در توسعه و استقرار برنامه‌های App Engine
• توصیه می‌شود قبل از شروع این بخش (بخش ۵)، یکی (یا هر دو) از آزمایشگاه‌های کد ماژول ۲ یا ماژول ۳ ، از جمله انتقال آنها به پایتون ۳ را تکمیل کنید.
• یک برنامه‌ی کاربردی با موتور برنامه‌ی پایتون ۳ که آماده‌ی کانتینرایز شدن است
  • ماژول 2 نمونه NDB ابری یا
  • نمونه ماژول ۳ پایگاه داده ابری

نظرسنجی

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

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

۲. پیشینه

سیستم‌های 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 را حذف کنید، یک وب سرور را مدیریت کنید، و همچنین نحوه شروع برنامه خود را بیاموزید.

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

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

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

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

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

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

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

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

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

• شروع:
  • کد ماژول ۲ برای NDB ابری
  • فروشگاه داده ابری: کد ماژول ۳
• پایان: کد ماژول ۵
• کل مخزن (برای کلون کردن یا دانلود فایل زیپ)

دایرکتوری فایل‌های START (مال شما یا مال ما) باید به این شکل باشد:

$ 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 ماژول ۴ را انجام دهید. این بخش مشابه این بخش است، اما از داکر برای درک عمیق‌تر نحوه مدیریت تصاویر کانتینر استفاده می‌کند.

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

توضیحات	موتور برنامه	داکر	بسته‌های ساخت
پیکربندی عمومی	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 به طور خودکار برنامه شما را اجرا می‌کند، اما Cloud Run این کار را نمی‌کند. Procfile نقشی مشابه دستورالعمل app.yaml entrypoint ایفا می‌کند. برای برنامه نمونه ما، Procfile ما python main.py برای شروع سرور توسعه Flask اجرا می‌کند. در صورت تمایل می‌توانید از یک وب سرور عملیاتی مانند gunicorn نیز استفاده کنید و اگر این کار را می‌کنید، حتماً آن را به requirements.txt اضافه کنید. برای کسب اطلاعات بیشتر در مورد نحوه استقرار از کد منبع با استفاده از Buildpacks به این صفحه مستندات Cloud Run مراجعه کنید.

شما فقط باید دستورالعمل app.yaml entrypoint خود را به یک Procfile منتقل کنید. اگر چنین سروری ندارید، فعلاً از سرور توسعه Flask استفاده کنید زیرا این فقط یک برنامه آزمایشی نمونه برای آشنایی کاربران با این مهاجرت است. برنامه شما یک دستور راه‌اندازی خاص خواهد بود که شما بهتر آن را می‌شناسید. در پشت صحنه، سرویس Cloud Run یک service.yaml ایجاد می‌کند که بیشتر شبیه app.yaml به نظر می‌رسد/عمل می‌کند. می‌توانید service.yaml تولید شده خودکار را با مراجعه به لینکی مانند این مشاهده کنید، اما برای سرویس شما SVC_NAME و REGION : https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view .

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

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

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

Buildpacks از پایتون ۲ پشتیبانی نمی‌کند، بنابراین ما اینجا در مورد آن بحث نمی‌کنیم. برنامه‌های پایتون ۳ که در کانتینرها در Cloud Run اجرا می‌شوند، مشابه برنامه‌های App Engine پایتون ۳ هستند، به این صورت که کتابخانه‌های شخص ثالث باید در requirements.txt مشخص شوند.

استارتاپ

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

runtime: python38
entrypoint: python main.py

دستور entrypoint به App Engine می‌گوید که چگونه سرور شما را راه‌اندازی کند. می‌توانید آن را تقریباً مستقیماً به Procfile خود منتقل کنید. خلاصه اینکه یک دستور entrypoint بین هر دو پلتفرم کجا قرار می‌گیرد: این به طور مستقیم به شکل زیر ترجمه می‌شود؛ همچنین معادل Docker آن را به عنوان اطلاعات بیشتر نشان می‌دهد:

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

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

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

تمام برنامه‌های ماژول ۲ یا ماژول ۳ کاملاً با پایتون ۲-۳ سازگار هستند، به این معنی که هیچ تغییری در اجزای اصلی 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)))

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

با جایگزینی پیکربندی App Engine با Buildpacks و تکمیل به‌روزرسانی‌های فایل منبع، آماده اجرای آن در 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 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 Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] 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 کار می‌کرد، کار می‌کند. اگر بدون انجام هیچ یک از آزمایش‌های کد قبلی وارد این مجموعه شده‌اید، خود برنامه تغییر نمی‌کند؛ تمام بازدیدها از صفحه وب اصلی ( / ) را ثبت می‌کند و پس از بازدید کافی از سایت، به این شکل به نظر می‌رسد:

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

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

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

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

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

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

مراحل بعدی

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

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

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

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

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

• ردیاب مشکل برای آزمایشگاه‌های کد مهاجرت App Engine
  • جستجوی مسائل
  • ثبت مشکل/بازخورد جدید

منابع مهاجرت

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

کدلب	پایتون ۲	پایتون ۳
ماژول ۲	کد	( کد )
ماژول ۳	( کد )	کد
ماژول ۵	(نامشخص)	کد

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

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

• ظروف
  • گوگل کلود ران
  • ساخت فضای ابری گوگل
  • رجیستری کانتینرهای ابری گوگل
  • داکر
  • پست راه‌اندازی Cloud Buildpacks
  • پست استقرار Cloud Buildpacks
  • مخزن Cloud Buildpacks
  • مشخصات بسته‌های ساخت CNCF
  • ابزار App Engine to Cloud Run — برای تولید service.yaml خودتان
• عمومی
  • پایتون در پلتفرم ابری گوگل
  • کتابخانه‌های کلاینت پایتون گوگل کلود