مهاجرت از App Engine Memcache به Cloud Memorystore (ماژول 13)

۱. مرور کلی

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

هدف از این آزمایشگاه کد، نشان دادن نحوه مهاجرت از App Engine Memcache به Cloud Memorystore (برای Redis ) به توسعه‌دهندگان App Engine 2 در پایتون ۲ است. همچنین یک مهاجرت ضمنی از App Engine ndb به Cloud NDB نیز وجود دارد، اما این موضوع عمدتاً در آزمایشگاه کد ماژول ۲ پوشش داده شده است. برای اطلاعات گام به گام بیشتر، آن را بررسی کنید.

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

  • یک نمونه Cloud Memorystore راه‌اندازی کنید (از Cloud Console یا ابزار gcloud )
  • یک رابط دسترسی VPC بدون سرور ابری (Cloud Serverless VPC Access) راه‌اندازی کنید (از Cloud Console یا ابزار gcloud )
  • مهاجرت از App Engine Memcache به Cloud Memorystore
  • پیاده‌سازی ذخیره‌سازی موقت با Cloud Memorystore در یک برنامه نمونه
  • مهاجرت از App Engine ndb به Cloud NDB

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

نظرسنجی

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

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

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

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

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

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

۲. پیشینه

این آزمایشگاه کد، نحوه‌ی انتقال یک برنامه‌ی نمونه از App Engine Memcache (و NDB) به Cloud Memorystore (و Cloud NDB) را نشان می‌دهد. این فرآیند شامل جایگزینی وابستگی‌ها در سرویس‌های همراه App Engine و قابل حمل‌تر کردن برنامه‌های شما می‌شود. می‌توانید انتخاب کنید که در App Engine بمانید یا به هر یک از گزینه‌هایی که قبلاً توضیح داده شد، مهاجرت کنید.

این مهاجرت در مقایسه با سایر موارد این مجموعه به تلاش بیشتری نیاز دارد. جایگزین پیشنهادی برای App Engine Memcache، Cloud Memorystore است که یک سرویس ذخیره‌سازی ابری کاملاً مدیریت‌شده است. Memorystore از دو موتور ذخیره‌سازی متن‌باز محبوب، Redis و Memcached، پشتیبانی می‌کند. این ماژول مهاجرت از Cloud Memorystore برای Redis استفاده می‌کند. می‌توانید اطلاعات بیشتر را در نمای کلی Memorystore و Redis کسب کنید.

از آنجا که Memorystore به یک سرور در حال اجرا نیاز دارد، Cloud VPC نیز مورد نیاز است. به طور خاص، باید یک رابط Serverless VPC Access ایجاد شود تا برنامه App Engine بتواند از طریق آدرس IP خصوصی خود به نمونه Memorystore متصل شود. پس از اتمام این تمرین، برنامه را به‌روزرسانی کرده‌اید تا در حالی که مانند قبل رفتار می‌کند، Cloud Memorystore سرویس ذخیره‌سازی باشد و جایگزین سرویس Memcache برنامه App Engine شود.

این آموزش با نمونه برنامه ماژول ۱۲ در پایتون ۲ آغاز می‌شود و پس از آن یک ارتقاء جزئی، اختیاری و اضافی به پایتون ۳ انجام می‌شود. اگر از قبل با دسترسی به سرویس‌های همراه App Engine از پایتون ۳ از طریق SDK مربوط به App Engine پایتون ۳ آشنا هستید، می‌توانید به جای آن با نسخه پایتون ۳ از نمونه برنامه ماژول ۱۲ شروع کنید. انجام این کار مستلزم حذف استفاده از SDK خواهد بود زیرا Memorystore یک سرویس همراه App Engine نیست . یادگیری نحوه استفاده از SDK مربوط به App Engine پایتون ۳ خارج از محدوده این آموزش است.

این آموزش شامل مراحل کلیدی زیر است:

  1. راه‌اندازی/پیش‌پردازش
  2. راه‌اندازی سرویس‌های ذخیره‌سازی موقت
  3. به‌روزرسانی فایل‌های پیکربندی
  4. به‌روزرسانی برنامه اصلی

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

آماده سازی پروژه ابری

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

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

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

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

پوشه START باید شامل فایل‌های زیر باشد:

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

اگر از نسخه پایتون ۲ شروع می‌کنید، یک فایل appengine_config.py و احتمالاً یک پوشه lib نیز وجود خواهد داشت، البته اگر codelab ماژول ۱۲ را تکمیل کرده باشید.

(دوباره) استقرار برنامه ماژول ۱۲

مراحل پیش از کار باقی مانده شما:

  1. (در صورت لزوم) دوباره با ابزار خط فرمان gcloud آشنا شوید
  2. (در صورت لزوم) کد ماژول ۱۲ را در App Engine (دوباره) مستقر کنید

کاربران پایتون ۲ باید پوشه lib را با این دستورات حذف و دوباره نصب کنند:

rm -rf ./lib; pip install -t lib -r requirements.txt

حالا همه (کاربران پایتون ۲ و ۳) باید کد را با این دستور در App Engine آپلود کنند:

gcloud app deploy

پس از استقرار موفقیت‌آمیز، تأیید کنید که ظاهر و عملکرد برنامه درست مانند برنامه موجود در ماژول ۱۲ است، یک برنامه وب که بازدیدها را ردیابی می‌کند و آنها را برای همان کاربر به مدت یک ساعت ذخیره می‌کند:

dfe56a02ae59ddd8.png

