خلفية: كما هو مفصل في مكان آخر، تم استضافة تثبيت Discourse الخاص بي بواسطة خادم افتراضي خاص (VPS) كان قرصه صغيرًا جدًا لإكمال الترقية. في البداية، نقرت على “Upgrade” في لوحة تحكم المسؤول. فشلت الترقية، ولم تعمل الواجهة الرسومية مرة أخرى أبدًا. بعد ذلك، سجلت الدخول إلى وحدة التحكم الخاصة بالخادم الافتراضي الخاص بي وأعطيت الأمر الشهير ./launcher rebuild app. لم يكتمل هذا الأمر أيضًا: لقد نفدت مساحة التخزين الخاصة بي بشكل حاسم. للحصول على مساحة أكبر والبقاء ضمن الميزانية، قررت نقل إعدادي بالكامل إلى خادم افتراضي خاص جديد مع شركة استضافة مختلفة. كان حفظ بيانات الموقع الثمينة أولوية قصوى.
إخفاقات: فشلت طريقتان واضحتان لعمل نسخة احتياطية:
محاولتي الأصلية للترقية كسرت الواجهة الرسومية المستندة إلى الويب، لذلك لم تكن هناك طريقة للوصول إلى لوحة تحكم المسؤول وبدء نسخة احتياطية من هناك؛ و
محاولة الدخول إلى حاوية docker وإعطائها بعض أوامر shell لم تنجح أيضًا. الأمر الموصى به لهذا هو /var/discourse/launcher enter app. ولكن، على الأقل في حالتي، حاول برنامج launcher إعادة بناء التطبيق قبل السماح لي بالدخول إليه، وكانت عمليات إعادة البناء تفشل باستمرار، لذلك لم يمنحني هذا الأمر حاوية أبدًا، ناهيك عن shell بداخله.
نجاح: كنت على وشك الاستسلام عندما حصلت على مفاجأة سارة. أثناء العمل في سطر الأوامر الخاص بجهازي الافتراضي الصغير، قلت docker ps وعلمت أن هناك حاوية نشطة تسمى app. ولدى docker طريقة مباشرة للدخول إلى حاوية قيد التشغيل: الأمر هو docker exec -it app bash.
داخل الحاوية، تمكنت من إحراز تقدم: أصدرت الأمر discourse backup، وانتظرت بضع دقائق، ثم نسخت ملف <backup>.tar.gz إلى موقع جديد آمن. مع وجود نسخة احتياطية حالية في متناول اليد، كان من الممكن الانتهاء من ترحيل إعدادي إلى موطنه الجديد. (هناك مواضيع أخرى في هذه المنتديات توضح كيفية القيام بذلك.)
النقطة الرئيسية هنا هي أن أمر docker أعلاه للدخول إلى الحاوية نجح، حتى عندما لم ينجح الأمر الخاص بـ Discourse ./launcher.
خلال الأيام التي كنت أحاول فيها تشغيل إعدادي الأصلي، اعتقدت أنني فعلت كل ما هو ممكن لاستعادة المساحة، بما في ذلك بالتأكيد ./launcher cleanup، ولكن أيضًا أكثر من ذلك بكثير… إزالة النواة القديمة، ومسح ذاكرة التخزين المؤقت لـ apt، والتخلي عن البرامج غير الضرورية، وما إلى ذلك، إلخ.
بعد أن التزمت بنقل موقعي بالكامل واستثمرت الكثير من الوقت في العملية، تساءلت عما إذا كان بإمكاني فعل المزيد… ولكن بحلول ذلك الوقت، كنت قد فقدت الدافع للتحقيق أكثر. (راجع “مغالطة التكلفة الغارقة”). لتكون محددًا، كان حجم القرص الاسمي للخادم الافتراضي الخاص الذي كنت على وشك التخلي عنه هو 25 جيجابايت. حوالي 19 جيجابايت من ذلك كانت مخصصة للدليل /var/lib/docker/overlay2. وكانت حاويات Docker الوحيدة التي كنت أقوم بتشغيلها هي Discourse والمستقبل البريدي المرتبط بها. تشير التجربة إلى أن Discourse، على الرغم من قوته، يجب أن يكون قادرًا على العمل بمساحة أقل بكثير من 19 جيجابايت على القرص. ولكن يبدو أن عمليات البحث على الإنترنت تشير إلى أن إجراء تغييرات داخل دليل overlay2 غير آمن، لذلك شعرت أنني توقفت عند تلك النقطة.
في إعدادي الجديد تمامًا، يشغل الدليل /var/lib/docker/overlay2 مساحة 13 جيجابايت. لا يزال ضخمًا.
لقد اخترت Discourse لتشغيل المنتديات على موقعي الهواة الصغير على أمل أن “يعمل ببساطة” - أي أنه سيكون سهل الإدارة للغاية دون الحاجة إلى تعلم مجموعة من الأشياء الجديدة. يبدو أن هذا صحيح إلى حد كبير، إذا كان لدى المرء موارد كافية (مفرطة؟) لتخصيصها.
خطتي الجديدة هي أن آمل بشكل أعمى ألا ينمو دليل overlay2 بمرور الوقت ويغرق القرص البالغ حجمه 50 جيجابايت في خادمي الافتراضي الخاص الجديد. إذا كنت (أو أي شخص آخر) تعرف كيفية الحفاظ على حجم الثنائي الديناميكي لـ Docker و Discourse تحت السيطرة، فسأكون سعيدًا بسماع ذلك. ستكون بمثابة تتويج لطيف لبقية التعلم الذي قمت به في الأيام الأخيرة. شكراً مرة أخرى.
يسرني أنك تمكنت من إنقاذ نفسك. أدير منتدين صغيرين، أحدهما عن تخزين 20 جيجابايت والآخر عن 25 جيجابايت. يجب أن أستخدم الكثير من الوقت والبراعة أحيانًا للحفاظ على عمل ذلك. ولكن يبدو أنني أستمر في استخدام (ونشر عن) نفس مجموعة التكتيكات. انظر أدناه.
تطوير Discourse يحسن لأشياء أخرى غير العمل على أجهزة ذات تكلفة قليلة - على الرغم من أنه بالكاد يدير الاستمرار في العمل بالنسبة لي في بيئتي المقيدة. أتمنى أن يستمر ذلك.
المفتاح للعمل في إعدادات التخزين الصغيرة هو قياس ما يحدث - في كثير من الأحيان أرى الناس يخمنون ما قد يحدث. سيبدأ منهجي دائمًا بـ
لمزيد من المعلومات، ربما ابحث عن مشاركاتي عن prune و journalctl و kernel.