۱. مرور کلی
مجموعه آزمایشگاههای کد Serverless Migration Station (آموزشهای عملی و خودآموز) و ویدیوهای مرتبط با آن ، با هدف کمک به توسعهدهندگان Google Cloud serverless برای مدرنسازی برنامههایشان، با راهنمایی آنها در طول یک یا چند مهاجرت، و در درجه اول دور شدن از سرویسهای قدیمی، ارائه میشوند. انجام این کار، برنامههای شما را قابل حملتر میکند و گزینهها و انعطافپذیری بیشتری به شما میدهد و شما را قادر میسازد تا با طیف وسیعتری از محصولات Cloud ادغام شده و به آنها دسترسی داشته باشید و به راحتی به نسخههای جدیدتر زبان ارتقا دهید. در حالی که در ابتدا بر روی اولین کاربران Cloud، در درجه اول توسعهدهندگان App Engine (محیط استاندارد)، تمرکز دارد، این مجموعه به اندازه کافی گسترده است که شامل سایر پلتفرمهای serverless مانند Cloud Functions و Cloud Run یا در صورت لزوم، هر جای دیگری نیز میشود.
هدف از این آزمایشگاه کد، نشان دادن نحوه مهاجرت توسعهدهندگان App Engine با پایتون ۲ از صف وظایف App Engine (وظایف push) به Cloud Tasks است. همچنین یک مهاجرت ضمنی از App Engine NDB به Cloud NDB برای دسترسی به Datastore وجود دارد (که عمدتاً در ماژول ۲ پوشش داده شده است).
ما استفاده از وظایف push را در ماژول ۷ اضافه کردیم و این استفاده را در ماژول ۸ به Cloud Tasks منتقل کردیم، سپس در ماژول ۹ به پایتون ۳ و Cloud Datastore ادامه دادیم. کسانی که از Task Queues برای وظایف pull استفاده میکنند، به Cloud Pub/Sub مهاجرت میکنند و باید به ماژولهای ۱۸-۱۹ مراجعه کنند.
یاد خواهید گرفت که چگونه
- استفاده از صف وظایف موتور برنامه (وظایف ارسالی) را با وظایف ابری جایگزین کنید
- جایگزینی استفاده از App Engine NDB با Cloud NDB (همچنین به ماژول ۲ مراجعه کنید)
آنچه نیاز دارید
- یک پروژه Google Cloud با یک حساب پرداخت GCP فعال
- مهارتهای پایه پایتون
- آشنایی کامل با دستورات رایج لینوکس
- دانش پایه در توسعه و استقرار برنامههای App Engine
- یک برنامهی کاربردی ماژول ۷ موتور برنامه ( کد آزمایشگاه آن را تکمیل کنید [توصیه میشود] یا برنامه را از مخزن کپی کنید)
نظرسنجی
چگونه از این آموزش استفاده خواهید کرد؟
تجربه خود را با پایتون چگونه ارزیابی میکنید؟
تجربه خود را در استفاده از خدمات ابری گوگل چگونه ارزیابی میکنید؟
۲. پیشینه
صف وظایف موتور برنامه از هر دو وظیفه push و pull پشتیبانی میکند. برای بهبود قابلیت حمل برنامه، تیم Google Cloud توصیه میکند از سرویسهای قدیمی مانند Task Queue به سایر سرویسهای مستقل Cloud یا معادلهای شخص ثالث مهاجرت کنید.
- کاربرانی که میخواهند وظایف را در صف وظایف (Task Queue) ارسال کنند، باید به Cloud Tasks مهاجرت کنند.
- کاربران Task Pull Queue باید به Cloud Pub/Sub مهاجرت کنند.
مهاجرت وظیفهی Pull در ماژولهای مهاجرت ۱۸-۱۹ پوشش داده شده است، در حالی که ماژولهای ۷-۹ بر مهاجرت وظیفهی Push تمرکز دارند. برای مهاجرت از وظایف Push صف وظیفهی App Engine، ما کاربرد آن را به برنامهی نمونهی موجود Python 2 App Engine اضافه کردیم که بازدیدهای جدید صفحه را ثبت کرده و جدیدترین بازدیدها را نمایش میدهد. Codelab ماژول ۷ یک وظیفهی Push برای حذف قدیمیترین بازدیدها اضافه میکند - آنها دیگر هرگز نمایش داده نمیشوند، پس چرا باید فضای ذخیرهسازی اضافی را در Datastore اشغال کنند؟ Codelab ماژول ۸ همان عملکرد را حفظ میکند، اما مکانیسم صفبندی اساسی را از وظایف Push صف وظیفه به Cloud Tasks منتقل میکند و همچنین مهاجرت ماژول ۲ را از App Engine NDB به Cloud NDB برای دسترسی به Datastore تکرار میکند.
این آموزش شامل مراحل زیر است:
- راهاندازی/پیشپردازش
- پیکربندی را بهروزرسانی کنید
- اصلاح کد برنامه
۳. تنظیمات/پیشپردازش
این بخش توضیح میدهد که چگونه:
- پروژه ابری خود را راهاندازی کنید
- دریافت برنامه نمونه پایه
- (دوباره)استقرار و اعتبارسنجی برنامه پایه
- فعال کردن سرویسها/APIهای جدید Google Cloud
این مراحل تضمین میکنند که شما با کدی که کار میکند شروع میکنید و برنامه نمونه شما برای انتقال به سرویسهای ابری آماده است.
۱. پروژه راهاندازی
اگر آزمایشگاه کد ماژول ۷ را تکمیل کردهاید، از همان پروژه (و کد) دوباره استفاده کنید. روش دیگر، ایجاد یک پروژه کاملاً جدید یا استفاده مجدد از یک پروژه موجود دیگر است. مطمئن شوید که پروژه دارای یک حساب صورتحساب فعال و یک برنامه App Engine فعال است. شناسه پروژه خود را پیدا کنید زیرا در طول این آزمایشگاه کد به آن نیاز دارید و هر زمان که با متغیر PROJECT_ID مواجه شدید، از آن استفاده کنید.
۲. نمونه برنامه پایه را دریافت کنید
یکی از پیشنیازها، یک برنامهی ماژول ۷ App Engine است که کار کند: کدلب ماژول ۷ (توصیه میشود) را تکمیل کنید یا برنامهی ماژول ۷ را از مخزن کپی کنید. چه از کد خودتان استفاده کنید و چه از کد ما، کد ماژول ۷ جایی است که ما شروع میکنیم ("شروع"). این کدلب شما را در طول مهاجرت راهنمایی میکند و با کدی که شبیه کد موجود در پوشهی مخزن ماژول ۸ است ("پایان")، به پایان میرسد.
- شروع: مخزن ماژول ۷
- پایان: مخزن ماژول ۸
- کل مخزن (کلون کردن یا دانلود فایل زیپ)
صرف نظر از اینکه از کدام برنامه ماژول ۷ استفاده میکنید، پوشه باید مانند زیر باشد، احتمالاً شامل یک پوشه lib نیز خواهد بود:
$ ls README.md appengine_config.py requirements.txt app.yaml main.py templates
۳. (دوباره) استقرار و اعتبارسنجی برنامه پایه
برای نصب برنامه ماژول ۷ مراحل زیر را انجام دهید:
- اگر پوشه
libوجود دارد، آن را حذف کنید وpip install -t lib -r requirements.txtرا برای پر کردن مجددlibاجرا کنید. اگر پایتون ۲ و ۳ را روی دستگاه توسعه خود نصب دارید، ممکن است لازم باشد ازpip2استفاده کنید. - مطمئن شوید که ابزار خط فرمان
gcloudرا نصب و راهاندازی اولیه کردهاید و نحوهی استفاده از آن را بررسی کردهاید. - (اختیاری) اگر نمیخواهید
PROJECT_IDبا هر دستورgcloudوارد کنید، پروژه Cloud خود را باgcloud config set projectPROJECT_IDتنظیم کنید. - برنامه نمونه را با
gcloud app deployمستقر کنید - تأیید کنید که برنامه طبق انتظار و بدون مشکل اجرا میشود. اگر ماژول ۷ codelab را تکمیل کرده باشید، برنامه بازدیدکنندگان برتر را به همراه جدیدترین بازدیدها (در زیر نشان داده شده است) نمایش میدهد. در پایین، نشانهای از وظایف قدیمیتر که حذف خواهند شد، وجود دارد.