از آنجا که آخرین بازدیدها ذخیره می‌شوند، به‌روزرسانی‌های صفحه باید نسبتاً سریع بارگیری شوند.

۴. سرویس‌های ذخیره‌سازی را راه‌اندازی کنید

Cloud Memorystore بدون سرور نیست . یک نمونه مورد نیاز است؛ در این مورد، نمونه‌ای که Redis را اجرا می‌کند. برخلاف Memcache، Memorystore یک محصول Cloud مستقل است و ردیف رایگان ندارد ، بنابراین قبل از ادامه، حتماً اطلاعات قیمت‌گذاری Redis را در Memorystore بررسی کنید. برای به حداقل رساندن هزینه‌ها برای این تمرین، حداقل میزان منابع برای کار را توصیه می‌کنیم: یک ردیف سرویس پایه و ظرفیت ۱ گیگابایت .

نمونه Memorystore در شبکه‌ای متفاوت از برنامه App Engine شما (نمونه‌ها) قرار دارد و به همین دلیل است که باید یک رابط Serverless VPC Access ایجاد شود تا App Engine بتواند به منابع Memorystore شما دسترسی پیدا کند. برای به حداقل رساندن هزینه‌های VPC، نوع نمونه ( f1-micro ) و کمترین تعداد نمونه برای درخواست را انتخاب کنید (ما حداقل ۲ و حداکثر ۳ مورد را پیشنهاد می‌کنیم). همچنین صفحه اطلاعات قیمت‌گذاری VPC را بررسی کنید.

ما این توصیه‌ها را برای کاهش هزینه‌ها، همزمان با راهنمایی شما در ایجاد هر منبع مورد نیاز، تکرار می‌کنیم. علاوه بر این، وقتی منابع Memorystore و VPC را در Cloud Console ایجاد می‌کنید، ماشین حساب قیمت‌گذاری هر محصول را در گوشه بالا سمت راست مشاهده خواهید کرد که تخمین هزینه ماهانه را به شما می‌دهد (به تصویر زیر مراجعه کنید). در صورت تغییر گزینه‌هایتان، این مقادیر به طور خودکار تنظیم می‌شوند. این تقریباً همان چیزی است که باید انتظار دیدن آن را داشته باشید:

7eb35ebf7248c010.png

هر دو منبع مورد نیاز هستند و فرقی نمی‌کند کدام را اول ایجاد کنید. اگر ابتدا نمونه Memorystore را ایجاد کنید، برنامه App Engine شما بدون کانکتور VPC نمی‌تواند به آن دسترسی پیدا کند. به همین ترتیب، اگر ابتدا کانکتور VPC را ایجاد کنید، هیچ چیزی در شبکه VPC برای ارتباط برنامه App Engine شما وجود ندارد. این آموزش به شما آموزش می‌دهد که ابتدا نمونه Memorystore و سپس کانکتور VPC را ایجاد کنید.

وقتی هر دو منبع آنلاین شدند، باید اطلاعات مربوطه را به app.yaml اضافه کنید تا برنامه شما بتواند به حافظه پنهان دسترسی داشته باشد. همچنین می‌توانید به راهنماهای پایتون ۲ یا پایتون ۳ در مستندات رسمی مراجعه کنید. راهنمای ذخیره‌سازی داده‌ها در صفحه مهاجرت Cloud NDB ( پایتون ۲ یا پایتون ۳ ) نیز ارزش مراجعه دارد.

یک نمونه Cloud Memorystore ایجاد کنید

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

  • پایین‌ترین سطح سرویس را انتخاب کنید: پایه (پیش‌فرض کنسول: "استاندارد"، پیش‌فرض gcloud : "پایه").
  • کمترین میزان فضای ذخیره‌سازی را انتخاب کنید: ۱ گیگابایت (پیش‌فرض کنسول: ۱۶ گیگابایت، پیش‌فرض gcloud : ۱ گیگابایت).
  • معمولاً جدیدترین نسخه‌های هر نرم‌افزاری به بیشترین میزان منابع نیاز دارند، اما انتخاب قدیمی‌ترین نسخه نیز احتمالاً توصیه نمی‌شود. در حال حاضر، دومین نسخه جدید، Redis نسخه ۵.۰ است (پیش‌فرض کنسول: ۶.x).

با در نظر گرفتن این تنظیمات، بخش بعدی شما را در ایجاد نمونه از Cloud Console راهنمایی می‌کند. اگر ترجیح می‌دهید این کار را از خط فرمان انجام دهید، از ادامه مطلب صرف نظر کنید.

از کنسول ابری

به صفحه Cloud Memorystore در کنسول Cloud بروید (ممکن است از شما اطلاعات صورتحساب خواسته شود). اگر هنوز Memorystore را فعال نکرده‌اید، از شما خواسته می‌شود این کار را انجام دهید:

۶۸۳۱۸۹۹۷e۳۱۰۵db۶.png

پس از فعال کردن آن (و احتمالاً همراه با صورتحساب)، به داشبورد Memorystore خواهید رسید. در اینجا می‌توانید تمام نمونه‌های ایجاد شده در پروژه خود را مشاهده کنید. پروژه نشان داده شده در زیر هیچ نمونه‌ای ندارد، به همین دلیل است که عبارت "هیچ ردیفی برای نمایش وجود ندارد" را می‌بینید. برای ایجاد یک نمونه Memorystore، روی ایجاد نمونه در بالا کلیک کنید:

63547aa575838a36.png

