الوحدة النمطية 4: الانتقال من Google App Engine إلى التشغيل السحابي باستخدام Docker

1. نظرة عامة

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

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

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

  • تضمين تطبيقك في حاوية باستخدام Docker
  • نشر صور الحاويات على Cloud Run

المتطلبات

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

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

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

2. الخلفية

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

ومع ذلك، فإنّ مرونة الحاويات جذابة أيضًا، إذ تتيح إمكانية اختيار أي لغة وأي مكتبة وأي ملف ثنائي. توفّر خدمة Google Cloud Run للمستخدمين أفضل ما في الميزتين، أي سهولة استخدام الحوسبة بدون خادم ومرونة الحاويات.

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

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

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

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

  1. الإعداد/العمل التحضيري
  2. تضمين التطبيق في حاوية
    • استبدال ملفات الإعداد
    • تعديل ملفات التطبيق

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

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

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

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

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

من المتطلبات الأساسية لهذا الدرس التطبيقي حول الترميز أن يكون لديك نموذج تطبيق من الوحدة 2 أو الوحدة 3. إذا لم يكن لديك تطبيق، يُرجى إكمال أحد الأدلة التوجيهية/التعليمية (الروابط أعلاه) قبل المتابعة هنا. إذا كنت على دراية بمحتواه، يمكنك البدء مباشرةً بالحصول على رمز الوحدة 2 أو 3 أدناه.

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

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

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

إذا كنت تستخدم رمز الوحدة 2 (2.x) الخاص بك، سيكون لديك أيضًا مجلد lib. لا يتم استخدام lib أو appengine_config.py في Python 3، حيث يجب أن يبدو رمز START الخاص بالوحدة 3 (3.x) على النحو التالي:

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

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

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

  1. التعرّف من جديد على أداة سطر الأوامر gcloud
  2. إعادة نشر نموذج التطبيق باستخدام gcloud app deploy
  3. تأكَّد من أنّ التطبيق يعمل على App Engine بدون أي مشاكل

بعد تنفيذ هذه الخطوات بنجاح، ستكون جاهزًا لتضمين التطبيق في حاوية.

4. تجهيز التطبيق للحاويات

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

أنت في المكان المناسب إذا كنت تعرف الحاويات وDocker وتريد معرفة المزيد عن تحويل تطبيق App Engine إلى حاوية لاستخدامه في Cloud Run. يمكنك أيضًا تجربة الدرس التطبيقي حول الترميز في الوحدة 5 (وهو مطابق لهذا التمرين ولكن باستخدام Cloud Buildpacks) بعد ذلك. تطبيقنا النموذجي البسيط خفيف بما يكفي لتجنُّب بعض المشاكل المذكورة أعلاه في Dockerfile.

تتضمّن خطوات نقل البيانات استبدال ملفات إعدادات App Engine وتحديد كيفية بدء تشغيل تطبيقك. في ما يلي جدول يلخّص ملفات الإعدادات التي يجب توقّعها لكل نوع من أنواع الأنظمة الأساسية. قارِن عمود App Engine بعمود Docker (ويمكنك اختياريًا مقارنتهما بعمود Buildpacks):

الوصف

App Engine

Docker

حِزم الإنشاء

الإعدادات العامة

app.yaml

Dockerfile

(service.yaml)

المكتبات التابعة لجهات خارجية

requirements.txt

requirements.txt

requirements.txt

إعدادات الجهة الخارجية

‫app.yaml (بالإضافة إلى appengine_config.py وlib [الإصدار 2.x فقط])

(غير متوفر)

(غير متوفر)

التشغيل

‫(غير متوفر) أو app.yaml (في حال استخدام entrypoint)

Dockerfile

Procfile

تجاهُل الملفات

.gcloudignore و.gitignore

.gcloudignore و.gitignore و.dockerignore

.gcloudignore و.gitignore

بعد وضع تطبيقك في حاوية، يمكن نشره على Cloud Run. تشمل خيارات منصة الحاويات الأخرى في Google Cloud Compute Engine وGKE وAnthos.

الإعدادات العامة

تعني عملية نقل البيانات من App Engine استبدال app.yaml بـ Dockerfile يوضّح كيفية إنشاء الحاوية وتشغيلها. يبدأ App Engine تطبيقك تلقائيًا، ولكن لا يفعل Cloud Run ذلك. هذا هو الغرض من الأوامر Dockerfile ENTRYPOINT وCMD. يمكنك الاطّلاع على مزيد من المعلومات عن Dockerfile من صفحة مستندات Cloud Run هذه، بالإضافة إلى مثال على Dockerfile يؤدي إلى إنشاء gunicorn.

