الوحدة 3: النقل من NDB في Google Cloud إلى Cloud Datastore

1. نظرة عامة

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

يوضّح هذا البرنامج التعليمي الاختياري للمطوّرين كيفية نقل البيانات من Cloud NDB إلى Cloud Datastore باعتبارها مكتبة برامج العميل للتواصل مع خدمة Datastore. يمكن للمطوّرين الذين يفضّلون NDB الاستمرار في استخدامه لأنّه متوافق مع Python 3، ولهذا السبب يكون نقل البيانات اختياريًا. لا يتوفّر خيار النقل هذا إلا للمطوّرين الذين يريدون إنشاء قاعدة رموز متسقة ومكتبات مشترَكة مع تطبيقات أخرى تستخدم Cloud Datastore حاليًا. يمكن الاطّلاع على المزيد من التفاصيل في القسم "الخلفية".

ستتعرّف على كيفية

• استخدام Cloud NDB (في حال عدم معرفتك بها)
• نقل البيانات من Cloud NDB إلى Cloud Datastore
• نقل تطبيقك إلى Python 3

المتطلبات

• مشروع Google Cloud Platform يتضمّن حساب فوترة نشطًا على Google Cloud Platform
• مهارات أساسية في لغة Python
• معرفة عملية بأوامر Linux الأساسية
• معرفة أساسية بتطوير تطبيقات App Engine ونشرها
• تطبيق يعمل على الإصدار 2.x أو 3.x من "الوحدة 2" في App Engine

استطلاع الرأي

كيف ستستخدم هذا الدرس التطبيقي حول الترميز؟

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

2. الخلفية

مع أنّ Cloud NDB هو حلّ رائع لخدمة Datastore بالنسبة إلى مطوّري App Engine منذ فترة طويلة ويساعد في الانتقال إلى Python 3، إلا أنّه ليس الطريقة الوحيدة التي يمكن لمطوّري App Engine من خلالها الوصول إلى Datastore. عندما أصبح Datastore في App Engine منتجًا مستقلاً في عام 2013، تم إنشاء Cloud Datastore من Google، وهي مكتبة برامج للعملاء جديدة تتيح لجميع المستخدمين استخدام Datastore.

يتم توجيه مطوّري Python 3 App Engine وغير App Engine إلى استخدام Cloud Datastore (وليس Cloud NDB). ننصح مطوّري تطبيقات Python 2 في App Engine بنقل البيانات من ndb إلى Cloud NDB ثم نقلها إلى Python 3، ولكن يمكنهم أيضًا اختيار نقلها إلى Cloud Datastore. هذا قرار منطقي، لا سيما بالنسبة إلى المطوّرين الذين لديهم رموز برمجية تستخدم Cloud Datastore، مثل الرموز المذكورة أعلاه، ويريدون إنشاء مكتبات مشترَكة في جميع تطبيقاتهم. إنّ إعادة استخدام الرموز البرمجية من أفضل الممارسات، وكذلك اتّساق الرموز البرمجية، وكلاهما يساهم في خفض تكلفة الصيانة الإجمالية، كما هو موضّح هنا:

نقل البيانات من Cloud NDB إلى Cloud Datastore

• تسمح للمطوّرين بالتركيز على قاعدة رموز برمجية واحدة للوصول إلى Datastore
• تجنُّب الاحتفاظ ببعض الرموز باستخدام Cloud NDB والبعض الآخر باستخدام Cloud Datastore
• توفير اتساق أكبر في قاعدة الرموز البرمجية وإمكانية أفضل لإعادة استخدام الرموز
• يتيح استخدام المكتبات الشائعة/المشترَكة، ما يساهم في خفض تكلفة الصيانة الإجمالية

ملاحظة: تم تصميم Cloud NDB لربط كلّ من أوقات تشغيل الجيل الأصلي والجيل التالي من App Engine، بالإضافة إلى مساعدة مستخدمي Python 2 على الانتقال إلى Python 3. إذا كنت لا تستخدم Cloud Datastore، و/أو لا تنوي استخدامه، و/أو ليس لديك تطبيقات أخرى تستخدمه، يمكنك تخطّي هذا البرنامج التعليمي والاستمرار في استخدام Cloud NDB.

تتضمّن عملية النقل هذه الخطوات الأساسية التالية:

1. الإعداد/العمل التحضيري
2. استبدال Cloud NDB بمكتبات برامج Cloud Datastore
3. تعديل التطبيق

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

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

1. إعداد المشروع

