نقل البيانات من App Engine Memcache إلى Cloud Memorystore (الوحدة 13)

1. نظرة عامة

تهدف سلسلة البرامج التعليمية حول Serverless Migration Station (برامج تعليمية ذاتية السرعة وعملية) ومقاطع الفيديو ذات الصلة إلى مساعدة مطوّري الحوسبة بدون خادم على Google Cloud في تحديث تطبيقاتهم من خلال إرشادهم خلال عملية نقل واحدة أو أكثر، مع التركيز بشكل أساسي على التخلّي عن الخدمات القديمة. يؤدي ذلك إلى زيادة قابلية نقل تطبيقاتك ويمنحك المزيد من الخيارات والمرونة، ما يتيح لك الدمج مع مجموعة أكبر من منتجات Cloud والوصول إليها، كما يسهّل عليك الترقية إلى أحدث إصدارات اللغة. على الرغم من أنّ هذه السلسلة تركّز في البداية على أوائل مستخدمي Cloud، وخاصةً مطوّري App Engine (البيئة العادية)، إلا أنّها واسعة النطاق بما يكفي لتشمل منصات أخرى بلا خادم، مثل Cloud Functions وCloud Run، أو في أي مكان آخر إذا كان ذلك منطبقًا.

الغرض من هذا الدرس التطبيقي حول الترميز هو توضيح كيفية نقل البيانات من App Engine Memcache إلى Cloud Memorystore (Redis) لمطوّري تطبيقات Python 2 في App Engine. هناك أيضًا عملية نقل ضمنية من App Engine ndb إلى Cloud NDB، ولكن يتم تناولها بشكل أساسي في درس تطبيقي حول الترميز من الوحدة 2، لذا يُرجى الاطّلاع عليه للحصول على مزيد من المعلومات المفصّلة.

ستتعرَّف على كيفية إجراء ما يلي:

إعداد مثيل Cloud Memorystore (من Cloud Console أو أداة gcloud)
إعداد موصّل Cloud Serverless VPC Access (من Cloud Console أو أداة gcloud)
نقل البيانات من App Engine Memcache إلى Cloud Memorystore
تنفيذ التخزين المؤقت باستخدام Cloud Memorystore في تطبيق نموذجي
نقل البيانات من App Engine ndb إلى Cloud NDB

المتطلبات

مشروع على Google Cloud يتضمّن حساب فوترة نشطًا (هذا ليس درسًا برمجيًا مجانيًا)
مهارات أساسية في لغة Python
معرفة عملية بالأوامر الشائعة على نظام التشغيل Linux
معرفة أساسية بشأن تطوير ونشر تطبيقات App Engine
تطبيق يعمل على الوحدة 12 من App Engine (أكمِل الدرس التطبيقي حول الترميز للوحدة 12 [يُنصح بذلك] أو انسخ تطبيق الوحدة 12 من المستودع)

استطلاع

كيف ستستخدم هذا البرنامج التعليمي؟

قراءة المحتوى فقط

قراءة المحتوى وإكمال التمارين

كيف تقيّم تجربتك مع Python؟

مبتدئ

متوسط

متمكّن

ما هو تقييمك لتجربة استخدام خدمات 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 for Redis. يمكنك الاطّلاع على مزيد من المعلومات في نظرة عامة على Memorystore وRedis.

بما أنّ خدمة Memorystore تتطلّب خادمًا قيد التشغيل، يجب توفُّر شبكة VPC على Google Cloud أيضًا. على وجه التحديد، يجب إنشاء موصِّل Serverless VPC Access حتى يتمكّن تطبيق App Engine من الاتصال بمثيل Memorystore من خلال عنوان IP الخاص به. بعد إكمال هذا التمرين، سيتم تعديل التطبيق ليعمل كما كان من قبل، ولكن سيتم استخدام Cloud Memorystore كخدمة التخزين المؤقت بدلاً من خدمة Memcache في App Engine.

