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

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

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

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

از Memcache استفاده نمی کنید؟

اگر برنامه شما از App Engine Memcache استفاده نمی‌کند، می‌توانید از این کد لبه صرف نظر کنید یا آن را به عنوان تمرینی برای آشنایی با مهاجرت به Cloud Memorystore انجام دهید.

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

• یک نمونه Cloud Memorystore را تنظیم کنید (از Cloud Console یا ابزار gcloud )
• یک رابط دسترسی VPC بدون سرور Cloud را تنظیم کنید (از Cloud Console یا ابزار gcloud )
• از App Engine Memcache به Cloud Memorystore مهاجرت کنید
• کش را با Cloud Memorystore در یک برنامه نمونه اجرا کنید
• از App Engine ndb به Cloud NDB مهاجرت کنید

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

• یک پروژه Google Cloud با یک حساب صورت‌حساب فعال (این یک کد رایگان نیست )
• مهارت های پایه پایتون
• دانش کاری دستورات رایج لینوکس
• دانش اولیه توسعه و استقرار برنامه های App Engine
• یک برنامه کاربردی Module 12 App Engine ( لاب کد ماژول 12 را تکمیل کنید [توصیه می شود] یا برنامه ماژول 12 را از مخزن کپی کنید)

نظرسنجی

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

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

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

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

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

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

2. پس زمینه

این آزمایشگاه کد نحوه انتقال یک برنامه نمونه از 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 نیز مورد نیاز است. به طور خاص، یک اتصال دهنده دسترسی VPC بدون سرور باید ایجاد شود تا برنامه App Engine بتواند از طریق آدرس IP خصوصی خود به نمونه Memorystore متصل شود. وقتی این تمرین را کامل کردید، برنامه را به‌روزرسانی کرده‌اید تا در حالی که مانند قبل عمل می‌کند، Cloud Memorystore سرویس ذخیره‌سازی خواهد بود و جایگزین سرویس Memcache موتور App خواهد شد.

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

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

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

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

پروژه Cloud را آماده کنید

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

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

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

از کد پایه ماژول 12 که ما از آن شروع می کنیم، این آزمایشگاه کد شما را گام به گام در مسیر مهاجرت راهنمایی می کند. پس از تکمیل، به یک برنامه ماژول 13 خواهید رسید که بسیار شبیه کد موجود در یکی از پوشه های FINISH است. در اینجا آن منابع آمده است:

• شروع: برنامه ماژول 12 Python 2 ( mod12 ) یا Python 3 ( mod12b )
• FINISH: ماژول 13 برنامه Python 2 ( mod13a ) یا Python 3 ( mod13b )
• کل مخزن مهاجرت (کلون یا دانلود ZIP)

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

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

اگر از نسخه Python 2 شروع می کنید، یک فایل appengine_config.py و احتمالاً یک پوشه lib در صورت تکمیل ماژول 12 Codelab وجود خواهد داشت.

(دوباره) برنامه ماژول 12 را مستقر کنید

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

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

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

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

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

gcloud app deploy                

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

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

4. سرویس های کش را راه اندازی کنید

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

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

هزینه: این آموزش رایگان نیست

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

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

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

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

همه منابع را در منطقه App Engine ایجاد کنید

در زیر، همه منابع Cloud اضافی لازم برای استفاده از Cloud Memorystore به عنوان سرویس کش برنامه App Engine خود را ایجاد خواهید کرد. قبل از انجام این کار، تشخیص دهید که باید هر دو نمونه Memorystore و کانکتور دسترسی VPC بدون سرور را در همان منطقه برنامه App Engine ایجاد کنید.

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

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

• پایین‌ترین ردیف سرویس را انتخاب کنید: Basic (پیش‌فرض کنسول: "Standard"، پیش‌فرض gcloud : "Basic").
• حداقل فضای ذخیره سازی را انتخاب کنید: 1 گیگابایت (پیش فرض کنسول: 16 گیگابایت، پیش فرض gcloud : 1 گیگابایت).
• معمولاً جدیدترین نسخه‌های هر نرم‌افزاری به بیشترین مقدار منابع نیاز دارند، اما احتمالاً انتخاب قدیمی‌ترین نسخه نیز توصیه نمی‌شود. آخرین نسخه در حال حاضر Redis نسخه 5.0 است (پیش‌فرض کنسول: 6.x)

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

