Cool good to know, thanks for your feedback
The first post says this
Is this the only way to do it? We don’t have nginx running outside docker
Yes, that’s the only way. The idea is to install a webserver (nginx recommended) to serve the request, if Discourse is up it routes it there. If not it does something else. All the installation process is explained step by step.
إعجابَين (2)
مرحبًا،
مقدمة
شكرًا لك على هذا الحل، @fefrei! لقد قمنا بتطبيقه على https://community.hiveeyes.org/ ويعمل بشكل ممتاز.
أفكار إضافية
ومع ذلك، نود الإشارة إلى السؤال ذي الصلة الذي طرحه @mlinksva على Site maintenance mode during rebuilds? هنا، حيث أن هذا الأمر يلامس همومنا أيضًا ولم يتم حله بعد عبر حل /errorpages. يتعلق الأمر بتحسين النص العام “عذرًا، لم نتمكن من تحميل هذا الموضوع، ربما بسبب مشكلة في الاتصال”. سنحاول توضيح ذلك بمزيد من التفصيل.
تقديم ملف discourse_offline.html
هذا مثالي عندما يزور المستخدمون الموقع لأول مرة.
تقديم نص مختلف لـ “عذرًا على ذلك”
لكن عند التصفح داخل Discourse، سيظهر لك رسالة مثل
دون الكشف عن أي شيء حول السبب.
وبما أننا نعرفك بالفعل، فغالبًا ما تكون هناك ميزة تخصيص تسمح بتغيير هذا النص، أليس كذلك؟ ربما فاتنا ذلك. كما أننا لم نفحص بعد ما إذا كانت الميزة المسؤول » النسخ الاحتياطي » تمكين وضع القراءة فقط ستحل هذه المشكلة بالفعل كما هو موضح في Maintenance Mode?.
ومع ذلك، بدا لنا من المنطقي طرح هذا الموضوع هنا مرة أخرى ونأمل ألا تمانع لو كان ذلك غير لائق.
مع أطيب التحيات،
أندرياس.
ملاحظة: @staff: بما أن هذه المناقشة خرجت عن السيطرة إلى حد ما فيما يتعلق بتفاصيل إعدادات Nginx أو خادم الويب المناسبة، أود اقتراح إعادة هيكلة شاملة من خلال تقسيم هذه المنشورات إلى موضوع يحمل اسمًا مناسبًا مثل “إعداد خادم الويب لصفحة عدم الاتصال”. أنا متأكد من أنك ستجد عنوانًا جيدًا. شكرًا مسبقًا إذا أعجبك هذا الاقتراح ووجدته يستحق المتابعة.
الآن، نشعر في الواقع بالغباء بعد اكتشافه فورًا كنص موقع قابل للتخصيص:
– https://community.hiveeyes.org/admin/customize/site_texts/js.topic.server_error.description
لقد قمنا بتغيير النص الافتراضي js.topic.server_error.description ليصبح:
شكرًا لاستماعكم ;].
3 إعجابات
همم. نحن غير متأكدين مما إذا كان تغيير هذا النص يعمل فعليًا بالنسبة لنا. هل يجب أن نأخذ في الاعتبار شيئًا خاصًا هنا عند تعديل هذا العنصر؟
أيضًا، نود أن نذكر أنه خلال نطاق زمني محدد بينما كان الموقع معطلاً، كان يعرض رسالة مختلفة مثل
هل لديك فكرة عن كيفية قدرتنا على تغيير ذلك أيضًا؟
إعجاب واحد (1)
أنا أستخدم ذلك، لكنني أريد صفحة ويب مخصصة تعمل دون اتصال بالإنترنت، وأنا غير قادر على تحقيق ذلك.
دليل رائع.
لكن لو كنت قد ذكرت بعض الأوامر لأتمتة تجديد هذه الشهادة أيضًا لكان الدليل مكتملاً.
لأنني رأيت الرابط المذكور هنا، لكنه يذكر فقط كيفية تثبيت الشهادة من جديد أو تجديدها يدويًا.
ولكنني لم أجد إرشادات حول “التجديد التلقائي” لها.
شكرًا لك.
إعجاب واحد (1)
نقطة جيدة! قمت بتحديث هذا القسم أعلاه في المنشور الأصلي 
إعجاب واحد (1)
هل لاحظ أي شخص آخر ظهور خطأ 500 عام أكثر عند حدوث الترقية؟ ربما صادفتها في وقت غير مناسب؟
إعجاب واحد (1)
عند إيقاف الحاوية أثناء إعادة البناء، لا توجد أي عملية نشطة لتقديم خطأ 500.
4 إعجابات
هل جرب أحدكم استخدام حاوية Docker أخرى لذلك لتجنب كل هذه الخطوات اليدوية، كما اقُترح في البداية؟
نعم، فعل الكثيرون ذلك. راجع Move from standalone container to separate web and data containers. يرجى ملاحظة أن استخدام حاويات منفصلة يتطلب إعدادًا أكثر تعقيدًا، كما أن العديد من الأدلة هنا على Meta تفترض تثبيتًا بحاوية واحدة (مستقلة). قبل الانتقال إلى حاويات منفصلة، تأكد من فهمك لوظيفة كل من الحاويتين، وكيف ستتعامل معهما في المستقبل. أهم نقطة: لن يكون app هدفًا صالحًا بعد الآن لأمر ./launcher.
5 إعجابات
هه، لا يزال هذا الموضوع يذكر “nginx في المقدمة” لسبب ما في منشورين…
بالمناسبة، ما أريده فعليًا هو:
- أن يكون هناك صفحة غير متصلة بالإنترنت نوقشت هنا
- إعادة توجيه http إلى https ومنطقة الجذر إلى www على خادم الويب الخاص بي. لا أريد استخدام Cloudflare لذلك لأن بعض عناوين IP الخاصة بها محظورة في روسيا.
لذا، كما أفهم الأمر، أحتاج فقط إلى معرفة كيفية القيام بذلك في حاوية الويب فقط 
الآن أنا مرتبك.
لا يتطلب أي من هذين الهدفين إعداد حاوية منفصلة. هل تبحث عن تكوين كلتا الخطوتين المذكورتين أعلاه، وفي الوقت نفسه تبحث عن حاويات منفصلة؟ أم أنك كنت تفكر في حاويات منفصلة معتقدًا أنها ضرورية لإكمال ما سبق؟
كما أفهم، لا يمكن أن يكون التعامل مع صفحة إعادة البناء (offline) في نفس الحاوية، لأنها لن تكون قيد التشغيل. لذا، فإن الحل المقترح في الموضوع الحالي هو إضافة nginx في المقدمة. ولكن كما تم مناقشته في هذا الموضوع، يتطلب ذلك العديد من الخطوات اليدوية ويعتمد على نظام التشغيل، لذلك اعتقدت أن استخدام حاوية Docker أخرى لهذا الـ nginx الأمامي سيكون أكثر موثوقية وأسهل في الصيانة.
آه، الآن فهمت. في هذه الحالة، تجاهل الموضوع الذي ربطت به سابقًا. ذلك الموضوع يناقش فصل خادم الويب الخاص بـ Discourse عن قاعدة البيانات. وهذا غير مطلوب هنا.
تثبيت Nginx في حاوية Docker، بدلاً من تثبيته مباشرة على نظام التشغيل، ممكن بالتأكيد، لكنني لا أعرف أي أدلة مخصصة لـ Discourse للقيام بذلك. إذا سلكتم هذا المسار، فتأكدوا من فهمكم لبداية هذا الموضوع (التغييرات الضرورية لإنشاء الصفحة غير المتصلة وتثبيت وكيل nginx أمامه)، وأنكم متمكنون من كيفية عمل Docker، خاصةً في تكوين الشبكات بين حاويتين Docker. لاحظوا أيضًا أننا قد نكون محدودين في المساعدة التي يمكننا تقديمها، حيث أن هذا ليس شيئًا لدينا خبرة في تنفيذه.
لقد أدركت أيضًا أن هذا لم يعد يعمل.
كانت قد طبقت نهج @fefrei في أوائل نوفمبر، وكان يعمل بالتأكيد في ذلك الوقت. ربما يكون السبب في أنني كنت أوقف الحاوية يدويًا وأقوم بسحب git بدلاً من استخدام /admin/upgrade.
إعجاب واحد (1)
تم تقسيم 4 مشاركات إلى موضوع جديد: إضافة دعم لصفحة غير متصلة بالإنترنت بشكل أصلي أثناء إعادة البناء
لقد قمنا بنفس الشيء مؤخرًا وتم تشغيل صفحة عدم الاتصال بنجاح.
في الوقت الحالي، قمنا مؤخرًا بالترقية عبر الإنترنت من خلال /admin/upgrade ووجدنا أن Discourse لم يذهب إلى وضع عدم الاتصال على الإطلاق! بغض النظر عما إذا كان هذا قد تحسن مؤخرًا أم لا، أو ما إذا كنا محظوظين هذه المرة، فمن الرائع رؤية ترقية عبر الإنترنت تحدث دون تجربة أي سلوك توقف كبير على الإطلاق.
يجب ألا يتوقف Discourse عن العمل أبدًا عند تشغيل التحديثات عبر Docker Manager (/admin/upgrade). هل يتوقف عادةً عن العمل بالنسبة لك؟ إذا كان الأمر كذلك، يجب أن نبدأ موضوع دعم # حول ذلك.