إذا أكملت الدرس التطبيقي حول الترميز Module 2، ننصحك بإعادة استخدام المشروع (والرمز) نفسه. يمكنك بدلاً من ذلك إنشاء مشروع جديد تمامًا أو إعادة استخدام مشروع حالي آخر. تأكَّد من أنّ المشروع يتضمّن حساب فوترة نشطًا وأنّ خدمة App Engine (التطبيق) مفعَّلة.

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

أحد المتطلبات الأساسية هو توفُّر نموذج تطبيق عملي من الوحدة التدريبية 2. استخدِم الحلّ الذي توصلت إليه إذا أكملت هذا البرنامج التعليمي. يمكنك إكمالها الآن (الرابط أعلاه)، أو إذا كنت تريد تخطّيها، يمكنك نسخ مستودع الوحدة التدريبية 2 (الرابط أدناه).

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

Python 2

• البداية: رمز الوحدة 2
• إنهاء: رمز الوحدة 3
• المستودع بأكمله (لنسخه أو تنزيل ملف ZIP)

يجب أن يبدو دليل ملفات STARTing الخاصة بالوحدة 2 من Python 2 (الخاصة بك أو الخاصة بنا) على النحو التالي:

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

إذا أكملت البرنامج التعليمي الخاص بالوحدة 2، سيكون لديك أيضًا مجلد lib يحتوي على Flask والملفات التابعة له. إذا لم يكن لديك مجلد lib، أنشئه باستخدام الأمر pip install -t lib -r requirements.txt لنتمكّن من نشر هذا التطبيق الأساسي في الخطوة التالية. إذا كان لديك الإصداران 2 و3 من Python مثبّتَين، ننصحك باستخدام pip2 بدلاً من pip لتجنُّب الخلط بينهما.

Python 3

• البدء: مستودع الوحدة 2
• إنهاء: مستودع الوحدة التدريبية 3
• المستودع بأكمله (لنسخه أو تنزيل ملف ZIP)

يجب أن يبدو دليل ملفات STARTing الخاص بالوحدة 2 من Python 3 (ملفاتك أو ملفاتنا) على النحو التالي:

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

لا يتم استخدام lib أو appengine_config.py في Python 3.

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

في ما يلي الخطوات المتبقية التي يجب تنفيذها الآن:

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

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

4. استبدال Cloud NDB بمكتبات برامج Cloud Datastore

التغيير الوحيد في الإعداد هو تبديل حزمة بسيط في ملف requirements.txt.

1. تعديل "requirements.txt"

بعد إكمال الوحدة التدريبية 2، كان ملف requirements.txt يبدو على النحو التالي:

• قبل (Python 2 و3):

Flask==1.1.2
google-cloud-ndb==1.7.1

عدِّل requirements.txt من خلال استبدال مكتبة Cloud NDB (google-cloud-ndb) بأحدث إصدار من مكتبة Cloud Datastore (google-cloud-datastore)، مع ترك الإدخال الخاص بـ Flask كما هو، مع الأخذ في الاعتبار أنّ الإصدار النهائي من Cloud Datastore المتوافق مع Python 2 هو 1.15.3:

• بعد (Python 2):

Flask==1.1.2
google-cloud-datastore==1.15.3

• بعد (Python 3):

Flask==1.1.2
google-cloud-datastore==2.1.0

يُرجى العِلم أنّه يتم تعديل المستودع بشكل أكثر انتظامًا من هذا البرنامج التعليمي، لذا من المحتمل أن يعرض ملف requirements.txt إصدارات أحدث. ننصحك باستخدام أحدث إصدارات كل مكتبة، ولكن إذا لم تعمل، يمكنك الرجوع إلى إصدار أقدم. أرقام الإصدارات المذكورة أعلاه هي الأحدث عند آخر تعديل تم إجراؤه على هذا الدرس البرمجي.

ملاحظة لمستخدمي Python 2: احذف المجلد lib إذا كان لديك مجلد ولم تنشئه للتو كما هو موضّح أعلاه. الآن، (أعِد) تثبيت المكتبات المعدَّلة باستخدام الأمر pip install -t lib -r requirements.txt، واستخدِم pip2 بدلاً من pip حسب الحاجة.