این صفحه شامل فرمی است که باید تنظیمات دلخواه خود را برای ایجاد نمونه Memorystore تکمیل کنید:

b77d927287fdf4c7.png

برای کاهش هزینه‌های این آموزش و برنامه نمونه آن، توصیه‌های قبلی را دنبال کنید. پس از انتخاب‌های خود، روی ایجاد کلیک کنید. فرآیند ایجاد چند دقیقه طول می‌کشد. پس از اتمام، آدرس IP و شماره پورت نمونه را برای اضافه کردن به app.yaml کپی کنید.

از خط فرمان

اگرچه ایجاد نمونه‌های Memorystore از کنسول ابری از نظر بصری آموزنده است، اما برخی خط فرمان را ترجیح می‌دهند. قبل از ادامه، حتماً gcloud نصب و راه‌اندازی کرده باشید.

همانند کنسول ابری، Cloud Memorystore برای Redis نیز باید فعال باشد. دستور gcloud services enable redis.googleapis.com را اجرا کنید و منتظر بمانید تا عملیات تکمیل شود، مانند این مثال:

$ gcloud services enable redis.googleapis.com
Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

اگر سرویس از قبل فعال شده باشد، اجرای مجدد دستور هیچ عارضه جانبی (منفی) ندارد. با فعال شدن سرویس، بیایید یک نمونه Memorystore ایجاد کنیم. آن دستور به شکل زیر است:

gcloud redis instances create NAME --redis-version VERSION \
    --region REGION --project PROJECT_ID

یک نام برای نمونه Memorystore خود انتخاب کنید؛ این آزمایشگاه از " demo-ms " به عنوان نام به همراه شناسه پروژه " my-project " استفاده می‌کند. منطقه این برنامه نمونه us-central1 (همان us-central ) است، اما اگر تأخیر نگران‌کننده است، می‌توانید از منطقه‌ای نزدیک‌تر به خود استفاده کنید. باید همان منطقه برنامه App Engine خود را انتخاب کنید. می‌توانید هر نسخه Redis را که ترجیح می‌دهید انتخاب کنید، اما ما از نسخه 5 همانطور که قبلاً توصیه شد استفاده می‌کنیم. با توجه به این تنظیمات، این دستوری است که باید صادر کنید (همراه با خروجی مرتبط):

$ gcloud redis instances create demo-ms --region us-central1 \
    --redis-version redis_5_0 --project my-project

Create request issued for: [demo-ms]
Waiting for operation [projects/my-project/locations/us-central1/operations/operation-xxxx] to complete...done.
Created instance [demo-ms].

برخلاف پیش‌فرض‌های کنسول ابری، gcloud به طور پیش‌فرض از حداقل منابع استفاده می‌کند. نتیجه این است که نه سطح سرویس و نه میزان فضای ذخیره‌سازی در آن دستور مورد نیاز نبوده‌اند. ایجاد یک نمونه Memorystore چند دقیقه طول می‌کشد و پس از اتمام کار، آدرس IP و شماره پورت نمونه را یادداشت کنید زیرا به زودی به app.yaml اضافه خواهند شد.

تأیید ایجاد نمونه

از کنسول ابری یا خط فرمان

چه نمونه خود را از طریق کنسول ابری و چه از طریق خط فرمان ایجاد کرده باشید، می‌توانید با این دستور تأیید کنید که در دسترس و آماده استفاده است: gcloud redis instances list --region REGION

در اینجا دستور بررسی نمونه‌ها در ناحیه us-central1 به همراه خروجی مورد انتظار که نمونه‌ای را که ایجاد کرده‌ایم نشان می‌دهد، آمده است:

$ gcloud redis instances list --region us-central1
INSTANCE_NAME  VERSION    REGION       TIER   SIZE_GB  HOST         PORT  NETWORK  RESERVED_IP     STATUS  CREATE_TIME
demo-ms        REDIS_5_0  us-central1  BASIC  1        10.aa.bb.cc  6379  default  10.aa.bb.dd/29  READY   2022-01-28T09:24:45

وقتی از شما اطلاعات نمونه یا پیکربندی برنامه‌تان پرسیده شد، حتماً از HOST و PORT استفاده کنید (نه RESERVED_IP ). داشبورد Cloud Memorystore در Cloud Console اکنون باید آن نمونه را نمایش دهد:

c5a6948ec1c056ed.png

از ماشین مجازی Compute Engine

اگر یک ماشین مجازی (VM) از نوع Compute Engine دارید، می‌توانید دستورات مستقیمی را از یک VM به نمونه Memorystore خود ارسال کنید تا از کارکرد آن اطمینان حاصل کنید. توجه داشته باشید که استفاده از یک VM ممکن است هزینه‌هایی مستقل از منابعی که در حال حاضر استفاده می‌کنید، داشته باشد.

ایجاد کانکتور دسترسی VPC بدون سرور

مانند Cloud Memorystore، می‌توانید رابط Cloud VPC بدون سرور را در کنسول Cloud یا در خط فرمان ایجاد کنید. به طور مشابه، Cloud VPC هیچ ردیف رایگانی ندارد، بنابراین توصیه می‌کنیم کمترین میزان منابع را برای تکمیل آزمایشگاه کد اختصاص دهید تا هزینه‌ها به حداقل برسد و این امر با این تنظیمات قابل دستیابی است:

  • کمترین تعداد حداکثر نمونه‌ها را انتخاب کنید: ۳ (پیش‌فرض کنسول و gcloud : ۱۰)
  • کم‌هزینه‌ترین نوع دستگاه را انتخاب کنید: f1-micro (پیش‌فرض کنسول: e2-micro ، بدون پیش‌فرض gcloud )

