ברצוני לפתוח דיון בנוגע לשיטות עבודה מומלצות לביצוע משימות תחזוקה מרכזיות במופע Discourse תוך מזעור או ביטול השבתה.
משימות כמו שינוי הגדרות משאבים קריטיים (למשל, UNICORN_WORKERS, DISCOURSE_SIDEKIQ_WORKERS, DISCOURSE_DB_POOL) או יישום עדכונים גדולים דורשות בדרך כלל launcher rebuild app שיכול לקחת זמן משמעותי, לעיתים 30 דקות או יותר.
שאלתי היא: מהן האסטרטגיות המומלצות למנהלי מערכת לביצוע עדכונים חיוניים אלו ושינויי תצורה עם מינימום השבתה למשתמשים?
האם קיימות טכניקות מתקדמות, כמו פריסות כחול/ירוק או אסטרטגיות פריסה אחרות ללא השבתה, הנתמכות או מומלצות עבור Discourse? או שתהליך ה-rebuild הסטנדרטי הוא השיטה היחידה הנתמכת, והמיקוד צריך להיות על אופטימיזציה של זמן ה-rebuild עצמו?
אני מעוניין לשמוע מכל מי שיש לו ניסיון בניהול מופעים גדולים או בעלי תעבורה גבוהה וכיצד נראה זרימת העבודה שלהם לתחזוקה.
If you have a two container install, the new container builds while the old one runs. Downtime is just the amount of time it takes to launch the new container. The only issue is that you need enough ram to build a container while the other runs.
If you want zero down time then you need a load balancer that keeps the old container running until the new one has fully started. Then you shut down the old container and do the post update migrations.
Discourse is so stable this is pretty unnecessary for most installs (but I guess you might consider it for very high availability requirements or if you are hosting others?!)
I don’t think I’ve had a single outage in 7 years due to a production “glitch” …
The riskiest moments in a Discourse’s life is always at rebuild.
the two container setup gives you the ability to bootstrap a new build before committing to it though that won’t catch some runtime errors of course.
The issue is that if your migrations have run, you might need to commit to the new build and so you would usually try to track down and fix the source of those errors rather than roll back.