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

1. نظرة عامة

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

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

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

• استخدام Cloud NDB (إذا لم تكن معتادًا على ذلك)
• نقل البيانات من Cloud NDB إلى Cloud Datastore
• يمكنك أيضًا نقل تطبيقك إلى Python 3

المتطلبات

• مشروع Google Cloud Platform مع حساب فوترة نشط على Google Cloud Platform
• المهارات الأساسية في لغة بايثون
• معرفة عملية بأوامر Linux الأساسية
• معرفة أساسية بتطوير ونشر تطبيقات App Engine
• تطبيق الوحدة التنظيمية 2 App Engine 2.x أو 3.x قيد التشغيل.

استطلاع

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

قراءة النص فقط اقرأها وأكمِل التمارين

2. الخلفية

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

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

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

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

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

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

1. الإعداد/التمهيد
2. استبدال Cloud NDB بمكتبات عملاء Cloud Datastore
3. تحديث التطبيق

3- الإعداد/التمهيد

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

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

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

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

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

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

Python

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

يجب أن يبدو دليل بدء تشغيل الوحدة 2 في بايثون 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 مثبّتان، ننصحك باستخدام pip2 بدلاً من pip لتجنُّب حدوث أي التباس مع Python 3.

بايثون 3

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

يجب أن يبدو دليل بدء الوحدة 2 في بايثون 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 على النحو التالي:

• قبل (بايثون 2 و3):

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

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

• بعد (بايثون 2):

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

• بعد (بايثون 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" بأخرى من أجل "مخزن البيانات في السحابة الإلكترونية": google.cloud.datastore. بما أنّ مكتبة برامج "تخزين البيانات" لا تتيح الإنشاء التلقائي لحقل طابع زمني في كيان، يمكنك أيضًا استيراد وحدة datetime للمكتبة العادية لإنشاء وحدة يدويًا. بحسب ما هو متفق عليه، تتجاوز عمليات استيراد المكتبة العادية عمليات استيراد الحزم التابعة لجهات خارجية. عند الانتهاء من هذه التغييرات، من المفترض أن يظهر على النحو التالي:

• بعد:

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)

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

• بعد:

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

3- الوصول إلى مخزن البيانات

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

• قبل:

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 (Python dict) من أزواج المفتاح/القيمة، ثم اكتبه في Datastore باستخدام القيمة put() المتوقَّعة. يُعد الاستعلام مشابهًا ولكنه أكثر وضوحًا باستخدام Datastore. يمكنك في ما يلي معرفة أوجه اختلاف رمز تخزين البيانات المكافئ:

• بعد:

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(). بعد الانتهاء من هذه التغييرات، أصبح تطبيقك جاهزًا للاختبار.

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

نشر التطبيق

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

• Python 2
• Python 3

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

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

اختياري: إخلاء مساحة تخزين

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

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

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

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

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

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

من هنا، يمكنك الاطّلاع على وحدات نقل البيانات التالية:

• مكافأة الوحدة الثالثة: تابع إلى قسم المكافأة للتعرّف على كيفية الانتقال إلى Python 3 والجيل التالي من بيئة تشغيل App Engine.
• الوحدة 7: قوائم انتظار مهام Drive Engine App Engine (مطلوبة إذا كنت تستخدم [push] قوائم انتظار المهام)
  • إضافة مهام دفع taskqueue في App Engine إلى تطبيق الوحدة 1
  • تحضير المستخدمين لنقل البيانات إلى Cloud Tasks في الوحدة 8
• الوحدة 4: النقل إلى التشغيل في السحابة الإلكترونية باستخدام Docker
  • احتواء تطبيقك على حاويات لتشغيله على Cloud Run مع Docker
  • البقاء على Python 2
• الوحدة 5: النقل إلى Cloud Run باستخدام Cloud Buildpack
  • توفير حاويات في تطبيقك لتشغيله على Cloud Runs مع حِزم 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

بعد:

في بايثون 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، يكون ملخص التغييرات الكبيرة كما يلي:

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

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

نشر التطبيق

أعِد نشر تطبيقك للتأكُّد من أنّه يعمل بشكلٍ سليم. يمكنك أيضًا التأكّد من مدى قُرب الحل من نموذج الوحدة 3 على رمز Python 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. من المحتمل أن يؤدي أي إدخال/إخراج إلى عدم توافق سلسلة يونيكود مقابل سلسلة البايت.

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

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

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

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

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

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

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

Codelab	Python 2	Python 3
الوحدة 2	الرموز البرمجية	الرموز البرمجية
الوحدة 3	الرموز البرمجية	الرموز البرمجية

موارد App Engine

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

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