لكن للدقة، يجب أن أبدأ بالقول إنني جديد على المنصة وعلى قاعدة الكود، وبالتالي لا أعرف كيف تعمل عملية إعادة البناء حاليًا من الداخل. ومع ذلك، فإن فهمي الحالي هو أن إعادة البناء تقوم بما يلي:
إيقاف الحاوية الحالية
إنشاء حاوية جديدة باستخدام بيانات من شجرة المصدر
الانتظار حتى تقوم أنت بتشغيل الحاوية الجديدة
من منظور يركز على عمليات التطوير والتشغيل (DevOps)، لماذا لا يمكن بناء الحاوية الجديدة (ربما في فرع آخر أو مجلد مؤقت) بينما لا تزال الحاوية القديمة قيد التشغيل؟ يبدو أن هذا من شأنه أن يجعل عملية استبدال الحاوية الجديدة بال旧ة أسرع بكثير (على الأقل من حيث وقت التوقف)، ربما على مدار ثوانٍ بدلاً من دقائق.
إذا كانت الحاويات تستخدم وحدات تخزين لا يتم تدميرها عند إعادة بناء الحاوية، فأنا لست متأكدًا حتى من ضرورة معالجة تغييرات الإعدادات أو قاعدة البيانات (مثل الرسائل الجديدة) بشكل خاص في هذه الحالة، مما يعني أن بناء الحاوية لا يجب أن يكون مقترنًا بشكل وثيق بحالة الحاوية.
هل هذه ببساطة مسألة لم يوجه أحد انتباهه إليها بعد، أم أن هناك قرارًا معماريًا قائمًا يتطلب إيقاف حاوية واحدة قبل أن يمكن بناء حاوية أخرى؟
يعتبر التحديث الشامل (Rebuild) تحديثًا شاملًا يمكنه:
تحديث مصدر Discourse
تحديث تبعيات مستوى نظام التشغيل، مثل الإصدار الرئيسي من Ruby
الانتقال إلى إصدارات أحدث وغير متوافقة من PostgreSQL، حيث يتولى تحديث تنسيق قرص البيانات للإصدار الأحدث
تحديث صورة Docker. كمثال، في وقت سابق من هذا العام قمنا بالانتقال من Ubuntu 16.04 إلى أحدث إصدار من Debian، وجميع هذه التغييرات شفافة للمستخدم؛ ما عليك سوى كتابة ./launcher rebuild app.
لا تكون عمليات إعادة البناء ضرورية في كل الأوقات، بل تكون إلزامية فقط بضع مرات في السنة عند حدوث تحديث كبير للتبعيات. بالنسبة لجميع التحديثات الأخرى، يمكنك إجراء تحديثات بدون توقف (0 downtime) بالنقر على مُحدّث الويب في واجهة المستخدم الإدارية.
لمزيد من النقاط المتعلقة بـ “DevOps”، يمكنك تجربة:
قد أكون مخطئًا، لكنني أشعر أن سؤال @CodeGnome حول إعادة البناء دون توقف لا يزال يستحق مزيدًا من الاستقصاء.
إذا فهمت Docker بشكل صحيح، فيمكن إعادة بناء الجوانب التالية من Discourse في الخلفية داخل حاوية جديدة بينما لا تزال الحاوية الحالية تعمل:
تحديث مصدر Discourse
تحديث تبعيات مستوى نظام التشغيل، مثل الإصدار الرئيسي لـ Ruby
تحديث صورة Docker. كمثال فقط، في وقت سابق من هذا العام انتقلنا من Ubuntu 16.04 إلى Debian الأحدث، وكان كل ذلك شفافًا للمستخدم، فقط اكتب ./launcher rebuild app.
أما فيما يتعلق بالتغييرات المكسرة في PostgreSQL، فهي أكثر تعقيدًا بسبب حجم البيانات، والذي أفترض أنه مشترك بين الحاوية القديمة والجديدة.
ربما يمكن وضع الموقع في وضع القراءة فقط في بداية عملية إعادة البناء، مع احتفاظ الحاوية القديمة بحجم البيانات الحالي، بينما تعمل قاعدة البيانات قيد البناء داخل حجم Docker جديد؟
بالنسبة لتحديث مصدر Discourse، والاعتماديات على مستوى نظام التشغيل، وصورة Docker الأساسية، وروبي جيمز وما شابه، يمكن تحقيق ذلك عن طريق بناء التطبيق في خطوتين، مع تنفيذ المهام المذكورة أعلاه في الخطوة الأولى.
هذه الخطوة الأولى مستقلة عن البيئة ويمكن تشغيلها حتى في بيئة CI (وهو ما يعني أنه يمكن استخدام صورة متطابقة تقريبًا في بيئات الاختبار والإنتاج، مما يتجنب الأخطاء المحتملة الناتجة عن إعادة البناء في تواريخ مختلفة، ناهيك عن تقليل وقت التوقف).
لا تزال هجرات قاعدة البيانات ومهمة assets:precompile بحاجة إلى التنفيذ على الجهاز المستهدف. في معظم الحالات، ستكون هجرة قاعدة البيانات سريعة. من ناحية أخرى، تُعد مهمة assets:precompile مشكلة لأنها الخطوة التي تستغرق وقتًا أطول. أعتقد أن السبب في ذلك هو أن بعض الأصول تحتاج إلى معرفة بعض إعدادات البيئة كما هي مُعرَّفة في قاعدة البيانات، مثل بعض قواعد CSS، لتنفيذها.
سيكون ذلك رائعًا للغاية إذا تم تقسيم هذه المهمة إلى جزأين: حيث تُنفَّذ جميع الأصول التي لا تعتمد على البيئة أولاً، ويمكن تشغيلها في بيئة CI، وفي الخطوة الثانية يتم تجميع الأصول التي تعتمد فقط على أشياء في قاعدة البيانات وما إلى ذلك… ومع ذلك، لا أعرف مدى صعوبة تنفيذ ذلك تقنيًا.
أناقش بدء تشغيل حاوية التطبيق في خطوتين في الموضوع التالي:
كانت التغييرات التي قمت بها تقتصر فقط على تقسيم قالب Discourse Web إلى ثلاثة ملفات، لكن المهام تبقى نفسها، على الرغم من أنه سيكون رائعًا لو دعم فريق Discourse ذلك، حتى لا أحتاج إلى تحديثها بسبب التغييرات المستقبلية في قالب الويب.