حدث خطأ في تحديثاتي
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
يرجى مساعدتي في إصلاحه.
مرحباً!
أنا لا أجيب على سؤالك، أنا فقط أودّ معرفة السبب. لماذا تعتقد أنك بحاجة إلى صفحة صيانة؟ يبدو الأمر مزعجاً جداً لإعداده مقابل فائدة ضئيلة.
خوادماتي تتوقف عن العمل لمدة خمس دقائق شهرياً للتحديثات، وهذا كل شيء.
كلما قمت بإجراء تغييرات كبيرة، مثل تثبيت الإضافات على سبيل المثال، كان الأمر يستغرق أحياناً 20 دقيقة.
ليس أمراً كبيراً إذا أخذنا في الاعتبار أن هذه التغييرات لا تُجرى كل أسبوع أو حتى كل شهر، لكن بالنسبة لزيّار جديد، فإن تلك الصفحة القبيحة التي تشير إلى أن شيئاً ما لا يعمل، لا تترك انطباعاً أولياً جيداً. وحتى بالنسبة للزوار العائدين الذين لا يدركون أن الموقع سيكون غير متاح، فقد يدفعهم ذلك إلى “وضع الذعر” معتقدين أن المجتمع بأكمله قد تم إغلاقه أو شيء من هذا القبيل، وربما يرسل بعضهم ليّ رسائل بريد إلكتروني على الفور يسألون فيها عما يحدث.
أعتقد أن هذا مجرد لمسة لطيفة نقدمها للزائر، سواء كان جديداً أم قديماً، لإعلامه بما يحدث.
إذا كان النهج الذي اقترحه كلود يستغرق بضع دقائق فقط، لكنه لا يحتاج إلى تعديل مرة أخرى، فأعتقد أن الوقت قد استُخدم بشكل جيد.
يستغرق الأمر ثوانٍ فقط إذا انتقلت إلى تثبيت الحاويتين المنفصلتين.
يمكنك حتى جدولة عملية التحويل ليلاً إذا كنت ترغب في ذلك حقاً، بينما أنت و/أو جمهورك الأساسي نائمون.
لا تحتاج إلى صفحة صيانة.
أستخدم بناء الحاوية المزدوجة خلف شبكة توصيل المحتوى (CDN) من Cloudflare. يقلل استخدام الحاوية المزدوجة من وقت التوقف، وكلا منتديي الإنتاج الرئيسيين لديّ لا يتجاوزان 30 ثانية من وقت التوقف أثناء إعادة البناء. أحب وجود صفحة صيانة لأن صفحة الخادم الافتراضية عند التوقف قبيحة ولا تقدم أي مؤشر حول المدة التي سيظل فيها الموقع غير متاح.
التوثيق اللازم لفعل ذلك متاح الآن هنا:
واو! أنا حقاً أقدر هذا الشرح التفصيلي! 
لقد قمت刚才 بحفظ ردك في ملاحظاتي، لذا عندما أقوم بتثبيت Discourse مرة أخرى قريباً، سأعود إليه. سأخبرك بالتأكيد كيف سارت الأمور، حتى لو استغرق الأمر بعض الوقت حتى أقوم بتثبيته. أنا أنهي بعض الأمور المتعلقة بالبرمجة في الوقت الحالي، وسأركز على Discourse مرة أخرى بعد ذلك.
وأوافق على أن صفحة “خادم الويب متوقف” قبيحة، وبالنسبة للمستخدمين غير المتمرسين، هذه الرسالة لا تعني الكثير. وجود صفحة صيانة بسيطة مع رسالة مخصصة، هو دائماً أفضل، حتى لو كان ذلك يتطلب بعض الجهد في الإعداد.
مرة أخرى، شكراً جزيلاً لك جداً على تخصيص الوقت لمشاركة هذا. آمل أن يجد آخرون هذا مفيداً 
وهنا تكمن المشكلة.
إنه ليس تغييراً بسيطاً، كما أنه يتطلب بنية تحتية إضافية تحتاج إلى الاهتمام والصيانة، وفي رأيي الشخصي، لا تستحق العناء إطلاقاً لتجنب بضع ثوانٍ من توقف الخدمة.
أفهم ما تقصد، لكن هذا مجرد حالة واحدة. ماذا لو حدث خلل حقيقي وتطلبت إصلاحه أكثر من بضع ثوانٍ؟
أيضًا، كيف تحصل على بضع ثوانٍ من وقت التوقف بينما كنت أرى حوالي 20 دقيقة، بعد تثبيت الإضافات؟
لأنه في إعداد الحاويتين (المشار إليه في كل من منشورينا ويعتبر اعتمادًا غير قابل للتفاوض)، تقوم بتهيئة الإصدار الجديد باستخدام الأمر ./launcher bootstrap web_only (حيث يظل موقعك يعمل بنسبة 100% خلال هذه العملية)، ثم تقوم ببساطة بتدمير الحاوية القديمة وإطلاق الحاوية الجديدة التي تم بناؤها بالفعل فورًا (وهو ما يستغرق بضع ثوانٍ فقط).
أوه، حسناً، هذا لا يزال يتعلق بإعداد الحاويات الثنائية. ظننت أنك تقول إن بناء إعداد الحاويات الثنائية بالكامل لا يستحق الجهد. ما تقوله هو أن العمل الإضافي الخاص بصفحة الصيانة هو ما لا يستحق الجهد، أليس كذلك؟
شخصياً، نعم.
إذا كنت تريد ضمانات إضافية للمشاهدين عبر الويب الذين يظهر لديهم تنقل جديد خلال الـ 30 إلى 60 ثانية، فإن صفحة الصيانة معقولة.
يجب عليك الموازنة بين فائدة ذلك والوقت اللازم لصيانة البنية التحتية المحيطة به.
الآن فهمت. شكراً.
إذن، السؤال الآن هو: مع وجود حاويتين، لا تزال فترة الـ20 دقيقة تقريباً قائمة، والفرق الوحيد هو أنني يمكنني تركها تعمل على إحدى الحاويتين، تلك التي ليست نشطة، وعندما تكون جاهزة، أقوم بالتبديل. هل هذا هو كيفية عملها؟
نعم، لا يزال الأمر يستغرق بعض الوقت لبناء الحاوية. ولعلمك، يجب أن تتأكد من أن خادمك قوي بما يكفي للسماح بحدوث هذه العملية بالتوازي مع خدمة مجتمعك بشكل طبيعي (والأهم من ذلك هو ضمان وجود ذاكرة كافية في البداية - لذا من المهم جداً التأكد من وجود مساحة SWAP كافية). كما أن عملية البناء ستستهلك نواة واحدة على الأقل، لذا فكّر في استخدام خادم يحتوي على نواتين إضافيتين.
ويبدو أن الخادم أقل فعالية…؟أوصي باستخدام 4 جيجابايت على الأقل و3 نوى (“vcpu”) لهذا النوع من الإعدادات …
للمرجع، كما طُرح في موضوع آخر، الإجابة (تعديل: خاطئة): Any cheaper alternatives to Hetzner? - #2 by Canapin
هذا هو الوحيد الذي يطابق ذلك… ما الفرق في السعر…
أعتقد أنني سأضطر الآن إلى بنائه باستخدام حاوية واحدة، وعندما يحين الوقت (
)، سأقوم بالترقية.
شكراً لك على المعلومات، روبرت!
أنا لا أوافق وأعتقد أنها تستحق صفحة الصيانة. في تجربتي، عندما يرى الأشخاص صفحة خطأ Discourse، فإن أول شيء يفعلونه هو الضغط على زر التحديث، وعندها سيرون صفحة الصيانة المؤقتة التي ستقوم تلقائيًا بإعادة تحميل الموقع عند اكتمال تبديل الحاوية. لا يتطلب الأمر الكثير من الجهد لإعدادها، وعليك القيام بذلك مرة واحدة فقط. أثناء إعادة البناء باستخدام تكوين الحاويات المزدوجة، يحدث جزء التمهيد في الخلفية ويمكن للمستخدمين الاستمرار في استخدام الموقع؛ إن تبديل الحاوية هو ما يسبب انقطاع الخدمة المؤقت (على عكس تكوين الحاوية المفرد القياسي).
تكلفة الخادم واختياره أمر مختلف تمامًا وينبغي أن يكون في موضوع منفصل آخر.
أعتقد أنني الآن في المنتصف. أفهم ما تقصد، وكذلك @merefield. إنها لمسة لطيفة أن يكون الأمر كذلك، وإذا تم ضبطه مرة واحدة فقط، فلا أعتقد أن الأمر كبير؟
في الوقت نفسه، إذا استغرق الأمر حقًا ما يصل إلى 60 ثانية، في أسوأ سيناريو، فإن الجميع لن يزور الموقع في الثانية صفر بالتحديد ويضطر للانتظار 60 ثانية. سيرى بعض الأشخاص الصفحة غير الجميلة لمدة 5 ثوانٍ، والبعض الآخر 20، والبعض الآخر 60. قد لا يرى بعض الأشخاص ذلك على الإطلاق (أعتقد؟)، على سبيل المثال إذا كانوا يقرأون ردًا فقط أو يكتبون واحدًا، فقد يحدث هذا التبديل قبل أن يضغطوا على إرسال أو قبل أن يتوقفوا عن قراءة الموضوع ويضغطوا على رد (أو يزوروا صفحة أخرى).
مشكلتي مع مسار nginx كانت تتعلق أكثر بأمر الـ 20 دقيقة في إعداد الحاوية الواحدة. مع خيار وجود حاويتين والانتقال من 20 دقيقة إلى 60 ثانية كحد أقصى، أتساءل عما إذا كان ذلك ذا صلة حقًا؟ خاصة إذا كان بإمكاني إضافة إعلان في الأعلى يقول إن الأمور ستتوقف لبضع ثوانٍ فقط، في وقت منخفض الحركة، فلن يكون ذلك مشكلة كبيرة؟
يجب أن أجلس وأفكر في الأمر. سيكون إعداد الحاويتين بالتأكيد شيئًا لتنفيذه، إذا وجدت عرضًا جيدًا للسيرفر.
هل يمكنك توضيح هذا الأمر بطريقة يفهمها شخص مبتدئ مثلي؟ لا أزال غير مألوف مع العمال (Workers)…
لماذا تقوم بإضافة وحذف صفحة مسار العمال إذا كان تركها لا يمثل مشكلة؟ إذًا، إذا أضفت صفحة الصيانة، هل يمكنني حقًا إعدادها مرة واحدة، ومن تلك اللحظة فصاعدًا، أقوم دائمًا بالاتصال بخادمي عبر SSH باستخدام المحطة الطرفية (Terminal) وأقوم بكل شيء هناك كما أفعل مع حاوية واحدة، دون الحاجة مطلقًا إلى زيارة Cloudflare؟
ذكر @merefield أن هذا (صفحة الصيانة، العمال، وما إلى ذلك) هو أيضًا شيء يحتاج إلى صيانة، لذا أتساءل عما إذا كان هذا حقًا شيئًا تُضبطه وتنساه، أم أن هناك شيئًا يحتاج إلى القيام به من وقت لآخر؟