تحديد المشاكل وحلّها في Python 2: إذا ظهر لك الخطأ ImportError: cannot import name collections_abc في تطبيقك، تأكَّد من أنّ إصدار الاعتمادية Cloud NDB، google-cloud-core، هو 1.4.4 على الأقل في lib. لا تظهر المشكلة الأساسية التي تتسبّب في هذا الخطأ إلا في الإصدارَين 1.4.2 و1.4.3. (لقد مرّ وقت طويل منذ إصدار هذه الميزات، لذا ستتم إزالة هذا التحذير في الإصدارات المستقبلية من هذا البرنامج التعليمي).

2. ملفات الإعداد الأخرى

يجب أن تظل ملفات الإعداد الأخرى، app.yaml وappengine_config.py، بدون تغيير من خطوة النقل السابقة:

• يجب أن يشير app.yaml (كما في السابق) إلى حِزمتَي grpcio وsetuptools المجمّعتَين التابعتَين لجهة خارجية.
• يجب أن يشير appengine_config.py (أيضًا) إلى pkg_resources وgoogle.appengine.ext.vendor في موارد الجهات الخارجية في lib.

لننتقل الآن إلى ملفات التطبيق.

5- تعديل ملفات التطبيق

لم نجرِ أي تغييرات على template/index.html، ولكن أجرينا بعض التعديلات على main.py.

1. عمليات الاستيراد

يجب أن يبدو رمز البداية لقسم الاستيراد على النحو التالي:

• قبل:

from flask import Flask, render_template, request
from google.cloud import ndb

استبدِل عملية الاستيراد google.cloud.ndb بعملية استيراد خاصة بـ Cloud Datastore: google.cloud.datastore. بما أنّ مكتبة برامج Datastore لا تتيح إنشاء حقل طابع زمني تلقائيًا في كيان، عليك أيضًا استيراد وحدة datetime من المكتبة العادية لإنشاء حقل يدويًا. حسب الاتفاقية، يتم وضع عمليات استيراد المكتبة العادية فوق عمليات استيراد حِزم الجهات الخارجية. بعد الانتهاء من هذه التغييرات، من المفترض أن تبدو على النحو التالي:

• AFTER:

from datetime import datetime
from flask import Flask, render_template, request
from google.cloud import datastore

2. التهيئة ونموذج البيانات

بعد تهيئة Flask، يبدو تطبيق الوحدة التدريبية 2 النموذجي الذي ينشئ فئة نموذج بيانات NDB وحقولها على النحو التالي:

• قبل:

app = Flask(__name__)
ds_client = ndb.Client()

class Visit(ndb.Model):
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

لا تتضمّن مكتبة Cloud Datastore مثل هذه الفئة، لذا احذف تعريف الفئة Visit. ستظل بحاجة إلى عميل للتواصل مع Datastore، لذا غيِّر ndb.Client() إلى datastore.Client(). تتسم مكتبة Datastore بأنّها أكثر "مرونة"، ما يتيح لك إنشاء عناصر بدون "تحديد" بنيتها مسبقًا مثل NDB. بعد هذا التعديل، من المفترض أن يبدو هذا الجزء من main.py على النحو التالي:

• AFTER:

app = Flask(__name__)
ds_client = datastore.Client()

3- الوصول إلى Datastore

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

• قبل:

def store_visit(remote_addr, user_agent):
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    with ds_client.context():
        return (v.to_dict() for v in Visit.query().order(
                -Visit.timestamp).fetch_page(limit)[0])

باستخدام Cloud Datastore، يمكنك إنشاء عنصر عام وتحديد الكائنات المجمّعة في العنصر باستخدام "مفتاح". أنشئ سجلّ البيانات باستخدام عنصر JSON (dict في Python) يتضمّن أزواجًا من المفاتيح والقيم، ثم اكتبه في Datastore باستخدام put() المتوقّع. تكون عملية طلب البحث مشابهة ولكنها أكثر وضوحًا مع Datastore. في ما يلي كيفية اختلاف رمز Datastore المكافئ:

• AFTER:

def store_visit(remote_addr, user_agent):
    entity = datastore.Entity(key=ds_client.key('Visit'))
    entity.update({
        'timestamp': datetime.now(),
        'visitor': '{}: {}'.format(remote_addr, user_agent),
    })
    ds_client.put(entity)

def fetch_visits(limit):
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    return query.fetch(limit=limit)

عدِّل نص الدالتَين store_visit() وfetch_visits() كما هو موضّح أعلاه، مع الحفاظ على توافق توقيعهما مع الإصدار السابق. لم يتم إجراء أي تغييرات على المعالج الرئيسي root(). بعد إكمال هذه التغييرات، يكون تطبيقك الآن مجهّزًا لاستخدام Cloud Datastore وجاهزًا للاختبار.

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

