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

1. بررسی اجمالی

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

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

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

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

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

نظرسنجی

چگونه از این کد لبه استفاده خواهید کرد؟

فقط آن را بخوانید آن را بخوانید و تمرینات را کامل کنید

2. پس زمینه

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

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

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

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

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

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

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

3. راه اندازی/پیش کار

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

1. پروژه راه اندازی

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

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

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

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

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

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

اگر از کد ماژول 2 (2.x) خود استفاده می کنید، یک پوشه lib نیز خواهید داشت. نه lib و نه appengine_config.py برای Python 3 استفاده نمی شود، جایی که کد شروع ماژول 3 (3.x) باید به این صورت باشد: 

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

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

مراحل پیش‌کار باقی‌مانده برای اجرا اکنون:

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

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

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

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

اگر قبلاً در مورد کانتینرها، Docker می‌دانید و می‌خواهید درباره کانتینر کردن برنامه App Engine خود برای Cloud Run اطلاعات بیشتری کسب کنید، در جای درستی هستید. با خیال راحت پس از آن، ماژول 5 را نیز انجام دهید. برنامه نمونه barebones ما به اندازه کافی سبک است تا از برخی از مشکلات Dockerfile فوق الذکر جلوگیری کند.

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

توضیحات

موتور برنامه

داکر

Buildpacks

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

app.yaml

Dockerfile

( service.yaml )

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

requirements.txt

requirements.txt

requirements.txt

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

app.yaml (به علاوه appengine_config.py و lib [2.x-only])

(n/a)

(n/a)

راه اندازی

(n/a) یا 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 این کار را نمی کند. این همان چیزی است که دستورات Dockerfile ENTRYPOINT و CMD برای آن هستند. در مورد 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" به توزیع حداقل پایتون اشاره دارد. از صفحه تصاویر داکر پایتون بیشتر بیاموزید.

مجموعه میانی دستورات دایرکتوری کار ( /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 اضافه کنید.

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

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

راه اندازی

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

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

runtime: python38
entrypoint: python main.py

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

  • Docker: خط در Dockerfile : ENTRYPOINT ["python", "main.py"]
  • Buildpacks: خط در Procfile : web: python main.py

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

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

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

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

فایل های کاربردی

همه برنامه های ماژول 2 یا ماژول 3 کاملاً با Python 2-3 سازگار هستند، به این معنی که هیچ تغییری در اجزای اصلی main.py وجود ندارد. ما فقط چند خط کد راه اندازی را اضافه خواهیم کرد. یک جفت خط در پایین main.py اضافه کنید تا سرور توسعه راه اندازی شود زیرا Cloud Run باید درگاه 8080 باز باشد تا بتواند با برنامه شما تماس بگیرد: 

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

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

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

خدمات در مقابل برنامه ها

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

مگر اینکه برنامه App Engine شما از چندین سرویس تشکیل شده باشد، واقعاً نیازی به نامگذاری در هنگام استقرار برنامه های خود ندارید. این با Cloud Run تغییر می‌کند، جایی که باید نام سرویس را پیدا کنید. در حالی که دامنه appspot.com یک App Engine دارای شناسه پروژه خود است، به عنوان مثال، https://PROJECT_ID.appspot.com ، و شاید مخفف ID منطقه باشد، به عنوان مثال، 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

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

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

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

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

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

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

برنامه visitme

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

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

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

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

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

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

مراحل بعدی

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

  • اگر قبلاً این کار را نکرده اید به پایتون 3 مهاجرت کنید . برنامه نمونه در حال حاضر با 2.x و 3.x سازگار است، بنابراین تنها تغییر این است که کاربران Docker Dockerfile خود را برای استفاده از تصویر Python 3 به‌روزرسانی کنند.
  • ماژول 5: با Cloud Buildpacks به Cloud Run مهاجرت کنید
    • برنامه خود را برای اجرا در Cloud Run با Cloud Buildpacks کانتینری کنید
    • نیازی نیست در مورد Docker، کانتینرها یا Dockerfile چیزی بدانید
    • از شما می خواهد که قبلاً برنامه خود را به پایتون 3 منتقل کرده باشید
  • ماژول 7: App Engine Push Task Queues (الزامی در صورت استفاده از [push] Task Queues)
    • وظایف فشار taskqueue موتور برنامه را به برنامه ماژول 1 اضافه می کند
    • کاربران را برای مهاجرت به Cloud Tasks در ماژول 8 آماده می کند
  • ماژول 3:
    • دسترسی به Datastore را از Cloud NDB به Cloud Datastore مدرن کنید
    • این کتابخانه ای است که برای برنامه های Python 3 App Engine و برنامه های غیر App Engine استفاده می شود
  • ماژول 6: مهاجرت به Cloud Firestore
    • برای دسترسی به ویژگی های Firebase به Cloud Firestore مهاجرت کنید
    • در حالی که Cloud Firestore از Python 2 پشتیبانی می کند، این کد لبه فقط در Python 3 در دسترس است.

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

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

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

منابع مهاجرت

پیوندهای پوشه‌های مخزن برای ماژول 2 و 3 (START) و ماژول 4 (FINISH) را می‌توانید در جدول زیر مشاهده کنید. همچنین می‌توانید از مخزن برای همه انتقال‌های نرم‌افزار App Engine که می‌توانید یک فایل ZIP را شبیه‌سازی یا دانلود کنید، دسترسی پیدا کنید.

Codelab

پایتون 2

پایتون 3

ماژول 2

کد

( کد )

ماژول 3

( کد )

کد

ماژول 4

کد

کد

منابع App Engine و Cloud Run

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