بخش بعدی شما را در ایجاد کانکتور از کنسول ابری با استفاده از تنظیمات Cloud VPC فوق راهنمایی می‌کند. اگر ترجیح می‌دهید این کار را از خط فرمان انجام دهید، به بخش بعدی بروید.

از کنسول ابری

به صفحه «دسترسی VPC بدون سرور» در کنسول ابری بروید (ممکن است از شما اطلاعات صورتحساب خواسته شود). اگر هنوز API را فعال نکرده‌اید، از شما خواسته می‌شود این کار را انجام دهید:

e3b9c0651de25e97.png

پس از فعال کردن API (و احتمالاً همراه با صورتحساب)، به داشبوردی خواهید رسید که تمام کانکتورهای VPC ایجاد شده را نمایش می‌دهد. پروژه‌ای که در تصویر زیر استفاده شده است، هیچ کانکتوری ندارد، به همین دلیل است که می‌گوید: "ردیفی برای نمایش وجود ندارد". در کنسول خود، روی ایجاد کانکتور در بالا کلیک کنید:

b74b49b9d73b7dcf.png

فرم را با تنظیمات دلخواه تکمیل کنید:

6b26b2aafa719f73.png

تنظیمات مناسب را برای برنامه‌های خود انتخاب کنید. برای این آموزش و برنامه نمونه آن با حداقل نیازها، منطقی است که هزینه‌ها را به حداقل برسانید، بنابراین توصیه‌های قبلی را دنبال کنید. پس از انتخاب‌های خود، روی ایجاد کلیک کنید. درخواست یک کانکتور VPC چند دقیقه طول می‌کشد.

از خط فرمان

قبل از ایجاد کانکتور VPC، ابتدا Serverless VPC Access API را فعال کنید. پس از اجرای دستور زیر، باید خروجی مشابهی را مشاهده کنید:

$ gcloud services enable vpcaccess.googleapis.com
Operation "operations/acf.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

با فعال کردن API، یک کانکتور VPC با دستوری شبیه به این ایجاد می‌شود:

gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
    --range 10.8.0.0/28 --region REGION --project PROJECT_ID

یک نام برای کانکتور خود و همچنین یک آدرس IP شروع از بلوک CIDR /28 استفاده نشده انتخاب کنید. این آموزش فرضیات زیر را در نظر می‌گیرد:

  • شناسه پروژه : my-project
  • نام کانکتور VPC : demo-vpc
  • حداقل نمونه‌ها : ۲ (پیش‌فرض) و حداکثر نمونه‌ها : ۳
  • نوع نمونه : f1-micro
  • منطقه : us-central1
  • بلوک CIDR IPv4 : 10.8.0.0/28 (مطابق توصیه در کنسول ابری)

اگر دستور زیر را با در نظر گرفتن فرضیات بالا اجرا کنید، انتظار خروجی مشابه آنچه در زیر می‌بینید را داشته باشید: 

$ gcloud compute networks vpc-access connectors create demo-vpc \
    --max-instances 3 --range 10.8.0.0/28 --machine-type f1-micro \
    --region us-central1  --project my-project

Create request issued for: [demo-vpc]
Waiting for operation [projects/my-project/locations/us-central1/operations/xxx] to complete...done.
Created connector [demo-vpc].

دستور بالا مقادیر پیش‌فرض مانند حداقل تعداد نمونه‌ها ۲ و شبکه‌ای به نام default را مشخص نمی‌کند. ایجاد یک کانکتور VPC چند دقیقه طول می‌کشد.

تأیید ایجاد کانکتور

پس از اتمام فرآیند، دستور gcloud زیر را با فرض اینکه region us-central1 است، اجرا کنید تا تأیید شود که ایجاد شده و آماده استفاده است: 

$ gcloud compute networks vpc-access connectors list --region us-central1
CONNECTOR_ID  REGION       NETWORK  IP_CIDR_RANGE  SUBNET  SUBNET_PROJECT  MIN_THROUGHPUT  MAX_THROUGHPUT  STATE
demo-vpc      us-central1  default  10.8.0.0/28                            200             300             READY

به طور مشابه، داشبورد اکنون باید کانکتوری را که ایجاد کرده‌اید نمایش دهد:

e03db2c8140ed014.png

به شناسه پروژه ابری، نام کانکتور VPC و منطقه توجه کنید.

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

۵. به‌روزرسانی فایل‌های پیکربندی

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

الزامات.txt

در این بخش، ما بسته‌هایی را برای پشتیبانی از Cloud Memorystore و همچنین Cloud NDB اضافه می‌کنیم. برای Cloud Memorystore برای Redis ، کافی است از کلاینت استاندارد Redis برای پایتون ( redis ) استفاده کنید زیرا هیچ کتابخانه کلاینت Cloud Memorystore به خودی خود وجود ندارد. redis و google-cloud-ndb را به requirements.txt اضافه کنید و flask از ماژول ۱۲ به آن اضافه کنید: 

flask
redis
google-cloud-ndb

این فایل requirements.txt هیچ شماره نسخه‌ای ندارد، به این معنی که آخرین نسخه‌ها انتخاب شده‌اند. در صورت بروز هرگونه ناسازگاری، شماره نسخه‌ها را برای قفل کردن نسخه‌های فعال مشخص کنید.