از کنسول Cloud

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

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

به روز رسانی های Cloud Console

توجه داشته باشید که رابط کاربری Cloud Console هر از چند گاهی تغییر می کند، بنابراین ممکن است دقیقاً شبیه اسکرین شات های اینجا نباشد.

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

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

از خط فرمان

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

همانند Cloud Console، 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].

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

نمونه ایجاد شده را تأیید کنید

از Cloud Console یا command-line

چه نمونه خود را از کنسول Cloud ایجاد کرده باشید یا از خط فرمان، می توانید تأیید کنید که در دسترس و آماده استفاده با این دستور است: 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 اکنون باید آن نمونه را نمایش دهد:

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

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

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

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

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

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

از Cloud Console

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

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

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

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

از خط فرمان

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

$ 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 شروع بلوک /28 CIDR استفاده نشده انتخاب کنید. این آموزش مفروضات زیر را بیان می کند:

• شناسه پروژه : my-project
• نام کانکتور VPC : demo-vpc
• حداقل نمونه : 2 (پیش فرض) و حداکثر نمونه : 3
• نوع نمونه : f1-micro
• منطقه : us-central1
• بلوک IPv4 CIDR : 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].

دستور بالا از تعیین مقادیر پیش‌فرض، مانند نمونه‌های min 2 و شبکه‌ای با نام default صرفنظر می‌کند. ایجاد یک کانکتور VPC چند دقیقه طول می کشد تا کامل شود.

اتصال ایجاد شده را تأیید کنید

پس از تکمیل فرآیند، دستور gcloud زیر را با فرض اینکه منطقه 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

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

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

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

5. فایل های پیکربندی را به روز کنید

اولین قدم این است که تمام به روز رسانی های لازم را برای فایل های پیکربندی انجام دهید. کمک به مهاجرت کاربران پایتون 2 هدف اصلی این نرم افزار کد است، با این حال معمولاً محتوا با اطلاعاتی در مورد انتقال بیشتر به پایتون 3 در هر بخش زیر دنبال می شود.

الزامات. txt

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

flask
redis
google-cloud-ndb

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

app.yaml

بخش های جدید برای افزودن

زمان اجرا Python 2 App Engine به بسته‌های شخص ثالث خاصی در هنگام استفاده از Cloud API مانند Cloud NDB، یعنی grpcio و setuptools نیاز دارد. کاربران پایتون 2 باید کتابخانه های داخلی مانند این را به همراه نسخه موجود در 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 اعمال کنید نشان می‌دهد:

*تفاوت های پایتون 3

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

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

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

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 هنگام پورت کردن به پایتون 3:

• تنظیمات 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 نمونه ما 10.10.10.10 با استفاده از پورت 6379 در پروژه my-project واقع در منطقه us-central1 با نام رابط VPC demo-vpc ، این بخش‌ها در 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 برای پشتیبانی از کتابخانه های شخص ثالث داخلی تغییر دهید. اگر این آشنا به نظر می رسد، به این دلیل است که در ماژول 2 هنگام مهاجرت از App Engine ndb به Cloud NDB نیز به آن نیاز بود. تغییر دقیق مورد نیاز این است که پوشه lib را به مجموعه کاری setuptools.pkg_resources اضافه کنید:

*تفاوت های پایتون 3

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

6. فایل های برنامه را به روز کنید

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

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

واردات را به روز کنید

بخش واردات در main.py برای ماژول 12 از 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 Python و همچنین redis ، مشتری Python Redis نیاز داریم. از آنجایی که Redis نمی تواند اشیاء پایتون را کش کند، لیست بازدیدهای اخیر را با استفاده از pickle بررسی کنید، بنابراین آن را نیز وارد کنید. یکی از مزایای Memcache این است که سریال سازی اشیاء به طور خودکار انجام می شود در حالی که Memorystore کمی بیشتر "DIY" است. در نهایت، با جایگزینی 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

به روز رسانی اولیه

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

قبل از :

app = Flask(__name__)
HOUR = 3600

استفاده از Cloud API به یک کلاینت نیاز دارد، بنابراین یک کلاینت Cloud NDB را درست بعد از Flask نمونه سازی کنید. سپس، آدرس 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)

* مهاجرت پایتون 3

