حاليًا، عند إجراء أي نوع من الصيانة (باستثناء التحديث البسيط) ورغبةً في إيقاف الموقع أو تعيينه في وضع القراءة فقط، لا توجد طريقة لعرض رسالة للزوار توضح ما يحدث أو تقدير المدة التي قد يكون فيها النظام غير متاح.
سيكون من الجيد وجود وضع عدم اتصال شامل يسمح للإدارة بتقديم تحديثات الحالة ورسائل للزوار القادمين خلال فترة التوقف هذه، وذلك لإدارة التوقعات وجعل الزوار يشعرون بالرضا تجاه الموقف بدلاً من التساؤل عما قد يحدث.
لأغراض التوثيق، إليك التعليق الأصلي الذي أدى إلى هذا الانقسام وفقًا لـ @jomaxro:
ما يجب فعله حقًا هنا هو وضع عدم اتصال/صيانة متكامل يدمج هذه المنهجية مع إمكانية تقديم رسائل مخصصة للمستخدمين بينما يكون النظام في وضع عدم الاتصال و/أو الصيانة.
قد يكون هذا شيئًا مدمجًا في مدير الترقية (إعادة تسمية مدير الترقية إلى “مدير نظام Discourse” وجعل الترقيات والسجلات والعمليات والنسخ الاحتياطية جميعها معًا في هذا القسم).
سيؤدي ذلك إلى جعل النظام أقل هشاشة، وأكثر ودية وفائدة لكل من المدراء والمستخدمين.
لا يتسبب Docker Manager، وهو الإضافة الرسمية التي ندعمها للتحديثات، في أي توقف للخدمة. لا ينبغي أن يكون هناك حاجة لإجراء تغييرات على الإضافة، لأنها تدعم بالفعل التحديثات دون توقف. المشكلة التي يعالجها هذا الدليل howto هي التحديثات (إعادة البناء) التي تتم من سطر الأوامر. لا يُطلب هذه التحديثات إلا بشكل نادر، عدة مرات في السنة، عندما نحتاج إلى تحديث اعتمادية أساسية، مثل إصدار Ruby أو Postgres.
لا يمكن جعل Docker Manager يتعامل مع مثل هذه التحديثات، لأن Docker Manager، مثل جميع مكونات Discourse، يكون متوقفًا أثناء إعادة البناء. يجب أن تكون أي حل خارج نطاق Discourse، مثل حل وكيل Nginx الذي يوفره هذا الموضوع.
حسناً، أعتقد أن هناك خيارات أخرى هنا تتماشى بشكل أفضل مع طبيعة منصة Discourse… بدلاً من رفض هذه الفكرة، دعونا نتحدث عن سبل تحسين التجربة العامة في هذا الصدد، خاصة إذا اضطر المسؤول - لسبب أو لآخر - إلى إيقاف الموقع للصيانة.
فكرة تتبادر إلى ذهني: لماذا لا ندمج حل وسيط Nginx المذكور في المنشور الأصلي ضمن إعدادات Docker، لتصبح العملية أكثر قابلية للتنبؤ والإدارة والاتساق لكل من مستخدمي ومسؤولي Discourse وفريق الدعم (مثلكم هنا في المنتدى)، بدلاً من التعامل مع حلول غير مترابطة مثل الخيار المطروح هنا؟
إذا كنت ترغب في تقليل فترات التوقف أثناء تشغيل ./launcher rebuild app، فستحتاج إلى إعداد متعدد الحاويات.
هذا مُوثّق بالفعل، وهو إعداد أكثر تعقيدًا.
ولجعل أمر launcher rebuild في وضع حاوية واحدة مع عرض صفحة “غير متصل”، سيتعين علينا استبدال الحاوية بحاوية مخصصة خاصة بعنوان “الموقع غير متصل”. هذا ليس مستحيلاً، لكنه سيتطلب حوالي أسبوعين من العمل الهندسي لضمان عمله بشكل مثالي. ولا أعتقد أننا نستطيع تمويل هذا المشروع حاليًا، نظرًا لندرة إعادة بناء الحاوية، ولأن لدينا بالفعل طريقة مُوثَّقة لإجراء عمليات إعادة البناء دون انقطاع.
تتيح طريقة التثبيت المكونة من حاويتين عمليات ترقية بأقل وقت توقف ممكن في معظم الأحيان. أحيانًا، يؤدي بناء الحاوية الجديدة إلى عملية هجرة تُسبب انهيار الموقع قيد التشغيل. هناك طريقة لتجاوز ذلك، لكنها معقدة إلى حد ما، وهذه التحديثات تحدث نادرًا جدًا.
يمكنك أيضًا إعادة توجيه اسم النطاق (DNS) لديك (أو استخدام عنوان IP مرن أو ما يسميه Digital Ocean بذلك)، ثم تشغيل Droplet (أو ما يسميه AWS بذلك) يحتوي على خادم ويب يعرض رسالة الحالة الخاصة بك.
بالمناسبة @jomaxro، كيف قمت بفصل مشاركتي إلى هذا الموضوع الجديد هنا؟ ما هي الخطوات التي اتبعتها؟ سيكون من المفيد جدًا معرفة ذلك… لا أرى أي منهجية للقيام بذلك في Discourse الافتراضي.