عملية إنشاء "استضافة التطبيقات"

تستخدم Firebase App Hosting Cloud Build لتحويل رمز المصدر الخاص بتطبيقك إلى تنسيق حاوية مناسب للنشر على Cloud Run.

تتم عملية الإنشاء من خلال المراحل الرئيسية التالية:

  1. ubuntu: تهيئة مساحة العمل

  2. preparer: يجمع رمز المصدر وإعدادات تطبيقك.

  3. pre-buildpack: لإعداد بيئة حزمة الإنشاء

  4. build: لتثبيت التبعيات وإنشاء تطبيقك

  5. الناشر: يضع اللمسات الأخيرة على حاوية Cloud Run الإنتاج.

تتطابق هذه الخطوات الخمس مباشرةً مع خطوات الإنشاء كما هو موضّح في Cloud Build في وحدة تحكّم Google Cloud:

لقطة شاشة من عرض Google Cloud Console لخطوات Cloud Build

تهيئة Workspace

تتطابق هذه المرحلة مع خطوة إنشاء Ubuntu. تعمل هذه الخطوة على تهيئة مساحة عمل الإصدار، ما يضمن ضبط أذونات الملفات الصحيحة للأدلة المستخدَمة في خطوات الإصدار اللاحقة.

المُعدّ

هذه المرحلة مسؤولة عن معالجة منطق ما قبل الإنشاء. يقرأ هذا الإذن متغيّرات البيئة التي يحدّدها المستخدم ويعدّلها ويكتبها. ويؤدي أيضًا إلى إلغاء الإشارة إلى أي أسرار محددة في ملف apphosting.yaml وتثبيتها.

Pre-buildpack

تُعِدّ هذه الخطوة البيئة لدورة حياة Cloud Native Buildpacks. يتضمّن ذلك تشغيل طبقة وسيطة (shim) تترجم الإعدادات ومتغيرات البيئة التي تم إعدادها في المرحلة السابقة إلى التنسيق الذي تتوقّعه أدوات CNB.

إنشاء

هذه هي الخطوة الأساسية في عملية التصميم، وهي مسؤولة عن إنشاء صورة حاوية قابلة للتنفيذ وملف bundle.yaml يحدّد إعدادات التصميم. ويستخدم Cloud Native Buildpacks وlifecycle creator الثنائي لتعبئة التطبيق بكفاءة. يمكنك الاطّلاع على مزيد من المعلومات حول ملف bundle.yaml على GitHub.

تتولّى حِزم الإنشاء مسؤولية تحويل الرمز المصدر لتطبيقك إلى صور حاويات جاهزة للإنتاج. تجمع Firebase App Hosting عدة حِزم إنشاء معًا لإكمال عملية التصميم:

  1. حزمة الإنشاء في وقت التشغيل: تضمن تضمين جميع المكوّنات اللازمة لتشغيل تطبيق Node.js أساسي وتثبيت التبعيات.
  2. Monorepo Buildpack: تضبط هذه الحزمة حزم الإنشاء اللاحقة للتعامل مع سيناريوهات مختلفة في مستودع الرموز البرمجية الأحادي.

  3. حزمة الإنشاء الخاصة بإطار العمل: تثبِّت محوّل إطار العمل الصحيح (مثل Angular أو Next.js) وتجهّز حِزم الإنشاء اللاحقة.

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

  4. حزمة إنشاء مدير الحزم: تنفّذ عملية تثبيت التبعيات وتنشئ التطبيق باستخدام npm أو yarn أو pnpm.

  5. حزمة الإنشاء لحزمة الإخراج: تحدّد أمر التشغيل وتجهّز حزمة الإخراج للتنفيذ.

الناشر

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

إنشاء سياسة تنظيف

Firebase App Hosting تفرض سياسة مبرمَجة للاحتفاظ بعمليات الإنشاء وتنظيفها. بموجب هذه السياسة، يحتفظ App Hosting بعمليات الإنشاء الناجحة وعمليات Cloud Run المراجعة المرتبطة بها من آخر 14 يومًا. بالإضافة إلى ذلك، ولضمان توفّر إصدار يمكنك الرجوع إليه في أي وقت، يحتفظ App Hosting بآخر 5 إصدارات وعمليات طرح ناجحة بغض النظر عن تاريخها.

لن تحذف App Hosting أبدًا إصدارًا حاليًا في تقسيم حركة المرور النشط أو مرتبطًا بعملية طرح قيد التقدّم.

عندما تتجاوز الإصدارات القديمة حدود الاحتفاظ هذه، يتم تعديل حالتها الداخلية إلى EXPIRED. لا يمكنك إجراء عملية رجوع فوري إلى إصدار EXPIRED، وستتم إزالة خيار الرجوع إلى هذه الإصدارات من وحدة تحكّم Firebase. بدلاً من ذلك، عليك إنشاء إصدار جديد يستهدف المصدر نفسه (إما عملية git، أو حاوية في Artifact Registry، أو حزمة Google Cloud Storage) وطرح هذا الإصدار.

إحدى طرق الحفاظ على موارد الإنشاء هي التحكّم في عدد المرات التي يتم فيها تشغيل عمليات الطرح التلقائي. اطّلِع على كيفية إدارة عمليات الطرح التلقائي.

مزيد من المعلومات

إنّ App Hosting عملية التصميم بأكملها هي عملية مفتوحة المصدر.