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

1. نظرة عامة

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

يشرح لك هذا البرنامج التعليمي كيفية نقل البيانات من مكتبة برامج ndb (قاعدة البيانات التالية) المدمجة في App Engine إلى مكتبة برامج Cloud NDB.

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

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

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

المتطلبات

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

استطلاع

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

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

2. الخلفية

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

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

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. إعداد المشروع

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

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

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

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

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

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

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

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

إليك الخطوات المتبقية لتنفيذ العمل المسبق الآن:

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

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

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

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

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

1. تحديث requirements.txt

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

• قبل:

Flask==1.1.2

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

• بعد:

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 هو إطار عمل مفتوح لاستدعاء الإجراء عن بُعد تستخدمه جميع مكتبات عملاء Google Cloud، بما في ذلك google-cloud-ndb. مكتبة grpcio هي محوّل gRPC في Python، وبالتالي هي مطلوبة. إنّ السبب في تضمين setuptools قريبًا.

• بعد:

بعد تطبيق التغييرات الواردة أعلاه، من المفترض أن يظهر 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

• بعد:

from google.cloud import ndb

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

2. الوصول إلى مخزن البيانات

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

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

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

يُستخدم الأمر Pythonwith فقط للحصول على سياق الكائن. استخدِم عبارات with لإلغاء حظر أي رموز برمجية للوصول إلى Datastore.

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

• قبل:

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

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))

• بعد:

يمكنك الآن إضافة with ds_client.context(): ونقل رمز الدخول إلى مخزن البيانات إلى المجموعة 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، عند التعامل مع المعاملات وNDB على السحابة الإلكترونية، تعمل قوائم انتظار المهام بشكل مستقل. على سبيل المثال، في رمز المعاملات، لا يتم التراجع عن مكالمات قائمة انتظار المهام في حالة فشل المعاملة، ولكن عمليات تخزين البيانات فقط. في حين أنه لا تتوفر لدينا وثائق حول هذا القيد، فقد تم إدراجها في "غير متاح" مع صفحة "مهام Google"

يظل تطبيق برنامج التشغيل الرئيسي متطابقًا مع ما وضعناه في الوحدة رقم 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.

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

تهانينا على إكمال هذا الدرس التطبيقي حول الترميز في الوحدة 2. لقد تجاوزت خط النهاية للتوّ، فهي آخر عمليات نقل البيانات الموصى بها بشدة في هذه السلسلة بقدر ما يمرّ على استخدام 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
• الوحدة الثالثة:
  • تحديث الوصول إلى مخزن البيانات من 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

بعد:

في بايثون 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 بالإضافة إلى مستندات بدء تشغيل بيئة 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.

نشر التطبيق

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

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

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

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

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

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

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

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

Codelab	Python 2	Python 3
الوحدة 1	الرموز البرمجية	(لا ينطبق)
الوحدة 2	الرموز البرمجية	الرموز البرمجية

موارد App Engine

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

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