ماژول 11: مهاجرت از Google App Engine به Cloud Functions

۱. مرور کلی

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

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

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

  • از پوسته ابری استفاده کنید
  • فعال کردن API ترجمه ابری گوگل
  • درخواست‌های API را تأیید اعتبار کنید
  • تبدیل یک برنامه کوچک App Engine برای اجرا روی Cloud Functions
  • کد خود را در توابع ابری مستقر کنید

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

نظرسنجی

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

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

تجربه خود را با پایتون چگونه ارزیابی می‌کنید؟

تازه کار متوسط ماهر

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

تازه کار متوسط ماهر

۲. پیشینه

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

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

توابع ابری برای استقرار بخش کوچکی از کد است که:

  • بخشی از کل یک برنامه نیست
  • در کل پشته توسعه مورد نیاز نیست
  • در یک برنامه یا بک‌اند تکی از اپلیکیشن‌های موبایل است که روی یک چیز تمرکز دارد

همچنین می‌توانید از توابع ابری برای تقسیم یک برنامه بزرگ و یکپارچه به چندین میکروسرویس استفاده کنید که هر کدام از یک پایگاه داده مشترک مانند Cloud Firestore یا Cloud SQL استفاده می‌کنند. و اگر می‌خواهید تابع یا میکروسرویس شما به صورت کانتینری و بدون سرور در Cloud Run اجرا شود، می‌توانید این کار را نیز انجام دهید.

نمونه برنامه App Engine ما که تقریباً در تمام آموزش‌های مهاجرت نمایش داده شده است، یک برنامه کوتاه با قابلیت‌های اساسی است که به خوبی در Cloud Functions کار می‌کند. در این آموزش، یاد خواهید گرفت که چگونه آن برنامه را برای اجرا روی Cloud Functions تغییر دهید. از دیدگاه App Engine، از آنجا که توابع ساده‌تر از کل برنامه‌ها هستند، تجربه شروع کار شما باید آسان‌تر (و سریع‌تر) و به طور کلی با "سربار" کمتری باشد. این مهاجرت شامل این مراحل است:

  • راه‌اندازی/پیش‌پردازش
  • حذف فایل‌های پیکربندی
  • تغییر فایل‌های برنامه

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

این آزمایشگاه کد با نسخه پایتون ۳ از برنامه نمونه Module 2 Cloud NDB App Engine آغاز می‌شود زیرا Cloud Functions از پایتون ۲ پشتیبانی نمی‌کند. ابتدا، بیایید پروژه خود را راه‌اندازی کنیم، کد را دریافت کنیم، سپس برنامه پایه را مستقر کنیم تا تأیید کنیم که با کد کار شروع می‌کنیم.

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

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

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

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

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

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

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

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

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

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

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

۴. فایل‌های پیکربندی را حذف کنید

فایل app.yaml یک فایل مصنوعی App Engine است که با Cloud Functions استفاده نمی‌شود، بنابراین همین حالا آن را حذف کنید . اگر این کار را انجام نمی‌دهید یا فراموش می‌کنید، ضرری ندارد زیرا Cloud Functions از آن استفاده نمی‌کند. این تنها تغییر پیکربندی است زیرا requirements.txt مشابه ماژول ۲ باقی می‌ماند.

اگر در حال انتقال یک برنامه App Engine پایتون ۲ به پایتون ۳ هستید، در صورت وجود appengine_config.py و پوشه lib را حذف کنید. آنها مصنوعات App Engine هستند که در زمان اجرای پایتون ۳ استفاده نشده‌اند.

۵. فایل‌های برنامه را تغییر دهید

فقط یک فایل برنامه، main.py ، وجود دارد، بنابراین تمام تغییرات لازم برای انتقال به Cloud Functions در این فایل رخ می‌دهد.

واردات

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

از آنجا که چارچوب‌های وب بخشی از چشم‌انداز توابع ابری نیستند، هیچ ایمپورتی از Flask وجود ندارد ، مگر اینکه برنامه شما از سایر ویژگی‌های Flask استفاده کند. در واقع این مورد ما است زیرا رندر قالب پس از تبدیل به یک تابع هنوز در حال انجام است، به این معنی که فراخوانی flask.render_template() هنوز مورد نیاز است، بنابراین ایمپورت آن از Flask انجام می‌شود. عدم وجود چارچوب وب به این معنی است که نیازی به نمونه‌سازی یک برنامه Flask نیست، بنابراین app = Flask(__name__) را حذف کنید. کد شما قبل و بعد از اعمال تغییرات به شکل زیر خواهد بود:

قبل از:

from flask import Flask, render_template, request
from google.cloud import ndb

app = Flask(__name__)
ds_client = ndb.Client()

بعد از:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

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

به‌روزرسانی امضای تابع کنترل‌کننده اصلی

تغییرات مورد نیاز در امضای تابع به شرح زیر است:

  1. فلسک پس از تبدیل برنامه به یک تابع ابری دیگر استفاده نمی‌شود، بنابراین دکوراتورهای مسیر را حذف کنید.
  2. توابع ابری به طور خودکار شیء Request فلاسک را به عنوان پارامتر ارسال می‌کنند، بنابراین یک متغیر برای آن ایجاد کنید. در برنامه نمونه ما، آن را request می‌نامیم.
  3. توابع ابری مستقر شده باید نامگذاری شوند. هندلر اصلی ما در App Engine به طور مناسب root() نامگذاری شده است تا توصیف کند که چیست (هندلر ریشه برنامه). به عنوان یک تابع ابری، استفاده از این نام منطقی‌تر نیست. در عوض، ما تابع ابری را با نام visitme مستقر خواهیم کرد، بنابراین از آن به عنوان نام تابع پایتون نیز استفاده کنید. به طور مشابه، در ماژول‌های ۴ و ۵، سرویس Cloud Run را visitme نیز نامگذاری کردیم.

قبل و بعد از این به‌روزرسانی‌ها را در اینجا مشاهده می‌کنید:

قبل از:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

بعد از:

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

این پایان تمام به‌روزرسانی‌های لازم است. توجه داشته باشید که تغییرات ایجاد شده فقط کد «زیرساخت» برنامه را تحت تأثیر قرار داده است. هیچ تغییری در کد اصلی برنامه لازم نیست و هیچ یک از عملکردهای برنامه تغییر نکرده است. در اینجا یک نمایش تصویری از تغییراتی که برای نشان دادن این نکته ایجاد شده است، آورده شده است:

668f30e3865b27a9.png

توسعه و آزمایش محلی

در حالی که App Engine دارای سرور توسعه محلی dev_appserver.py است، Cloud Functions دارای Functions Framework مخصوص به خود است. با این چارچوب، می‌توانید به صورت محلی توسعه داده و آزمایش کنید. کد شما می‌تواند در Cloud Functions مستقر شود، اما می‌تواند در سایر پلتفرم‌های محاسباتی مانند Compute Engine ، Cloud Run یا حتی سیستم‌های ابری داخلی یا ترکیبی که از Knative پشتیبانی می‌کنند نیز مستقر شود. برای پیوندهای بیشتر به Functions Framework به زیر مراجعه کنید.

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

استقرار در توابع ابری کمی با موتور برنامه (App Engine) متفاوت است. از آنجایی که هیچ فایل پیکربندی خارج از requirements.txt استفاده نمی‌شود، اطلاعات بیشتر در مورد کد باید در خط فرمان مشخص شود. تابع ابری جدید HTTP-triggered خود را که تحت پایتون ۳.۱۰ اجرا می‌شود، با این دستور مستقر کنید:

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

انتظار خروجی مشابه زیر را داشته باشید:

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

پس از استقرار تابع، از URL موجود در خروجی استقرار استفاده کنید و برنامه خود را مشاهده کنید. URL به شکل زیر است: REGION-PROJECT_ID.cloudfunctions.net/visitme . خروجی باید مشابه زمانی باشد که قبلاً آن را در App Engine مستقر کرده‌اید:

2732ae9218f011a2.png

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

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

