كيفية استخدام قائمة انتظار مهام App Engine (سحب المهام) في تطبيقات Flask (الوحدة 18)

1. نظرة عامة

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

يعلّمك هذا الدرس التطبيقي حول الترميز كيفية تضمين مهام السحب في "قائمة انتظار المهام" في App Engine واستخدامها في نموذج التطبيق من الدرس التطبيقي حول الترميز 1. نضيف استخدام مهام السحب في هذا البرنامج التعليمي للوحدة 18، ثم ننقل هذا الاستخدام إلى Cloud Pub/Sub في الوحدة 19. بالنسبة إلى المستخدمين الذين يستعملون "قوائم انتظار المهام" لتنفيذ مهام الدفع، سيتم نقل بياناتهم إلى Cloud Tasks، وعليهم الرجوع إلى الوحدات 7 إلى 9 بدلاً من ذلك.

ستتعرَّف على كيفية إجراء ما يلي:

  • استخدام واجهة برمجة التطبيقات/الخدمة المجمّعة "قائمة مهام App Engine"
  • إضافة استخدام قائمة انتظار السحب إلى تطبيق أساسي على Python 2 Flask App Engine NDB

المتطلبات

استطلاع

كيف ستستخدم هذا البرنامج التعليمي؟

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

كيف تقيّم تجربتك مع Python؟

مبتدئ متوسط متمكّن

ما هو تقييمك لتجربة استخدام خدمات Google Cloud؟

مبتدئ متوسط متقدّم

2. الخلفية

لإجراء عملية نقل البيانات من مهام السحب في "قائمة انتظار المهام" في App Engine، أضِف استخدامها إلى تطبيق Flask وApp Engine NDB الحالي الناتج عن الدرس التطبيقي حول الترميز في الوحدة 1. يعرض نموذج التطبيق آخر الزيارات التي أجراها المستخدم النهائي. لا بأس بذلك، ولكن من الأفضل أيضًا تتبُّع الزوّار لمعرفة مَن يزور الموقع الإلكتروني أكثر من غيره.

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

لتنفيذ هذا التصميم، سنضيف استخدام قوائم انتظار السحب إلى التطبيق الرئيسي، بالإضافة إلى توفير وظائف العامل. يمكن أن يعمل العامل كعملية منفصلة (مثل مثيل خلفي أو رمز يعمل على جهاز افتراضي يعمل دائمًا)، أو مهمة cron، أو طلب HTTP أساسي من سطر الأوامر باستخدام curl أو wget. بعد عملية الدمج هذه، يمكنك نقل التطبيق إلى Cloud Pub/Sub في الدرس التطبيقي التالي (الوحدة 19).

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

  1. الإعداد/العمل التحضيري
  2. تعديل الإعدادات
  3. تعديل الرمز البرمجي للتطبيق

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

يوضّح هذا القسم كيفية تنفيذ ما يلي:

  1. إعداد مشروعك على السحابة الإلكترونية
  2. الحصول على نموذج تطبيق أساسي
  3. (إعادة) نشر تطبيق أساسي وإثبات صحته

تضمن لك هذه الخطوات البدء برمز برمجي صالح.

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

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

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

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

بغض النظر عن تطبيق الوحدة 1 الذي تستخدمه، يجب أن يبدو المجلد مثل الناتج أدناه، وربما يتضمّن مجلد lib أيضًا:

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

3- (إعادة) نشر التطبيق الأساسي

اتّبِع الخطوات التالية لنشر تطبيق الوحدة 1:

  1. احذف المجلد lib إذا كان متوفّرًا ونفِّذ الأمر: pip install -t lib -r requirements.txt لإعادة ملء lib. قد تحتاج إلى استخدام الأمر pip2 بدلاً من ذلك إذا كان لديك كل من Python 2 و3 مثبّتَين.
  2. تأكَّد من أنّك ثبَّت وبدأت استخدام أداة سطر الأوامر gcloud وراجعت طريقة استخدامها.
  3. اضبط مشروعك على Cloud باستخدام gcloud config set project PROJECT_ID إذا كنت لا تريد إدخال PROJECT_ID مع كل أمر gcloud يتم إصداره.
  4. نشر نموذج التطبيق باستخدام gcloud app deploy
  5. تأكَّد من أنّ تطبيق الوحدة 1 يعمل على النحو المتوقّع ويعرض أحدث الزيارات (كما هو موضّح أدناه).