برنامه.yaml

بخش‌های جدید برای اضافه شدن

موتور اجرای پایتون ۲ (Python 2 App Engine) هنگام استفاده از APIهای ابری مانند Cloud NDB، به بسته‌های شخص ثالث خاصی، یعنی grpcio و setuptools ، نیاز دارد. کاربران پایتون ۲ باید کتابخانه‌های داخلی مانند این‌ها را به همراه نسخه موجود در app.yaml فهرست کنند. اگر هنوز بخش libraries را ندارید، یکی ایجاد کنید و هر دو کتابخانه را مانند زیر اضافه کنید: 

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

هنگام انتقال برنامه‌تان ، ممکن است از قبل بخش libraries را داشته باشد. اگر دارد، و grpcio و setuptools وجود ندارند، کافیست آنها را به بخش libraries موجود خود اضافه کنید.

در مرحله بعد، برنامه نمونه ما به نمونه Cloud Memorystore و اطلاعات کانکتور VPC نیاز دارد، بنابراین دو بخش جدید زیر را صرف نظر از اینکه از کدام زمان اجرای پایتون استفاده می‌کنید، به app.yaml اضافه کنید: 

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

خب، به‌روزرسانی‌های مورد نیاز همین بود. app.yaml به‌روزرسانی‌شده‌ی شما حالا باید به این شکل باشد: 

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

در زیر یک «قبل و بعد» وجود دارد که به‌روزرسانی‌هایی را که باید در app.yaml اعمال کنید، نشان می‌دهد:

ec2bb027a67debb6.png

*تفاوت‌های پایتون ۳

این بخش اختیاری است و فقط در صورتی که قصد انتقال به پایتون ۳ را دارید، باید آن را انجام دهید. برای انجام این کار، باید تعدادی تغییر در پیکربندی پایتون ۲ خود ایجاد کنید. اگر در حال حاضر قصد ارتقا ندارید، از این بخش صرف نظر کنید.

نه threadsafe و نه api_version برای زمان اجرای پایتون ۳ استفاده نمی‌شوند، بنابراین هر دوی این تنظیمات را حذف کنید. آخرین زمان اجرای App Engine از کتابخانه‌های شخص ثالث داخلی و همچنین کپی کردن کتابخانه‌های غیر داخلی پشتیبانی نمی‌کند. تنها الزام برای بسته‌های شخص ثالث، فهرست کردن آنها در requirements.txt است. در نتیجه، کل بخش libraries از app.yaml قابل حذف است.

در مرحله بعد، زمان اجرای پایتون ۳ نیاز به استفاده از چارچوب‌های وب دارد که مسیریابی خود را انجام می‌دهند، به همین دلیل است که ما در ماژول ۱ به توسعه‌دهندگان نحوه مهاجرت از webp2 به Flask را نشان دادیم. در نتیجه، همه کنترل‌کننده‌های اسکریپت باید به auto تغییر داده شوند. از آنجایی که این برنامه هیچ فایل استاتیکی را ارائه نمی‌دهد، "بی‌معنی" است که کنترل‌کننده‌ها فهرست شوند (زیرا همه آنها auto هستند)، بنابراین کل بخش handlers نیز می‌تواند حذف شود. در نتیجه، app.yaml جدید و مختصر شما که برای پایتون ۳ بهینه شده است، باید به این شکل کوتاه شود: 

runtime: python39

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

خلاصه تفاوت‌های app.yaml هنگام انتقال به پایتون ۳:

  • تنظیمات threadsafe و api_version را حذف کنید
  • بخش حذف libraries
  • بخش handlers حذف کنید (یا اگر برنامه شما از فایل‌های استاتیک پشتیبانی می‌کند، فقط هندلرهای script را حذف کنید)

مقادیر را جایگزین کنید

مقادیر موجود در بخش‌های جدید برای Memorystore و کانکتور VPC فقط متغیرهایی هستند. مقادیر بزرگ ( YOUR_REDIS_HOST, YOUR_REDIS_PORT, PROJECT_ID, REGION, CONNECTOR_NAME ) را با مقادیر ذخیره شده از زمانی که این منابع را قبلاً ایجاد کرده‌اید، جایگزین کنید. در مورد نمونه Memorystore خود، حتماً HOST (نه RESERVED_IP ) و PORT استفاده کنید. در اینجا یک روش سریع خط فرمان برای دریافت HOST و PORT با فرض نام نمونه demo-ms و REGION us-central1 آورده شده است: 

$ gcloud redis instances describe demo-ms --region us-central1 \
    --format "value(host,port)"
10.251.161.51   6379

اگر آدرس IP نمونه Redis ما در پروژه my-project که در ناحیه us-central1 با نام کانکتور VPC به نام demo-vpc قرار دارد، 10.10.10.10 باشد و از پورت 6379 استفاده کند، این بخش‌ها در app.yaml به این شکل خواهند بود: 

env_variables:
    REDIS_HOST: '10.10.10.10'
    REDIS_PORT: '6379'

vpc_access_connector:
    name: projects/my-project/locations/us-central1/connectors/demo-vpc

appengine_config.py را ایجاد یا به‌روزرسانی کنید.

اضافه شدن پشتیبانی از کتابخانه‌های شخص ثالث داخلی