تبریک بابت تبدیل این برنامه کوچک App Engine به یک Cloud Function! یک مورد استفاده مناسب دیگر: تجزیه یک برنامه بزرگ یکپارچه App Engine به مجموعه‌ای از میکروسرویس‌ها، هر کدام به عنوان یک Cloud Function. این یک تکنیک توسعه مدرن‌تر است که منجر به یک کامپوننت "plug-and-play" (شبیه به " JAM stack ") می‌شود. این امکان ترکیب و تطبیق و استفاده مجدد از کد را فراهم می‌کند که دو هدف هستند، اما مزیت دیگر این است که این میکروسرویس‌ها به مرور زمان اشکال‌زدایی می‌شوند، به این معنی که کد پایدارتر و هزینه‌های نگهداری کلی کاهش می‌یابد.

تمیز کردن

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

استقرار در پلتفرم‌هایی مانند App Engine و Cloud Functions هزینه‌های ساخت و ذخیره‌سازی کمی دارد. در برخی مناطق، Cloud Build نیز مانند Cloud Storage سهمیه رایگان خود را دارد. Buildها مقداری از آن سهمیه را مصرف می‌کنند. برای به حداقل رساندن هزینه‌های احتمالی، به ویژه اگر منطقه شما چنین سطح رایگانی ندارد، از میزان استفاده از فضای ذخیره‌سازی خود آگاه باشید.

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

مراحل بعدی

فراتر از این آموزش، ماژول‌های مهاجرت دیگری که باید بررسی شوند شامل کانتینرایز کردن برنامه App Engine شما برای Cloud Run است. به لینک‌های آزمایشگاه‌های کد ماژول ۴ و ماژول ۵ مراجعه کنید:

  • ماژول 4 : مهاجرت به Cloud Run با Docker
  • برنامه خود را برای اجرا در Cloud Run با Docker کانتینریزه کنید
  • این مهاجرت به شما امکان می‌دهد تا در پایتون ۲ بمانید.
  • ماژول 5 : مهاجرت به Cloud Run با Cloud Buildpacks
  • با استفاده از Cloud Buildpacks، برنامه خود را برای اجرا در Cloud Run کانتینرایز کنید
  • لازم نیست چیزی در مورد داکر، کانتینرها یا Dockerfile بدانید.
  • مستلزم آن است که برنامه شما قبلاً به پایتون ۳ مهاجرت کرده باشد (Buildpacks از پایتون ۲ پشتیبانی نمی‌کند)

بسیاری از ماژول‌های دیگر بر نشان دادن چگونگی مهاجرت از سرویس‌های همراه App Engine به سرویس‌های جایگزین مستقل Cloud به توسعه‌دهندگان تمرکز دارند:

اگر کانتینرسازی به بخشی از گردش کار توسعه برنامه شما تبدیل شده است، به خصوص اگر شامل یک خط لوله CI/CD (ادغام مداوم/تحویل یا استقرار مداوم) باشد، مهاجرت به Cloud Run را به جای Cloud Functions در نظر بگیرید. برای کانتینرسازی برنامه خود با Docker به ماژول ۴ و برای انجام این کار بدون کانتینرها، دانش Docker یا Dockerfile ها به ماژول ۵ مراجعه کنید. چه Cloud Functions را در نظر داشته باشید و چه Cloud Run، تغییر به یک پلتفرم بدون سرور دیگر اختیاری است و توصیه می‌کنیم قبل از ایجاد هرگونه تغییر، بهترین گزینه‌ها را برای برنامه‌ها و موارد استفاده خود در نظر بگیرید.

صرف نظر از اینکه کدام ماژول مهاجرت را در مرحله بعد در نظر بگیرید، تمام محتوای Serverless Migration Station (آزمایشگاه‌های کد، ویدیوها، کد منبع [در صورت وجود]) در مخزن متن‌باز آن قابل دسترسی است. README این مخزن همچنین راهنمایی‌هایی در مورد اینکه کدام مهاجرت‌ها را باید در نظر گرفت و هرگونه «ترتیب» مربوط به ماژول‌های مهاجرت ارائه می‌دهد.

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

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

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

منابع مهاجرت

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

کدلب

پایتون ۳

ماژول ۲

کد

ماژول ۱۱

کد

منابع آنلاین

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

موتور برنامه

توابع ابری

سایر اطلاعات ابری

ویدیوها

مجوز

این اثر تحت مجوز عمومی Creative Commons Attribution 2.0 منتشر شده است.