۴. فعال کردن سرویسها/APIهای جدید گوگل کلود
برنامه قدیمی از سرویسهای همراه App Engine استفاده میکرد که نیازی به تنظیمات اضافی ندارند، اما سرویسهای Cloud مستقل این کار را انجام میدهند و برنامه بهروزرسانیشده از Cloud Tasks و Cloud Datastore (از طریق کتابخانه کلاینت Cloud NDB) استفاده خواهد کرد. تعدادی از محصولات Cloud دارای سهمیههای سطح "همیشه رایگان" هستند، از جمله App Engine ، Cloud Datastore و Cloud Tasks . تا زمانی که زیر این محدودیتها بمانید، نباید برای تکمیل این آموزش هزینهای متحمل شوید. APIهای Cloud را میتوان بسته به ترجیح شما از طریق Cloud Console یا از طریق خط فرمان فعال کرد.
از کنسول ابری
به صفحه کتابخانه مدیر API (برای پروژه صحیح) در کنسول ابری بروید و با استفاده از نوار جستجو در وسط صفحه، APIهای Cloud Datastore و Cloud Tasks را جستجو کنید:

برای هر API به طور جداگانه روی دکمه فعالسازی کلیک کنید - ممکن است از شما اطلاعات صورتحساب خواسته شود. این مثالی از صفحه کتابخانه Cloud Pub/Sub API است (API Pub/Sub را برای این codelab فعال نکنید، فقط Cloud Tasks و Datastore را فعال کنید):

