אני בהחלט לא מנסה להעביר את האשמה. הדבר מצער עם אירוח עצמי באופן ספציפי יותר. זה לא בהכרח הבנה של מערכת ההפעלה של השרת. רוב האנשים מתקינים מערכת הפעלה ובדרך כלל משאירים אותה מעודכנת. אבל לעתים קרובות עם LTS (תמיכה ארוכת טווח) אולי לא יודעים או מבינים שדרוג של מערכת ההפעלה. במיוחד אם הם רגילים לגרסאות מתגלגלות (rolling releases).
לדוגמה, חברה שאני עוזר לה אחרי שלא עדכנה במשך זמן מה, שמה לב שיש עדכון זמין. אז הם עדכנו את Docker דרך ממשק המשתמש של האינטרנט. מה שאפשר להם לעדכן את Discourse.
בגלל שה-Ubuntu LTS לא היה חדש מספיק, עדכון ה-Docker לא עמד בדרישת המינימום. שממשק המשתמש של האינטרנט עדיין איפשר את ניסיון העדכון. שכמובן נכשל והוריד את האתר.
אז הם ניסו לבצע בנייה מחדש משורת הפקודה, שכמובן נכשלה עקב אי עמידה בדרישות המינימום.
אם העדכון באינטרנט היה מזהה שגרסת ה-Docker אינה מינימלית. זה היה יכול לבטל את תהליך העדכון ולהודיע על תלות שלא נענתה מבלי שהאתר יירד.
הצצתי עבורם באופן כללי. מכיוון שנראה שאולי הם מריצים דברים אחרים על השרת. הוריתי להם לבקש מהטכנולוגיה שלהם לבדוק שדרוג של ה-LTS לגרסה חדשה יותר. מכיוון שלא רציתי לנסות לשדרג את מערכת ההפעלה למקרה שזה ישבור דברים אחרים שהם מריצים.
האם יש דרך קלה להפעיל מחדש את הקונטיינר לפני הניסיון לבנות מחדש דרך האינטרנט וגם דרך שורת הפקודה?
ניסיתי ./launcher start app
שנכשל.
הדבר השני. בגלל האופן שבו האתר של Discourse ירד, האם הקמה של שרת חדש עם rsync תעבוד? הם מריצים גרסה יציבה (stable) במקום בדיקות שאושרו (tests passed) המומלצות.
אם הם יריצו את ה-:‘do-release-upgrade’ וישדרגו ידנית את Docker, האם זה יהיה יעיל כדי לגרום לשדרוג postgreq?