الوحدة النمطية 11: الانتقال من Google App Engine إلى دوال السحابة

1. نظرة عامة

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

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

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

  • استخدام Cloud Shell
  • تفعيل Google Cloud Translation API
  • مصادقة طلبات البيانات من واجهة برمجة التطبيقات
  • تحويل تطبيق App Engine صغير لتشغيله على Cloud Functions
  • نشر الرمز في دوال Cloud

المتطلبات

استطلاع

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

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

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

حديث متوسط بارع

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

حديث متوسط بارع

2. الخلفية

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

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

الغرض من Cloud Functions هو نشر جزء صغير من الرمز البرمجي الذي:

  • ليس جزءًا من تطبيق كامل
  • غير مطلوبة في حزمة تطوير كاملة
  • مضمّنة في تطبيق أو خلفية واحدة لتطبيق للأجهزة الجوّالة تركّز على شيء واحد

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

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

  • الإعداد/التمهيد
  • إزالة ملفات الإعداد
  • تعديل ملفات التطبيق

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

يبدأ هذا الدرس التطبيقي حول الترميز بإصدار Python 3 من نموذج تطبيق App Engine على Cloud 2 Cloud NDB لأنّ Cloud Functions لا تتوافق مع Python 2. أولاً، لنقم بإعداد مشروعنا، ونحصل على الرمز، ثم ننشر التطبيق الأساسي للتأكيد على أننا نبدأ برمز يعمل.

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

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

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

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

سنبدأ باستخدام كود الوحدة 2 Python 3 الخاص بك أو المستخدم الخاص بنا. يرشدك الدرس التطبيقي حول ترميز الوحدة 11 هذا خلال كل خطوة، وينتهي بتعليمة برمجية تشبه ما هو موجود في مجلد Repo للوحدة 11 (FINISH).

يجب أن يبدو دليل بدء الوحدة 2 في بايثون 3 (ملفاتك أو ملفاتنا) على النحو التالي:

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

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

إليك الخطوات المتبقية لتنفيذ العمل المسبق الآن:

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

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

4. إزالة ملفات الإعداد

الملف app.yaml هو عنصر في App Engine لا يتم استخدامه مع دوال Cloud، لذا يمكنك حذفه الآن. إذا لم تفعل ذلك أو نسيت إجراء ذلك، لن يكون هناك أي ضرر لأن Cloud Functions لا تستخدمه. هذا هو التغيير الوحيد في الإعدادات، إذ يبقى requirements.txt مطابقًا لما هو عليه في الوحدة 2.

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

5- تعديل ملفات التطبيق

هناك ملف تطبيق واحد فقط، main.py، لذا تحدث جميع التغييرات اللازمة للانتقال إلى دوال السحابة في هذا الملف.

عمليات الاستيراد

نظرًا لأننا نعمل مع الدوال فقط، ليست هناك حاجة إلى إطار عمل لتطبيق الويب. ولتسهيل الأمر، عندما يتم استدعاء دوال السحابة الإلكترونية المستنِدة إلى لغة Python، يتم تلقائيًا تمرير كائن طلب إلى رمزك لاستخدامه عند الحاجة. (اختاره فريق Cloud Functions ليكون كائن "طلب Flask" تم تمريره إلى دالتك.)

بما أنّ إطارات عمل الويب ليست جزءًا من منظومة Cloud Functions، لن يتم إجراء أي عمليات استيراد من Flask إلا إذا كان تطبيقك يستخدم ميزات Flask الأخرى. هذه هي حالتنا لأنّ عرض النموذج لا يزال يحدث بعد التحويل إلى دالة، ما يعني أنّ طلب flask.render_template() لا يزال مطلوبًا، وبالتالي يتم استيراده من Flask. ما مِن إطار عمل على الويب يعني عدم الحاجة إلى إنشاء مثيل لتطبيق Flask، لذا احذف app = Flask(__name__). تظهر التعليمة البرمجية على النحو التالي، قبل تطبيق التغييرات وبعدها:

قبل:

from flask import Flask, render_template, request
from google.cloud import ndb

app = Flask(__name__)
ds_client = ndb.Client()

