حل بديل لصفحة الصيانة - هل يمكن فعل ذلك؟

الدعم تثبيت
22

نعم، سأقوم بذلك على مراحل:

  1. الحصول على خادم أكثر قوة قليلاً
  2. جعل تثبيت الحاويتين يعمل

إذا كنت راضيًا عن النتيجة في هذه المرحلة، توقف هنا، أو:

  1. تنفيذ صفحة الصيانة باستخدام دليل @Lilly الممتاز أعلاه. :+1:
23

هههه، أنا سعيد لأنك سألت، لأنني لم أخذ الوقت الكافي لشرح هذا الجزء (كان يجب أن أفعل ذلك - هناك الكثير مما يجب شرحه وCloudflare معقدة!).

عندما يتم تعيين مسار العمال (workers route)، فإن كل تحميل للصورة وكل مشاهدة للصفحة على المنتدى تمر عبر هذا العامل (worker).

تتضمن خطة CDN المجانية من Cloudflare حدًا مجانيًا بـ 100,000 طلب في اليوم لمسار العامل.

لذلك، إذا كان لديك منتدى نشط نسبيًا، ومنعًا للوصول إلى حد الخطة المجانية في يوم واحد، فمن الجيد عدم إبقائها مفعلة طوال الوقت. هذا يتعلق فقط بمسار العامل، وليس بصفحة الصيانة - يمكنك إبقاء صفحة الصيانة مفعلة طوال الوقت - لن يتم استدعاؤها إلا إذا كان مسار العامل مفعلاً. هذا يتعلق فقط بـ الخطوة 2 حيث قمت بتعيين المسار (وهو سهل الإعداد والإزالة). ما لم تكن تستخدم خطة مدفوعة من Cloudflare، فمن الجيد عادةً إبقاء المسار مفعلاً فقط أثناء إجراء صيانة خاصة بك.

  1. انتقل إلى صفحة مسارات العمال (workers route) في Cloudflare لمجالك وانقر على الزر الموجود على الجانب الأيمن من المسار.

Screenshot 2026-08-01 at 5.06.14 PM
Screenshot 2026-08-01 at 5.06.14 PM1652×552 43.9 KB

  1. في أسفل شاشة التعديل، انقر على زر remove لفصل صفحة العامل عن المسار.

Screenshot 2026-08-01 at 5.09.01 PM
Screenshot 2026-08-01 at 5.09.01 PM742×658 40.5 KB

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

إذا كنت تستخدم خطة مدفوعة من Cloudflare، فلا داعي للقلق. ومع ذلك، يمكنك في هذه الحالة استخدام صفحات الأخطاء من Cloudflare بدلاً من صفحة العامل… (هل ذكرت أن Cloudflare معقدة جدًا؟ LOL)

:warning: إعدادات المسؤول المتقدمة أدناه

إذا أراد أحد أن يقوم بأتمتة تحديثاته بالكامل على الخطة المجانية، فيجب عليه استخدام رمز API من Cloudflare، واستخدام معرف المنطقة (zone-id) وأمر curl للحصول على route id للعامل. ثم قم بتعديل سكريبت /root/update-web.sh بإضافة بعض الأشياء الممتعة الأخرى لتشغيل وإيقاف مسار العامل تلقائيًا:

#!/bin/bash
cd /var/discourse

CF_TOKEN="your_actual_token_here" #<---رمز API الخاص بـ Cloudflare
ZONE_ID="xxxx" #<---من صفحة ملفك الشخصي في Cloudflare
ROUTE_ID="xxxx"
WORKER_NAME="my-site-maintenance-page"

echo "➡️ جاري سحب أحدث سكريبتات Docker الخاصة بـ Discourse..."
git pull

echo "➡️ جاري تهيئة حاوية الويب الجديدة في الخلفية..."
./launcher bootstrap web_only

