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

1. نظرة عامة

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

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

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

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

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

المتطلبات

استطلاع

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

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

2. الخلفية

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

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

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

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

وفي هذا البرنامج التعليمي، ستتعلم كيفية وضع تطبيقك في حاويات وإزالة ملفات تهيئة App Engine وإدارة خادم ويب بما في ذلك كيفية بدء تشغيل تطبيقك.

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

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

3- الإعداد/التمهيد

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

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

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

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

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

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

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

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

تشمل خطوات نقل البيانات استبدال ملفات إعداد App Engine وتحديد كيفية بدء تطبيقك. في ما يلي جدول يلخّص ملفات الإعداد المتوقّعة لكل نوع من أنواع الأنظمة الأساسية. قارن عمود App Engine بعمود Buildpacks (واختياريًا إلى 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. يمكنك الاطّلاع على مزيد من المعلومات عن كيفية النشر من الرمز المصدر باستخدام حِزم Buildpack من صفحة مستندات 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 أو Cloud NDB). إذا أردت استخدام خادم HTTP آخر متوافق مع WSGI، مثل Gunicorn، وهو الإصدار الحالي في وقت كتابة هذا التقرير هو 20.0.4، أضِف gunicorn==20.0.4 إلى requirements.txt.

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

لا تتوافق حِزم Buildpacks مع Python 2، لذلك نحن لا نناقش ذلك هنا. تشبه تطبيقات Python 3 التي يتم تشغيلها في حاويات على Cloud Run تطبيقات Python 3 App Engine في أنّ مكتبات الجهات الخارجية يجب تحديدها في requirements.txt.

التشغيل

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

runtime: python38
entrypoint: python main.py

يوجِّه التوجيه entrypoint App Engine بكيفية بدء تشغيل خادمك. يمكنك نقله مباشرةً إلى جهاز Procfile. تلخيص المكان الذي ينتقل فيه توجيه نقطة الدخول بين كلا النظامين الأساسيين: يُترجم هذا مباشرةً إلى ما يلي؛ أيضًا عرض مكافئ Docker على سبيل المعلومات:

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

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

تطبيق findme

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

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

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

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

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

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

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

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

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

Codelab

Python 2

Python 3

الوحدة 2

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

(الرمز)

الوحدة 3

(الرمز)

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

الوحدة 5

(لا ينطبق)

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

موارد App Engine وCloud Run

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