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

1. نظرة عامة

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

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

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

  • احتواء تطبيقك في حاويات باستخدام Docker
  • نشر صور الحاوية إلى التشغيل في السحابة الإلكترونية

المتطلبات

استطلاع

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

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

2. الخلفية

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

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

إنّ تعلُّم كيفية استخدام Cloud Run لا يندرج ضمن نطاق هذا الدرس التطبيقي حول الترميز. المشمولة في مستندات تشغيل Cloud. الهدف هنا هو معرفة كيفية إضافة تطبيق 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 هو المكان الذي سنبدأ فيه بإصدار بايثون 2 من هذا البرنامج التعليمي، وبالمثل، رمز الوحدة 3 لـ بايثون 3. يرشدك الدرس التطبيقي حول الترميز الخاص بالوحدة 4 خلال كل خطوة، واستنادًا إلى خياراتك، يُفترض أن ينتهي بك الأمر إلى رمز يشبه أحد مجلدات مستودع الوحدة التنظيمية رقم 4 (FINISH) عند الانتهاء.

يجب أن يبدو دليل بدء تشغيل الوحدة 2 في بايثون 2 (خاصة بك أو بنا) على النحو التالي:

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

إذا كنت تستخدم رمز الوحدة 2 (2.x) الخاص بك، سيكون لديك أيضًا مجلد lib. لا يتم استخدام lib أو appengine_config.py في Python 3، حيث يجب أن يبدو رمز بدء الوحدة 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 فعّال، وهو ملف الإعداد الذي يحدّد كيفية إنشاء صور الحاويات. من ناحية أخرى، تتطلّب حِزم تطوير البرامج (Buildpacks) القليل من الجهد لأنّها تستخدِم التأمل الداخلي لتحديد اعتماديات تطبيقك، ما يجعل حاوية Buildpacks فعّالة قدر الإمكان لتطبيقك.

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

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

الوصف

محرك التطبيقات

مدقّق

حِزم إنشاء

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

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. هذا هو الغرض من الأمرَين ENTRYPOINT وCMD في Dockerfile. يمكنك التعرّف على مزيد من المعلومات حول Dockerfile من صفحة مستندات تشغيل Cloud هذه، بالإضافة إلى الاطّلاع على مثال 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" يشير إلى الحد الأدنى من توزيع بايثون. تعرَّف على مزيد من المعلومات من خلال صفحة صور Docker Python.

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

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

يمكن أن يبقى ملف requirements.txt كما هو، يجب أن يتوفّر Flask مع مكتبة برامج Datastore (مخزن البيانات في Cloud أو 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 في Python 3 app.yaml، ستظهر على النحو التالي:

runtime: python38
entrypoint: python main.py

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

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

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

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

ننصحك بإنشاء ملف .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 يتكون من خدمات متعددة، فلن تكون هناك حاجة إلى تسمية هذا التطبيق عند نشر تطبيقاتك. يتغيّر ذلك مع تشغيل السحابة الإلكترونية حيث يجب عليك التوصل إلى اسم خدمة. بينما يعرض نطاق 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. إذا انتقلت إلى هذه السلسلة بدون المشاركة في أيّ من الدروس التطبيقية السابقة حول الترميز، لن يتغيّر التطبيق نفسه. تسجِّل هذه الأداة جميع الزيارات إلى صفحة الويب الرئيسية (/) وتبدو على هذا النحو بعد زيارتك للموقع مرات كافية:

تطبيق findme

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

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

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

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

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

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

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

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

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

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

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

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

Codelab

Python 2

Python 3

الوحدة 2

الرموز البرمجية

(الرمز)

الوحدة 3

(الرمز)

الرموز البرمجية

الوحدة 4

الرموز البرمجية

الرموز البرمجية

موارد App Engine وCloud Run

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