الوحدة النمطية 5: الانتقال من Google App Engine إلى Cloud Run باستخدام Cloud Buildpacks

1. نظرة عامة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$ 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 أو أي منصة أخرى لاستضافة الحاويات. إذا كنت مهتمًا بمعرفة كيفية استخدام Docker لتغليف التطبيقات، يمكنك إجراء الدرس التطبيقي حول الترميز في الوحدة 4 بعد الانتهاء من هذا الدرس. وهي مطابقة لهذا البرنامج التعليمي، ولكنها تستخدم Docker لتمنحك فهمًا أعمق لكيفية إدارة صور الحاويات.

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

الوصف

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 تطبيقك تلقائيًا، ولكن لا يفعل Cloud Run ذلك. يؤدي Procfile دورًا مشابهًا لدور التوجيه app.yaml entrypoint. بالنسبة إلى نموذج تطبيقنا، سيتم تنفيذ Procfile python main.py لبدء خادم تطوير Flask. يمكنك أيضًا استخدام خادم ويب للإنتاج مثل gunicorn إذا أردت ذلك، وفي حال استخدامك له، احرص على إضافته إلى requirements.txt. يمكنك الاطّلاع على مزيد من المعلومات حول كيفية النشر من رمز المصدر باستخدام حِزم الإنشاء من صفحة مستندات Cloud Run هذه.

ما عليك سوى نقل توجيه app.yaml entrypoint إلى Procfile. إذا لم يكن لديك خادم، استخدِم خادم تطوير Flask في الوقت الحالي لأنّ هذا التطبيق هو مجرّد تطبيق اختبار نموذجي لتعريف المستخدمين بعملية نقل البيانات هذه. سيكون تطبيقك عبارة عن أمر بدء تشغيل محدّد تعرفه جيدًا. في الخلفية، تنشئ خدمة Cloud Run service.yaml يبدو/يتصرف بشكل أقرب إلى app.yaml. يمكنك الاطّلاع على service.yaml الذي تم إنشاؤه تلقائيًا من خلال الانتقال إلى رابط مشابه لهذا الرابط ولكن لخدمتك SVC_NAME وREGION: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view.

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

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

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

لا تتوافق حزم الإنشاء مع Python 2، لذا لن نتناولها هنا. تتشابه تطبيقات Python 3 التي تعمل في حاويات على Cloud Run مع تطبيقات Python 3 في App Engine من حيث ضرورة تحديد مكتبات الجهات الخارجية في requirements.txt.

التشغيل

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

runtime: python38
entrypoint: python main.py

تخبر التوجيه entrypoint App Engine بكيفية بدء تشغيل الخادم. يمكنك نقلها مباشرةً تقريبًا إلى Procfile. في ما يلي ملخّص لمكان وضع توجيه نقطة الدخول بين المنصّتَين، مع عرض ما يعادله في Docker أيضًا:

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

للاختبار والتجهيز، من السهل تشغيل خادم تطوير Flask من Python كما فعلنا أعلاه، ولكن يمكن للمطوّرين اختيار شيء أكثر فعالية للإنتاج، مثل نموذج التشغيل السريع في Cloud Run الذي يستخدم gunicorn.

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

تتوافق جميع تطبيقات الوحدة 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- التطوير والنشر

بعد استبدال إعدادات App Engine بـ Buildpacks وإكمال تحديثات ملف المصدر، يمكنك تشغيلها على 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 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 Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] 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

يجب أن يتطابق الرمز البرمجي الآن مع ما هو موجود في مجلد مستودع الوحدة التدريبية 5. تهانينا على إكمال الدرس التطبيقي العملي رقم 5 في هذه الوحدة.

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

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

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

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

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

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

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

  • الوحدة 4: نقل البيانات إلى Cloud Run باستخدام Docker
    • وضع تطبيقك في حاوية لتشغيله على Cloud Run باستخدام Docker
    • يتيح لك البقاء على Python 2
  • الوحدة 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 (البداية) والوحدة 5 (النهاية). يمكن أيضًا الوصول إليها من مستودع جميع عمليات نقل Codelab في App Engine الذي يمكنك استنساخه أو تنزيل ملف ZIP منه.

Codelab

Python 2

Python 3

الوحدة 2

code

(الرمز)

الوحدة 3

(الرمز)

code

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

(غير متوفر)

code

موارد App Engine وCloud Run

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