يبدأ هذا البرنامج التعليمي بتطبيق نموذجي للوحدة 12 في Python 2، يليه ترقية اختيارية إضافية بسيطة إلى Python 3. إذا كنت على دراية مسبقة بالوصول إلى الخدمات المجمّعة في App Engine من Python 3 من خلال حزمة تطوير البرامج (SDK) في Python 3 لمنصة App Engine، يمكنك البدء باستخدام إصدار Python 3 من نموذج تطبيق Module 12 بدلاً من ذلك. سيستلزم ذلك إزالة استخدام حزمة SDK لأنّ Memorystore ليست خدمة مجمّعة في App Engine. لا يتناول هذا الدليل التوجيهي كيفية استخدام حزمة تطوير البرامج (SDK) في App Engine بلغة Python 3.

يتضمّن هذا الدليل التعليمي الخطوات الرئيسية التالية:

الإعداد/العمل التحضيري
إعداد خدمات التخزين المؤقت
تعديل ملفات الإعداد
تعديل التطبيق الرئيسي

3- الإعداد/العمل التحضيري

إعداد مشروع على السحابة الإلكترونية

ننصحك بإعادة استخدام المشروع نفسه الذي استخدمته لإكمال الدرس التطبيقي حول الترميز Module 12. يمكنك بدلاً من ذلك إنشاء مشروع جديد تمامًا أو إعادة استخدام مشروع حالي آخر. يتضمّن كل درس تطبيقي حول الترميز في هذه السلسلة قسمًا بعنوان "البداية" (الرمز الأساسي الذي يجب البدء منه) وقسمًا بعنوان "النهاية" (التطبيق الذي تم نقله). يتم توفير رمز FINISH حتى تتمكّن من مقارنة الحلول التي توصلت إليها بالحلول التي توصلنا إليها في حال واجهتك مشاكل. يمكنك دائمًا العودة إلى الحالة السابقة إلى START إذا حدث خطأ. تم تصميم نقاط التحقّق هذه لضمان نجاحك في تعلُّم كيفية إجراء عمليات نقل البيانات.

بغض النظر عن مشروع على السحابة الإلكترونية الذي تستخدمه، تأكَّد من أنّه يتضمّن حساب فوترة نشطًا. تأكَّد أيضًا من تفعيل App Engine. راجِع الآثار العامة للتكلفة الناتجة عن اتّباع هذه البرامج التعليمية وتأكَّد من فهمها. على عكس غيرها من السلاسل، يستخدم هذا الدرس التطبيقي حول الترميز موارد Cloud التي لا تتضمّن طبقة مجانية، لذا سيتم تحمّل بعض التكاليف لإكمال التمرين. سيتم تقديم معلومات أكثر تحديدًا عن التكلفة مع اقتراحات لتقليل الاستخدام، بما في ذلك التعليمات في النهاية بشأن تحرير الموارد لتقليل رسوم الفوترة.

الحصول على نموذج تطبيق أساسي

انطلاقًا من الرمز الأساسي للوحدة 12 الذي سنبدأ منه، سيرشدك هذا الدرس التطبيقي حول الترميز خطوة بخطوة خلال عملية نقل البيانات. عند الانتهاء، سيظهر لك تطبيق "الوحدة 13" يعمل ويشبه إلى حد كبير الرمز البرمجي في أحد مجلدات FINISH. في ما يلي هذه المراجع:

START: Module 12 Python 2 (mod12) or Python 3 (mod12b) app
إنهاء: الوحدة 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.

(إعادة) نشر تطبيق الوحدة التدريبية 12

خطوات العمل التحضيري المتبقية:

التعرّف من جديد على أداة سطر الأوامر gcloud (إذا لزم الأمر)
إعادة نشر رمز الوحدة التدريبية 12 على App Engine (إذا لزم الأمر)

على مستخدمي Python 2 حذف المجلد lib وإعادة تثبيته باستخدام الأوامر التالية:

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

على جميع المستخدمين (مستخدمو Python 2 و3) الآن تحميل الرمز إلى App Engine باستخدام الأمر التالي:

gcloud app deploy

بعد نشر التطبيق بنجاح، تأكَّد من أنّ مظهره ووظائفه مماثلة للتطبيق في الوحدة 12، وهو تطبيق ويب يتتبّع الزيارات ويخزّنها مؤقتًا للمستخدم نفسه لمدة ساعة:

بما أنّ الزيارات الأخيرة يتم تخزينها مؤقتًا، من المفترض أن يتم تحميل عمليات إعادة تحميل الصفحة بسرعة كبيرة.

4. إعداد خدمات التخزين المؤقت

‫Cloud Memorystore ليست خدمة بدون خادم. يجب توفير مثيل، وفي هذه الحالة مثيل Redis قيد التشغيل. على عكس Memcache، فإنّ Memorystore هو منتج مستقل على السحابة الإلكترونية لا يتضمّن فئة مجانية، لذا احرص على الاطّلاع على معلومات أسعار Memorystore for Redis قبل المتابعة. لتقليل تكاليف هذا التمرين، ننصحك باستخدام أقل قدر من الموارد اللازمة للتشغيل: فئة خدمة أساسية وسعة 1 غيغابايت.

يقع مثيل Memorystore على شبكة مختلفة عن تطبيق App Engine (المثيلات)، ولهذا السبب يجب إنشاء موصّل إمكانية الوصول إلى VPC بدون خادم لكي يتمكّن App Engine من الوصول إلى موارد Memorystore. لتقليل تكاليف شبكة VPC، اختَر نوع المثيل (f1-micro) وأقل عدد من المثيلات المطلوب طلبها (ننصحك بطلب مثيلَين كحدّ أدنى و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 في المستندات الرسمية. ننصحك أيضًا بالرجوع إلى دليل التخزين المؤقت للبيانات في صفحة نقل البيانات في Cloud NDB ( Python 2 أو Python 3).

إنشاء مثيل Cloud Memorystore

بما أنّ Cloud Memorystore لا تتضمّن طبقة مجانية، ننصحك بتخصيص أقل قدر من الموارد لإكمال الدرس التطبيقي حول الترميز. يمكنك الحفاظ على الحد الأدنى من التكاليف باستخدام الإعدادات التالية:

اختَر أدنى فئة خدمة: أساسية (الإعداد التلقائي على وحدة التحكّم: "عادية"، الإعداد التلقائي على gcloud: "أساسية").
اختَر أقل مساحة تخزين: 1 غيغابايت (الإعداد التلقائي لوحدة التحكّم: 16 غيغابايت، الإعداد التلقائي لـ gcloud: 1 غيغابايت).
عادةً ما تتطلّب أحدث إصدارات أي برنامج أكبر قدر من الموارد، ولكن لا يُنصح أيضًا باختيار أقدم إصدار. أحدث إصدار ثانٍ حاليًا هو إصدار Redis 5.0 (الإعداد التلقائي في وحدة التحكّم: 6.x)

مع أخذ هذه الإعدادات في الاعتبار، سيرشدك القسم التالي خلال عملية إنشاء المثيل من Cloud Console. إذا كنت تفضّل إجراء ذلك من سطر الأوامر، يمكنك الانتقال إلى القسم التالي.

من Cloud Console

انتقِل إلى صفحة Cloud Memorystore في Cloud Console (قد يُطلب منك تقديم معلومات الفوترة). إذا لم تكن قد فعّلت Memorystore بعد، سيُطلب منك إجراء ذلك:

بعد تفعيلها (وربما مع الفوترة)، ستنتقل إلى لوحة بيانات Memorystore. هذا هو المكان الذي يمكنك فيه الاطّلاع على جميع الآلات الافتراضية التي تم إنشاؤها في مشروعك. لا يتضمّن المشروع الموضّح أدناه أي صفوف، ولهذا السبب تظهر الرسالة "ما مِن صفوف لعرضها". لإنشاء مثيل Memorystore، انقر على إنشاء مثيل في أعلى الصفحة:

تعرض هذه الصفحة نموذجًا يجب ملؤه بالإعدادات المطلوبة لإنشاء مثيل Memorystore:

للحفاظ على انخفاض تكاليف هذا البرنامج التعليمي والتطبيق النموذجي، اتّبِع الاقتراحات التي تم تناولها سابقًا. بعد الانتهاء من تحديد اختياراتك، انقر على إنشاء. تستغرق عملية الإنشاء عدة دقائق. عند الانتهاء، انسخ عنوان IP الخاص بالجهاز الافتراضي ورقم المنفذ لإضافتهما إلى app.yaml.

من سطر الأوامر

على الرغم من أنّ إنشاء مثيلات Memorystore من Cloud Console يقدّم معلومات مرئية، يفضّل البعض استخدام سطر الأوامر. يُرجى التأكّد من gcloud تثبيته و تهيئة قبل المتابعة.

كما هو الحال مع Cloud Console، يجب تفعيل Cloud Memorystore for 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 Console، يتم ضبط gcloud تلقائيًا على الحد الأدنى من الموارد. والنتيجة هي أنّه لم يكن مطلوبًا في هذا الأمر تحديد مستوى الخدمة أو مقدار مساحة التخزين. تستغرق عملية إنشاء مثيل Memorystore عدة دقائق، وعند اكتمالها، دوِّن عنوان IP للمثيل ورقم المنفذ لأنّه سيتم إضافتهما إلى app.yaml قريبًا.

تأكيد إنشاء الجهاز الافتراضي

من Cloud Console أو سطر الأوامر

سواء أنشأت مثيلك من Cloud Console أو سطر الأوامر، يمكنك التأكّد من أنّه متاح وجاهز للاستخدام من خلال هذا الأمر: 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 الافتراضي

إذا كان لديك جهاز Compute Engine افتراضي، يمكنك أيضًا إرسال أوامر مباشرة إلى مثيل Memorystore من جهاز افتراضي للتأكّد من أنّه يعمل. يُرجى العِلم أنّ استخدام جهاز افتراضي قد يتضمّن تكاليف مرتبطة به بشكل مستقل عن الموارد التي تستخدمها حاليًا.

إنشاء موصّل إمكانية الوصول إلى سحابة VPC بدون خادم

كما هو الحال مع Cloud Memorystore، يمكنك إنشاء موصِّل Cloud VPC بدون خادم في Cloud Console أو على سطر الأوامر. وبالمثل، لا تتضمّن Cloud VPC طبقة مجانية، لذا ننصح بتخصيص أقل قدر من الموارد لإكمال الدرس العملي بهدف الحفاظ على التكاليف عند الحد الأدنى، ويمكن تحقيق ذلك باستخدام الإعدادات التالية:

اختَر الحدّ الأقصى الأدنى لعدد المثيلات: 3 (وحدة التحكّم وgcloud القيمة التلقائية: 10)
اختَر نوع الجهاز الأقل تكلفة: f1-micro (الإعداد التلقائي لوحدة التحكّم: e2-micro، بدون إعداد تلقائي gcloud)

سيرشدك القسم التالي خلال عملية إنشاء الموصّل من Cloud Console باستخدام إعدادات Cloud VPC المذكورة أعلاه. إذا كنت تفضّل إجراء ذلك من سطر الأوامر، انتقِل إلى القسم التالي.

من Cloud Console

انتقِل إلى صفحة "الوصول إلى شبكة VPC بدون خادم" في Cloud Networking في Cloud Console (قد يُطلب منك تقديم معلومات الفوترة). إذا لم تكن قد فعّلت واجهة برمجة التطبيقات بعد، سيُطلب منك إجراء ذلك:

بعد تفعيل واجهة برمجة التطبيقات (وربما مع إعداد الفوترة)، ستنتقل إلى لوحة البيانات التي تعرض جميع موصلات شبكة VPC التي تم إنشاؤها. لا يتضمّن المشروع المستخدَم في لقطة الشاشة أدناه أي صفوف، ولهذا السبب تظهر الرسالة "لا توجد صفوف لعرضها". في وحدة التحكّم، انقر على إنشاء أداة ربط في أعلى الصفحة:

أكمِل النموذج باستخدام الإعدادات المطلوبة:

اختَر الإعدادات المناسبة لتطبيقاتك. بالنسبة إلى هذا البرنامج التعليمي والتطبيق النموذجي الذي يتضمّن الحد الأدنى من الاحتياجات، من المنطقي خفض التكاليف إلى أدنى حدّ، لذا اتّبِع الاقتراحات التي تم تناولها سابقًا. بعد تحديد خياراتك، انقر على إنشاء. سيستغرق طلب موصّل شبكة VPC بضع دقائق.

من سطر الأوامر

قبل إنشاء موصِّل VPC، عليك تفعيل واجهة برمجة التطبيقات Serverless VPC Access API أولاً. من المفترض أن تظهر لك نتيجة مشابهة بعد تنفيذ الأمر التالي:

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

بعد تفعيل واجهة برمجة التطبيقات، يتم إنشاء موصّل 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
الحدّ الأدنى لعدد النسخ: 2 (الإعداد التلقائي) والحدّ الأقصى لعدد النسخ: 3
نوع الجهاز الظاهري: 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].