درست مانند کاری که قبلاً با app.yaml انجام دادیم، استفاده از کتابخانه‌های grpcio و setuptools را اضافه کنید. appengine_config.py را برای پشتیبانی از کتابخانه‌های شخص ثالث داخلی تغییر دهید. اگر این مورد آشنا به نظر می‌رسد، به این دلیل است که این مورد در ماژول ۲ هنگام مهاجرت از App Engine ndb به Cloud NDB نیز مورد نیاز بود. تغییر دقیق مورد نیاز، اضافه کردن پوشه lib به مجموعه کاری setuptools.pkg_resources است:

4140b3800694f77e.png

*تفاوت‌های پایتون ۳

این بخش اختیاری است و فقط در صورتی که قصد انتقال به پایتون ۳ را دارید، باید آن را انجام دهید. یکی از تغییرات خوشایند نسل دوم App Engine این است که کپی کردن (که گاهی اوقات "فروش" نامیده می‌شود) از بسته‌های شخص ثالث (غیر داخلی) و ارجاع به بسته‌های شخص ثالث داخلی در app.yaml دیگر ضروری نیست، به این معنی که می‌توانید کل فایل appengine_config.py را حذف کنید.

۶. به‌روزرسانی فایل‌های برنامه

فقط یک فایل برنامه، main.py ، وجود دارد، بنابراین تمام تغییرات در این بخش فقط روی آن فایل تأثیر می‌گذارند. ما یک نمایش تصویری از تغییراتی که قرار است برای انتقال این برنامه به Cloud Memorystore ایجاد کنیم، ارائه داده‌ایم. این فقط برای اهداف نمایشی است و برای تجزیه و تحلیل دقیق شما در نظر گرفته نشده است. تمام کار مربوط به تغییراتی است که در کد ایجاد می‌کنیم.

5d043768ba7be742.png

بیایید این بخش‌ها را یکی‌یکی بررسی کنیم، و از بالا شروع کنیم.

به‌روزرسانی واردات

بخش ایمپورت در main.py برای ماژول ۱۲ از Cloud NDB و Cloud Tasks استفاده می‌کند؛ ایمپورت‌های آنها به شرح زیر است:

قبل از: 

from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb

تغییر به Memorystore نیاز به خواندن متغیرهای محیطی دارد، به این معنی که ما به ماژول os پایتون و همچنین redis ، کلاینت پایتون Redis، نیاز داریم. از آنجایی که Redis نمی‌تواند اشیاء پایتون را ذخیره کند، لیست آخرین بازدیدها را با استفاده از pickle مرتب کنید، بنابراین آن را نیز وارد کنید. یکی از مزایای Memcache این است که سریال‌سازی اشیاء به طور خودکار اتفاق می‌افتد در حالی که Memorystore کمی "خودتان انجام دهید" است. در نهایت، با جایگزینی google.appengine.ext.ndb با google.cloud.ndb ، از App Engine ndb به Cloud NDB ارتقا دهید. پس از این تغییرات، ایمپورت‌های شما اکنون باید به شکل زیر باشند:

بعد از: 

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

مقداردهی اولیه را به‌روزرسانی کنید

مقداردهی اولیه ماژول ۱۲ شامل نمونه‌سازی app برنامه Flask و تنظیم یک ثابت برای ذخیره‌سازی به مدت یک ساعت است:

قبل از : 

app = Flask(__name__)
HOUR = 3600

استفاده از APIهای ابری نیاز به یک کلاینت دارد، بنابراین بلافاصله پس از Flask، یک کلاینت Cloud NDB نمونه‌سازی کنید. در مرحله بعد، آدرس IP و شماره پورت را برای نمونه Memorystore از متغیرهای محیطی که در app.yaml تنظیم کرده‌اید، دریافت کنید. با استفاده از این اطلاعات، یک کلاینت Redis نمونه‌سازی کنید. کد شما پس از این به‌روزرسانی‌ها به این شکل خواهد بود:

بعد از: 

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

* مهاجرت به پایتون ۳

این بخش اختیاری است و اگر از نسخه پایتون ۳ برنامه ماژول ۱۲ شروع می‌کنید، در این صورت، چندین تغییر الزامی در رابطه با واردات و مقداردهی اولیه وجود دارد.

اولاً، از آنجا که Memcache یک سرویس همراه با App Engine است، استفاده از آن در یک برنامه پایتون ۳ نیاز به App Engine SDK دارد، که به طور خاص برنامه WSGI (و همچنین سایر پیکربندی‌های لازم ) را در بر می‌گیرد:

قبل از: 

from flask import Flask, render_template, request
from google.appengine.api import memcache, wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
HOUR = 3600

از آنجایی که ما در حال مهاجرت به Cloud Memorystore هستیم (نه یک سرویس همراه با App Engine مانند Memcache)، استفاده از SDK باید حذف شود. این کار ساده است زیرا شما به سادگی کل خطی را که هم memcache و هم wrap_wsgi_app را وارد می‌کند، حذف خواهید کرد. همچنین خطی را که wrap_wsgi_app() را فراخوانی می‌کند، حذف خواهید کرد. این به‌روزرسانی‌ها این بخش از برنامه (در واقع کل برنامه) را با نسخه پایتون ۲ یکسان باقی می‌گذارند.

بعد از: 

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

در نهایت، استفاده از SDK را از app.yaml (خط app_engine_apis: true حذف کنید) و requirements.txt (خط appengine-python-standard را حذف کنید) حذف کنید.

مهاجرت به Cloud Memorystore (و Cloud NDB)

