أخطاء 503 عابرة عند تقديمها بواسطة HAProxy

تثبيت استضافة
1

لقد أنشأت منتدى اختبار يحتوي على حاويتين web_only، وحاوية mail-receiver، و Postgres، و Redis على شبكة Docker. تم وضع حاويتي الويب nginx بواسطة HAProxy. لقد عملت بشكل جيد، لكنني وجدت عند إعادة بناء إحدى حاويتي الويب كان هناك دائمًا قدر ضئيل من وقت التعطل حيث تم إرجاع 503.

لحسن الحظ، وجدت حلاً تخفيفيًا، ولكنه ليس مثاليًا؛

قبل إعادة بناء app1، قم بتشغيل

echo "disable server be_discourse/app1" | socat stdio /run/haproxy/admin.sock

وبعد انتهاء عملية إعادة بناء app1، قم بتشغيل

echo "enable server be_discourse/app1" | socat stdio /run/haproxy/admin.sock

وبالمثل، لإعادة بناء app2 قم بتشغيل

echo "disable server be_discourse/app2" | socat stdio /run/haproxy/admin.sock

وبعد انتهاء عملية إعادة بناء app2، قم بتشغيل

echo "enable server be_discourse/app1" | socat stdio /run/haproxy/admin.sock

هذا يعتمد على تطابق /etc/haproxy/haproxy.cfg فيما يتعلق بـ be_discourse، لن أقوم بلصق ملف التكوين في كتلة التعليمات البرمجية بعد، ولكن إذا أرادت كتلة حرجة فسأفعل ذلك.

لذلك هذا يخفف من 503 عن طريق إخبار HAProxy بتوجيه حركة المرور قبل أن يعرف أنه سيكون هناك 503 من الحاوية التي تعطلت.

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

2

لماذا لا تقوم بإعادة الإرسال (redispatch) إلى الخادم التالي عند حدوث خطأ 503؟

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

جميل! سيكون ذلك جيدًا. أيضًا، هل لديك أي اقتراحات بخصوص sidekiq؟ لا أرى sidekiq على الإطلاق في discourse_docker/samples at main · discourse/discourse_docker · GitHub مما دفعني إلى إجراء التغييرات التالية على أي من ملفات yml

app1.yml

## تذكر، هذه صيغة YAML - يمكنك فقط الحصول على كتلة واحدة باسم
run:
  - exec: echo "Beginning of custom commands"
+  - exec: rm -f /etc/service/sidekiq/down
  ## إذا كنت ترغب في تكوين تسجيل الدخول بكلمة مرور للمستخدم الجذر، قم بإلغاء التعليق والتغيير:

app2.yml

## تذكر، هذه صيغة YAML - يمكنك فقط الحصول على كتلة واحدة باسم
run:
  - exec: echo "Beginning of custom commands"
+  - exec: bash -lc 'mkdir -p /etc/service/sidekiq & touch /etc/service/sidekiq/down'
  ## إذا كنت ترغب في تكوين تسجيل الدخول بكلمة مرور للمستخدم الجذر، قم بإلغاء التعليق والتغيير:
4

لكل من يشغل حاويات ويب متعددة، هناك شيء إضافي يجب التفكير فيه وهو مكان تشغيل Sidekiq.

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

يستخدم Discourse runit في الخلفية: تبدأ كل خدمة في /etc/service/* ما لم يكن هناك ملف يسمى down داخل دليلها. هذا هو كل التحكم المطلوب.

إليك مثال على عامل Sidekiq مخصص:

worker.yml — Sidekiq فقط 
templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/sshd.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"

expose: []   # لا توجد منافذ HTTP

env:
  DISCOURSE_DB_HOST: data
  DISCOURSE_REDIS_HOST: data
  DISCOURSE_HOSTNAME: "forum.example.com"
  # مطابقة أسرارك الحالية / إعدادات SMTP

hooks:
  after_code:
    - exec:
        cd: $home
        cmd:
          # تعطيل خدمات الويب
          - mkdir -p /etc/service/puma  && touch /etc/service/puma/down
          - mkdir -p /etc/service/nginx && touch /etc/service/nginx/down
          # تمكين Sidekiq
          - rm -f /etc/service/sidekiq/down

run:
  - exec: echo "بدء حاوية عامل Sidekiq"

في حاويات الويب (app1/app2)، يجب القيام بالعكس - إبقاء Puma و Nginx ممكّنين، ولكن أضف:

hooks:
  after_code:
    - exec:
        cd: $home
        cmd:
          - mkdir -p /etc/service/sidekiq && touch /etc/service/sidekiq/down

مع هذا الإعداد، يقوم HAProxy بموازنة حاويات الويب فقط، بينما يستمر Sidekiq في العمل في العامل. بهذه الطريقة، لا تنقطع المهام الخلفية عند إعادة بناء أو تدوير عقد الويب الخاصة بك.

5

لقد نقلت هذا إلى Installation > Hosting حيث يبدو أنه محادثة مفتوحة. لنتجنب إنشاء مثل هذه المحادثات في Support.

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