بعد:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

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

تعديل توقيع وظيفة المعالِج الرئيسي

في ما يلي التغييرات المطلوبة في توقيع الدالة:

  1. لم تعُد القارورة تُستخدَم بعد تحويل التطبيق إلى إحدى وظائف السحابة الإلكترونية، لذا عليك إزالة أدوات تصميم المسارات.
  2. تمرِّر دوال السحابة الإلكترونية تلقائيًا الكائن Flask Request كمَعلمة، لذا عليك إنشاء متغيّر له. في نموذج التطبيق، سنطلق عليه اسم request.
  3. يجب تسمية دوال السحابة الإلكترونية المنشورة. تمت تسمية المعالج الرئيسي root() بشكل مناسب في App Engine لوصف ما كان عليه (معالج تطبيق الجذر). ومن غير المنطقي استخدام هذا الاسم كدالة Cloud. بدلاً من ذلك، سننشر دالة Cloud باسم visitme، لذا عليك استخدامها كاسم للدالة في بايثون أيضًا. وبالمثل، في الوحدتين 4 و5، أطلقنا أيضًا اسم خدمة تشغيل السحابة الإلكترونية visitme.

في ما يلي الصورة المصغّرة قبل التعديل وبعده:

قبل:

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

بعد:

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

وبهذا نكون قد انتهينا من جميع التعديلات اللازمة. لاحظ أن التغييرات التي تم إجراؤها أثرت فقط في "البنية الأساسية" للتطبيق الرمز. ولا يلزم إجراء أي تغييرات في رمز التطبيق الأساسي، كما لم يتم تغيير أي من وظائف التطبيق. في ما يلي عرض تصويري للتغييرات التي تمّ إجراؤها لتوضيح هذه النقطة:

668f30e3865b27a9.png

التطوير والاختبار على المستوى المحلي

بينما يتضمّن App Engine خادم التطوير المحلي dev_appserver.py، لدى Cloud Functions إطار عمل الدوال التابع لها. ويمكنك من خلال إطار العمل هذا تطوير التطبيقات واختبارها محليًا. يمكن نشر الرمز البرمجي الخاص بك في Cloud Functions، ولكن يمكن نشره أيضًا على أنظمة الحوسبة الأساسية الأخرى، مثل Compute Engine أو Cloud Run أو حتى على الأنظمة السحابية المختلطة أو داخل مقر الشركة والتي تتوافق مع KNative. انظر أدناه للحصول على روابط إضافية إلى إطار عمل الدوال.

6- الإنشاء والنشر

تختلف عملية النشر في دوال Cloud قليلاً عن App Engine. ونظرًا لعدم استخدام أي ملفات إعداد خارج requirements.txt، يجب تحديد مزيد من المعلومات حول الرمز في سطر الأوامر. انشر دالة Cloud الجديدة التي يتم تشغيلها عبر HTTP والتي تعمل ضمن Python 3.10 باستخدام الأمر التالي:

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

يمكنك توقُّع الحصول على ناتج مشابه لما يلي:

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

بعد نشر الدالة، استخدِم عنوان URL من ناتج النشر وانتقِل إلى تطبيقك. يجب أن يكون عنوان URL بالشكل التالي: REGION-PROJECT_ID.cloudfunctions.net/visitme. يجب أن تكون النتيجة مماثلة لتلك التي سبق لك نشرها في App Engine:

2732ae9218f011a2.png

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

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

تهانينا على تحويل تطبيق App Engine الصغير هذا إلى دالة Cloud. هناك حالة استخدام أخرى مناسبة، ألا وهي تقسيم تطبيق App Engine متجانس كبير إلى سلسلة من الخدمات المصغّرة، كل منها كوظيفة في السحابة الإلكترونية. وهذا أسلوب تطوير أكثر حداثة ينتج عنه المزيد من "اللعب وتشغيل" (a la " JAM stack") يتيح ذلك المزج والمطابقة وإعادة استخدام الرمز البرمجي، وهما هدفان، ولكن هناك فائدة أخرى تتمثل في استمرار تصحيح الأخطاء في هذه الخدمات المصغَّرة بمرور الوقت، ما يعني أنّ الرموز الثابتة وتكاليف الصيانة أقل بشكلٍ عام.

