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

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

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

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

این کد برای توسعه دهندگان Python 2 App Engine است که برنامه های خود را از سرویس های داخلی اصلی دور کرده و آنها را به Python 3 منتقل کرده اند و اکنون به دنبال اجرای آنها در یک کانتینر هستند. نرم افزار کد با یک برنامه تکمیل شده ماژول 2 یا ماژول 3 پایتون 3 شروع می شود.

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

  • برنامه خود را با استفاده از Cloud Buildpacks کانتینری کنید
  • استقرار تصاویر کانتینر در 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، مدیریت وب سرور، از جمله نحوه راه اندازی برنامه را خواهید آموخت.

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

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

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

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

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

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

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

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

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

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

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

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

توضیحات

موتور برنامه

داکر

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 به طور خودکار برنامه شما را راه اندازی می کند، اما 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 است. می‌توانید با مراجعه به پیوندی مانند این، اما برای سرویس SVC_NAME و REGION ، service.yaml تولید شده را مشاهده کنید: 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 از Python 2 پشتیبانی نمی کند، بنابراین ما در اینجا در مورد آن بحث نمی کنیم. برنامه‌های Python 3 که در کانتینرها در Cloud Run اجرا می‌شوند مشابه برنامه‌های Python 3 App Engine هستند، زیرا کتابخانه‌های شخص ثالث باید در requirements.txt مشخص شوند.

راه اندازی

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

runtime: python38
entrypoint: python main.py

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

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

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

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

همه برنامه های ماژول 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. ساخت و استقرار

با جایگزینی پیکربندی App Engine شما با Buildpacks و تکمیل به‌روزرسانی فایل منبع، آماده اجرای آن در 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 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

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

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

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

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

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

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

برنامه visitme

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

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

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

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

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

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

مراحل بعدی

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

  • ماژول 4: با Docker به Cloud Run مهاجرت کنید
    • برنامه خود را برای اجرا در Cloud Run with Docker محفظه کنید
    • به شما امکان می دهد در پایتون 2 بمانید
  • ماژول 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) و ماژول 5 (FINISH) را می‌توانید در جدول زیر مشاهده کنید. همچنین می‌توانید از مخزن برای همه انتقال‌های نرم‌افزار App Engine که می‌توانید یک فایل ZIP را شبیه‌سازی یا دانلود کنید، دسترسی پیدا کنید.

Codelab

پایتون 2

پایتون 3

ماژول 2

کد

( کد )

ماژول 3

( کد )

کد

ماژول 5

(n/a)

کد

منابع App Engine و Cloud Run

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