שגיאות 503 חולפות כאשר HAProxy נמצא מלפנים

התקנה אירוח
1

יצרתי פורום בדיקה עם שני קונטיינרים מסוג web_only, קונטיינר mail-receiver, Postgres ו-Redis ברשת Docker. שני קונטיינרי ה-web nginx היו מול HAProxy. הם עבדו היטב, אבל גיליתי שבבנייה מחדש של אחד משני קונטיינרי ה-web תמיד היה פרק זמן קצר של השבתה שבו הוחזר 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

Why don’t you redispatch to the next server on a 503 ?

לייק 1
3

nice! that would be good. Also, do you have any suggestions about sidekiq? I don’t see sidekiq at all in discourse_docker/samples at main · discourse/discourse_docker · GitHub which lead to me making the following changes to either yml

app1.yml

## Remember, this is YAML syntax - you can only have one block with a name
run:
  - exec: echo "Beginning of custom commands"
+  - exec: rm -f /etc/service/sidekiq/down
  ## If you want to configure password login for root, uncomment and change:

app2.yml

## Remember, this is YAML syntax - you can only have one block with a name
run:
  - exec: echo "Beginning of custom commands"
+  - exec: bash -lc 'mkdir -p /etc/service/sidekiq && touch /etc/service/sidekiq/down'
  ## If you want to configure password login for root, uncomment and change:
4

עבור כל מי שמריץ מספר קונטיינרים של ווב, פרט נוסף שכדאי לחשוב עליו הוא היכן Sidekiq רץ.

503s משפיעים רק על בקשות ווב, אך אם Sidekiq מושבת, האתר שלך יפסיק בשקט לטפל במשימות רקע (מיילים, סיכומים, תגים, webhooks). דרך נחמדה לטפל בזה היא להקצות ל-Sidekiq קונטיינר משלו ולהשאיר אותו מושבת בצמתי הווב.

Discourse משתמש ב-runit מאחורי הקלעים: כל שירות ב-/etc/service/* מתחיל אלא אם כן קיים קובץ בשם down בתוך התיקייה שלו. זה כל השליטה הדרושה.

הנה דוגמה של worker ייעודי ל-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 "Starting Sidekiq worker container"

בצמתי הווב (app1/app2), יש לעשות את ההפך - להשאיר את Puma ו-Nginx מופעלים, ולהוסיף:

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

עם הגדרה זו, HAProxy מאזן רק את צמתי הווב, בעוד Sidekiq ממשיך לרוץ ב-worker. כך, משימות רקע אינן מופרעות כאשר אתה מבצע בנייה מחדש או מחליף את צמתי הווב שלך.

5

העברתי זאת ל-Installation > Hosting מכיוון שזה נראה כמו שיחה פתוחה. בואו נימנע מיצירת כאלה ב-Support.

לייק 1