تَنظيم

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

إنّ النشر على المنصات، مثل App Engine وCloud Functions يؤدي إلى تحمُّل تكاليف بسيطة لإنشاء المحتوى وتخزينه. في بعض المناطق، تمتلك خدمة Cloud Build حصتها المجانية الخاصة كما هي الحال في Cloud Storage. تستهلك الإصدارات بعض هذه الحصة. ننصحك بالانتباه إلى سعة التخزين التي تستخدمها للحدّ من التكاليف المحتمَلة، لا سيما في حال عدم توفّر هذا المستوى المجاني في منطقتك.

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

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

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

  • الوحدة 4: الانتقال إلى التشغيل في السحابة الإلكترونية باستخدام Docker
  • احتواء تطبيقك على حاويات لتشغيله على Cloud Run مع Docker
  • تتيح لك عملية النقل هذه البقاء على Python 2.
  • الوحدة 5: الانتقال إلى التشغيل في السحابة الإلكترونية باستخدام حِزم Cloud Buildpacks
  • توفير حاويات في تطبيقك لتشغيله على Cloud Runs مع حِزم Cloud Buildpacks
  • لست بحاجة إلى معرفة أي معلومات عن Docker أو الحاويات أو Dockerfile.
  • يتطلب نقل تطبيقك إلى Python 3 مسبقًا (Buildpacks لا تتوافق مع Python 2)

تركّز العديد من الوحدات الأخرى على توضيح كيفية الانتقال من خدمات App Engine المجمّعة إلى خدمات الاستبدال المستقلة في السحابة الإلكترونية للمطوّرين:

  • الوحدة 2: النقل من App Engine ndb إلى Cloud NDB
  • الوحدات 7-9: نقل المهام من قائمة انتظار مهام App Engine إلى "مهام السحابة الإلكترونية"
  • الوحدات 12-13: النقل من App Engine Memcache إلى Cloud Memorystore
  • الوحدات 15-16: النقل من App Engine Blobstore إلى Cloud Storage
  • الوحدات 18-19: النقل من قائمة انتظار مهام App Engine (سحب المهام) إلى Cloud Pub/Sub

إذا أصبحت الحاوية جزءًا من سير عمل تطوير التطبيقات، لا سيما إذا كانت تتألف من مسار CI/CD (التكامل المستمر أو العرض أو النشر المستمر)، ننصحك بنقل البيانات إلى التشغيل في السحابة الإلكترونية بدلاً من دوال Cloud. راجِع الوحدة 4 لتضمين تطبيقك مع Docker، أو الوحدة 5 للقيام بذلك بدون حاويات أو معلومات Docker أو Dockerfiles. سواء أردت استخدام Cloud Functions أو Cloud Run، فإنّ التبديل إلى نظام أساسي آخر بدون خادم هو أمر اختياري، لذلك ننصحك بالاطّلاع على أفضل الخيارات لتطبيقاتك وحالات الاستخدام قبل إجراء أي تغييرات.

بغض النظر عن وحدة نقل البيانات التي تفكر فيها بعد ذلك، يمكن الوصول إلى كل محتوى محطة النقل بدون خادم (الدروس التطبيقية حول الترميز والفيديوهات ورمز المصدر [عند توفّره]) من خلال مستودع البرامج المفتوحة المصدر. يوفّر README الخاص بالمستودع أيضًا إرشادات حول عمليات نقل البيانات التي يجب أخذها في الاعتبار وأي "طلب" ذي صلة. لوحدات النقل.

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

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

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

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

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

Codelab

Python 3

الوحدة 2

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

الوحدة 11

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

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

في ما يلي موارد على الإنترنت قد تكون ذات صلة بهذا البرنامج التعليمي:

App Engine

وظائف السحابة الإلكترونية

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

الفيديوهات

الترخيص

هذا العمل مرخّص بموجب رخصة المشاع الإبداعي 2.0 مع نسب العمل إلى مؤلف عام.