a7a9d2b80d706a2b.png

4. تعديل الإعدادات

لا يلزم إجراء أي تغييرات على ملفات الإعداد العادية في App Engine (app.yaml وrequirements.txt وappengine_config.py). بدلاً من ذلك، أضِف ملف إعداد جديدًا، queue.yaml، يتضمّن المحتوى التالي، وضَعْه في دليل المستوى الأعلى نفسه:

queue:
- name: pullq
  mode: pull

يحدّد ملف queue.yaml جميع قوائم انتظار المهام المتوفّرة لتطبيقك (باستثناء قائمة انتظار default [push] التي ينشئها App Engine تلقائيًا). في هذه الحالة، هناك قائمة انتظار واحدة فقط، وهي قائمة انتظار سحب باسم pullq. يتطلّب App Engine تحديد التوجيه mode على أنّه pull، وإلا سيتم إنشاء قائمة انتظار دفع تلقائيًا. يمكنك الاطّلاع على مزيد من المعلومات حول إنشاء قوائم انتظار السحب في المستندات. يمكنك أيضًا الاطّلاع على صفحة مرجع queue.yaml للتعرّف على الخيارات الأخرى.

يمكنك نشر هذا الملف بشكل منفصل عن تطبيقك، وسيظل بإمكانك استخدام gcloud app deploy، ولكن عليك أيضًا تقديم queue.yaml في سطر الأوامر:

$ gcloud app deploy queue.yaml
Configurations to update:

descriptor:      [/tmp/mod18-gaepull/queue.yaml]
type:            [task queues]
target project:  [my-project]

WARNING: Caution: You are updating queue configuration. This will override any changes performed using 'gcloud tasks'. More details at
https://cloud.google.com/tasks/docs/queue-yaml

Do you want to continue (Y/n)?

Updating config [queue]...⠹WARNING: We are using the App Engine app location (us-central1) as the default location. Please use the "--location" flag if you want to use a different location.
Updating config [queue]...done.

Task queues have been updated.

Visit the Cloud Platform Console Task Queues page to view your queues and cron jobs.
$

5- تعديل الرمز البرمجي للتطبيق

يتضمّن هذا القسم تعديلات على الملفات التالية:

  • main.py: إضافة استخدام قوائم الانتظار إلى التطبيق الرئيسي
  • templates/index.html: تعديل نموذج الويب لعرض البيانات الجديدة

عمليات الاستيراد والثوابت

تتمثل الخطوة الأولى في إضافة عملية استيراد جديدة واحدة وعدة ثوابت لدعم قوائم الانتظار:

  • أضِف عملية استيراد لمكتبة "قائمة انتظار المهام"، google.appengine.api.taskqueue.
  • أضِف ثلاثة ثوابت لتوفير تأجير الحد الأقصى لعدد مهام السحب (TASKS) لمدة ساعة واحدة (HOUR) من قائمة انتظار السحب (QUEUE).
  • أضِف ثابتًا لعرض أحدث الزيارات بالإضافة إلى أهم الزوّار (LIMIT).

في ما يلي الرمز الأصلي والشكل الذي سيظهر به بعد إجراء هذه التعديلات:

قبل:

from flask import Flask, render_template, request
from google.appengine.ext import ndb

app = Flask(__name__)

بعد:

from flask import Flask, render_template, request
from google.appengine.api import taskqueue
from google.appengine.ext import ndb

HOUR = 3600
LIMIT = 10
TASKS = 1000
QNAME = 'pullq'
QUEUE = taskqueue.Queue(QNAME)
app = Flask(__name__)

إضافة مهمة سحب (جمع البيانات للمهمة وإنشاء مهمة في قائمة انتظار السحب)

