التعرّف على خدمة استضافة التطبيقات وطريقة عملها

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

دعم إطار العمل

App Hosting توفّر إمكانية إنشاء تطبيقات الويب ونشرها بدون الحاجة إلى ضبط الإعدادات ، وذلك إذا تم تطويرها باستخدام الأطر التالية:

  • الإصدار 13 من Next.js والإصدارات الأحدث
  • Angular 17.2 أو الإصدارات الأحدث

يحدِّد App Hosting الإطار الذي تستخدمه من خلال فحص ملف package-lock.json أو ملف قفل آخر في مستودعك. إذا حاولت نشر تطبيق Node.js لا يتضمّن ملف قفل، لن يتمكّنApp Hosting من إنشاء تطبيقك وتشغيله. يمكنك إنشاءpackage-lock.json من خلال تشغيلnpm install في الدليل الجذر.

App Hosting تلعب محوِّلات الإطارات دورَين رئيسيَين:

  1. وهي تُحلِّل الرمز المصدر وأي ملفات إعدادات خاصة بالإطار (مثل next.config.js) لفهم السلوك الذي تم ضبطه لتطبيقك.
  2. وتعمل هذه الأدوات على تنفيذ أمر إنشاء تطبيقك لإنشاء مواد عرض ثابتة وإنشاء إصدار محسّن من تطبيقك للإصدار العلني.

تُنشئ محوِّلات إطار العمل تطبيقك على Node.js باستخدام npm run build، وتعمل بشكل أفضل مع نصوص الإنشاء التلقائية لكل إطار عمل: next build لتطبيق Next.js و ng build لتطبيق Angular. سيحاول App Hosting إنشاء إصدارات باستخدام تعليمات برمجية مخصّصة لإنشاء الإصدارات، ولكن لا يمكنه ضمان النجاح بشكل موثوق.

آلية عمل دمج مستودع App Hosting

تتعامل أداة Developer Connect، وهي منصّة اتصال في Google Cloud لأدوات DevOps الخارجية، مع عملية الربط المهمة بين مستودع GitHub وApp Hosting الجانب الخلفي. أثناء إنشاء App Hosting خلفية، ترشدك سير عمل واجهة مستخدِم Developer Connect خلال عملية تثبيت تطبيق Firebase على GitHub. في ما يلي الخطوات الرئيسية في هذه العملية:

  1. يمكنك منح Developer Connect دور مشرف أداة إدارة الأسرار. ويسمح ذلك للنظام بتخزين بيانات الاعتماد بأمان كـ "أسرار" في Cloud Secret Manager.
  2. عليك منح تطبيق Firebase GitHub إذن الوصول إلى مستودع GitHub.
  3. تخزِّن أداة Developer Connect رمز مميّزًا لمنح الأذونات على GitHub في مستودع أداة إدارة الأسرار في مشروعك، ولا تعدِّل هذا الرمز المميّز أو تحذفه.

بالإضافة إلى ذلك، يتم دمج App Hosting مع واجهة برمجة التطبيقات GitHub checks API لتقديم فحص للعمليات الطرح. يتيح لك هذا الفحص الاطّلاع على حالة الطرح في GitHub وتحديد الأخطاء في عملية النشر وإصلاحها في حال حدوث أي أخطاء.

الدمج مع Firebase وخدمات Google الأخرى

App Hosting يُعدّ كلّ من بيئة الإنشاء وبيئة التشغيل لكي تتمكّن من تهيئة حزمة تطوير البرامج (SDK) الخاصة بمسؤول Firebase باستخدام "سمات اعتماد التطبيق التلقائية" من Google . بهذه الطريقة، يمكن للجزء الخلفي من تطبيقك التواصل مع منتجات Firebase الأخرى أثناء كلّ من مرحلة الإنشاء والنشر.

App Hosting موقع جغرافي

يؤدّي App Hosting النشر إلى إنشاء موارد الخلفية في موقع جغرافي محدّد. هذه المرونة في موقع تطبيق الويب لديك مزايا رئيسية:

  • تحسين الأداء وتقليل وقت الاستجابة من خلال تقريب البيانات جغرافيًا إلى المستخدمين
  • لن يؤثّر تعطُّل App Hosting بشكلٍ كبير في منطقة معيّنة على تطبيقات الويب التي تم نشرها في مناطق أخرى.

