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

1. نظرة عامة

تهدف سلسلة الدروس التطبيقية حول الترميز بدون خادم (البرامج التعليمية العملية) والفيديوهات ذات الصلة إلى مساعدة مطوّري 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. تحقق منها للحصول على المزيد من المعلومات خطوة بخطوة.

ألا تستخدم 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 مع حساب فوترة نشط (هذا ليس درسًا تطبيقيًا مجانيًا عن الترميز)
• المهارات الأساسية في لغة بايثون
• المعرفة العملية بأوامر نظام التشغيل Linux الشائعة
• معرفة أساسية حول تطوير ونشر تطبيقات App Engine
• يجب أن يكون لديك تطبيق App Engine صالح للوحدة 12 (أكمل الدرس التطبيقي حول الترميز للوحدة 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 تتطلب خادمًا قيد التشغيل، يجب أيضًا استخدام Cloud VPC. على وجه التحديد، يجب إنشاء موصِّل إمكانية الوصول إلى VPC بدون خادم حتى يتمكّن تطبيق App Engine من الاتصال بمثيل Memorystore من خلال عنوان IP الخاص الخاص به. عند الانتهاء من هذا التمرين، ستكون قد حدّثت التطبيق حتى يعمل كما كان من قبل، وستكون Cloud Memorystore خدمة التخزين المؤقت، بدلاً من خدمة Memcache في App Engine.

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

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

1. الإعداد/العمل المسبق
2. إعداد خدمات التخزين المؤقت
3. تحديث ملفات الإعداد
4. تحديث التطبيق الرئيسي

3- الإعداد/العمل المسبق

إعداد مشروع على Google Cloud

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

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

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

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

• START: الوحدة 12 Python 2 (mod12) أو تطبيق Python 3 (mod12b)
• FINISH: Module 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 إذا أكملت الدرس التطبيقي حول الترميز Module 12.

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

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

1. التعرف على أداة سطر أوامر gcloud (إذا لزم الأمر)
2. (إعادة) نشر رمز الوحدة 12 على App Engine (إذا لزم الأمر)

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

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

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

gcloud app deploy                

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

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

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

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

يقع مثيل Memorystore على شبكة مختلفة عن تطبيق App Engine (المثيلات)، ولهذا السبب يجب إنشاء موصل الوصول إلى VPC بدون خادم حتى يتمكن App Engine من الوصول إلى موارد Memorystore. لتقليل تكاليف سحابة VPC، اختَر نوع المثيل (f1-micro) وأقل عدد من المثيلات المطلوبة (نقترح الحد الأدنى مرتين والحد الأقصى 3). يمكنك أيضًا الاطّلاع على صفحة معلومات تسعير VC.

التكلفة: هذا الدليل التوجيهي ليس مجانيًا

على الرغم من أنّه يمكن إكمال معظم الدروس التطبيقية حول ترميز نقل البيانات في هذه السلسلة بدون أي تكلفة، فإنّ هذا الدرس يعد استثناءً. لا يتوفّر في 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).

إنشاء جميع الموارد في منطقة App Engine

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

إنشاء مثيل في 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، انقر على إنشاء مثيل في أعلى الصفحة:

تحديثات Cloud Console

يُرجى العلم بأنّ واجهة مستخدم Cloud Console تتغير من حين لآخر، لذلك قد لا تبدو تمامًا مثل لقطات الشاشة الواردة هنا.

تعرض هذه الصفحة نموذجًا لإكماله بالإعدادات المطلوبة لإنشاء النسخة الافتراضية من 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

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

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

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

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

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

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

$ 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

اختَر اسمًا للموصل بالإضافة إلى مجموعة CIDR غير المستخدَمة (CIDR) /28. يضع هذا البرنامج التعليمي الافتراضات التالية:

• رقم تعريف المشروع: my-project
• اسم موصل VC: demo-vpc
• الحدّ الأدنى للمثيلات: 2 (الإعداد التلقائي) والحدّ الأقصى للمثيلات: 3
• نوع المثيل: f1-micro
• المنطقة: us-central1
• حظر CIDR للإصدار 4 من بروتوكول الإنترنت: 10.8.0.0/28 (كما هو موصى به في Cloud Console)

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

$ 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

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

سجِّل رقم تعريف المشروع على Google Cloud واسم موصل VPC والمنطقة.

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

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

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

requirements.txt

في هذا القسم، نضيف حزمًا لدعم Cloud Memorystore وكذلك Cloud NDB. بالنسبة إلى Cloud Memorystore في 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 APIs، مثل 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 في الوحدة الأولى. نتيجةً لذلك، يجب تغيير جميع معالِجات النص البرمجي إلى 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 عند النقل إلى Python 3:

• حذف إعدادات threadsafe وapi_version
• حذف القسم "libraries"
• حذف قسم "handlers" (أو معالِجات script فقط إذا كان تطبيقك يعرض ملفات ثابتة)

استبدال القيم

القيم المتوفّرة في الأقسام الجديدة لمتجر الذاكرة وموصل شبكة 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، عميل Python Redis. بما أنّ 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 من عميل، لذا يمكن إنشاء مثيل لعميل 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 لتطبيق Module 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

يجب إيقاف استخدام حزمة تطوير البرامج (SDK)، بما أنّنا ننقل البيانات إلى Cloud Memorystore (وهي ليست خدمة App Engine المجمَّعة مثل Memcache)، الأمر بسيط، حيث ستحذف ببساطة السطر بالكامل الذي يستورد كلاً من 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، يتم زيادة كل طلبات تخزين البيانات في 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() إلى كلتا الدالتين، وضع طلبات تخزين البيانات بالداخل (مع مسافة بادئة). وفي هذه الحالة، لا يلزم إجراء أي تغييرات على المكالمات نفسها:

بعد:

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" و"تعيين" على غرار Memcache. كل ما نفعله هو تبديل مكتبات العملاء المعنية، أليس كذلك؟ اقتربت من الجواب الصحيح. كما ذكرنا سابقًا، لا يمكننا إجراء تخزين مؤقت لقائمة Python باستخدام Redis (لأنّها يجب أن تكون تسلسلية أولاً، وهو أمر يعتني به Memcache تلقائيًا)، لذلك في استدعاء set()، "pickle" الزيارات في سلسلة تحتوي على 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 بدون أي تغييرات في الرموز أو مكتبات التوافق. ستجد 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.

يوفّر كل من NDB وCloud NDB في App Engine ذاكرة تخزين مؤقت مبرمَجة

بينما نعمل على النقل بشكل صريح من App Engine Memcache إلى Cloud Memorystore، يُرجى ملاحظة أنّ كلاً من App Engine ndb وCloud NDB يوفّران إمكانية التخزين المؤقت التلقائي للتخزين المؤقت في Memcache أو Memorystore على التوالي، إما للإصدارين 2 أو 3 من Python. يمكنك الاطّلاع على معلومات عن التخزين المؤقت في ndb ضمن التخزين المؤقت لـ NDB والتخزين المؤقت في Cloud NDB ضمن مقالة تفعيل التخزين المؤقت للبيانات، حيث تعكس تعليماته هذه التعليمات بشكل وثيق في هذا الدرس التطبيقي حول الترميز. يمكن العثور على ميزات إضافية في خيارات السياق والمعاملات.

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

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

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

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

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

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

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

gcloud app deploy

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

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

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

• App Engine
• Cloud Datastore
• Cloud Memorystore
• شبكة 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].

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

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

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

• الوحدة 2: النقل من App Engine ndb إلى Cloud NDB
• الوحدات 7-9: نقل المهام من قائمة انتظار مهام App Engine إلى "مهام السحابة الإلكترونية"
• الوحدات 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 صغير أو تطبيق ذو وظائف محدودة وتريد تحويله إلى خدمة مصغّرة مستقلة، أو إذا كنت تريد تقسيم تطبيق متجانس إلى عدة مكوّنات قابلة لإعادة الاستخدام، هذه هي الأسباب الوجيهة للانتقال إلى وظائف السحابة الإلكترونية. إذا أصبحت عملية التطوير جزءًا من سير عمل تطوير التطبيقات، خاصةً إذا كانت تتألف من مسار CI/CD (التكامل المستمر أو العرض أو النشر المستمر)، ننصحك بنقل البيانات إلى تشغيل السحابة الإلكترونية. تغطي الوحدات التالية هذه السيناريوهات:

• نقل البيانات من App Engine إلى Cloud Functions: راجِع الوحدة 11.
• نقل البيانات من App Engine إلى Cloud Run: راجِع الوحدة 4 لتضمين تطبيقك مع Docker، أو الوحدة 5 لتنفيذ ذلك بدون حاويات أو معلومات Docker أو Dockerfiles.

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

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

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

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

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

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

• البحث عن المشاكل
• إرسال مشكلة/ملاحظات جديدة

موارد نقل البيانات

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

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

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

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

App Engine

• مستندات App Engine
• وقت تشغيل Python 2 App Engine (بيئة عادية)
• استخدام المكتبات المضمَّنة في App Engine على Python 2 App Engine
• وقت تشغيل Python 3 App Engine (بيئة عادية)
• الاختلافات بين Python 2 3 بيئات تشغيل App Engine (بيئة عادية)
• دليل نقل البيانات من الإصدار 2 إلى 3 من App Engine (البيئة العادية)
• معلومات حول الأسعار والحصص في App Engine

NDB وCloud NDB في App Engine

• نظرة عامة على NDB في App Engine
• استخدام NDB Datastore في App Engine
• مستندات NDB في Google Cloud
• مستودع NDB في Google Cloud
• معلومات أسعار تخزين البيانات في السحابة الإلكترونية

App Engine Memcache وCloud Memorystore

• نظرة عامة على App Engine Memcache
• مرجع memcache لـ Python 2 App Engine
• مرجع memcache لـ Python 3 App Engine
• دليل نقل البيانات من App Engine memcache إلى Cloud Memorystore
• مستندات Cloud Memorystore
• مستندات "مخزن الذاكرة في السحابة الإلكترونية" لـ Redis
• Cloud Memorystore لمعلومات أسعار Redis
• إصدارات Redis المتوافقة مع Cloud Memorystore
• الصفحة الرئيسية في Cloud Memorystore
• إنشاء مثيل Memorystore جديد في Cloud Console
• الصفحة الرئيسية لعميل Python Redis
• مستندات مكتبة برامج Python Redis

شبكة VPC في السحابة الإلكترونية

• مستندات Google Cloud VPC
• الصفحة الرئيسية لشبكة VPC في Google Cloud
• معلومات أسعار Cloud VPC
• إنشاء موصِّل جديد للوصول إلى VPC بدون خادم في Cloud Console

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

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

الترخيص

هذا العمل مرخّص بموجب رخصة المشاع الإبداعي 2.0 مع نسب العمل إلى مؤلف عام.