لا يحدّد الأمر أعلاه القيم التلقائية، مثل الحد الأدنى لعدد المثيلات وهو 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

وبالمثل، من المفترض أن تعرض لوحة البيانات الآن أداة الربط التي أنشأتها للتو:

دوِّن رقم تعريف مشروع على السحابة الإلكترونية واسم موصِّل سحابة VPC والمنطقة.

بعد إنشاء موارد Cloud الإضافية اللازمة، سواء من خلال سطر الأوامر أو في وحدة التحكّم، حان الوقت لتعديل إعدادات التطبيق من أجل إتاحة استخدامها.

5- تعديل ملفات الإعداد

تتمثّل الخطوة الأولى في إجراء جميع التعديلات اللازمة على ملفات الإعداد. إنّ الهدف الرئيسي من هذا الدرس التطبيقي حول الترميز هو مساعدة مستخدمي Python 2 في نقل البيانات، ولكن عادةً ما يتم تضمين معلومات حول تكييف البرنامج إلى Python 3 في كل قسم أدناه.

requirements.txt

في هذا القسم، نضيف حِزمًا لتوفير الدعم لكلّ من Cloud Memorystore وCloud NDB. بالنسبة إلى Cloud Memorystore for Redis، يكفي استخدام برنامج Redis العادي للغة Python (redis) لأنّه لا تتوفّر مكتبة برامج Cloud Memorystore بحد ذاتها. أضِف كلاً من redis وgoogle-cloud-ndb إلى requirements.txt، مع إضافة flask من الوحدة 12:

flask
redis
google-cloud-ndb

لا يحتوي ملف requirements.txt هذا على أي أرقام إصدارات، ما يعني أنّه تم اختيار أحدث الإصدارات. في حال حدوث أي حالات عدم توافق، حدِّد أرقام الإصدارات لتثبيت الإصدارات المتوافقة.

app.yaml

أقسام جديدة لإضافتها

يتطلّب وقت تشغيل Python 2 في App Engine حِزمًا معيّنة تابعة لجهات خارجية عند استخدام واجهات Cloud API، مثل Cloud NDB، وتحديدًا grpcio وsetuptools. على مستخدمي Python 2 إدراج المكتبات المضمّنة، مثل هذه المكتبات، مع إصدار متاح في app.yaml. إذا لم يكن لديك قسم libraries بعد، أنشئ قسمًا وأضِف إليه كلتا المكتبتَين كما يلي:

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

عند نقل تطبيق خاص بك، قد يكون لديه قسم libraries. إذا كان الأمر كذلك، ولم يتوفّر أي من grpcio وsetuptools، ما عليك سوى إضافتهما إلى قسم libraries الحالي.

بعد ذلك، يحتاج نموذج تطبيقنا إلى معلومات حول مثيل Cloud Memorystore وموصّل شبكة VPC، لذا أضِف القسمَين الجديدَين التاليَين إلى app.yaml بغض النظر عن وقت تشغيل Python الذي تستخدمه:

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:

*الاختلافات في Python 3

هذا القسم اختياري ولا يُستخدم إلا إذا كنت تنقل البيانات إلى Python 3. لإجراء ذلك، عليك إجراء عدد من التغييرات على إعدادات Python 2. يمكنك تخطّي هذا القسم إذا لم تكن بصدد الترقية في الوقت الحالي.

