يعالج App Hosting سلسلة معقدة من المهام التي تعمل في الخلفية لتبسيط نشر تطبيقك. توضّح هذه الصفحة الأجزاء الرئيسية من تسلسل المهام، وتوفّر معلومات عن النقاط التي قد تحتاج فيها إلى تخصيص التسلسل استنادًا إلى احتياجات تطبيقك.
دمج إطار العمل
App Hosting توفّر إمكانية إعداد مُسبَق لعمليتي الإنشاء والنشر لتطبيقات الويب التي تم تطويرها باستخدام هذه الأطر:
- Next.js 13 أو إصدار أحدث
- Angular 17.2 أو الإصدارات الأحدث
يحدِّد App Hosting الإطار الذي تستخدمه من خلال فحص ملف
package-lock.json أو ملف قفل آخر في مستودعك. إذا حاولت
نشر تطبيق Node.js لا يتضمّن ملف قفل، لن يتمكّنApp Hosting من
إنشاء تطبيقك وتشغيله. يمكنك إنشاءpackage-lock.json من خلال تشغيلnpm
install في الدليل الجذر.
محوِّلات إطار العمل
App Hosting تلعب محدّدات الإطارات دورَين رئيسيَين:
- وهي تُحلِّل الرمز المصدر وأي ملفات إعدادات خاصة بإطار العمل (مثل
next.config.js) وتُنشئ حِزمة مخرجات يمكن معالجتها من خلال بقية البنية الأساسية لاستضافة التطبيقات. - وتعمل هذه الأدوات على تنفيذ أمر إنشاء تطبيقك لإنشاء مواد عرض ثابتة وإنشاء إصدار محسّن من تطبيقك للإصدار العلني.
تُنشئ محوِّلات إطار العمل تطبيقك على Node.js باستخدام npm run build، وتعمل بشكل أفضل
مع نصوص الإنشاء التلقائية لكل إطار عمل: next build لتطبيق Next.js و
ng build لتطبيق Angular. سيحاول App Hosting إنشاء إصدارات باستخدام تعليمات برمجية مخصّصة لإنشاء الإصدارات، ولكن لا يمكنه ضمان النجاح بشكل موثوق.
يتوفّر مصدر محوّلات Next.js وAngular في firebase-framework-tools.
أُطر عمل أخرى
بالإضافة إلى Nextjs وAngular، يتيح "استضافة التطبيقات" أيضًا استخدام أي إطار عمل ويب يمكنه توفير ناتج إنشاء يتطابق مع مواصفات حِزمة الإخراج. يمكن لمؤلفي الإطارات الاستفادة من مواصفات حِزم الإخراج لتأكيد توافق إطاراتهم مع ميزة "استضافة التطبيقات".
إذا أردت استخدام إطارات عمل إضافية متوافقة، يمكنك إنشاء محوِّل أو التواصل مع القائمين على إطار العمل لتحويل نتائج الإنشاء إلى تنسيق "استضافة التطبيقات". إنّ محوِّلَي Nextjs و Angular هما مثالان مرجعيّان جيدان لأيّ شخص ينشئ محوِّلاً.
يمكن العثور على الأطر المتوافقة على Firebase Open Source.
آلية عمل دمج مستودع App Hosting
تُجري أداة Developer Connect عملية الربط المهمة بين مستودع GitHub وApp Hosting الخلفية، وهي منصّة الربط في Google Cloud لأدوات DevOps الخارجية. أثناء إنشاء App Hosting خلفية، ترشدك سير عمل واجهة مستخدِم Developer Connect خلال عملية تثبيت تطبيق Firebase على GitHub. في ما يلي الخطوات الرئيسية في هذه العملية:
- يمكنك منح Developer Connect دور مشرف أداة إدارة الأسرار. ويسمح ذلك للنظام بتخزين بيانات الاعتماد بأمان كـ "أسرار" في Cloud Secret Manager.
- عليك منح تطبيق Firebase GitHub إذن الوصول إلى مستودع GitHub.
- تخزِّن أداة 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
ينطبق حساب الخدمة هذا على جميع الخلفيات تلقائيًا ويحتوي على الحد الأدنى من الأذونات للسماح لك بإنشاء تطبيقك وتشغيله ومراقبته. ويحتوي أيضًا على إذن للقيام بعمليات مثل تحميل البيانات من Cloud Firestore، وذلك من خلال مصادقة Admin SDK باستخدام بيانات الاعتماد التلقائية للتطبيق. اطّلِع على أدوار 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). وبما أنّ هذه التوجيهات لن تحمي الطلبات التي تم تخزينها مؤقتًا، احرص على ضبط توجيهات التحكّم المناسبة للمحتوى الذي يتم عرضه.