نشر التطبيق

أعِد نشر تطبيقك باستخدام gcloud app deploy، وتأكَّد من أنّه يعمل. من المفترض أن يتطابق الرمز البرمجي الآن مع الرمز البرمجي في مجلدات مستودع الوحدة التدريبية 3:

• Python 2
• Python 3

إذا انتقلت إلى هذه السلسلة بدون إجراء أي من الدروس العملية السابقة، لن يتغيّر التطبيق نفسه، بل سيسجّل جميع الزيارات إلى صفحة الويب الرئيسية (/) وسيظهر على النحو التالي بعد زيارة الموقع الإلكتروني عدة مرات:

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

اختياري: التنظيف

ماذا عن التنظيف لتجنُّب تحصيل الرسوم منك إلى أن تصبح مستعدًا للانتقال إلى الدرس العملي التالي حول نقل البيانات؟ بصفتك مطوّرًا حاليًا، من المحتمل أنّك على دراية بمعلومات الأسعار في App Engine.

ملاحظة مهمة: لم تكن أوقات تشغيل App Engine الأصلية تتطلّب حساب فوترة نشطًا، ولكن لم يعُد هذا هو الحال (بدءًا من تشرين الثاني (نوفمبر) 2019، وتم فرض ذلك بدءًا من نيسان (أبريل) 2020). ومع ذلك، يمكنك الاطمئنان إلى أنّ App Engine لا يزال يتضمّن مستوى وصول مجانيًا لن يتم تحصيل أي رسوم منك إلا في حال تجاوز هذه الحدود.

اختياري: إيقاف التطبيق

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

من ناحية أخرى، إذا كنت لن تواصل عمليات النقل وأردت حذف كل شيء تمامًا، يمكنك إيقاف مشروعك.

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

يمكنك من هنا استكشاف وحدات نقل البيانات التالية:

• مكافأة الوحدة التدريبية 3: انتقِل إلى قسم المكافأة للتعرّف على كيفية نقل البيانات إلى Python 3 وبيئة التشغيل من الجيل التالي في App Engine.
• الوحدة 7: قوائم انتظار المهام الفورية في App Engine (مطلوبة إذا كنت تستخدم قوائم انتظار المهام الفورية)
  • إضافة مهام دفع App Engine taskqueue إلى تطبيق الوحدة 1
  • إعداد المستخدمين لنقل البيانات إلى Cloud Tasks في الوحدة التدريبية 8
• الوحدة 4: نقل البيانات إلى Cloud Run باستخدام Docker
  • وضع تطبيقك في حاوية لتشغيله على Cloud Run باستخدام Docker
  • يتيح لك البقاء على Python 2
• الوحدة 5: نقل البيانات إلى Cloud Run باستخدام Cloud Buildpacks
  • وضع تطبيقك في حاوية لتشغيله على Cloud Run باستخدام Cloud Buildpacks
  • لا تحتاج إلى معرفة أي شيء عن Docker أو الحاويات أو Dockerfile
  • يجب أن تكون قد نقلت تطبيقك إلى Python 3
• الوحدة 6: نقل البيانات إلى Cloud Firestore
  • نقل البيانات إلى Cloud Firestore للوصول إلى ميزات Firebase
  • على الرغم من أنّ Cloud Firestore تتوافق مع Python 2، لا يتوفّر هذا الدرس العملي إلا في Python 3.

7. مكافأة: الانتقال إلى Python 3

ملاحظة: يمكنك تخطّي هذا القسم بالكامل إذا كان تطبيقك يعمل حاليًا على Python 3.

للوصول إلى أحدث وقت تشغيل وميزات في App Engine، ننصحك بالانتقال إلى Python 3. في نموذج تطبيقنا، كانت خدمة Datastore هي الخدمة المضمّنة الوحيدة التي استخدمناها، وبما أنّنا نقلنا البيانات من ndb إلى Cloud NDB، يمكننا الآن تكييف البرنامج مع وقت تشغيل Python 3 في App Engine.

نظرة عامة

مع أنّ عملية تكييف البرنامج إلى Python 3 ليست ضمن نطاق دليل توجيهي/تعليمي على Google Cloud، يقدّم هذا الجزء من درس تطبيقي حول الترميز للمطوّرين فكرة عن كيفية اختلاف وقت تشغيل Python 3 في App Engine. إحدى الميزات البارزة لوقت التشغيل من الجيل التالي هي سهولة الوصول إلى حِزم الجهات الخارجية: لا حاجة إلى تحديد الحِزم المضمّنة في app.yaml ولا إلى نسخ أو تحميل المكتبات غير المضمّنة، إذ يتم تثبيتها ضمنيًا من خلال إدراجها في requirements.txt.