این بخش اختیاری است و اگر از نسخه Python 3 برنامه Module 12 شروع می کنید. اگر چنین است، چندین تغییر مورد نیاز مربوط به واردات و مقداردهی اولیه وجود دارد.

اولاً، از آنجایی که Memcache یک سرویس همراه با App Engine است، استفاده از آن در یک برنامه Python 3 به 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() فراخوانی می کند حذف کنید. این به‌روزرسانی‌ها این بخش از برنامه (در واقع، کل برنامه) را با نسخه Python 2 یکسان می‌کنند.

بعد از:

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 ثابت می‌ماند. با تقلید از انتقال ماژول 2 به 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() از ماژول 12 است:

قبل از:

@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 دارای تماس های "get" و "set" است، درست مانند Memcache. تنها کاری که ما انجام می دهیم این است که کتابخانه های مشتری مربوطه را عوض کنیم، درست است؟ تقریبا همانطور که قبلاً ذکر شد، ما نمی‌توانیم یک لیست پایتون را با Redis کش کنیم (زیرا ابتدا باید سریال شود، چیزی که Memcache به طور خودکار از آن مراقبت می‌کند)، بنابراین در فراخوانی set() ، بازدیدها را در یک رشته با pickle.dumps() . به طور مشابه، هنگام بازیابی بازدیدها از حافظه نهان، باید آن را با pickle.loads() درست بعد از get() حذف کنید. در اینجا کنترل کننده اصلی پس از اجرای آن تغییرات آمده است:

بعد از:

@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 و انتقال به پایتون 3 چطور؟

فایل قالب HTML و پورت را به پایتون 3 به روز کنید؟

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

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

App Engine NDB و Cloud NDB ذخیره خودکار را ارائه می دهند

در حالی که صراحتاً در حال انتقال از App Engine Memcache به Cloud Memorystore هستیم، توجه داشته باشید که هر دو App Engine ndb و Cloud NDB به ترتیب برای Python 2 یا 3 ذخیره خودکار را به Memcache یا Memorystore ارائه می دهند. در مورد کش کردن ndb در کش NDB و Cloud NDB بخوانید. caching در فعال کردن حافظه پنهان داده ، که آخرین دستورالعمل آن دقیقاً منعکس کننده دستورالعمل‌های این کد لبه است. ویژگی های اضافی را می توان در گزینه های زمینه و تراکنش یافت.

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

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

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

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

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

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

توسعه دهندگان Python 2 و 3 اکنون باید برنامه های خود را با موارد زیر مستقر کنند:

gcloud app deploy

از آنجایی که شما صرفاً چیزهای زیر را برای یک سرویس کش کاملاً متفاوت سیم کشی کرده اید، خود برنامه باید مانند برنامه ماژول 12 شما عمل کند:

این مرحله Codelab را کامل می کند. ما از شما دعوت می کنیم برنامه نمونه به روز شده خود را با یکی از پوشه های ماژول 13، mod13a (Python 2) یا mod13b (Python 3) مقایسه کنید.

پاک کن

ژنرال

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

برای افشای کامل، استقرار در یک پلت فرم محاسباتی بدون سرور 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 * شما بستگی دارد، به عنوان مثال، اگر برنامه شما در ایالات متحده میزبانی می شود، " us ".

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

مخصوص این کد لبه

خدمات لیست شده در زیر منحصر به این کدلب است. برای اطلاعات بیشتر به مستندات هر محصول مراجعه کنید:

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

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

• موتور برنامه
• Cloud Datastore
• حافظه ابری
• Cloud VPC

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

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

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

از Cloud Console

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

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

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

از خط فرمان

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

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

اگر شناسه پروژه خود را با gcloud config set project تنظیم نکرده اید، ممکن است مجبور شوید --project PROJECT_ID را ارائه دهید. اگر نمونه Memorystore شما demo-ms و رابط VPC به نام demo-vpc نامیده می‌شود و هر دو در منطقه us-central1 هستند، جفت دستور زیر را صادر کرده و تأیید کنید:

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

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

مراحل بعدی

فراتر از این آموزش، ماژول‌های مهاجرت دیگری که بر دور شدن از سرویس‌های همراه قدیمی تمرکز دارند عبارتند از:

