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

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

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

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

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

  • از Cloud Shell استفاده کنید
  • Google Cloud Translation API را فعال کنید
  • احراز هویت درخواست های API
  • یک برنامه App Engine کوچک را برای اجرا در Cloud Functions تبدیل کنید
  • کد خود را در Cloud Functions مستقر کنید

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

نظرسنجی

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

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

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

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

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

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

2. پس زمینه

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

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

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

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

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

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

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

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

این نرم افزار کد با نسخه Python 3 ماژول 2 برنامه نمونه برنامه موتور برنامه Cloud NDB آغاز می شود زیرا توابع ابری از Python 2 پشتیبانی نمی کند. ابتدا، اجازه دهید پروژه خود را راه اندازی کنیم، کد را دریافت کنیم، سپس برنامه پایه را برای تأیید شروع شروع کنیم. با کد کار

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تنها یک فایل برنامه، 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. پس از تبدیل برنامه به یک عملکرد ابری دیگر از Flask استفاده نمی شود، بنابراین تزئینات مسیر را حذف کنید.
  2. Cloud Functions به طور خودکار در شیء Request Flask به عنوان یک پارامتر ارسال می شود، بنابراین یک متغیر برای آن ایجاد کنید. در برنامه نمونه ما، آن را request می نامیم.
  3. توابع ابری مستقر شده باید نامگذاری شوند. کنترل کننده اصلی ما به طور مناسب root() در App Engine نامگذاری شد تا توضیح دهد که چه چیزی بود (برنامه کنترل کننده ریشه). به عنوان یک تابع ابری، استفاده از آن نام منطقی نیست. در عوض، ما تابع Cloud را با نام visitme اجرا می کنیم، بنابراین از آن به عنوان نام تابع پایتون نیز استفاده کنید. به همین ترتیب، در ماژول‌های 4 و 5، سرویس 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 چارچوب توابع خود را دارد. با این فریم ورک می توانید به صورت محلی توسعه داده و تست کنید. کد شما را می‌توان در توابع ابری مستقر کرد، اما همچنین می‌تواند در سایر پلت‌فرم‌های محاسباتی مانند Compute Engine ، Cloud Run یا حتی سیستم‌های ابری اولیه یا ترکیبی که از Knative پشتیبانی می‌کنند نیز مستقر شود. برای پیوندهای بیشتر به Functions Framework به زیر مراجعه کنید.

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

استقرار در توابع Cloud کمی با App Engine متفاوت است. از آنجایی که هیچ فایل پیکربندی خارج از requirements.txt استفاده نمی شود، اطلاعات بیشتری در مورد کد باید در خط فرمان مشخص شود. تابع Cloud جدید خود را که توسط HTTP راه اندازی شده است در حال اجرا در پایتون 3.10 با این دستور اجرا کنید:

$ 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.

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

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

تمیز کردن

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

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

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

مراحل بعدی

فراتر از این آموزش، سایر ماژول‌های مهاجرتی که باید به آنها نگاه کنید شامل محفظه کردن برنامه App Engine شما برای Cloud Run است. پیوندهای ماژول 4 و ماژول 5 را مشاهده کنید:

  • ماژول 4 : با Docker به Cloud Run مهاجرت کنید
  • برنامه خود را برای اجرا در Cloud Run with Docker محفظه کنید
  • این مهاجرت به شما امکان می دهد در پایتون 2 بمانید.
  • ماژول 5 : با Cloud Buildpacks به Cloud Run مهاجرت کنید
  • برنامه خود را برای اجرا در Cloud Run با Cloud Buildpacks کانتینری کنید
  • نیازی نیست در مورد Docker، کانتینرها یا Dockerfile چیزی بدانید.
  • نیاز دارد که برنامه شما قبلاً به پایتون 3 منتقل شده باشد (Buildpacks از Python 2 پشتیبانی نمی کند)

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

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

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

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

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

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

منابع مهاجرت

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

Codelab

پایتون 3

ماژول 2

کد

ماژول 11

کد

منابع آنلاین

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

موتور برنامه

توابع ابری

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

ویدیوها

مجوز

این اثر تحت مجوز Creative Commons Attribution 2.0 Generic مجوز دارد.