بدلاً من استخدام ENTRYPOINT أو CMD في Dockerfile، يمكنك استخدام Procfile. أخيرًا، يساعد .dockerignore في فلترة الملفات غير التابعة للتطبيق للحفاظ على صغر حجم الحاوية. سنتناول المزيد حول هذه الميزات قريبًا.

حذف app.yaml وإنشاء Dockerfile

لا يتم استخدام app.yaml في الحاويات، لذا احذفه الآن. ملف إعداد الحاوية هو Dockerfile، ولا يتطلّب نموذج تطبيقنا سوى ملف بسيط. أنشئ Dockerfile باستخدام هذا المحتوى، واستبدِل NNN بـ 2 أو 3، استنادًا إلى إصدار Python الذي تستخدمه:

FROM python:NNN-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
ENTRYPOINT ["python", "main.py"]

تحدّد معظم الأوامر في Dockerfile كيفية إنشاء الحاوية باستثناء ENTRYPOINT الذي يحدّد كيفية بدء الحاوية، وفي هذه الحالة يتم استدعاء python main.py لتنفيذ خادم تطوير Flask. إذا كنت مبتدئًا في استخدام Docker، يشير التوجيه FROM إلى الصورة الأساسية التي سيتم البدء منها، وتشير كلمة "slim" إلى الحد الأدنى من توزيع Python. يمكنك الاطّلاع على مزيد من المعلومات من صفحة صور Docker Python.

تنشئ مجموعة الأوامر الوسطى دليل العمل (/app)، وتنسخ ملفات التطبيق، ثم تشغّل pip install لإضافة مكتبات تابعة لجهات خارجية إلى الحاوية. يجمع WORKDIR بين الأمرَين mkdir وcd في نظام التشغيل Linux. يمكنك الاطّلاع على مزيد من المعلومات حول هذا الأمر في مستندات WORKDIR . إنّ التوجيهَين COPY وRUN لا يحتاجان إلى شرح.

المكتبات التابعة لجهات خارجية

يمكن أن يظل ملف requirements.txt كما هو، ويجب أن يكون Flask متوفّرًا مع مكتبة برامج Datastore (Cloud Datastore أو Cloud NDB). إذا كنت تريد استخدام خادم HTTP آخر متوافق مع WSGI، مثل Gunicorn (الإصدار الحالي في وقت كتابة هذا المستند هو 20.0.4)، أضِف gunicorn==20.0.4 إلى requirements.txt.

إعدادات الجهة الخارجية

يعرف مطوّرو تطبيقات Python 2 في App Engine أنّه يتم إما نسخ مكتبات الجهات الخارجية إلى المجلد lib أو الإشارة إليها في requirements.txt أو إدراجها في app.yaml أو إتاحتها من خلال appengine_config.py. لا تستخدم الحاويات، مثل تطبيقات Python 3 App Engine، سوى requirements.txt، لذا يمكن حذف كل العناصر الأخرى، ما يعني أنّه إذا كان لديك تطبيق App Engine 2.x، عليك حذف appengine_config.py وأي مجلد lib الآن.

التشغيل

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

يمكن لمستخدمي Python 3 تحويل ملفات app.yaml لتتضمّن entrypoint بدلاً من توجيهات script: auto في قسم handlers. إذا كنت تستخدم entrypoint في app.yaml Python 3، سيبدو بالشكل التالي:

runtime: python38
entrypoint: python main.py

تخبر التوجيه entrypoint App Engine بكيفية بدء تشغيل الخادم. يمكنك نقلها مباشرةً تقريبًا إلى Dockerfile (أو Procfile إذا كنت تستخدم Buildpacks [راجِع الوحدة 5] لتضمين تطبيقك في حاوية). في ما يلي ملخّص لمكان وضع توجيه نقطة الدخول بين النظامَين الأساسيَين:

  • Docker: السطر في Dockerfile: ENTRYPOINT ["python", "main.py"]
  • حِزم الإنشاء: السطر في Procfile: web: python main.py