مدل داده‌ی Cloud NDB طوری در نظر گرفته شده است که با App Engine ndb سازگار باشد، به این معنی که تعریف اشیاء Visit ثابت می‌ماند. با تقلید از مهاجرت ماژول ۲ به Cloud NDB، تمام فراخوانی‌های Datastore در store_visit() و fetch_visits() افزوده شده و در یک بلوک with جدید جاسازی می‌شوند (زیرا استفاده از مدیر زمینه‌ی Cloud NDB مورد نیاز است). در اینجا فراخوانی‌های قبل از این تغییر آمده است:

قبل از: 

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    return Visit.query().order(-Visit.timestamp).fetch(limit)

یک بلوک with ds_client.context() به هر دو تابع اضافه کنید و فراخوانی‌های Datastore را درون آن قرار دهید (و تورفتگی ایجاد کنید). در این حالت، هیچ تغییری برای خود فراخوانی‌ها لازم نیست:

بعد از: 

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()

def fetch_visits(limit):
    'get most recent visits'
    with ds_client.context():
        return Visit.query().order(-Visit.timestamp).fetch(limit)

در مرحله بعد، بیایید به تغییرات ذخیره‌سازی نگاهی بیندازیم. در اینجا تابع main() از ماژول ۱۲ آمده است:

قبل از: 

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    visits = memcache.get('visits')

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0].visitor != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        memcache.set('visits', visits, HOUR)  # set() not add()

    return render_template('index.html', visits=visits)

Redis درست مثل Memcache فراخوانی‌های "get" و "set" را دارد. تنها کاری که انجام می‌دهیم این است که کتابخانه‌های کلاینت مربوطه را جابجا می‌کنیم، درست است؟ تقریباً. همانطور که قبلاً ذکر شد، نمی‌توانیم یک لیست پایتون را با Redis کش کنیم (زیرا ابتدا باید سریالی شود، چیزی که Memcache به طور خودکار از آن مراقبت می‌کند)، بنابراین در فراخوانی set() ، بازدیدها را با pickle.dumps() به یک رشته تبدیل کنید. به طور مشابه، هنگام بازیابی بازدیدها از کش، باید بلافاصله پس از get() آن را با pickle.loads() از حالت فشرده خارج کنید. در اینجا هندلر اصلی پس از اجرای این تغییرات آمده است:

بعد از: 

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    rsp = REDIS.get('visits')
    visits = pickle.loads(rsp) if rsp else None

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0].visitor != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        REDIS.set('visits', pickle.dumps(visits), ex=HOUR)

    return render_template('index.html', visits=visits)

این پایان تغییرات مورد نیاز در main.py برای تبدیل استفاده برنامه نمونه از Memcache به Cloud Memorystore است. در مورد قالب HTML و پورت کردن به پایتون ۳ چطور؟

فایل قالب HTML را به‌روزرسانی کنید و آن را به پایتون ۳ منتقل کنید؟

جای تعجب است! اینجا هیچ کاری برای انجام دادن وجود ندارد زیرا برنامه طوری طراحی شده است که هم روی پایتون ۲ و هم روی پایتون ۳ بدون هیچ تغییر کد یا کتابخانه سازگاری اجرا شود. main.py در پوشه‌های "FINISH" mod13a (2.x) و mod13b (3.x) یکسان خواهید یافت. همین امر در مورد requirements.txt نیز صدق می‌کند، جدا از هرگونه تفاوت در شماره نسخه (در صورت استفاده). از آنجا که رابط کاربری بدون تغییر باقی مانده است، هیچ به‌روزرسانی در templates/index.html نیز وجود ندارد.

هر آنچه برای اجرای این برنامه روی پایتون ۳ App Engine لازم بود، قبلاً در پیکربندی انجام شده بود: دستورالعمل‌های غیرضروری از app.yaml حذف شدند و appengine_config.py و پوشه lib نیز حذف شدند، زیرا در پایتون ۳ بلااستفاده هستند.

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

این بخش، این آزمایشگاه کد را با استقرار برنامه، تأیید عملکرد آن طبق برنامه و در هر خروجی منعکس‌شده، به پایان می‌رساند. پس از اعتبارسنجی برنامه، هرگونه پاکسازی را انجام داده و مراحل بعدی را در نظر بگیرید.

استقرار و تأیید برنامه

آخرین بررسی همیشه برای استقرار برنامه نمونه است. توسعه‌دهندگان پایتون ۲: lib با دستورات زیر حذف و دوباره نصب کنید. (اگر پایتون ۲ و ۳ را روی سیستم خود نصب کرده‌اید، ممکن است لازم باشد به جای آن، pip2 صریحاً اجرا کنید.) 

rm -rf ./lib
pip install -t lib -r requirements.txt

هر دو توسعه‌دهنده پایتون ۲ و ۳ اکنون باید برنامه‌های خود را با موارد زیر مستقر کنند: 

gcloud app deploy

از آنجایی که شما صرفاً زیرساخت‌ها را برای یک سرویس ذخیره‌سازی کاملاً متفاوت تغییر داده‌اید، خود برنامه باید دقیقاً مشابه برنامه ماژول ۱۲ شما عمل کند:

ماژول ۷ اپلیکیشن visitme

این مرحله codelab را تکمیل می‌کند. از شما دعوت می‌کنیم تا برنامه نمونه به‌روزرسانی‌شده خود را با یکی از پوشه‌های ماژول ۱۳، mod13a (پایتون ۲) یا mod13b (پایتون ۳) مقایسه کنید.

تمیز کردن

عمومی