يبقى نموذج البيانات Visit كما هو، وكذلك طلب البحث عن الزيارات لعرضها في fetch_visits(). التغيير الوحيد المطلوب في هذا الجزء من الرمز هو في store_visit(). بالإضافة إلى تسجيل الزيارة، أضِف مهمة إلى قائمة انتظار السحب تتضمّن عنوان IP الخاص بالزائر حتى يتمكّن العامل من زيادة عدّاد الزوّار.

قبل:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

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)

بعد:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit in Datastore and queue request to bump visitor count'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()
    QUEUE.add(taskqueue.Task(payload=remote_addr, method='PULL'))

def fetch_visits(limit):
    'get most recent visits'
    return Visit.query().order(-Visit.timestamp).fetch(limit)

إنشاء نموذج بيانات ووظيفة طلب بحث لتتبُّع الزوّار

أضِف نموذج بيانات VisitorCount لتتبُّع الزوّار، ويجب أن يتضمّن حقولاً خاصة بـ visitor بالإضافة إلى عدد صحيح counter لتتبُّع عدد الزيارات. بعد ذلك، أضِف دالة جديدة (أو يمكن أن تكون classmethod في Python) باسم fetch_counts() للاستعلام عن أهم الزوّار وعرضهم بترتيب تنازلي. أضِف الفئة والدالة أسفل نص fetch_visits() مباشرةً:

class VisitorCount(ndb.Model):
    visitor = ndb.StringProperty(repeated=False, required=True)
    counter = ndb.IntegerProperty()

def fetch_counts(limit):
    'get top visitors'
    return VisitCount.query().order(-VisitCount.counter).fetch(limit)

إضافة رمز العامل

أضِف دالة جديدة log_visitors() لتسجيل الزوّار من خلال طلب استرداد بيانات باستخدام GET إلى /log. يستخدم قاموسًا/تجزئة لتتبُّع أحدث أعداد الزوّار، ويستأجر أكبر عدد ممكن من المهام لمدة ساعة. بالنسبة إلى كل مهمة، يتم احتساب جميع الزيارات التي أجراها الزائر نفسه. بعد الحصول على النتائج، يحدّث التطبيق جميع عناصر VisitorCount ذات الصلة الموجودة في Datastore أو ينشئ عناصر جديدة إذا لزم الأمر. تعرض الخطوة الأخيرة رسالة نصية عادية تشير إلى عدد الزوّار الذين تم تسجيلهم من إجمالي عدد المهام التي تمت معالجتها. أضِف هذه الدالة إلى main.py أسفل fetch_counts() مباشرةً:

@app.route('/log')
def log_visitors():
    'worker processes recent visitor counts and updates them in Datastore'
    # tally recent visitor counts from queue then delete those tasks
    tallies = {}
    tasks = QUEUE.lease_tasks(HOUR, TASKS)
    for task in tasks:
        visitor = task.payload
        tallies[visitor] = tallies.get(visitor, 0) + 1
    if tasks:
        QUEUE.delete_tasks(tasks)

    # increment those counts in Datastore and return
    for visitor in tallies:
        counter = VisitorCount.query(VisitorCount.visitor == visitor).get()
        if not counter:
            counter = VisitorCount(visitor=visitor, counter=0)
            counter.put()
        counter.counter += tallies[visitor]
        counter.put()
    return 'DONE (with %d task[s] logging %d visitor[s])\r\n' % (
            len(tasks), len(tallies))

تعديل المعالج الرئيسي باستخدام بيانات العرض الجديدة

لعرض أهم الزوّار، عدِّل المعالج الرئيسي root() لاستدعاء fetch_counts(). بالإضافة إلى ذلك، سيتم تعديل النموذج لعرض عدد أهم الزوّار وأحدث الزيارات. يجب تجميع عدد الزوّار مع أحدث الزيارات من المكالمة إلى fetch_visits() وإدراجها في context واحدة لتمريرها إلى نموذج الويب. في ما يلي الرمز البرمجي قبل إجراء هذا التغيير وبعده:

قبل:

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

بعد:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    context = {
        'limit':  LIMIT,
        'visits': fetch_visits(LIMIT),
        'counts': fetch_counts(LIMIT),
    }
    return render_template('index.html', **context)

