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

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

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

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

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

  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 بعمليات الإنشاء الناجحة ومراجعاتها المرتبطة بها من آخر 14 يومًا.Cloud Run بالإضافة إلى ذلك، لضمان توفّر إصدار يمكنك الرجوع إليه في أي وقت، يحتفظ App Hosting بأحدث 5 إصدارات وعمليات طرح ناجحة بغض النظر عن تاريخها.

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

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

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

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

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