if [ $? -eq 0 ]; then
    echo "✅ تمت التهيئة بنجاح!"
    
    # تفعيل عامل الصيانة في Cloudflare
    echo "🚧 جاري تفعيل صفحة الصيانة..."
    curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/workers/routes/$ROUTE_ID" \
         -H "Authorization: Bearer $CF_TOKEN" \
         -H "Content-Type: application/json" \
         --data '{"pattern":"*your-site.com/*","script":"'$WORKER_NAME'"}' > /dev/null

    # تبديل الحاويات (فترة التوقف لمدة 30 ثانية)
    echo "🔄 جاري تبديل الحاويات..."
    ./launcher destroy web_only && ./launcher start web_only
    
    # إيقاف عامل الصيانة في Cloudflare
    echo "🌍 جاري إيقاف صفحة الصيانة..."
    curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/workers/routes/$ROUTE_ID" \
         -H "Authorization: Bearer $CF_TOKEN" \
         -H "Content-Type: application/json" \
         --data '{"pattern":"*your-site.com/*","script":null}' > /dev/null

    echo "🚀 تم! تم تحديث الموقع دون أي توقف مرئي."
else
    echo "❌ فشلت التهيئة! جاري إلغاء التبديل لإبقاء الموقع الحالي متصلًا."
fi

أستخدم النسخة السابقة من السكريبت لأنني لا أهتم بأتمتة كل شيء، وأفضل أن أكون حاضرًا أثناء إجراء التحديثات/إعادة البناء. ما أفعله هو إضافة مسار العمال مباشرة قبل إجراء التحديث ثم إزالته بعد ذلك. يستغرق ذلك بضع ثوانٍ فقط.

خطواتي العامة هي:

  1. إضافة مسار العمال في Cloudflare
  2. الاتصال بـ Hetzner عبر SSH
  3. إجراء أي تحديثات للنظام (مثل: sudo apt update && sudo apt upgrade -y)، ثم إعادة تشغيل الخادم إذا لزم الأمر
  4. إعادة الاتصال عبر SSH إذا كنت بحاجة إلى إعادة التشغيل
  5. تشغيل ./update-web.sh
  6. إزالة مسار العمال في Cloudflare
24

لا أعرف شيئًا عن البرمجة أو عالم التطوير، سوى أنني قمت ذات مرة بكتابة برنامج “مرحبًا بالعالم” البسيط باستخدام Visual Basic منذ زمن بعيد جدًا. لكنني أستطيع القيام ببعض المهام، لأنني أفضل في إدارة خوادم WordPress و Mastodon/Pixelfed، وبشكل ما، خادم Discourse الخاص بي. بالإضافة إلى ذلك، هناك شيء يُدعى الذكاء الاصطناعي (وهو ليس سهلًا للمبتدئين كما يُعلن عنه).

لا أعرف ما إذا كان هذا ممكنًا حتى عن بُعد مع Discourse بسبب استخدام Docker، لكن في عالم Nginx-Varnish-WordPress العادي، قمت ببناء نظام حيث يحصل خادم Plesk على معلومات عن أخطاء 50x ويعرض صفحة خطأ. في الواقع، لدي ثلاثة إعدادات: حيث يعرض Nginx الأمامي محتوى لقطة شاشة مولدة إذا كان Varnish متوقفًا، ويبدأ Varnish باستخدام لقطة الشاشة للمحتوى غير المخزن مؤقتًا عندما يكون الخادم الخلفي المتعلق بـ WordPress متوقفًا، والثالث هو صفحة خطأ في حال عدم استجابة Nginx الأمامي.

أما الأمور المتعلقة بـ Varnish فهي غير ممكنة مع Discourse، لكنني لا أرى أي سبب يمنع بناء شبكة معقدة مماثلة في عالم Docker أيضًا، بحيث تعرض أي خطأ من نوع 50x صفحة خطأ.

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

وهناك أيضًا الإجابة الأكثر وضوحًا، بالطبع: استخدام Nginx قبل Discourse. كنت أستخدم ذلك قبل أن أنتقل إلى إعداد الحاويات المزدوجة.