بما أنّ العيّنة بسيطة جدًا وCloud Datastore متوافق مع Python 2-3، لا يلزم نقل أي رمز برمجي للتطبيق بشكل صريح إلى الإصدار 3.x: يعمل التطبيق على الإصدارين 2.x و3.x بدون تعديل، ما يعني أنّ التغييرات المطلوبة الوحيدة هي في الإعدادات في هذه الحالة:

1. تبسيط app.yaml للإشارة إلى Python 3 وإزالة الإشارة إلى المكتبات المجمّعة التابعة لجهات خارجية
2. احذف appengine_config.py والمجلد lib لأنّهما لم يعودا ضروريين.

لن يتم إجراء أي تغيير على ملفَي التطبيق main.py وtemplates/index.html.

تعديل "requirements.txt"

الإصدار النهائي من Cloud Datastore المتوافق مع Python 2 هو 1.15.3. يجب تحديث requirements.txt إلى أحدث إصدار من Python 3 (قد يكون هناك إصدار أحدث الآن). عند كتابة هذا البرنامج التعليمي، كان أحدث إصدار هو 2.1.0، لذا عدِّل هذا السطر ليصبح على النحو التالي (أو أي إصدار أحدث):

google-cloud-datastore==2.1.0

التبسيط app.yaml

قبل:

التغيير الوحيد الفعلي في نموذج التطبيق هذا هو تقصير app.yaml بشكلٍ كبير. للتذكير، إليك ما كان لدينا في app.yaml في نهاية الوحدة 3:

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

AFTER:

في Python 3، تم إيقاف جميع توجيهات threadsafe وapi_version وlibraries نهائيًا، ويُفترض أنّ جميع التطبيقات آمنة للاستخدام المتزامن، ولا يتم استخدام api_version في Python 3. لم تعُد هناك حِزم مضمّنة تابعة لجهات خارجية مثبَّتة مسبقًا على خدمات App Engine، لذا تم إيقاف libraries نهائيًا أيضًا. يمكنك الاطّلاع على المستندات حول التغييرات في app.yaml للحصول على مزيد من المعلومات حول هذه التغييرات. نتيجةً لذلك، عليك حذف جميع الإصدارات الثلاثة من app.yaml والتحديث إلى إصدار متوافق من Python 3 (يُرجى الاطّلاع على ما يلي).

اختياري: استخدام التوجيه handlers

بالإضافة إلى ذلك، تم إيقاف التوجيه handlers نهائيًا، وهو التوجيه الذي يوجّه الزيارات إلى تطبيقات App Engine. بما أنّ وقت التشغيل من الجيل التالي يتوقّع أن تدير أُطر عمل الويب توجيه التطبيقات، يجب تغيير جميع "نصوص معالجة الطلبات" إلى "auto". من خلال الجمع بين التغييرات الواردة أعلاه، يمكنك الوصول إلى app.yaml:

runtime: python38

handlers:
- url: /.*
  script: auto

يمكنك الاطّلاع على مزيد من المعلومات حول script: auto من صفحة المرجع app.yaml.

إزالة التوجيه handlers

بما أنّ handlers قد تم إيقافه نهائيًا، يمكنك أيضًا إزالة القسم بأكمله، مع ترك سطر واحد app.yaml:

runtime: python38

سيؤدي ذلك تلقائيًا إلى تشغيل خادم الويب Gunicorn WSGI المتاح لجميع التطبيقات. إذا كنت على دراية بـ gunicorn، هذا هو الأمر الذي يتم تنفيذه عند بدء تشغيله تلقائيًا باستخدام app.yaml:

gunicorn main:app --workers 2 -c /config/gunicorn.py

اختياري: استخدام التوجيه entrypoint

ومع ذلك، إذا كان تطبيقك يتطلّب أمر بدء تشغيل محدّدًا، يمكن تحديد ذلك باستخدام توجيه entrypoint، ما يؤدي إلى إنشاء app.yaml على النحو التالي:

runtime: python38
entrypoint: python main.py