• ماژول 2 : از App Engine ndb به Cloud NDB مهاجرت کنید
• ماژول‌های 7-9 : انتقال از وظایف فشاری App Engine Task Queue به Cloud Tasks
• ماژول‌های 12-13 : انتقال از App Engine Memcache به Cloud Memorystore
• ماژول های 15-16 : از App Engine Blobstore به Cloud Storage مهاجرت کنید
• ماژول‌های 18-19 : انتقال از App Engine Task Queue (کشش وظایف) به Cloud Pub/Sub

App Engine دیگر تنها پلتفرم بدون سرور در Google Cloud نیست. اگر یک برنامه App Engine کوچک یا برنامه‌ای دارید که عملکرد محدودی دارد و می‌خواهید آن را به یک میکروسرویس مستقل تبدیل کنید، یا می‌خواهید یک برنامه یکپارچه را به چندین مؤلفه قابل استفاده مجدد تقسیم کنید، اینها دلایل خوبی برای فکر رفتن به Cloud Functions هستند. اگر کانتینری‌سازی بخشی از گردش کار توسعه برنامه شما شده است، به‌ویژه اگر شامل یک خط لوله CI/CD (ادغام پیوسته/تحویل مداوم یا استقرار) باشد، مهاجرت به Cloud Run را در نظر بگیرید. این سناریوها توسط ماژول های زیر پوشش داده می شوند:

• مهاجرت از App Engine به Cloud Functions: به ماژول 11 مراجعه کنید
• مهاجرت از App Engine به Cloud Run: به ماژول 4 مراجعه کنید تا برنامه خود را با Docker محفظه کنید، یا ماژول 5 را بدون کانتینر، دانش Docker یا Dockerfile s انجام دهید.

جابجایی به یک پلتفرم بدون سرور دیگر اختیاری است، و توصیه می‌کنیم قبل از هر گونه تغییر، بهترین گزینه‌ها را برای برنامه‌ها و موارد استفاده خود در نظر بگیرید.

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

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

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

مسائل/بازخورد Codelabs

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

• مسائل را جستجو کنید
• پرونده / بازخورد جدید

منابع مهاجرت

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

Codelab	پایتون 2	پایتون 3
ماژول 12	کد	کد
ماژول 13 (این آزمایشگاه کد)	کد	کد

مراجع آنلاین

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

موتور برنامه

• مستندات App Engine
• زمان اجرا Python 2 App Engine (محیط استاندارد).
• استفاده از کتابخانه های داخلی App Engine در Python 2 App Engine
• زمان اجرا Python 3 App Engine (محیط استاندارد).
• تفاوت بین زمان اجرا Python 2 و 3 App Engine (محیط استاندارد).
• راهنمای مهاجرت Python 2 به 3 App Engine (محیط استاندارد).
• اطلاعات قیمت و سهمیه موتور App

App Engine NDB و Cloud NDB

• مروری بر NDB Engine App
• استفاده از App Engine NDB Datastore
• اسناد Google Cloud NDB
• مخزن Google Cloud NDB
• اطلاعات قیمت گذاری Cloud Datastore

App Engine Memcache و Cloud Memorystore

• نمای کلی Memcache Engine App
• مرجع memcache پایتون 2 App Engine
• مرجع memcache پایتون 3 App Engine
• راهنمای انتقال memcache برنامه App Engine به Cloud Memorystore
• مستندات Cloud Memorystor
• Cloud Memorystore برای مستندات Redis
• Cloud Memorystore برای اطلاعات قیمت گذاری Redis
• Cloud Memorystore از نسخه های Redis پشتیبانی می کند
• صفحه اصلی Cloud Memorystore
• یک نمونه جدید Memorystore در Cloud Console ایجاد کنید
• صفحه اصلی کلاینت پایتون ردیس
• مستندات کتابخانه کلاینت پایتون ردیس

Cloud VPC

• اسناد Google Cloud VPC
• صفحه اصلی Google Cloud VPC
• اطلاعات قیمت گذاری ابر VPC
• کانکتور دسترسی VPC بدون سرور جدید در کنسول Cloud ایجاد کنید

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

• پایتون در پلتفرم ابری گوگل
• کتابخانه های سرویس گیرنده Google Cloud Python
• لایه Google Cloud "همیشه رایگان".
• Google Cloud SDK (ابزار خط فرمان gcloud )
• تمام اسناد Google Cloud

مجوز

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