لاحظت أن مهمة rake assets:precompile تتطلب اتصالاً بقاعدة البيانات: وهذا يعني أنه لا يمكن تشغيل المهمة إلا في وقت “التشغيل” (بعد النشر) وليس في وقت “البناء” (أثناء بناء صورة الحاوية). وبما أن المهمة مكلفة جداً من حيث وقت التشغيل، فقد يكون ذلك مزعجاً.
وبما أنني لست مطور Ruby/Rails، قمت ببعض البحث ووجدت أنه يمكن تعطيل هذا السلوك حتى إصدار Rails 4، بينما لجأ المطورون بعد ذلك إلى بعض الحلول البديلة (اتصال قاعدة بيانات فارغ). وبالطبع يتطلب الحل الأخير معرفة عميقة بالتطبيق لتجنب كسر أي شيء.
وعند البحث عن حل أفضل، عثرت على هذا الالتزام الذي يبدو مشابهاً في روحه. لذا، أسئلتي هي:
هل يعمل المطورون بالفعل على هذه المسألة، أم أن هناك أسباباً تقنية تمنع ذلك؟
إذا كانت بعض أجزاء المهمة تتطلب بالفعل اتصالاً بقاعدة البيانات، فهل من الممكن تقسيم المهمة إلى جزأين (أو أكثر) بحيث يمكن إنجاز بعض الأعمال (مثل تجميع الملفات المحلية، وتصغير ملفات JS و CSS) في وقت البناء؟
هل هناك حل بديل معروف في الوقت الحالي (مثل “قاعدة بيانات فارغة” المذكورة أعلاه)؟
نحن نخزن السمات في قاعدة البيانات (يتم تحريرها في واجهة مستخدم المسؤول) لذا فإن CSS موجود داخل PostgreSQL، مما يعني أنك تحتاج إلى اتصال قاعدة البيانات في وقت البناء لتمكين تجميعها مسبقًا.
هل من الممكن التفكير في تنفيذ بناء اللغات بشكل منفصل (ليتم تشغيله وقت البناء)؟
أيضًا، أتخيل أن بعض البيئات (وهذا ينطبق علي على الأقل) قد لا ترغب في السماح بتغيير السمات: هل من الممكن توفير بديل لتخزين ملفات CSS في هذه الحالة؟
لقد ناقشنا فكرة إضافة مفتاح لإيقاف واجهة تخصيص المستخدم بالكامل، مما يسمح بترجمة ملفات CSS وقت البناء ورفعها إلى تخزين الكائنات خلال عملية البناء (أي نفس طريقة عمل نواة JavaScript والإضافات).
ومع ذلك، فإن هذا حالة ضيقة جدًا، ولن تجذب سوى بيئات النشر من فئة المؤسسات، بينما لا تقدم أي قيمة لـ 99% من المجتمعات على الويب. لذا، فإن هذا الإجراء غير مدرج في خارطة طريقنا، كما أنه من الصعب جدًا تبرير تخصيص جهد له على حساب تطوير ميزات جديدة أو تحسين الأداء.
هل يمكنك إخبارنا المزيد عن بيئتك وحالة الاستخدام الخاصة بك؟
حسنًا، عندما أقوم ببناء الصورة، أعمل على حاسوبي المحمول الخاص بالتطوير. ثم تُرفع الصورة إلى مستودع، ويقوم النظام النهائي (الخادم الافتراضي الخاص VPS على DigitalOcean) بسحبها من هناك.
توجد قاعدة البيانات في مجلد على الخادم الافتراضي الخاص VPS، لذا لا يمكن تحديثها على حاسوبي المحمول: سيتطلب ذلك مني إيقاف discourse، ومزامنة قاعدة البيانات باستخدام rsync إلى حاسوبي المحمول، وبناء الصورة ودفعها، وأخيرًا إعادة تشغيل discourse…
إذن هل تقوم بتشغيل قاعدة البيانات والتطبيق معًا داخل قطرة واحدة؟
في هذه الحالة، الالتزام بـ دليل التثبيت الرسمي الخاص بنا، والذي يؤدي إلى إنشاء قطرة تحتوي على التطبيق وقاعدة البيانات معًا في نفس القطرة، سيمنحك موقعًا يعمل بالكامل، ويمكن تحديثه من واجهة الويب، واختياريًا من سطر الأوامر مع إعادة بناء صورة كاملة.
إذا كنت تقصد بذلك “مباشرة على المضيف”، فالجواب لا. فهي تعمل داخل حاوية، وتحديدًا حاوية podman. في الوضع المثالي، سأقوم بتقسيم الحاوية إلى عدة حاويات (واحدة لـ Discourse، وواحدة لـ PostgreSQL، وواحدة لـ Redis…)، لكن هذا يرتبط بالقضية التي نناقشها، لذا لا تزال لدي شكوك حول المسار الصحيح للإجراء.
يبدو لي ذلك غير آمن. فعادةً ما أقوم باختبار الحاويات في بيئة التطوير الخاصة بي قبل نشرها في بيئة الإنتاج. علاوة على ذلك، من الأفضل أن تكون الحاويات للقراءة فقط.
يمكنك تقسيم هذه الحاويات ثم تشغيل عملية تهيئة الصورة في قطرة أخرى قصيرة الأجل. نظرًا لأن القطرات تُفرض رسومًا عليها على أساس ساعي، فستكون هذه العملية رخيصة. يمكنك حتى الاستفادة من الشبكة الخاصة للقطرات بين مضيف حاوية قاعدة البيانات ومضيف حاوية “البناء”.
هاها، شكرًا لك على الفكرة، لكن هذا سيصبح معقدًا. علاوة على ذلك، لن يحل المشكلة، لأننا ما زلنا بحاجة إلى إيقاف ديسكورد (Discourse) والانتظار حتى تكتمل عملية التمهيد (bootstrap)، وإلا فقد تظهر بيانات غير متسقة.
يبدو أننا سنضطر إلى تقبل فترة توقف طويلة (5-6 دقائق للهجرة والتجميع المسبق) عند الترقية. ومع ذلك، سأقدّر لو أنكم أنشأتم قضية ذات أولوية منخفضة في المتتبع، ربما مع رابط لهذا الموضوع.
جيد أن نعرف، شكرًا لك. في هذه الحالة، سأقوم حتمًا بفصل الحاويات، وهو بنية أفضل على أي حال.
ومع ذلك، لا أرى كيف يُحدث هذا فرقًا؟ إذا لم أكن مخطئًا، فستشارك جميع الحاويات جميع وحدات المعالجة المركزية للمضيف (ما لم يتم تكوينها خلاف ذلك)، لذا يجب أن تُنفَّذ العمليات بالتوازي في الحالتين. هل أغفلت شيئًا؟
سيستمر تشغيل الحاوية القديمة أثناء إعداد الحاوية الجديدة. بعد ذلك، يمكنك إيقاف الحاوية القديمة بسرعة وبدء تشغيل الحاوية الجديدة، مما يقلل من وقت التوقف.