لا يتم استخدام threadsafe أو api_version لوقت تشغيل Python 3، لذا احذف كلا الإعدادين. لا يتيح أحدث وقت تشغيل في App Engine استخدام مكتبات مدمجة تابعة لجهات خارجية أو نسخ مكتبات غير مدمجة. الشرط الوحيد لحِزم الجهات الخارجية هو إدراجها في requirements.txt. نتيجةً لذلك، يمكن حذف قسم libraries بالكامل من app.yaml.

بعد ذلك، يتطلّب وقت التشغيل في Python 3 استخدام أُطر ويب تقوم بالتوجيه الخاص بها، ولهذا السبب أوضحنا للمطوّرين كيفية الانتقال من webp2 إلى Flask في الوحدة 1. نتيجةً لذلك، يجب تغيير جميع معالِجات النصوص البرمجية إلى auto. بما أنّ هذا التطبيق لا يعرض أي ملفات ثابتة، من "غير المجدي" إدراج معالجات (لأنّها كلها auto)، لذا يمكن أيضًا إزالة القسم handlers بأكمله. نتيجةً لذلك، يجب اختصار app.yaml الجديدة والمعدَّلة لتتوافق مع Python 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 من Python:

حذف إعدادات 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:

*الاختلافات في Python 3

هذا القسم اختياري ولا يُستخدم إلا إذا كنت تنقل البيانات إلى Python 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 قراءة متغيّرات البيئة، ما يعني أنّنا نحتاج إلى وحدة Python os بالإضافة إلى redis، وهو برنامج Redis للعملاء في Python. بما أنّ Redis لا يمكنه تخزين عناصر Python مؤقتًا، يجب ترتيب قائمة آخر الزيارات باستخدام pickle، لذا يجب استيرادها أيضًا. إحدى مزايا Memcache هي أنّ تسلسل العناصر يتم تلقائيًا، بينما تتطلّب Memorystore بعض الجهد. أخيرًا، يمكنك الترقية من App Engine ndb إلى Cloud NDB من خلال استبدال google.appengine.ext.ndb بـ google.cloud.ndb. بعد إجراء هذه التغييرات، من المفترض أن تظهر عمليات الاستيراد على النحو التالي:

بعد:

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

بدء التحديث

يتكوّن إعداد الوحدة 12 من إنشاء مثيل لكائن تطبيق Flask app وتحديد ثابت لقيمة التخزين المؤقت لمدة ساعة:

قبل:

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)

*نقل البيانات إلى Python 3

هذا القسم اختياري، وينطبق إذا كنت تستخدم إصدار Python 3 من تطبيق الوحدة 12. وفي هذه الحالة، يجب إجراء عدة تغييرات مطلوبة متعلقة بعمليات الاستيراد والتهيئة.

أولاً، بما أنّ Memcache هي خدمة مجمّعة في App Engine، يتطلّب استخدامها في تطبيق Python 3 حزمة تطوير البرامج (SDK) الخاصة بـ App Engine، وتحديدًا تضمين تطبيق 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 ليكون متوافقًا مع ndb في App Engine، ما يعني أنّ تعريف عناصر 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. كل ما علينا فعله هو استبدال مكتبات البرامج المعنية، أليس كذلك؟ اقتربت من الجواب الصحيح. كما ذكرنا سابقًا، لا يمكننا تخزين قائمة Python مؤقتًا باستخدام 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 وتكييفه مع Python 3؟

تعديل ملف نموذج HTML ونقله إلى Python 3

مفاجأة! ليس عليك اتّخاذ أي إجراء هنا لأنّ التطبيق مصمّم للعمل على الإصدارين 2 و3 من Python بدون أي تغييرات في الرمز أو مكتبات توافق. ستظهر لك 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 يوفّران التخزين المؤقت التلقائي في Memcache أو Memorystore، على التوالي، لكل من Python 2 أو 3. يمكنك الاطّلاع على معلومات حول التخزين المؤقت في ndb من خلال التخزين المؤقت في NDB والتخزين المؤقت في Cloud NDB من خلال تفعيل التخزين المؤقت للبيانات، علمًا بأنّ تعليمات الأخير تشبه إلى حد كبير التعليمات الواردة في هذا الدرس التطبيقي حول الترميز. يمكنك العثور على ميزات إضافية في خيارات السياق والمعاملات.

