توخَّ الحذر ولا تفترض أن واجهة الويب للتحديث ستعمل دائمًا. التحديث من صفحة الويب لن يعمل دائمًا. بعض التحديثات (مثل تحديث إصدار قاعدة البيانات الأخير جدًا) ستستلزم إعادة البناء من سطر الأوامر. وهذا يعني الوصول إلى الخادم عبر SSH واستخدام سطر الأوامر لإعادة البناء.
على عكس العديد من المشرفين، عادةً ما أستخدم واجهة الويب للتحديث، لكنني أحتفظ بنافذة طرفية مفتوحة لتنفيذ التحديث يدويًا إذا لزم الأمر عند القيام بذلك.
لذا، قمت باتباع العملية كاملة، بمساعدة بوت Discourse، مما جعل الأمر أسهل قليلاً بالنسبة لي، إذ يبدو أن الموضوع الأصلي «الانتقال من حاوية مستقلة إلى حاويات منفصلة للويب والبيانات» كُتب قبل عشر سنوات، ولم أكن أريد أن أفوّت الأمور.
بعد طرح بعض الأسئلة وتدوين الكثير من الملاحظات، أعتقد أنني أصبحت أفهم الأمور بشكل أفضل. تثبيتي يعمل، لذا أظن أن كل شيء تم ضبطه بشكل صحيح…؟
أخبرني البوت أنه عندما أريد تحديث شيء يتطلب فعليًا مني استخدام SSH، يجب أن يكون الترتيب كالتالي:
# سيستغرق هذا حوالي 20 دقيقة (أول مرة)؛ وعادةً 5–15 دقيقة بعد ذلك
# (ليست وقت التمهيد الأولي الدقيق تمامًا — حيث يخزّن Docker الطبقات في عمليات إعادة البناء اللاحقة)
sudo ./launcher bootstrap web_only
# بعد نجاح التمهيد، شغّل:
sudo ./launcher destroy web_only && sudo ./launcher start web_only
# من حين لآخر، تحقق من مساحة القرص:
df -h
# وإذا كانت مساحة القرص تنفد بسبب صور قديمة غير مستخدمة:
sudo ./launcher cleanup
وأنا جاهز للانطلاق.
التحديث «مرة في السنة» أكثر تعقيدًا قليلاً، لكنني أخذت ملاحظات بشأنه أيضًا،我只 أحتاج إلى تنظيم تلك الملاحظات، لأنني لن أستخدمها الآن.
هل سير العمل المذكور أعلاه صحيح؟
وشكرًا لكم جميعًا لمشاركة آرائكم!
هل يمكنني أن أسأل عن القاعدة البسيطة التي تأخذ هذا في الاعتبار وتعرف متى يجب استخدام كل خيار تحديث متاح؟
لست خبيراً، والآخرون أكثر إلماماً بهذه الأمور، لكن… من خبرتي، لا تعتمد أبداً على نجاح الواجهة الويب، وكن دائماً مستعداً لإعادة البناء من سطر الأوامر. كان ترقية PostgreSQL من الإصدار 15 إلى 18 المفصّلة هنا أمراً حتمياً، فأنت تدرك أنك لن تستطيع الاعتماد على تحديث الواجهة الويب وحدها.
إنها ليست صعبة جداً، فكّر في تحديث واجهة الويب على أنه ملاءمة، فإذا نجح… فهذا رائع، لكن كن مستعداً إذا لم ينجح. على الأقل، عندما لا يعمل، فإنه يمنحك شرحاً مفصلاً عما حدث وما يجب عليك فعله لإصلاحه. سيخبرك العديد من مسؤولي Discourse المحترفين هنا بعدم حتى محاولة التجربة. منتداي صغير الحجم ومنخفض الحركة، لذا يمكنني تحمّل المخاطرة، لكن قد لا يكون لديك هذا الترف.
لم أعد أنشر هنا كثيرًا في هذه الأيام، لكن إذا كنت بحاجة إلى مساعدة في إعداد حاوية مزدوجة أو لديك أي أسئلة، فلا تتردد في مراسلتي على الخاص. أنا أشغّل منتدياتين منفصلين بنظام الحاوية المزدوجة خلف Cloudflare CDN مع تخزين كائنات متوافق مع S3 (R2). نعم، الأمر أكثر تعقيدًا بعض الشيء من نظام الحاوية المفردة، لكنه ليس صعبًا كما يعتقد الكثيرون. إنه سهل جدًا في الصيانة، ويمكنك استخدام سكريبت Bash لجعل عملية التحديث أسهل حتى.