اگر فعلاً کارتان تمام است، توصیه می‌کنیم برنامه 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 هستند. برای اطلاعات بیشتر به مستندات هر محصول مراجعه کنید:

این آموزش شامل استفاده از چهار محصول ابری بود:

  • موتور برنامه
  • فروشگاه داده ابری
  • حافظه ابری
  • ابر VPC

در زیر دستورالعمل‌هایی برای آزادسازی این منابع و جلوگیری/به حداقل رساندن هزینه‌های صدور صورتحساب آمده است.

خاموش کردن نمونه Memorystore و کانکتور VPC

اینها محصولاتی هستند که سطح رایگان ندارند ، بنابراین همین الان متحمل هزینه می‌شوید. اگر پروژه Cloud خود را خاموش نکنید (به بخش بعدی مراجعه کنید)، باید هم نمونه Memorystore و هم کانکتور VPC خود را حذف کنید تا هزینه‌ها متوقف شوند. مشابه زمانی که این منابع را ایجاد کردید، می‌توانید آنها را از Cloud Console یا خط فرمان نیز آزاد کنید.

از کنسول ابری

برای حذف نمونه Memorystore، به داشبورد Memorystore برگردید و روی شناسه نمونه کلیک کنید:

2b09baf1aa2e0a25.png

وقتی در صفحه جزئیات آن نمونه هستید، روی «حذف» کلیک کنید و تأیید کنید:

f9d9eb1c1d4c6107.png

برای حذف کانکتور VPC، به داشبورد آن بروید و کادر کنار کانکتوری که می‌خواهید حذف کنید را علامت بزنید، سپس روی «حذف» کلیک کنید و تأیید کنید:

ca5fbd9f4c7c9b60.png

از خط فرمان

دو دستور gcloud زیر به ترتیب هر دو نمونه Memorystore و کانکتور VPC را حذف می‌کنند:

  • gcloud redis instances delete INSTANCE --region REGION
  • gcloud compute networks vpc-access connectors delete CONNECTOR --region REGION

If you haven't set your project ID with gcloud config set project , you may have to provide --project PROJECT_ID . If your Memorystore instance is called demo-ms and VPC connector called demo-vpc , and both are in region us-central1 , issue the following pair of commands and confirm: 

$ gcloud redis instances delete demo-ms --region us-central1
You are about to delete instance [demo-ms] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-ms]
Waiting for operation [projects/PROJECT/locations/REGION/operations/operation-aaaaa-bbbbb-ccccc-ddddd] to complete...done.
Deleted instance [demo-ms].
$
$ gcloud compute networks vpc-access connectors delete demo-vpc --region us-central1
You are about to delete connector [demo-vpc] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-vpc]
Waiting for operation [projects/PROJECT/locations/REGION/operations/aaaaa-bbbb-cccc-dddd-eeeee] to complete...done.
Deleted connector [demo-vpc].

Each request takes a few minutes to run. These steps are optional if you choose to shut down your entire Cloud project as described earlier, however you still incur billing until the shut down process has completed.

مراحل بعدی

Beyond this tutorial, other migration modules that focus on moving away from the legacy bundled services to consider include:

  • Module 2 : migrate from App Engine ndb to Cloud NDB
  • Modules 7-9 : migrate from App Engine Task Queue push tasks to Cloud Tasks
  • Modules 12-13 : migrate from App Engine Memcache to Cloud Memorystore
  • Modules 15-16 : migrate from App Engine Blobstore to Cloud Storage
  • Modules 18-19 : migrate from App Engine Task Queue (pull tasks) to Cloud Pub/Sub

App Engine is no longer the only serverless platform in Google Cloud. If you have a small App Engine app or one that has limited functionality and wish to turn it into a standalone microservice, or you want to break-up a monolithic app into multiple reusable components, these are good reasons to consider moving to Cloud Functions . If containerization has become part of your application development workflow, particularly if it consists of a CI/CD (continuous integration/continuous delivery or deployment) pipeline, consider migrating to Cloud Run . These scenarios are covered by the following modules:

  • Migrate from App Engine to Cloud Functions: see Module 11
  • Migrate from App Engine to Cloud Run: see Module 4 to containerize your app with Docker, or Module 5 to do it without containers, Docker knowledge, or Dockerfile s

Switching to another serverless platform is optional, and we recommend considering the best options for your apps and use cases before making any changes.

Regardless of which migration module you consider next, all Serverless Migration Station content (codelabs, videos, source code [when available]) can be accessed at its open source repo . The repo's README also provides guidance on which migrations to consider and any relevant "order" of Migration Modules.

8. Additional resources

Listed below are additional resources for developers further exploring this or related Migration Module as well as related products. This includes places to provide feedback on this content, links to the code, and various pieces of documentation you may find useful.

Codelabs issues/feedback

If you find any issues with this codelab, please search for your issue first before filing. Links to search and create new issues:

Migration resources

Links to the repo folders for Module 12 (START) and Module 13 (FINISH) can be found in the table below. They can also be accessed from the repo for all App Engine codelab migrations which you can clone or download a ZIP file.

کدلب

Python 2

پایتون ۳

Module 12

کد

کد

Module 13 (this codelab)

کد

کد

Online references

Below are online resources which may be relevant for this tutorial:

موتور برنامه

App Engine NDB and Cloud NDB

App Engine Memcache and Cloud Memorystore

Cloud VPC

Other Cloud information

مجوز

This work is licensed under a Creative Commons Attribution 2.0 Generic License.