والسبب في عدم استخدام التخزين المؤقت التلقائي هذا هو أنّ نموذج تطبيقنا لا يطلب البحث عن عناصر Datastore الفردية (التي يمكن الوصول إليها بسهولة من خلال ذاكرة التخزين المؤقت). بدلاً من ذلك، يخزّن هذا التطبيق مؤقتًا مصفوفة من الكيانات (آخر الزيارات)، وهي حالة استخدام محدّدة جدًا ولا تتوافق مع طبقة التخزين المؤقت المبرمَجة. ومع ذلك، قد ينفّذ تطبيقك عمليات بحث من هذا النوع ويمكنه الاستفادة من هذه الميزة، ما يسهّل عليك استخدامه بشكل عام.

7. الملخّص/التنظيف

يختتم هذا القسم الدرس التطبيقي حول الترميز من خلال تفعيل التطبيق والتأكّد من عمله على النحو المطلوب وفي أي ناتج معروض. بعد التحقّق من التطبيق، نفِّذ أي عملية تنظيف وفكِّر في الخطوات التالية.

نشر التطبيق والتحقّق منه

آخر خطوة هي دائمًا نشر نموذج التطبيق. على مطوّري Python 2 حذف lib وإعادة تثبيته باستخدام الأوامر أدناه. (إذا كان لديك الإصداران 2 و3 من Python مثبّتَين على نظامك، قد تحتاج إلى تشغيل pip2 بشكلٍ صريح بدلاً من ذلك).

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

على مطوّري Python 2 و3 الآن نشر تطبيقاتهم باستخدام:

gcloud app deploy

بما أنّك أعدت ربط العناصر في الخلفية بخدمة تخزين مؤقت مختلفة تمامًا، من المفترض أن يعمل التطبيق نفسه بشكل مطابق لتطبيق الوحدة 12:

Module 7 visitme app

تُكمل هذه الخطوة الدرس العملي. ندعوك إلى مقارنة نموذج تطبيقك المعدَّل بأي من المجلّدَين في الوحدة 13، mod13a (Python 2) أو mod13b (Python 3).

تَنظيم

للجمهور العام

إذا انتهيت من استخدام التطبيق في الوقت الحالي، ننصحك بإيقاف تطبيق App Engine لتجنُّب تحمّل رسوم. ومع ذلك، إذا أردت إجراء المزيد من الاختبارات أو التجارب، تتضمّن منصة App Engine حصّة مجانية، وبالتالي لن يتم تحصيل رسوم منك طالما أنّك لا تتجاوز مستوى الاستخدام هذا. هذا السعر خاص بالحوسبة، ولكن قد تكون هناك رسوم أيضًا مقابل خدمات App Engine ذات الصلة، لذا يُرجى الاطّلاع على صفحة الأسعار للحصول على مزيد من المعلومات. إذا كان نقل البيانات هذا يتضمّن خدمات سحابية أخرى، يتم إصدار فواتير لها بشكل منفصل. في كلتا الحالتين، إذا كان ذلك منطبقًا، راجِع القسم "خاص بهذا الدرس التطبيقي حول الترميز" أدناه.

للتوضيح، يؤدي النشر على منصة حوسبة بدون خادم في 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 VPC.
يتضمّن Cloud Datastore (Cloud Firestore في وضع Datastore) فئة مجانية، يمكنك الاطّلاع على صفحة الأسعار للحصول على مزيد من المعلومات.

تضمّن هذا الدليل التعليمي استخدام أربعة منتجات من Cloud:

App Engine
Cloud Datastore
Cloud Memorystore
Cloud VPC

في ما يلي توجيهات لإيقاف هذه الموارد وتجنُّب رسوم الفوترة أو تقليلها.

إيقاف مثيل Memorystore وموصّل شبكة VPC

هذه هي المنتجات التي لا تتضمّن فئة مجانية، لذا يتم تحصيل رسوم منك في الوقت الحالي. إذا لم توقف مشروعك على السحابة الإلكترونية (راجِع القسم التالي)، عليك حذف كلّ من مثيل Memorystore وموصّل شبكة VPC لإيقاف الفوترة. كما هو الحال عند إنشاء هذه الموارد، يمكنك أيضًا إيقافها إما من Cloud Console أو من سطر الأوامر.