يطلب هذا المثال تحديدًا استخدام خادم تطوير Flask بدلاً من gunicorn. يجب أيضًا إضافة الرمز الذي يبدأ خادم التطوير إلى تطبيقك لتشغيله على واجهة 0.0.0.0 على المنفذ 8080 من خلال إضافة هذا القسم الصغير إلى أسفل main.py:

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080, debug=True)

يمكنك الاطّلاع على مزيد من المعلومات حول entrypoint من صفحة المرجع app.yaml. يمكنك العثور على المزيد من الأمثلة وأفضل الممارسات في مستندات بدء التشغيل في بيئة App Engine العادية بالإضافة إلى مستندات بدء التشغيل في بيئة App Engine المرنة.

حذف appengine_config.py وlib

احذف الملف appengine_config.py والمجلد lib. عند الانتقال إلى Python 3، يكتسب App Engine الحِزم المدرَجة في requirements.txt ويثبّتها.

يُستخدَم ملف الإعداد appengine_config.py للتعرّف على المكتبات أو الحِزم التابعة لجهات خارجية، سواء نسختها بنفسك أو استخدمت تلك المتوفّرة على خوادم App Engine (المضمّنة). عند الانتقال إلى الإصدار 3 من Python، إليك ملخّصًا للتغييرات الكبيرة:

1. عدم تجميع المكتبات المنسوخة التابعة لجهات خارجية (المدرَجة في requirements.txt)
2. لا يمكن وضع pip install في مجلد lib، ما يعني عدم إمكانية إنشاء مجلد lib على الإطلاق
3. ما مِن مكتبات تابعة لجهات خارجية مضمّنة في app.yaml
4. لا حاجة إلى الإشارة إلى التطبيق في المكتبات التابعة لجهات خارجية، وبالتالي لا حاجة إلى ملف appengine_config.py

يكفي إدراج جميع مكتبات الجهات الخارجية المطلوبة في requirements.txt.

نشر التطبيق

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

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

جارٍ تحضير طلب الحصول على إذن

عندما يحين وقت نقل تطبيقك ، عليك نقل main.py وملفات التطبيق الأخرى إلى الإصدار 3.x، لذا من أفضل الممارسات محاولة جعل تطبيقك المتوافق مع الإصدار 2.x "متوافقًا مع الإصدارات الأحدث" قدر الإمكان.

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

1. التأكّد من أنّ جميع تبعيات التطبيق متوافقة تمامًا مع الإصدار 3.x
2. تأكَّد من أنّ تطبيقك يعمل على الإصدار 2.6 على الأقل (ويُفضّل الإصدار 2.7).
3. التأكّد من أنّ التطبيق يجتاز مجموعة الاختبارات بأكملها (وبنسبة تغطية لا تقل عن% 80)
4. استخدام مكتبات التوافق، مثل six وFuture و/أو Modernize
5. التعرّف على الاختلافات الرئيسية بين الإصدار 2.x والإصدار 3.x غير المتوافقة مع الإصدارات السابقة
6. من المحتمل أن يؤدي أي إدخال/إخراج إلى حدوث حالات عدم توافق بين Unicode وسلسلة البايت.

تم تصميم نموذج التطبيق مع أخذ كل ذلك في الاعتبار، ولهذا السبب يعمل التطبيق على الإصدارَين ‎2.x و‎3.x مباشرةً لنتمكّن من التركيز على توضيح التغييرات التي يجب إجراؤها لاستخدام الجيل التالي من المنصة.

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

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

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

• البحث عن المشاكل
• تسجيل مشكلة أو ملاحظات جديدة

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

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

Codelab	Python 2	Python 3
الوحدة 2	code	code
الوحدة 3	code	code

موارد App Engine

في ما يلي مراجع إضافية بشأن عملية النقل المحدّدة هذه:

• مراجع Python Cloud NDB وCloud Datastore
  • مستندات مكتبة برامج Google Cloud NDB
  • مستودع مكتبة برامج Google Cloud NDB
  • مستندات مكتبة برامج Google Cloud Datastore
  • مستودع مكتبة برامج Google Cloud Datastore
• نقل البيانات إلى Python 3 وبيئة التشغيل من الجيل التالي في "محرّك تطبيقات Google"
  • معالجات النصوص البرمجية اختيارية
  • مرجع entrypoint
  • app.yaml أمثلة وأفضل الممارسات
  • مزيد من الأمثلة وأفضل الممارسات
  • نقل ملفات إعدادات App Engine
  • الصفحة الرئيسية لعملية نقل البيانات
• معلومات عامة
  • Python على Google Cloud Platform
  • مكتبات برامج Python في Google Cloud