هذه هي كل التغييرات المطلوبة من main.py، وفي ما يلي تمثيل صوري لهذه التعديلات لأغراض توضيحية من أجل منحك فكرة عامة عن التغييرات التي ستجريها على main.py:

ad5fd3345efc13d0.png

تعديل نموذج الويب باستخدام بيانات العرض الجديدة

يتطلّب نموذج الويب templates/index.html إجراء تعديل لعرض أهم الزوّار بالإضافة إلى الحمولة العادية لأحدث الزوّار. أدرِج أهم الزوّار وعدد زياراتهم في جدول في أعلى الصفحة، وواصِل عرض أحدث الزيارات كما كان من قبل. التغيير الوحيد الآخر هو تحديد الرقم المعروض من خلال المتغيّر limit بدلاً من الترميز الثابت للرقم. في ما يلي التعديلات التي يجب إجراؤها على نموذج الويب:

قبل:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>
<body>

<h1>VisitMe example</h1>
<h3>Last 10 visits</h3>
<ul>
{% for visit in visits %}
    <li>{{ visit.timestamp.ctime() }} from {{ visit.visitor }}</li>
{% endfor %}
</ul>

بعد:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>
<body>

<h1>VisitMe example</h1>

<h3>Top {{ limit }} visitors</h3>
<table border=1 cellspacing=0 cellpadding=2>
    <tr><th>Visitor</th><th>Visits</th></tr>
{% for count in counts %}
    <tr><td>{{ count.visitor|e }}</td><td align="center">{{ count.counter }}</td></tr>
{% endfor %}
</table>

<h3>Last {{ limit }} visits</h3>
<ul>
{% for visit in visits %}
    <li>{{ visit.timestamp.ctime() }} from {{ visit.visitor }}</li>
{% endfor %}
</ul>

بهذا نكون قد انتهينا من التغييرات اللازمة لإضافة استخدام مهام السحب في "قائمة انتظار المهام" في App Engine إلى نموذج التطبيق "الوحدة 1". يمثّل دليلك الآن نموذج التطبيق "الوحدة 18" ويجب أن يحتوي على الملفات التالية:

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

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

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

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

تأكَّد من إعداد قائمة انتظار السحب مسبقًا كما فعلنا بالقرب من أعلى هذا الدرس العملي باستخدام الرمز gcloud app deploy queue.yaml. إذا تم إكمال ذلك وأصبح نموذج تطبيقك جاهزًا، يمكنك نشر تطبيقك باستخدام gcloud app deploy. يجب أن يكون الناتج مطابقًا لتطبيق الوحدة 1 باستثناء أنّه يتضمّن الآن جدول "أهم الزوّار" في الأعلى:

b667551dcbab1a09.png

مع أنّ واجهة الويب الأمامية المعدَّلة تعرض أهم الزوّار وأحدث الزيارات، يجب العلم أنّ عدد الزوّار لا يشمل هذه الزيارة. يعرض التطبيق أعداد الزوّار السابقين مع إسقاط مهمة جديدة تزيد من عدد الزوّار هذا في قائمة انتظار السحب، وهي مهمة تنتظر المعالجة.

يمكنك تنفيذ المهمة من خلال استدعاء /log بعدة طرق:

على سبيل المثال، إذا كنت تستخدم curl لإرسال طلب استرداد بيانات باستخدام GET إلى /log، ستبدو النتيجة على النحو التالي، إذا قدّمت PROJECT_ID:

$ curl https://PROJECT_ID.appspot.com/log
DONE (with 1 task[s] logging 1 visitor[s])

سيظهر العدد المعدَّل عند زيارة الموقع الإلكتروني في المرة التالية. هذا كل شيء!

تهانينا على إكمال هذا الدرس التطبيقي حول الترميز بنجاح لإضافة استخدام خدمة قائمة انتظار السحب في App Engine Task Queue إلى نموذج التطبيق. أصبحت الآن جاهزة لنقل البيانات إلى Cloud Pub/Sub وCloud NDB وPython 3 في الوحدة التدريبية 19.

تَنظيم

للجمهور العام

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

للتوضيح، يؤدي النشر على منصة حوسبة بدون خادم في 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" إذا كان تطبيقك مستضافًا في الولايات المتحدة.

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

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

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

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

