الموقع خارج الخدمة عند تثبيت الإضافة

مرحباً، هل من الطبيعي أن يكون الموقع غير متاح عند تثبيت/تحديث السمات والإضافات؟

إعجاب واحد (1)

من الطبيعي أن يكون الموقع غير متاح عند إجراء إعادة بناء.\n\nالحلول هي استخدام تثبيت حاويتين، مما يسمح لك ببناء حاوية جديدة، بحيث يكون وقت التعطل أقل من دقيقة، أو اختلاق صفحة “سنعود قريبًا” لعرضها أثناء تعطل الموقع، مما لا يغير وقت التعطل، ولكنه يجعل الجميع يعرفون أنك على علم بتعطل موقعك.\n\nيعتقد الجميع أن أحد هذه الحلول على الأقل صعب للغاية ولا يستحق العناء على الإطلاق.

4 إعجابات

للتوضيح فقط، على عكس الإضافات، لن يتطلب تثبيت أو تحديث السمات ومكونات السمات أي وقت توقف. :+1:

4 إعجابات

هل هناك أي وثائق حول الطريقة التي ذكرتها؟ أيضًا، يبدو الأمر مثيرًا للسخرية نظرًا لأنها مناسبة جدًا لتحسين محركات البحث من حيث الخطاب، ولكن هناك انقطاع أثناء التحميل ولا يمكن لروبوتات جوجل الزحف إلى الموقع.

كم مرة تتوقع تثبيت إضافة جديدة؟ هذا عادة ما يكون حدثًا نادرًا جدًا.

يمكنك تحديث الإضافات عبر الإنترنت مع انقطاع بسيط في الخدمة عند تبديل الحاويات.

إعجابَين (2)

شكراً على الردود :saluting_face:

إعجاب واحد (1)

ألق نظرة على Add an offline page to display when Discourse is rebuilding or starting up عندما تشعر بالشجاعة.

إعجابَين (2)

مرحباً :wave: لست متأكداً وربما أكون مخطئاً (لم أجرب ذلك بعد) ولكن هل هذا الآن شيء أساسي؟ يوجد قالب جديد منذ بضعة أشهر في discourse/templates يسمى offline-page.template.yml وداخله يقوم بتشغيل GitHub - discourse/discourse-offline-page: offline page for discourse. وهو موقع HTML الثابت أثناء تحميل Discourse. يوجد أيضاً طلب سحب (PR) حول هذا الموضوع في discourse_docker FEATURE: add offline page template by featheredtoast · Pull Request #752 · discourse/discourse_docker · GitHub

3 إعجابات

يبدو أن هذا سيؤثر على نصفها فقط؟ سيظهر عند البدء، ولكن ليس عند إعادة البناء، إذا فهمت إعادة البناء بشكل صحيح:

إضافة قالب لسحب وتقديم ملفات HTML ثابتة من GitHub - discourse/discourse-offline-page: offline page for discourse عندما يكون nginx متاحًا، ولكن ليس rails.

^ طلب السحب الخاص بـ GitHub

إعجابَين (2)

ولكنها خطوة في الاتجاه الصحيح، شكرًا @Don@featheredtoast ! )

نعم @Firepup650 تساءلت لماذا لم أره، وأعتقد أنك أجبت على السبب!

لدي بعض :male_detective: :male_detective: الجيدة هنا! :slight_smile:

أتساءل عما إذا كانت هذه خطوة أولية لإعداد دائم قياسي للحاويات، حيث يتم بناء حاوية nginx بشكل منفصل؟!؟؟! :thinking:

إعجابَين (2)

لقد أمسكت بي - هناك بعض التحركات الجارية لجعل تقديم الصفحات غير المتصلة بالإنترنت ممكنًا على نطاق أوسع - الالتزامات والمستودعات المذكورة هي أساس لجعلها متاحة، لكنها ليست (بعد) في مكانها الآن.

5 إعجابات

لسبب ما، لا يرى أي من مستخدميَّ ذلك أثناء إعادة البناء. حسنًا، في الدردشة على أي حال، وهذا هو السبب في وقوع بعض الحوادث حيث فقد المستخدم رسالة مكتوبة للتو.

رأيي هو أن الوضع الذي لا نعلم فيه على الإطلاق عن وقت التوقف للمستخدمين الذين سجلوا الدخول بالفعل هو أكبر مشكلة تجربة مستخدم فردية في Discourse. بالتأكيد يمكنني فهم التفسيرات من طبيعة هذا التطبيق، وقد ورط المطورون أنفسهم نوعًا ما منذ البداية (مواقف مشابهة لتلك الخاصة بالمسودات وبعض الأشياء الأخرى)، لكن هذا لا يمحو المشكلة نفسها.

لدينا بعض الحلول البديلة. استخدام Nginx كوكيل عكسي أمام Discourse يعرض صفحة خطأ معدلة هو أحدها. وعندما يواجه المسؤول مشاكل، يكون الرد هو “نحن ندعم فقط النسخة القياسية”. كان هذا هو السبب الفعلي وراء تخلِّي عن ذلك.

حاويتان مختلفتان هو حل واحد. أو على الأقل فإنه يحافظ على وقت التوقف قصيرًا جدًا. هناك الكثير من التحذيرات بشأن ذلك، لذا أنا خائف قليلاً من سلوك هذا الطريق.

أو يمكننا الترقية في بعض الأحيان فقط، وإبلاغ المستخدمين قبل حدوث ذلك وإيقاف الوصول العام. نعم، هذا حل واحد، ولكن… الآن عام 2024 ونظام البنوك فقط يستخدم ذلك في بيئتي :smirking_face:

استخدام خادم تدريج هو شيء يجب القيام به. حسنًا، هذا حل على مستوى الشركات، مكلف وطريقة صعبة للغاية عند القيام بها بشكل صحيح، ويحب فريق تكنولوجيا المعلومات الخاص به.

لذا فإن الخطط الجديدة المتسربة :rofl: هي تحسن حقيقي بالفعل. حسنًا، إذا كانت تحتاج إلى حاويات منفصلة، فهناك وقت للغوص في العمق على ما أعتقد.

إعجاب واحد (1)

إنه نفس الشيء تمامًا باستثناء أنك تحتاج أحيانًا إلى إعادة بناء حاوية البيانات.

إعجاب واحد (1)

ولكن وقت التعطل أقصر بكثير من 20 دقيقة، أليس كذلك؟

إعجاب واحد (1)

قد تحتوي الدردشة على أشياء مختلفة عن العرض العادي للموقع حيث أعتقد أنها وصول في الوقت الفعلي مقارنة بالقدرة على تخزين الصفحات مؤقتًا.

أتفق. الصيانة المجدولة المعلنة في رأيي هي الأفضل كما في الأيام القديمة من لوحات الإعلانات التي تعمل بنظام DOS عبر الاتصال الهاتفي. كان هناك خيار لإرسال رسالة نظام تحذر من أن الصيانة المجدولة ستتوقف وستسجل خروج المستخدمين في الوقت المحدد. في تلك الأيام، كان ذلك عادةً لمعالجة حزم البريد بين لوحات الإعلانات المتصلة بالشبكة.

إعجاب واحد (1)

نعم. عادة ما يكون وقت التعطل أقل من دقيقة، ولكن ستحتاج إلى ذاكرة وصول عشوائي (RAM) أو مساحة تبديل كافية لإعادة بناء حاوية واحدة أثناء بناء الأخرى.

إعجاب واحد (1)