الوحدة النمطية 2: النقل من App Engine ndb إلى Cloud NDB

1. نظرة عامة

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

يعلّمك هذا البرنامج التعليمي كيفية نقل البيانات من ndb (Next Database) مكتبة برامج العميل المضمّنة في App Engine إلى مكتبة برامج العميل Cloud NDB.

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

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

• استخدام مكتبة App Engine ndb (إذا لم تكن على دراية بها)
• نقل البيانات من ndb إلى Cloud NDB
• نقل تطبيقك إلى Python 3

المتطلبات

• مشروع Google Cloud Platform يتضمّن ما يلي:
  • حساب فوترة نشط على Google Cloud Platform
  • تفعيل App Engine
• مهارات أساسية في لغة Python
• معرفة عملية بالأوامر الشائعة على نظام التشغيل Linux
• معرفة أساسية بشأن تطوير ونشر تطبيقات App Engine
• تطبيق App Engine للوحدة 1 يعمل

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

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

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

2. الخلفية

في الوحدة 1، نقلنا أُطر عمل الويب من webapp2 المضمّنة في App Engine إلى Flask. في هذا الدرس التطبيقي حول الترميز، سنواصل التوقّف عن استخدام الخدمات المضمّنة في App Engine من خلال الانتقال من مكتبة ndb في App Engine إلى Cloud NDB من Google.

بعد إكمال عملية نقل البيانات هذه، يمكنك إجراء ما يلي:

1. نقل البيانات إلى Python 3 وبيئة وقت التشغيل من الجيل التالي في App Engine
2. النقل إلى Cloud Datastore (مكتبة برامج للتطبيقات غير المستندة إلى App Engine)
3. تضمين تطبيق Python 2 (أو 3) في حاوية ونقل البيانات إلى Cloud Run
4. إضافة استخدام قوائم انتظار المهام في App Engine (التي يتم إرسالها)، ثم نقل البيانات إلى Cloud Tasks

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

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

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

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

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

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

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

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

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

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

يجب أن يحتوي مجلد الرمز البرمجي الخاص بالوحدة 1 من START على المحتوى التالي:

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

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

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

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

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

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

4. تعديل ملفات الإعداد (إضافة مكتبة Cloud NDB)

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

لنعدّل ملفات التأكيد لاستبدال ndb في App Engine بخدمة Cloud NDB، ثم نعدّل تطبيقنا.

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

في الوحدة 1، كانت التبعية الخارجية الوحيدة لتطبيقنا هي Flask. سنضيف الآن Cloud NDB. في ما يلي الشكل الذي كان يبدو عليه ملف requirements.txt في نهاية الوحدة 1:

• قبل:

Flask==1.1.2

تتطلّب عملية نقل البيانات من App Engine ndb مكتبة Cloud NDB (google-cloud-ndb)، لذا أضِف حزمة المكتبة إلى requirements.txt.

• AFTER:

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

عند كتابة هذا الدرس العملي، كان أحدث إصدار مقترَح هو 1.7.1، ولكن قد يكون هناك إصدار أحدث في requirements.txt في المستودع. ننصح باستخدام أحدث إصدارات كل مكتبة، ولكن إذا لم تعمل، يمكنك الرجوع إلى إصدار أقدم.

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

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

2. تعديل "app.yaml"

تتطلّب إضافة مكتبات برامج Google Cloud، مثل google-cloud-ndb، بعض المتطلبات التي تدور جميعها حول تضمين المكتبات"المضمّنة"، وهي حِزم تابعة لجهات خارجية متوفّرة حاليًا على خوادم Google. لا يتم إدراجها في requirements.txt ولا يتم نسخها باستخدام pip install. المتطلبات الوحيدة هي:

1. تحديد المكتبات المضمّنة في app.yaml
2. توجيههم إلى مكتبات تابعة لجهات خارجية تم نسخها وقد يعملون بها (في lib)

إليك app.yaml من الوحدة 1:

• قبل:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

أضِف الآن الأسطر التالية إلى app.yaml للإشارة إلى حزمتَين من حِزم الجهات الخارجية: grpcio وsetuptools في قسم libraries جديد:

libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

لماذا يجب استخدام هذه المكتبات المضمّنة؟ gRPC هو إطار عمل مفتوح لبروتوكول RPC تستخدمه جميع مكتبات برامج Google Cloud، بما في ذلك google-cloud-ndb. المكتبة grpcio هي محوّل gRPC في Python، وبالتالي فهي مطلوبة. سنشرح سبب تضمين setuptools في الفقرة التالية.

• AFTER:

بعد إجراء التغييرات المذكورة أعلاه، من المفترض أن يبدو 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

3- تعديل "appengine_config.py"

تُستخدَم الأداة pkg_resources، وهي جزء من المكتبة setuptools، للسماح للمكتبات المضمّنة التابعة لجهات خارجية بالوصول إلى المكتبات المجمّعة. عدِّل appengine_config.py لاستخدام pkg_resources لتوجيههم إلى المكتبات المجمّعة في lib. بعد إكمال هذا التغيير، من المفترض أن يبدو الملف بأكمله على النحو التالي:

import pkg_resources
from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)

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

بعد الانتهاء من إجراءات ملف الإعداد، يمكنك الآن نقل البيانات من ndb إلى Cloud NDB. لإكمال عملية نقل البيانات، عدِّل المكتبات المستورَدة وأضِف استخدام إدارة السياق في main.py.

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

أجرِ عملية التبديل التالية في main.py:

• قبل

from google.appengine.ext import ndb

• AFTER:

from google.cloud import ndb