يمكنك اختيار أيّ من هذه المناطق عند إنشاء App Hosting خلفية من وحدة التحكّم أو Firebase واجهة سطر الأوامر:

  • us-central1 (أيوا)
  • asia-east1 (تايوان)
  • europe-west4 (هولندا)

حساب خدمة الخلفية App Hosting

أثناء عملية الإنشاء وفي وقت التشغيل، تتم مصادقة App Hosting الخلفية مع خدمات Google الأخرى باستخدام حساب خدمة. ويتم إنشاء حساب خدمة تلقائي لهذه الأغراض في المرة الأولى التي تفعّل فيها App Hosting في مشروع Firebase:

firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com

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

إذا كان تطبيقك بحاجة إلى التفاعل مع خدمات إضافية من Google إما في وقت الإنشاء أو من الخلفية، يمكنك تخصيص حساب الخدمة التلقائي من خلال إضافة الأدوار. على سبيل المثال، إذا كان تطبيقك يتطلّب أذونات لخدمة Vertex AI، قد تحتاج إلى إضافة roles/aiplatform.user أو دور ذي صلة.

المصطلحات والتعريفات الرئيسية

  • الخلفية: مجموعة الموارد المُدارة التي ينشئها App Hosting لإنشاء تطبيق الويب وتشغيله.
  • الطرح: إصدار محدّد من تطبيقك المنشور، مرتبط بعمليات الربط في git
  • الفرع المنشور: هو فرع مستودع GitHub الذي يتم نشره على عنوان URL المنشور. غالبًا ما يكون هذا هو الفرع الذي يتم دمج فروع الميزات أو فروع التطوير فيه.

القيود والمشاكل المعروفة

هناك بعض القيود المعروفة على معاينة App Hosting:

  • في بعض الحالات، قد تُظهر App Hosting الخلفية رسائل Intermittent connection error على عنوان URL لتطبيقك. سيتم توفُّر حلّ في إصدار لاحق.
  • تم تعديل رؤوس Cache-Control لتقييد ذاكرات التخزين المؤقت لشبكة CDN بمدة 60 ثانية. في المستقبل، عندما تصبح App Hosting قادرة على تنظيف ذاكرة التخزين المؤقت بسرعة عند النشر، سيتم رفع هذا الحدّ.
  • يتم تحسين الصور في Cloud Run تلقائيًا، ولا يتم الاحتفاظ بالصور المحسّنة. ننصحك بإيقاف ميزة تحسين الصور أو تحديد أداة تحميل يدويًا إلى أن يتوفّر حلّ أفضل.
  • يتم عرض الملفات الثابتة غير المخزّنة مؤقتًا من Cloud Run. وفي إصدار لاحق، سيتم تخزينها وعرضها من أصل App Hosting لتحسين الأداء.
  • قد لا يتم عرض رموز التخزين التعريفية الخاصة بـ "App Hosting" في صفحة استخدام الخلفية في وحدة التحكّم Firebase. وستتوفّر هذه الميزة في إصدار لاحق.
  • قد تعرض وحدة تحكّم Firebase بشكل متقطع رسالة الخطأ "لم يتم العثور على الإصدار وتكون غير صالحة" عند إنشاء الواجهة الخلفية.
  • في الوقت الحالي، تشترك جميع الخلفيات في المشروع نفسه في مؤسسة/حساب GitHub. ويمكن ربطها بمستودعات مختلفة ضمن تلك المؤسسة أو الحساب. لإنشاء خدمات خلفية مرتبطة بحسابات مختلفة على GitHub، ضعها في مشاريع منفصلة.
  • يتم تنفيذ الوسيط وعمليات إعادة التوجيه وعمليات إعادة الكتابة في Next.js في Cloud Run، خلف شبكة توصيل المحتوى (CDN). وبما أنّ هذه الإعدادات لن تحمي الاستجابات المخزّنة مؤقتًا، عليك التأكّد من ضبط توجيهات تحكُّم مناسبة للمحتوى الذي تعرضه.