في عملية "نقل البيانات" هذه، أضفت استخدام قائمة انتظار الدفع في "قائمة انتظار المهام" إلى نموذج التطبيق 1، وذلك من خلال إضافة إمكانية تتبُّع الزوّار، وبالتالي تنفيذ نموذج التطبيق 18. في عملية نقل البيانات التالية، ستتم ترقية مهام السحب في App Engine إلى Cloud Pub/Sub. اعتبارًا من أواخر عام 2021، لم يعُد مطلوبًا من المستخدمين نقل البيانات إلى Cloud Pub/Sub عند الترقية إلى Python 3. يمكنك الاطّلاع على مزيد من المعلومات حول هذا الموضوع في القسم التالي.

للانتقال إلى Cloud Pub/Sub، يُرجى الرجوع إلى الدرس التطبيقي حول الترميز 19. بالإضافة إلى ذلك، هناك عمليات نقل بيانات إضافية يجب أخذها في الاعتبار، مثل Cloud Datastore أو Cloud Memorystore أو Cloud Storage أو Cloud Tasks (قوائم الانتظار). تتوفّر أيضًا عمليات نقل بيانات بين المنتجات إلى Cloud Run وCloud Functions. يمكن الوصول إلى جميع محتوى Serverless Migration Station (الدروس العملية والفيديوهات ورمز المصدر [عند توفّره]) من خلال مستودع المصدر المفتوح.

7. النقل إلى Python 3

في خريف 2021، وسّع فريق App Engine نطاق الدعم للعديد من الخدمات المجمّعة ليشمل أوقات التشغيل من الجيل الثاني (التي تتضمّن وقت تشغيل من الجيل الأول). نتيجةً لذلك، لن يُطلب منك بعد الآن نقل البيانات من الخدمات المجمّعة، مثل "قائمة انتظار المهام في App Engine"، إلى خدمات مستقلة من Cloud أو خدمات تابعة لجهات خارجية، مثل Cloud Pub/Sub، عند تكييف تطبيقك مع Python 3. بعبارة أخرى، يمكنك مواصلة استخدام Task Queue في تطبيقات Python 3 App Engine طالما أنّك تعدّل الرمز البرمجي للوصول إلى الخدمات المجمّعة من أوقات التشغيل من الجيل التالي.

يمكنك الاطّلاع على مزيد من المعلومات حول كيفية نقل استخدام الخدمات المجمّعة إلى Python 3 في الدرس العملي 17 والفيديو المرتبط به. على الرغم من أنّ هذا الموضوع خارج نطاق الوحدة التدريبية 18، إلا أنّ الروابط أدناه تتضمّن إصدارات Python 3 من تطبيق الوحدة التدريبية 1 الذي تم نقله إلى Python 3 ولا يزال يستخدم App Engine NDB. (في مرحلة ما، سيتم أيضًا توفير إصدار Python 3 من تطبيق Module 18).

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

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

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

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

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

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

Codelab

Python 2

Python 3

الوحدة 1

code

الرمز (غير وارد في هذا الدليل التعليمي)

الوحدة 18 (هذا الدرس التطبيقي حول الترميز)

code

لا ينطبق

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

في ما يلي مراجع ذات صلة بهذا البرنامج التعليمي:

قائمة انتظار المهام في App Engine

النظام الأساسي لـ App Engine

مستندات App Engine

وقت تشغيل Python 2 App Engine (البيئة العادية)

وقت تشغيل Python 3 App Engine (البيئة العادية)

الاختلافات بين أوقات تشغيل Python 2 و3 في App Engine (البيئة العادية)

دليل نقل البيانات من Python 2 إلى Python 3 في App Engine (البيئة العادية)

معلومات الأسعار والحصص في App Engine

إطلاق الجيل الثاني من منصة App Engine (‫2018)

الدعم الطويل الأمد لأوقات التشغيل القديمة

أمثلة على نقل المستندات

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

الفيديوهات

الترخيص

يخضع هذا العمل لترخيص المشاع الإبداعي مع نسب العمل إلى مؤلفه 2.0 Generic License.