The discussion revolves around improving Discourse’s update/upgrade process by implementing a dependency check to prevent failures due to outdated OS or Docker versions. Heliosurge proposes that the system should detect unmet requirements—like insufficient Docker versions—before starting an update, thereby avoiding downtime. pfaffman acknowledges the challenges, noting that while Discourse attempts to check dependencies (e.g., Docker version), users often fail to keep their systems updated, especially with LTS OSes nearing end-of-life. Heliosurge shares a real-world example where an outdated Ubuntu LTS caused a failed update, leading to site downtime. pfaffman suggests that while it’s possible to detect Docker version from within a container via the Docker API, the best practice is to migrate to a new VM using rsync, especially when the OS is outdated. Heliosurge agrees, noting that many users don’t follow updates and that a proactive approach—like using rsync—can prevent issues. The conversation highlights the need for better user guidance and automated checks to reduce update-related failures.
כפי שראינו במהלך השנים, לעתים עדכון/שדרוג נכשלים עקב תלויות. לדוגמה, גרסת Docker/מערכת הפעלה.
הרעיון שלי הוא ש-Discourse יריץ סוג כלשהו של בדיקת תלויות כדי לוודא שדרישות הבסיס מתקיימות. אם הבדיקה נכשלת, היא תספק פרטים על מה עשוי להיות נחוץ ותבטל את תהליך העדכון/שדרוג.
זה יעזור להפחית את זמן ההשבתה של הפורום על ידי ביטול עדכון/שדרוג של ליבת Discourse (Core Discourse) על ידי ביטול התהליך שעתיד להיכשל.
הם מנסים די חזק לעשות את זה. מספר הדברים שיכולים להשתבש הוא די גדול. בעיקר, אם אינך מעדכן את מערכת ההפעלה שלך (וכנראה גם את Docker), זו אשמתך.
הם מנסים לבדוק את גרסת Docker, והסקריפטים שאני משתמש בהם משדרגים את Docker אם ידוע שהיא פגומה (כנראה שזה צריך פשוט תמיד לשדרג את Docker).
אני חושב שהם יכולים לעשות טוב יותר אם תמיד יכריחו שדרוג של שורת הפקודה אם תמונת הבסיס משתנה בכלל. אני כמעט אף פעם לא משתמש בזה מכיוון שהלוח שלי עושה עדכון של שורת הפקודה בלחיצה.
האם העדכון docker_manager מעדכן את docker?
אני בהחלט לא מנסה להעביר את האשמה. הדבר מצער עם אירוח עצמי באופן ספציפי יותר. זה לא בהכרח הבנה של מערכת ההפעלה של השרת. רוב האנשים מתקינים מערכת הפעלה ובדרך כלל משאירים אותה מעודכנת. אבל לעתים קרובות עם LTS (תמיכה ארוכת טווח) אולי לא יודעים או מבינים שדרוג של מערכת ההפעלה. במיוחד אם הם רגילים לגרסאות מתגלגלות (rolling releases).
לדוגמה, חברה שאני עוזר לה אחרי שלא עדכנה במשך זמן מה, שמה לב שיש עדכון זמין. אז הם עדכנו את Docker דרך ממשק המשתמש של האינטרנט. מה שאפשר להם לעדכן את Discourse.
בגלל שה-Ubuntu LTS לא היה חדש מספיק, עדכון ה-Docker לא עמד בדרישת המינימום. שממשק המשתמש של האינטרנט עדיין איפשר את ניסיון העדכון. שכמובן נכשל והוריד את האתר.
אז הם ניסו לבצע בנייה מחדש משורת הפקודה, שכמובן נכשלה עקב אי עמידה בדרישות המינימום.
אם העדכון באינטרנט היה מזהה שגרסת ה-Docker אינה מינימלית. זה היה יכול לבטל את תהליך העדכון ולהודיע על תלות שלא נענתה מבלי שהאתר יירד.
הצצתי עבורם באופן כללי. מכיוון שנראה שאולי הם מריצים דברים אחרים על השרת. הוריתי להם לבקש מהטכנולוגיה שלהם לבדוק שדרוג של ה-LTS לגרסה חדשה יותר. מכיוון שלא רציתי לנסות לשדרג את מערכת ההפעלה למקרה שזה ישבור דברים אחרים שהם מריצים.
האם יש דרך קלה להפעיל מחדש את הקונטיינר לפני הניסיון לבנות מחדש דרך האינטרנט וגם דרך שורת הפקודה?
ניסיתי ./launcher start app
שנכשל.
הדבר השני. בגלל האופן שבו האתר של Discourse ירד, האם הקמה של שרת חדש עם rsync תעבוד? הם מריצים גרסה יציבה (stable) במקום בדיקות שאושרו (tests passed) המומלצות.
אם הם יריצו את ה-:‘do-release-upgrade’ וישדרגו ידנית את Docker, האם זה יהיה יעיל כדי לגרום לשדרוג postgreq?
זה יהיה בתוך הגרסה הנתמכת של Ubuntu LTS. אבל רק הגרסה(ות) הנתמכות על ידי ה-LTS. במקרה הזה, ה-LTS שלהם הגיע לסוף חייו. כך שזה לא תומך בגרסת ה-Docker המינימלית.
גרסאות Ubuntu LTS, אם אני זוכר נכון, יש להן 4 שנות עדכונים.
Not the people I work with. They won’t update it when I tell them it’s behind eol.
I’m pretty sure that stuff running inside the container cannot tell what version of docker it’s running under.
Maybe it can. It looks like you can get this from inside a container to see what version is running.
https://docs.docker.com/engine/api/v1.30/#operation/SystemVersion
So maybe they could do better. That could be a cool thing to add to the dashboard,if it really does work.
It usually works. An exception is if the database has been migrated.
If the os is out of date I generally find it easier and safer to move to a new vm. Ideally you do it whilst the old server still works. See Move a Discourse site to another VPS with rsync
If you have a backup, you can skip copying the database and skip the database upgrade, just restore it on the new database.
That is why I said update. In the case of eol it requires OS upgrade. But I do agree with you on that there are a wide variety of ppl whom do not follow instructions well. 
When I was upgraded to admin for the company I help out for free 
I had told them for over a month straight that their forum was going to crash at some point as they did not have space needed to perform rebuild app. They had a minimal sized server(7 years ago). Iirc it had a 25g space in total. Of course they didn’t listen. And ended up paying someone in here to get the forum onto a new server. Total downtime about 2 weeks maybe a bit more.
That would definitely be cool if that can be made to work. For folks like you and I who somewhat live on here we keep ourselves fairly up-to-date B’s a lot of folks in comparison who only visit after a problem arises or looking for add-ons and other more minor support issues.
Ok will advise them. However not sure how old the backup is. So imagine in their case rsync or OS upgrade will need to be explored.
On my personal server that was nearing out of date I did a lot of reading and was careful not to web/command line update. Til I was. Comfortable using the rsync procedure. And still hada couple of minor hiccups that you and the community assisted me in debugging.