من Cloud Console

لحذف مثيل Memorystore، ارجع إلى لوحة بيانات Memorystore وانقر على معرّف المثيل:

بعد الوصول إلى صفحة تفاصيل هذا الجهاز الافتراضي، انقر على "حذف" وأكِّد ذلك:

لحذف أداة ربط شبكة 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].

يستغرق تنفيذ كل طلب بضع دقائق. هذه الخطوات اختيارية إذا اخترت إيقاف مشروع على السحابة الإلكترونية بالكامل كما هو موضّح سابقًا، ولكن ستظلّ تتكبّد رسوم الفوترة إلى أن تكتمل عملية الإيقاف.

الخطوات التالية

بالإضافة إلى هذا البرنامج التعليمي، تتضمّن وحدات نقل البيانات الأخرى التي تركّز على التوقّف عن استخدام الخدمات المجمّعة القديمة ما يلي:

الوحدة 2: نقل البيانات من App Engine ndb إلى Cloud NDB
الوحدات من 7 إلى 9: نقل المهام من مهام الدفع في "قائمة انتظار المهام" في App Engine إلى Cloud Tasks
الوحدتان 12 و13: نقل البيانات من App Engine Memcache إلى Cloud Memorystore
الوحدتان 15 و16: نقل البيانات من App Engine Blobstore إلى Cloud Storage
الوحدتان 18 و19: نقل البيانات من "قائمة انتظار المهام" في App Engine (مهام السحب) إلى 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

إنّ الانتقال إلى منصة أخرى بلا خادم هو أمر اختياري، وننصحك بمراجعة أفضل الخيارات لتطبيقاتك وحالات الاستخدام قبل إجراء أي تغييرات.

بغض النظر عن وحدة النقل التي ستختارها، يمكنك الوصول إلى كل محتوى Serverless Migration Station (الدروس البرمجية والفيديوهات ورمز المصدر [عند توفّره]) من خلال مستودع المصدر المفتوح. يوفّر مستودع README أيضًا إرشادات حول عمليات نقل البيانات التي يجب أخذها في الاعتبار وأي "ترتيب" ذي صلة لوحدات نقل البيانات.

8. مراجع إضافية

في ما يلي مراجع إضافية للمطوّرين الذين يريدون استكشاف هذه الوحدة أو وحدة نقل البيانات ذات الصلة بالإضافة إلى المنتجات ذات الصلة. ويشمل ذلك أماكن لتقديم ملاحظات حول هذا المحتوى، وروابط إلى الرمز، ومختلف أجزاء المستندات التي قد تجدها مفيدة.

مشاكل/ملاحظات بشأن الدروس التطبيقية حول الترميز

إذا واجهت أي مشاكل في هذا الدرس العملي، يُرجى البحث عن مشكلتك أولاً قبل إرسالها. روابط للبحث عن مشاكل جديدة وإنشائها:

مراجع لنقل البيانات

يمكنك العثور على روابط لمجلدات المستودع لكل من الوحدة التدريبية 12 (البدء) والوحدة التدريبية 13 (الإنهاء) في الجدول أدناه. يمكن أيضًا الوصول إليها من مستودع جميع عمليات نقل Codelab في App Engine الذي يمكنك استنساخه أو تنزيل ملف ZIP منه.

Codelab	Python 2	Python 3
الوحدة 12	code	code
الوحدة 13 (هذا الدرس التطبيقي حول الترميز)	code	code

المراجع على الإنترنت

في ما يلي مراجع على الإنترنت قد تكون ذات صلة بهذا البرنامج التعليمي:

App Engine

‫App Engine NDB وCloud NDB

‫App Engine Memcache وCloud Memorystore

Cloud VPC

معلومات أخرى حول السحابة الإلكترونية

Python على Google Cloud Platform
مكتبات برامج Python في Google Cloud
فئة "دائمًا مجانية" في Google Cloud
Google Cloud SDK (أداة سطر الأوامر gcloud)
جميع مستندات Google Cloud

الترخيص

يخضع هذا العمل لترخيص المشاع الإبداعي مع نسب العمل إلى مؤلفه 2.0 Generic License.