ربما قمنا بتنفيذ صفحة التوقف المؤقت فقط لأننا بدأنا في استخدام إجراء الترقية »إيقاف الحاوية، سحب التغييرات عبر git، إعادة بناء launcher« بعد أن تعرضنا لمشاكل مثل [1، 2، 3] عدة مرات فعليًا.
ربما حدث تغيير ما في قوة إغلاق PostgreSQL إذا لم ينغلق في الوقت المحدد للسماح بإجراء عملية الترقية بسلاسة.
على أي حال، نجح الترقية عبر الإنترنت (مرة أخرى) بالنسبة لنا عندما أعطيناه فرصة أخرى الآن. لذا، لا بأس وعتذر عن الإزعاج.
هذا أمر محير بعض الشيء، لأن ما يلي هو دليل لتثبيت وتكوين nginx خارج الحاوية.
على أي حال، أدركت اليوم فائدة إضافية لهذا التكوين الخارجي لـ nginx: إذا كنت معتادًا على رؤية عناوين IP مثل 127.0.0.1 أو عنوان Docker الخاص بك (الذي يبدأ على الأرجح بـ 172.) كعنوان تسجيل أو تسجيل دخول، فقد يكون ذلك بسبب عدم حمل حركة مرور IPv6 الموجهة إلى الحاوية لعنوان IPv6 الخاص بها، على عكس IPv4. مع هذا التكوين، ستظهر الآن عناوين IPv6 صحيحة بدلاً من العناوين المحلية.
وبعبارة أخرى، يُعد هذا التكوين ضروريًا بشكل أساسي للعمل الصحيح لأداة إدارية مفيدة على الإنترنت الذي يعتمد بشكل متزايد على IPv6. (في الولايات المتحدة، يشمل ذلك الكثير من حركة مرور الهواتف المحمولة.)
شكرًا لك على هذا الدليل المفيد جدًا! لدي بعض الملاحظات:
أعتقد أن الأمر sudo apt-get install letsencrypt قد تم استبداله بـ sudo apt-get install certbot. عند تشغيل الأمر الأول، تظهر لي رسالة Note, selecting 'certbot' instead of 'letsencrypt'.
لاحظ صديق لي أن مشاركة الموقع على فيسبوك أظهرت معاينة لرسالة “301 moved permanently”.
تعديل: في البداية، قمت باستبدال قسم location / في كتلة الخادم على المنفذ 80 بقسم location / في كتلة الخادم على المنفذ 443. لكنني أعتقد أن هذا تكرار غير ضروري. بدلاً من ذلك، قمت بحذف كتلة الخادم على المنفذ 80 التي كانت تعمل ككتلة إعادة توجيه، وأضفت:
listen [::]:80;
listen 80;
في القسم المناسب من كتلة الخادم الرئيسية.
كما قمت بتفعيل إعادة التوجيه إلى https (غير متأكد مما إذا كان ذلك ضروريًا) من داخل إعدادات Discourse.
هذا حل مشكلة المشاركة على فيسبوك، ويبدو أن طلبات HTTP العادية يتم إعادة توجيهها إلى HTTPS. إذا كانت هناك طريقة أخرى أو أفضل، يرجى إعلامي بذلك.
شكرًا لك على الدليل، إنه رائع. الآن تبدو صفحة 502 الخاصة بي أفضل بكثير.
في حالتي العملية، يتعين علي إضافة إعدادات nginx إلى ملف /etc/nginx/sites-enabled/discourse.conf.
لقد نجحت في تثبيت Discourse بعد تشغيل nginx مع ووردبريس.
شكرًا لك على البرنامج التعليمي، فهو يعمل بشكل جيد جدًا بالنسبة لي.
كنت أتساءل فقط: إذا رأى روبوت بحث جوجل (Googlebot) صفحة الخطأ هذه، فهل سيعرف أنها صفحة مؤقتة؟ أم أننا بحاجة إلى إرسال رمز خطأ معين لجعله يدرك الطبيعة المؤقتة للتغيير؟
أفضل ألا يرى جوجل حذف جميع الفهرسة التي تمت على منتداي بسبب صفحة خطأ أكثر أناقة…
هذا يعني "عند مواجهة (أو إنشاء) رمز استجابة 502 Bad Gateway، أرسل محتويات ملف /errorpages/discourse_offline.html مع رمز استجابة 502 Bad Gateway. الرمز = هو ما يخبره برمز استجابة HTTP المراد إرساله.
كل شيء على ما يرام!
وأوافق @ashs؛ دقيقة واحدة أو أقل من أخطاء 502 مرة أو مرتين شهريًا لم تضر بالبحث. غالبًا ما أرى مشاركات حديثة تظهر في نتائج Google.
قد يشير خطأ 502 إلى أن Nginx لا يعمل، ربما بسبب خطأ في التكوين. يُخبرك تشغيل nginx -t ما إذا كان ملف التكوين يبدو سليمًا. إذا لم تكن هناك أخطاء، فقم بتشغيل systemctl status nginx.service للتحقق من حالة خدمة Nginx.
سؤالي يتعلق مباشرة بعنوان الموضوع، لكنه لا يتعلق بالطريقة المستخدمة في هذا الموضوع، لذا أأمل أن يكون من المقبول إبقاؤه ضمن هذه المناقشة.
لقد قمت بإعداد شيء بسيط جدًا لحل هذه المشكلة ولدي سؤال محدد.
أنشأت قطرة منفصلة في DigitalOcean وقمت بتثبيت خادم LAMP عبر السوق. ثم قمت برفع صفحة HTML أساسية تحتوي على بعض الصور للإشارة إلى أن الخادم متوقف للصيانة. بعد ذلك، كنت سأعوم عنوان IP بين خادم Discourse العادي وخادم الصيانة هذا حسب الحاجة.
إليك السؤال: لكي يعمل خادم ‘الصيانة’ بشكل صحيح، احتجت في النهاية إلى الحصول على شهادة عبر certbot لذلك الخادم (بالإضافة إلى الشهادة التي أملكها بالفعل لخادم Discourse الرئيسي). بعبارة أخرى، شهادتان لنفس النطاق على خوادم مختلفة. لقد نجح الأمر، لكنني كنت دائمًا قلقًا بشأن ما إذا كان ذلك قد يسبب مشاكل في المستقبل. تشير القراءات التي أجريتها على الإنترنت إلى أن هذا مقبول، لكنني أردت معرفة ما إذا كان أي شخص قد مر بتجربة مباشرة مع هذا الأمر.
هذا إجراء صحيح تمامًا. ومع ذلك، اعتمادًا على طريقة التحقق التي استخدمتها، قد لا تعمل تجديدات الشهادات – على سبيل المثال، إذا كان خادم “الصيانة” يستخدم التحقق القائم على HTTP، فسيكون ذلك فاشلًا طالما أن النطاق لا يشير إليه، وهو ما قد يُفقد الغرض من الإجراء. قد يكون من المنطقي أن يقوم خادم الصيانة بنسخ أحدث شهادة من الخادم الرئيسي بشكل دوري بدلاً من طلب شهادة جديدة من Let’s Encrypt.
أعترف بأنني لا أعرف شيئًا عما إذا كان خادمي يستخدم التحقق القائم على HTTP (لقد قمت بكل شيء من خلال certbot الرائع هذا)، لكن مخاوفك منطقية تمامًا. بحثت قليلًا، لكن لم أتمكن من العثور على أي موارد حول كيفية نسخ الشهادات كما اقترحت. كما أفترض أنني سأحتاج إلى إعداد نوع من مهام الجدولة (cron job). إذا كان لديك أي اقتراحات أخرى، فسأكون ممتنًا جدًا. وإلا، فشكرًا مرة أخرى على مساعدتك.
لنسخ الملفات مباشرة من خادم إلى آخر، تُعد أدوات scp أو rsync خيارات جيدة – هذا الرابط قد يكون نقطة انطلاق جيدة.
اقتراحي هو بالفعل إعداد مهمة مجدولة (cron job) لنسخ الشهادة من الخادم الرئيسي إلى خادم الصيانة بانتظام
وبالإضافة إلى ذلك، ولتوضيح الخلفية الخاصة بالتحقق القائم على بروتوكول HTTP: للتحقق من أن النطاق يعود إليك حقًا، ستطلب Let’s Encrypt ملفًا محددًا من خادمك وتتوقع استجابة معينة. يمكن لـ Certbot التعامل مع ذلك تلقائيًا (عن طريق تكوين خادمك مؤقتًا لإعادة إرجاع هذا الملف لطلب التحقق)، ولكن بالطبع، هذا لا يعمل إلا إذا وصل الطلب فعليًا إلى خادمك. إذا لم يشير DNS إلى خادمك، أو قمت بنقل عنوان IP إلى مكان آخر، فسيذهب الطلب إلى الخادم الخطأ، ولن تحصل Let’s Encrypt على الاستجابة المتوقعة، وبالتالي ترفض توقيع الشهادة.
إذا كنت تريد صفحة “قيد الإنشاء” أثناء إعادة بناء الموقع، فستحتاج إلى القيام بالخطوات الشاقة المذكورة أعلاه. أوصي بالتبديل إلى تثبيت حاويتين، وهو أمر أكثر صعوبة في الصيانة (تحتاج إلى معرفة وقت إعادة بناء حاوية البيانات)، ولكنه يتطلب حوالي 30 ثانية فقط من وقت التوقف عند تشغيل الحاوية الجديدة، ولكنه يتطلب حاليًا قدرًا كبيرًا من ذاكرة الوصول العشوائي (قد لا تكون 2 جيجابايت كافية، لكنني لست متأكدًا تمامًا).