از خط فرمان
اگرچه فعال کردن APIها از طریق کنسول از نظر بصری آموزنده است، اما برخی خط فرمان را ترجیح میدهند. دستور gcloud services enable cloudtasks.googleapis.com datastore.googleapis.com را برای فعال کردن همزمان هر دو API اجرا کنید:
$ gcloud services enable cloudtasks.googleapis.com datastore.googleapis.com Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.
ممکن است از شما اطلاعات صورتحساب خواسته شود. اگر میخواهید سایر APIهای ابری را فعال کنید و «URI»های آنها را بدانید، میتوانید آنها را در پایین صفحه کتابخانه هر API پیدا کنید. برای مثال، pubsub.googleapis.com به عنوان «نام سرویس» در پایین صفحه Pub/Sub درست در بالا مشاهده کنید.
پس از اتمام مراحل، پروژه شما قادر به دسترسی به APIها خواهد بود. اکنون زمان آن رسیده است که برنامه را برای استفاده از آن APIها بهروزرسانی کنید.
۴. بهروزرسانی پیکربندی
بهروزرسانیهای پیکربندی صراحتاً به دلیل افزایش استفاده از کتابخانههای کلاینت ابری هستند. صرف نظر از اینکه از کدام یک (یا کتابخانههایی) استفاده میکنید، همین تغییرات باید در برنامههایی که از هیچ کتابخانه کلاینت ابری استفاده نمیکنند، اعمال شود.
الزامات.txt
ماژول ۸ استفاده از App Engine NDB و Task Queue از ماژول ۱ را با Cloud NDB و Cloud Tasks جایگزین میکند. google-cloud-ndb و google-cloud-tasks به requirements.txt اضافه کنید تا به flask از ماژول ۷ متصل شود:
flask
google-cloud-ndb
google-cloud-tasks
این فایل requirements.txt هیچ شماره نسخهای ندارد، به این معنی که آخرین نسخهها انتخاب شدهاند. در صورت بروز هرگونه ناسازگاری، یک شماره نسخه برای قفل کردن نسخههای کاری برنامه مشخص کنید.
برنامه.yaml
هنگام استفاده از کتابخانههای کلاینت ابری، موتور اجرای پایتون ۲ (Python 2 App Engine) به بستههای شخص ثالث خاصی، یعنی grpcio و setuptools ، نیاز دارد. کاربران پایتون ۲ باید کتابخانههای داخلی مانند اینها را به همراه نسخه موجود یا "آخرین" در app.yaml فهرست کنند. اگر هنوز بخش libraries را ندارید، یکی ایجاد کنید و هر دو کتابخانه را مانند این اضافه کنید:
libraries:
- name: grpcio
version: latest
- name: setuptools
version: latest
هنگام مهاجرت برنامهتان ، ممکن است از قبل بخش libraries را داشته باشد . اگر دارد، و grpcio و setuptools وجود ندارند، کافیست آنها را به بخش libraries موجود خود اضافه کنید. app.yaml بهروزرسانیشده اکنون باید به شکل زیر باشد:
runtime: python27
threadsafe: yes
api_version: 1
handlers:
- url: /.*
script: main.app
libraries:
- name: grpcio
version: latest
- name: setuptools
version: latest
appengine_config.py
فراخوانی google.appengine.ext.vendor.add() در appengine_config.py کتابخانههای شخص ثالث کپی شده (که گاهی اوقات "vendoring" یا "self-bundling" نامیده میشوند) شما در lib را به برنامهتان متصل میکند. در بالا در app.yaml ، ما کتابخانههای شخص ثالث داخلی اضافه کردیم و آنها برای اتصال برنامه شما به بستههای داخلی موجود در lib به setuptools.pkg_resources.working_set.add_entry() نیاز دارند. در زیر ماژول اصلی 1 appengine_config.py و پس از انجام بهروزرسانیهای ماژول 8 آمده است:
قبل از:
from google.appengine.ext import vendor
# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
بعد از:
import pkg_resources
from google.appengine.ext import vendor
# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)
توضیحات مشابهی را میتوان در مستندات مهاجرت App Engine نیز یافت.
۵. کد برنامه را تغییر دهید
این بخش شامل بهروزرسانیهایی در فایل اصلی برنامه، main.py ، است که استفاده از صفهای ارسال وظیفه App Engine را با Cloud Tasks جایگزین میکند. هیچ تغییری در قالب وب، templates/index.html ، ایجاد نشده است - هر دو برنامه باید به طور یکسان عمل کنند و دادههای یکسانی را نمایش دهند. تغییرات در برنامه اصلی به این چهار "کار" تقسیم میشوند:
- بهروزرسانی واردات و مقداردهی اولیه
- بهروزرسانی عملکرد مدل داده (Cloud NDB)
- مهاجرت به Cloud Tasks (و Cloud NDB)
- بهروزرسانی (push) کنترلکنندهی وظیفه
۱. بهروزرسانی ایمپورتها و مقداردهی اولیه
- به ترتیب، App Engine NDB (
google.appengine.ext.ndb) و Task Queue (google.appengine.api.taskqueue) را با Cloud NDB (google.cloud.ndb) و Cloud Tasks (google.cloud.tasks) جایگزین کنید. - کتابخانههای کلاینت ابری نیاز به مقداردهی اولیه و ایجاد "کلاینتهای API" دارند؛ آنها را به ترتیب به
ds_clientوts_clientاختصاص دهید. - مستندات صف وظایف بیان میکند: «App Engine یک صف ارسال پیشفرض با نام
defaultارائه میدهد که پیکربندی شده و با تنظیمات پیشفرض آماده استفاده است.» Cloud Tasks صفdefaultارائه نمیدهد (زیرا یک محصول Cloud مستقل و مستقل از App Engine است)، بنابراین برای ایجاد یک صف Cloud Tasks با نامdefaultبه کد جدیدی نیاز است. - صف وظایف موتور برنامه (App Engine Task Queue) نیازی به مشخص کردن منطقه ندارد زیرا از منطقهای که برنامه شما در آن اجرا میشود استفاده میکند. با این حال، از آنجایی که Cloud Tasks اکنون یک محصول مستقل است، به یک منطقه نیاز دارد و آن منطقه باید با منطقهای که برنامه شما در آن اجرا میشود مطابقت داشته باشد. نام منطقه و شناسه پروژه Cloud برای ایجاد یک "نام مسیر کاملاً واجد شرایط" به عنوان شناسه منحصر به فرد صف مورد نیاز است.
بهروزرسانیهای شرح داده شده در موارد سوم و چهارم بالا، بخش عمدهای از ثابتهای اضافی و مقداردهی اولیه مورد نیاز را تشکیل میدهند. به «قبل» و «بعد» زیر مراجعه کنید و این تغییرات را در بالای main.py اعمال کنید.
قبل از:
from datetime import datetime
import logging
import time
from flask import Flask, render_template, request
from google.appengine.api import taskqueue
from google.appengine.ext import ndb
app = Flask(__name__)
بعد از:
from datetime import datetime
import json
import logging
import time
from flask import Flask, render_template, request
from google.cloud import ndb, tasks
app = Flask(__name__)
ds_client = ndb.Client()
ts_client = tasks.CloudTasksClient()
_, PROJECT_ID = google.auth.default()
REGION_ID = 'REGION_ID' # replace w/your own
QUEUE_NAME = 'default' # replace w/your own
QUEUE_PATH = ts_client.queue_path(PROJECT_ID, REGION_ID, QUEUE_NAME)
۲. بهروزرسانی عملکرد مدل داده (Cloud NDB)
NDB موتور برنامه و NDB ابری تقریباً یکسان کار میکنند. هیچ تغییر عمدهای در مدل داده یا تابع store_visit() ایجاد نشده است. تنها تفاوت قابل توجه این است که ایجاد موجودیت Visit در store_visit() اکنون درون یک بلوک with پایتون کپسولهسازی شده است. NDB ابری مستلزم آن است که تمام دسترسی به Datastore در مدیریت زمینه آن کنترل شود، از این رو از دستور with استفاده میشود. قطعه کدهای زیر این تفاوت جزئی را هنگام مهاجرت به NDB ابری نشان میدهند. این تغییر را پیادهسازی کنید.
قبل از:
class Visit(ndb.Model):
'Visit entity registers visitor IP address & timestamp'
visitor = ndb.StringProperty()
timestamp = ndb.DateTimeProperty(auto_now_add=True)
def store_visit(remote_addr, user_agent):
'create new Visit entity in Datastore'
Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()
بعد از:
class Visit(ndb.Model):
'Visit entity registers visitor IP address & timestamp'
visitor = ndb.StringProperty()
timestamp = ndb.DateTimeProperty(auto_now_add=True)
def store_visit(remote_addr, user_agent):
'create new Visit entity in Datastore'
with ds_client.context():
Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()
۳. مهاجرت به Cloud Tasks (و Cloud NDB)
مهمترین تغییر در این مهاجرت، تغییر زیرساخت صفبندی اصلی است. این تغییر در تابع fetch_visits() رخ میدهد که در آن یک وظیفه (push) برای حذف بازدیدهای قدیمی ایجاد و برای اجرا در صف قرار میگیرد. با این حال، عملکرد اصلی ماژول ۷ دست نخورده باقی میماند:
- آخرین بازدیدها را جستجو کنید.
- به جای اینکه آن بازدیدها را فوراً برگردانید، مهر زمانی آخرین
Visit، قدیمیترین بازدید نمایش داده شده، را ذخیره کنید - حذف همه بازدیدهای قدیمیتر از این تاریخ بیخطر است. - با استفاده از ابزارهای استاندارد پایتون، مهر زمانی را به صورت یک عدد اعشاری و یک رشته استخراج کنید و از هر دو در ظرفیتهای مختلف، مثلاً نمایش به کاربر، اضافه کردن به گزارشها، ارسال به کنترلکننده و غیره، استفاده کنید.
- یک وظیفهی ارسال (push task) با این مهر زمانی به عنوان بار داده (payload) و
/trimبه عنوان URL ایجاد کنید. - در نهایت، کنترلکنندهی وظیفه از طریق یک HTTP
POSTبه آن URL فراخوانی میشود.
این گردش کار توسط قطعه کد "قبل" نشان داده شده است:
قبل از:
def fetch_visits(limit):
'get most recent visits & add task to delete older visits'
data = Visit.query().order(-Visit.timestamp).fetch(limit)
oldest = time.mktime(data[-1].timestamp.timetuple())
oldest_str = time.ctime(oldest)
logging.info('Delete entities older than %s' % oldest_str)
taskqueue.add(url='/trim', params={'oldest': oldest})
return data, oldest_str
در حالی که عملکرد ثابت باقی میماند، Cloud Tasks به پلتفرم اجرا تبدیل میشود. بهروزرسانیهایی که این تغییر را اعمال میکنند عبارتند از:
- قرار دادن کوئری
Visitدرون یک بلوک پایتونwith(تکرار مهاجرت ماژول ۲ به Cloud NDB) - ابردادههای Cloud Tasks را ایجاد کنید، از جمله ویژگیهای مورد انتظار مانند بار داده timestamp و URL، و همچنین نوع MIME و رمزگذاری JSON بار داده را اضافه کنید.
- از کلاینت Cloud Tasks API برای ایجاد وظیفه به همراه فراداده و نام مسیر کامل صف استفاده کنید.
این تغییرات در fetch_visits() در زیر نشان داده شده است:
بعد از:
def fetch_visits(limit):
'get most recent visits & add task to delete older visits'
with ds_client.context():
data = Visit.query().order(-Visit.timestamp).fetch(limit)
oldest = time.mktime(data[-1].timestamp.timetuple())
oldest_str = time.ctime(oldest)
logging.info('Delete entities older than %s' % oldest_str)
task = {
'app_engine_http_request': {
'relative_uri': '/trim',
'body': json.dumps({'oldest': oldest}).encode(),
'headers': {
'Content-Type': 'application/json',
},
}
}
ts_client.create_task(parent=QUEUE_PATH, task=task)
return data, oldest_str
۴. بهروزرسانی (push) task handler
تابع (push) task handler نیازی به بهروزرسانیهای عمده ندارد؛ فقط به اجرا نیاز دارد. این موضوع در مورد Task Queue یا Cloud Tasks قابل اجرا است. میگویند: «کد، کد است». با این حال، تغییرات جزئی وجود دارد :
- بار دادهی برچسب زمانی کلمه به کلمه به صف وظایف (Task Queue) ارسال شد، اما برای وظایف ابری (Cloud Tasks) با فرمت JSON کدگذاری شده بود و بنابراین باید پس از ورود با فرمت JSON تجزیه شود.
- فراخوانی HTTP
POSTبه/trimبا Task Queue دارای MIMEtype ضمنیapplication/x-www-form-urlencodedبود، اما با Cloud Tasks، به صراحت به عنوانapplication/jsonتعیین میشود، بنابراین روش استخراج payload کمی متفاوت است. - از مدیر زمینه کلاینت Cloud NDB API استفاده کنید (ماژول 2، مهاجرت به Cloud NDB).
در زیر قطعه کد قبل و بعد از اعمال این تغییرات در task handler، trim() ، آمده است:
قبل از:
@app.route('/trim', methods=['POST'])
def trim():
'(push) task queue handler to delete oldest visits'
oldest = request.form.get('oldest', type=float)
keys = Visit.query(
Visit.timestamp < datetime.fromtimestamp(oldest)
).fetch(keys_only=True)
nkeys = len(keys)
if nkeys:
logging.info('Deleting %d entities: %s' % (
nkeys, ', '.join(str(k.id()) for k in keys)))
ndb.delete_multi(keys)
else:
logging.info('No entities older than: %s' % time.ctime(oldest))
return '' # need to return SOME string w/200
بعد از:
@app.route('/trim', methods=['POST'])
def trim():
'(push) task queue handler to delete oldest visits'
oldest = float(request.get_json().get('oldest'))
with ds_client.context():
keys = Visit.query(
Visit.timestamp < datetime.fromtimestamp(oldest)
).fetch(keys_only=True)
nkeys = len(keys)
if nkeys:
logging.info('Deleting %d entities: %s' % (
nkeys, ', '.join(str(k.id()) for k in keys)))
ndb.delete_multi(keys)
else:
logging.info(
'No entities older than: %s' % time.ctime(oldest))
return '' # need to return SOME string w/200
هیچ بهروزرسانی در root() کنترلکننده اصلی برنامه و همچنین templates/index.html قالب وب وجود ندارد.
۶. خلاصه/پاکسازی
این بخش، این آزمایشگاه کد را با استقرار برنامه، تأیید عملکرد آن طبق برنامه و در هر خروجی منعکسشده، به پایان میرساند. پس از اعتبارسنجی برنامه، هرگونه پاکسازی را انجام داده و مراحل بعدی را در نظر بگیرید.
استقرار و تأیید برنامه
برنامه خود را با gcloud app deploy مستقر کنید. خروجی باید با برنامه ماژول ۷ یکسان باشد، اما توجه داشته باشید که به یک محصول صف ارسال کاملاً متفاوت تغییر کردهاید که برنامه شما را قابل حملتر از قبل میکند!