في بعض الأحيان، يكون التغيير من مكتبة App Engine إلى مكتبة Google Cloud بسيطًا مثل هذا المثال. بالنسبة إلى الخدمات المضمّنة التي أصبحت منتجات Google Cloud كاملة، ستستورد السمات من google.cloud بدلاً من google.appengine.

2. الوصول إلى Datastore

لاستخدام مكتبة Cloud NDB، يجب أن يستخدم تطبيقك مدراء سياق Python. والغرض منها هو "حظر" الوصول إلى الموارد إلى أن يتم الحصول عليها. تستند أدوات إدارة السياق إلى تقنية التحكّم في علوم الكمبيوتر المعروفة باسم تخصيص الموارد هو التهيئة (أو RAII). يتم استخدام أدوات إدارة السياق مع ملفات Python (التي يجب فتحها قبل إمكانية الوصول إليها) والتزامن، ويجب الحصول على "أقفال متكررة" قبل تنفيذ الرمز في "قسم حرج".

وبالمثل، يتطلّب Cloud NDB الحصول على سياق العميل للتواصل مع Datastore قبل تنفيذ أي أوامر Datastore. أولاً، أنشئ عميلاً (ndb.Client()) عن طريق إضافة ds_client = ndb.Client() في main.py بعد تهيئة Flask مباشرةً:

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

يُستخدم الأمر Pythonwith فقط للحصول على سياق أحد العناصر. يمكنك تضمين أيّ كتل رموز تصل إلى Datastore في عبارات with.

في ما يلي الدوال نفسها من الوحدة 1 لكتابة كيان جديد إلى Datastore، والقراءة لعرض الكيانات التي تمت إضافتها مؤخرًا:

• قبل:

إليك الرمز الأصلي بدون إدارة السياق:

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 (v.to_dict() for v in Visit.query().order(
            -Visit.timestamp).fetch(limit))

• AFTER:

أضِف الآن with ds_client.context(): وانقل رمز الوصول إلى Datastore إلى الكتلة with:

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 (v.to_dict() for v in Visit.query().order(
                -Visit.timestamp).fetch(limit))

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

يظل تطبيق برنامج التشغيل الرئيسي مطابقًا لما كان لدينا من الوحدة 1، إذ لا يتضمّن أي رمز ndb (ولا Cloud NDB):

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

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

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

نشر التطبيق

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

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

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

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

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

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

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

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

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

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

من هنا، يمكنك اختيار الخطوة التالية التي تريد اتّخاذها. اختَر أيًا من الخيارات التالية:

• مكافأة الوحدة 2: يمكنك مواصلة القراءة أدناه للاطّلاع على الجزء الإضافي من هذا البرنامج التعليمي لاستكشاف عملية نقل البيانات إلى 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
• الوحدة التدريبية 3:
  • تحديث إمكانية الوصول إلى Datastore من Cloud NDB إلى Cloud Datastore
  • هذه هي المكتبة المستخدَمة لتطبيقات Python 3 على App Engine والتطبيقات غير المستندة إلى App Engine

7. مكافأة: الانتقال إلى 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 NDB متوافق مع Python 2-3، لا يلزم نقل أي رمز برمجي للتطبيق بشكل صريح إلى الإصدار 3.x، بل يعمل التطبيق على الإصدارين 2.x و3.x بدون تعديل، ما يعني أنّ التغييرات المطلوبة الوحيدة هي في الإعدادات في هذه الحالة:

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

بالإضافة إلى main.py، ستبقى الملفات requirements.txt وtemplates/index.html بدون تغيير.

التبسيط app.yaml

قبل:

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

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 من صفحة المستندات.

إزالة التوجيه 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 Engine Standard بالإضافة إلى مستندات بدء التشغيل في App Engine Flexible.

حذف 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 البرمجي الخاص بالوحدة التدريبية 2. لعرض الاختلافات مع Python 2، قارِن الرمز البرمجي بإصدار Python 2.

تهانينا على إكمال الخطوة الإضافية في الوحدة 2. يمكنك الاطّلاع على المستندات حول إعداد ملفات الضبط لوقت تشغيل 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

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

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

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

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

Codelab	Python 2	Python 3
الوحدة 1	code	(غير متوفر)
الوحدة 2	code	code

موارد App Engine

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

• مراجع Python NDB
  • مستندات App Engine ndb
  • مستودع ndb App Engine
  • مستندات Google Cloud NDB
  • مستودع Google Cloud NDB
• (قديم) الترحيل من الإصدار 2.5 من Python وwebapp إلى الإصدار 2.7 وwebapp2
  • تم إيقاف الإصدار 2.5 من Python نهائيًا في 2013/2017 لصالح الإصدار 2.7
  • مستندات Python 2.5 إلى 2.7
  • مكتبة db Python 2.5
  • نقل البيانات من الإصدار 2.5 db إلى الإصدار 2.7 ndb من Python
• نقل البيانات إلى Python 3 وبيئة التشغيل من الجيل التالي في "محرّك تطبيقات Google"
  • نقل البيانات من GAE ndb إلى Cloud NDB
  • مستودع نماذج مستندات GAE ndb إلى Cloud NDB
  • معالجات النصوص البرمجية اختيارية
  • مرجع entrypoint
  • app.yaml أمثلة وأفضل الممارسات
  • مزيد من الأمثلة وأفضل الممارسات
  • نقل ملفات إعدادات App Engine
  • الصفحة الرئيسية لعملية نقل البيانات
• معلومات عامة
  • Python على Google Cloud Platform
  • مكتبات برامج Python في Google Cloud