لا بأس باستخدام خادم تطوير Flask للاختبار، ولكن إذا كنت تستخدم خادمًا متاحًا للجميع مثل gunicorn لتطبيقك، احرص على توجيه الأمر ENTRYPOINT أو CMD إليه كما هو الحال في نموذج التشغيل السريع في Cloud Run.

تجاهُل الملفات

ننصحك بإنشاء ملف .dockerignore لتقليل حجم الحاوية وعدم إثقال صورة الحاوية بملفات غير ضرورية مثل:

*.md
*.pyc
*.pyo
.git/
.gitignore
__pycache__

ملفات التطبيق

تتوافق جميع تطبيقات الوحدة 2 أو الوحدة 3 تمامًا مع Python 2-3، ما يعني أنّه لن يتم إجراء أي تغييرات على المكوّنات الأساسية في main.py، بل سنضيف فقط بضعة أسطر من رمز بدء التشغيل. أضِف سطرَين في أسفل main.py لبدء خادم التطوير لأنّ Cloud Run يتطلّب فتح المنفذ 8080 ليتمكّن من استدعاء تطبيقك:

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

5- التطوير والنشر

بعد إكمال تعديلات ملف المصدر وإعداد Docker، يمكنك تشغيل التطبيق على Cloud Run. قبل ذلك، سنتناول بإيجاز الخدمات.

الخدمات مقابل التطبيقات

على الرغم من أنّ App Engine تم إنشاؤه في الأساس لاستضافة التطبيقات، إلا أنّه يمثّل أيضًا منصة لاستضافة خدمات الويب أو التطبيقات المكوّنة من مجموعة من الخدمات المصغّرة. في Cloud Run، يُعدّ كل شيء خدمة، سواء كانت خدمة فعلية أو تطبيقًا يتضمّن واجهة ويب، لذا يجب اعتبار استخدامه على أنّه نشر لخدمة وليس تطبيق.

ما لم يكن تطبيق App Engine يتألف من خدمات متعددة، لم يكن عليك إجراء أي نوع من التسمية عند نشر تطبيقاتك. يتغيّر ذلك في Cloud Run حيث تحتاج إلى تحديد اسم خدمة. في المقابل، يتضمّن نطاق appspot.com في App Engine رقم تعريف المشروع، مثل https://PROJECT_ID.appspot.com، وربما يتضمّن اختصار رقم تعريف المنطقة، مثل http://PROJECT_ID.REGION_ID.r.appspot.com.

ومع ذلك، يتضمّن نطاق إحدى خدمات Cloud Run اسم الخدمة واختصار رقم تعريف المنطقة ورمز التجزئة، ولكن لا يتضمّن رقم تعريف المشروع، مثلاً https://SVC_NAME-HASH-REG_ABBR.a.run.app. باختصار، ابدأ في التفكير في اسم خدمة.

تفعيل الخدمة

نفِّذ الأمر أدناه لإنشاء صورة الحاوية ونشرها على Cloud Run. عندما يُطلب منك ذلك، اختَر منطقتك واسمح بالاتصالات غير المصادَق عليها لتسهيل الاختبار، ثم اختَر منطقتك حسب الاقتضاء حيث SVC_NAME هو اسم الخدمة التي تنشرها.

$ gcloud beta run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Dockerfile and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying new service... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision... Deploying Revision.
  ✓ Routing traffic...
  ✓ Setting IAM Policy...
Done.
Service [SVC_NAME] revision [SVC_NAME-00001-vos] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

انتقِل إلى عنوان URL المحدّد باستخدام المتصفّح للتأكّد من نجاح عملية النشر.

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

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

في حال استخدام هذا الخيار، احرص على اختيار اسم الخدمة نفسه SVC_NAME وREGION الاسم المطلوب، وليس خيار القائمة المفهرسة كما فعلنا بشكل تفاعلي أعلاه.

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

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

visitme app

من المفترض أن يتطابق الرمز البرمجي الآن مع ما هو موجود في مجلد مستودع الوحدة التدريبية 4، سواء كان 2.x أو 3.x. تهانينا على إكمال وحدة الدرس التطبيقي حول الترميز الرابعة.

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

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

اختياري: إيقاف الخدمة

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

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

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

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

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

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

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

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

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

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

Codelab

Python 2

Python 3

الوحدة 2

code

(الرمز)

الوحدة 3

(الرمز)

code

الوحدة التدريبية 4

code

code

موارد App Engine وCloud Run

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