تمیز کردن
عمومی
اگر فعلاً کارتان تمام است، توصیه میکنیم برنامه App Engine خود را غیرفعال کنید تا از پرداخت هزینه جلوگیری شود. با این حال، اگر میخواهید بیشتر آزمایش یا تجربه کنید، پلتفرم App Engine سهمیه رایگان دارد و بنابراین تا زمانی که از آن سطح استفاده تجاوز نکنید، نباید هزینهای از شما دریافت شود. این هزینه برای محاسبات است، اما ممکن است برای سرویسهای مربوطه App Engine نیز هزینههایی وجود داشته باشد، بنابراین برای اطلاعات بیشتر به صفحه قیمتگذاری آن مراجعه کنید. اگر این مهاجرت شامل سایر سرویسهای ابری باشد، هزینه آنها جداگانه محاسبه میشود. در هر صورت، در صورت لزوم، به بخش "ویژه این codelab" در زیر مراجعه کنید.
برای روشن شدن کامل موضوع، استقرار در یک پلتفرم محاسباتی بدون سرور Google Cloud مانند App Engine هزینههای ساخت و ذخیرهسازی کمی را متحمل میشود. Cloud Build نیز مانند Cloud Storage سهمیه رایگان خود را دارد. ذخیرهسازی آن تصویر مقداری از آن سهمیه را مصرف میکند. با این حال، ممکن است در منطقهای زندگی کنید که چنین ردیف رایگانی ندارد، بنابراین برای به حداقل رساندن هزینههای احتمالی، از میزان استفاده از فضای ذخیرهسازی خود آگاه باشید. «پوشههای» خاص Cloud Storage که باید بررسی کنید عبارتند از:
-
console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images -
console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com - لینکهای ذخیرهسازی بالا به
PROJECT_IDو *LOC*ation شما بستگی دارند، برای مثال، اگر برنامه شما در ایالات متحده میزبانی میشود، "us" خواهد بود.
از طرف دیگر، اگر قصد ندارید با این برنامه یا سایر آزمایشگاههای کد مهاجرت مرتبط ادامه دهید و میخواهید همه چیز را به طور کامل حذف کنید، پروژه خود را ببندید .
مخصوص این آزمایشگاه کد
سرویسهای ذکر شده در زیر مختص این codelab هستند. برای اطلاعات بیشتر به مستندات هر محصول مراجعه کنید:
- Cloud Tasks یک نسخه رایگان دارد؛ برای جزئیات بیشتر به صفحه قیمتگذاری آن مراجعه کنید.
- سرویس App Engine Datastore توسط Cloud Datastore (Cloud Firestore در حالت Datastore) ارائه میشود که یک نسخه رایگان نیز دارد؛ برای اطلاعات بیشتر به صفحه قیمتگذاری آن مراجعه کنید.
مراحل بعدی
بدین ترتیب، مهاجرت ما از وظایف ارسالی App Engine Task Queue به Cloud Tasks به پایان میرسد. اگر علاقهمند به ادامهی انتقال این برنامه به پایتون ۳ و مهاجرت بیشتر از Cloud NDB به Cloud Datastore هستید، ماژول ۹ را در نظر بگیرید.
Cloud NDB به طور خاص برای توسعهدهندگان Python 2 App Engine وجود دارد و تجربه کاربری تقریباً یکسانی را ارائه میدهد، اما Cloud Datastore کتابخانه کلاینت بومی خود را دارد که برای کاربران غیر App Engine یا کاربران جدید (Python 3) App Engine ساخته شده است. با این حال، از آنجا که Cloud NDB برای پایتون 2 و 3 در دسترس است، نیازی به مهاجرت به Cloud Datastore نیست.
Cloud NDB و Cloud Datastore هر دو به Datastore دسترسی دارند (البته به روشهای مختلف)، بنابراین تنها دلیل برای در نظر گرفتن انتقال به Cloud Datastore این است که اگر از قبل برنامههای دیگری، بهویژه برنامههای غیر App Engine، دارید که از Cloud Datastore استفاده میکنند و مایل به استانداردسازی در یک کتابخانه کلاینت Datastore هستید، این انتقال اختیاری از Cloud NDB به Cloud Datastore نیز به خودی خود (بدون صف وظایف یا وظایف ابری) در ماژول 3 پوشش داده شده است.
فراتر از ماژولهای ۳، ۸ و ۹، سایر ماژولهای مهاجرت که بر فاصله گرفتن از سرویسهای همراه قدیمی App Engine تمرکز دارند و باید در نظر گرفته شوند عبارتند از:
- ماژول ۲ : مهاجرت از App Engine NDB به Cloud NDB
- ماژولهای ۱۲-۱۳ : مهاجرت از App Engine Memcache به Cloud Memorystore
- ماژولهای ۱۵-۱۶ : مهاجرت از App Engine Blobstore به Cloud Storage
- ماژولهای ۱۸-۱۹ : صف وظایف موتور برنامه (وظایف را بکشید) به Cloud Pub/Sub
App Engine دیگر تنها پلتفرم بدون سرور در Google Cloud نیست. اگر یک برنامه کوچک App Engine یا برنامهای با قابلیتهای محدود دارید و میخواهید آن را به یک میکروسرویس مستقل تبدیل کنید، یا میخواهید یک برنامه یکپارچه را به چندین مؤلفه قابل استفاده مجدد تقسیم کنید، اینها دلایل خوبی برای در نظر گرفتن انتقال به Cloud Functions هستند. اگر کانتینرسازی به بخشی از گردش کار توسعه برنامه شما تبدیل شده است، به خصوص اگر شامل یک خط لوله CI/CD (ادغام مداوم/تحویل مداوم یا استقرار) باشد، مهاجرت به Cloud Run را در نظر بگیرید. این سناریوها توسط ماژولهای زیر پوشش داده میشوند:
- مهاجرت از موتور برنامه به توابع ابری: به ماژول 11 مراجعه کنید
- مهاجرت از App Engine به Cloud Run: برای کانتینرایز کردن برنامه خود با Docker به ماژول ۴ و برای انجام این کار بدون کانتینرها، دانش Docker یا
Dockerfileها به ماژول ۵ مراجعه کنید.
تغییر به یک پلتفرم بدون سرور دیگر اختیاری است و توصیه میکنیم قبل از ایجاد هرگونه تغییر، بهترین گزینهها را برای برنامهها و موارد استفاده خود در نظر بگیرید.
صرف نظر از اینکه کدام ماژول مهاجرت را در مرحله بعد در نظر بگیرید، تمام محتوای Serverless Migration Station (آزمایشگاههای کد، ویدیوها، کد منبع [در صورت وجود]) در مخزن متنباز آن قابل دسترسی است. README این مخزن همچنین راهنماییهایی در مورد اینکه کدام مهاجرتها را باید در نظر گرفت و هرگونه «ترتیب» مربوط به ماژولهای مهاجرت ارائه میدهد.
۷. منابع اضافی
در زیر منابع بیشتری برای توسعهدهندگان جهت بررسی بیشتر این ماژول مهاجرت یا ماژولهای مرتبط و همچنین محصولات مرتبط فهرست شده است. این منابع شامل مکانهایی برای ارائه بازخورد در مورد این محتوا، لینکهایی به کد و مستندات مختلفی است که ممکن است برای شما مفید باشند.
مشکلات/بازخوردهای Codelabs
اگر در این آزمایشگاه کد مشکلی پیدا کردید، لطفاً قبل از ثبت، ابتدا مشکل خود را جستجو کنید. لینکهای جستجو و ایجاد مشکلات جدید:
منابع مهاجرت
لینکهای پوشههای مخزن ماژول ۷ (START) و ماژول ۸ (FINISH) را میتوانید در جدول زیر بیابید.
کدلب | پایتون ۲ | پایتون ۳ |
کد (در این آموزش نمایش داده نشده است) | ||
ماژول ۸ (این آزمایشگاه کد) | (نامشخص) |
منابع آنلاین
در زیر منابع آنلاینی وجود دارد که ممکن است برای این آموزش مرتبط باشند:
صف وظایف موتور برنامه و وظایف ابری
- مرور کلی صف وظایف موتور برنامه
- مرور کلی صفهای ارسال وظیفه در موتور برنامه
- صف وظایف موتور برنامه، وظایف را به مهاجرت وظایف ابری منتقل میکند.
- نمونه مستندات وظایف موتور برنامه، وظایف صف را به Cloud ارسال میکند.
- اسناد وظایف ابری
- نمونههای کتابخانه کلاینت پایتون Cloud Tasks
- اطلاعات قیمتگذاری Cloud Tasks
NDB موتور برنامه و NDB ابری (ذخیره داده)
- اسناد NDB موتور برنامه
- مخزن NDB موتور برنامه
- اسناد Google Cloud NDB
- مخزن Google Cloud NDB
- اطلاعات قیمتگذاری فروشگاه داده ابری
پلتفرم موتور برنامه
- مستندات موتور برنامه
- موتور برنامه پایتون ۲ (محیط استاندارد) در زمان اجرا
- استفاده از کتابخانههای داخلی App Engine در Python 2 App Engine
- موتور برنامه پایتون ۳ (محیط استاندارد) در زمان اجرا
- تفاوتهای بین زمانهای اجرای موتور برنامه پایتون ۲ و ۳ (محیط استاندارد)
- راهنمای مهاجرت موتور برنامه پایتون ۲ به ۳ (محیط استاندارد)
- اطلاعات قیمتگذاری و سهمیهبندی موتور برنامه
- راهاندازی پلتفرم نسل دوم App Engine (۲۰۱۸)
- مقایسه پلتفرمهای نسل اول و دوم
- پشتیبانی بلندمدت از رانتایمهای قدیمی
- نمونههای مهاجرت مستندات
- نمونههای مهاجرت با مشارکت جامعه
سایر اطلاعات ابری
- پایتون در پلتفرم ابری گوگل
- کتابخانههای کلاینت پایتون گوگل کلود
- سطح «همیشه رایگان» گوگل کلود
- کیت توسعه نرمافزار گوگل کلود (ابزار خط فرمان
gcloud) - تمام مستندات گوگل کلود
ویدیوها
- ایستگاه مهاجرت بدون سرور
- سفرهای اکتشافی بدون سرور
- مشترک شدن در فناوری ابری گوگل
- مشترک شدن در توسعهدهندگان گوگل
مجوز
این اثر تحت مجوز عمومی Creative Commons Attribution 2.0 منتشر شده است.