سنقوم بترحيل الخادم الخاص بنا وتثبيت discourse.
نحن نستخدم خادمًا جديدًا بنظام ملفات btrfs.
أقوم بإجراء بعض الاختبارات على جهاز اختبار، لقد نسخت جميع الملفات وقمت بتثبيت جميع الأجزاء الضرورية (nginx، docker، discourse نفسها).
لقد جربت نظام ملفات ext4 وعمل بشكل جيد.
ولكن الآن، عندما أفعل الشيء نفسه مع نظام ملفات btrfs مهيأ، أحصل على هذا الخطأ عندما أحاول ‘launcher rebuild app’:
تثبيت Docker الخاص بك لا يستخدم برنامج تشغيل تخزين مدعوم. إذا تابعنا، فقد يكون لديك تثبيت معطل.
overlay2 هو برنامج تشغيل التخزين الموصى به، على الرغم من أن zfs و aufs قد يعملان أيضًا.
من المعروف أن برامج تشغيل التخزين الأخرى تسبب مشاكل.
يمكنك معرفة نظام الملفات الذي تستخدمه عن طريق تشغيل "docker info" والنظر إلى سطر 'Storage Driver'.
إذا كنت ترغب في المتابعة على أي حال باستخدام برنامج تشغيل التخزين غير المدعوم الحالي لديك،
اقرأ الكود المصدري لـ launcher واكتشف كيفية تجاوز هذا التحقق.
من الواضح، أن docker info يذكر أنه يستخدم btrfs.
لقد قرأت في هذا المنتدى أن discourse لديها مشاكل مع بعض برامج تشغيل تخزين docker ولهذا السبب ترفض إعادة البناء.
هل هناك طريقة لتغييره إلى ‘overlay’ أو برنامج تشغيل آخر متوافق مع discourse وقادر على استرداد الملفات من نظام ملفات btrfs؟
كيف يجب أن أقوم بتهيئة docker؟
هل من الممكن القيام بذلك فقط لحاوية discourse وترك بقية تهيئة docker افتراضية؟
كل من overlay و overlay2 غير مدعومين حاليًا على btrfs أو أي نظام ملفات Copy on Write ويجب استخدامهما فقط فوق أقسام ext4.
نظرًا لأن Docker لا يدعم استخدام برنامج التشغيل overlay2 فوق btrfs، يبدو أن التوصية من أداة المشغل هي أقصى ما لديك من خيارات هنا. أي، استمر في تشغيل Discourse على نظام تدعمه Docker بواسطة ext4 أو قم بتعديل launcher لتجاهل برنامج تشغيل التخزين ونتمنى الأفضل.
سيؤدي التعليق على سطر exit 1 (بإضافة # قبله) في الأسطر التالية من البرنامج النصي launcher باستخدام محرر النصوص المفضل لديك إلى تحقيق هذا الأخير إذا كنت ترغب في اتباع هذا المسار:
بالنظر إلى أن “برامج تشغيل التخزين الأخرى معروف أنها تسبب مشاكل”، فلن أوصي بذلك.
إذن، إذا فهمت بشكل صحيح، فإن دوكر غير قادر على استخدام أي مشغل تخزين بديل للوصول إلى ملفات النظام الأساسية، إذا كنت تستخدم نظام ملفات COW مثل btrfs.
إذن لا يوجد حل جيد، حيث قد تواجه ديسكورس مشاكل في استخدام مشغل تخزين btrfs من دوكر.
العودة إلى ext4 ليست خياراً، حيث كان كل الانتقال للتأكد من أن ملفات البيانات بقيت تحت نظام ملفات COW btrfs، وقدرته على أخذ لقطات، والحفاظ على نظافة البيانات.
لا فائدة من استخدام btrfs في أجزاء أخرى من النظام، حيث أن هدفه الرئيسي هو توفير الوصول إلى منتدى ديسكورس.
إنه لأمر مؤسف لأنه سيكون من الرائع تشغيله مع حماية نظام ملفات COW.
من الأسهل استخدام العلامة --skip-prereqs. ولكن استخدامها في نظام الإنتاج قد يكون محفوفاً بالمخاطر.
لقد جربتها على جهاز الاختبار وهي تعمل بشكل جيد في الوقت الحالي، ولكن المشكلة تبدو في المدى الطويل.
استخدام --skip-prereqs يتجاوز العديد من الاختبارات الأخرى التي، كما ذكرت، تُدخل مخاطر مختلفة عند إجراء إعادة بناء. التعليق على هذا السطر الواحد ليس أكثر أو أقل خطورة من التشغيل على btrfs ويجب أن يتم دمجه تلقائيًا عندما يقوم المشغل بتحديث نفسه، مما يعني أنه يمكنك على الأرجح إجراء التغيير مرة واحدة وتنساه إلى حد كبير.
بصراحة، كانت تلك الرسالة موجهة إلى devicemapper القديم الذي كان يمثل مشكلة معروفة في الموثوقية.
على مر السنين، استخدمنا aufs ومؤخرًا نستخدم برنامج التشغيل overlay2، دون أي مشاكل. إذا كنت ترغب في استخدام brtfs لتجربته، فيرجى تقديم تقرير هنا بعد بضعة أشهر.
شكرا لك.
في خادم الإنتاج أخشى القيام بذلك.
إذا كانت هناك مشاكل مع مشغل docker وقام بكتابة بيانات تالفة، فلن يساعدك وجود لقطات أو نسخ احتياطية أو أي شيء آخر إذا حدث عطل.
إذا كانت هناك طريقة آمنة للاحتفاظ بالبيانات في نسخة احتياطية، فيمكنني المحاولة…
ما نوع المشاكل التي حدثت في الماضي؟
ولكن في الوقت الحاضر، هذه أنظمة الملفات COW مفيدة للغاية. يمكنك التقاط لقطات، والبيانات محمية ضد التلف أثناء الكتابة أو الأعطال الأخرى، ومن السهل إضافة مساحة أو نقل الأجهزة…
سيكون من الرائع إذا كان بإمكاننا رؤيته في discourse في المستقبل.
ربما يمكنني المساعدة في اختباره. لديّ جهاز قيد التشغيل في جهاز اختبار.
المشكلة هي أنه إذا قمت بتحرير ملف المشغل لإضافة btrfs إلى قائمة مشغلات تخزين docker المدعومة، فعند تشغيل البرنامج النصي، فإنه يشتكي من أن البرنامج النصي قد تم تغييره محليًا وسيتم الكتابة فوقه بواسطة الإصدار البعيد (من github).
كيف يمكنني حل هذا؟
ما هي الرسالة الدقيقة التي تراها وفي أي نقطة في إعادة البناء تحدث؟
لقد بدأت للتو تشغيل جهاز افتراضي كنت أستخدمه للاختبار وقمت بتعديل السطر، ثم أعدت البناء. في النقطة التي يقوم فيها المشغل بتحديث نفسه، قام بتنفيذ git pull وقام بدمج سريع كما توقعت، تاركًا التعديل سليمًا.
الإصدار الذي كنت أقوم بالتحديث منه لم يتضمن تغييرًا في المشغل نفسه ولكني أتوقع أن يعمل بنفس الطريقة طالما لا يوجد تعارض، أي طالما أن سطر exit 1 هذا أو الأسطر القريبة جدًا منه لم تتغير في المستودع.
لقد قمت بتغيير البرنامج النصي للمشغل ليشمل btrfs كأحد التنسيقات المقبولة.
في الدالة check_prereqs قمت بتغيير:
if ! $docker_path info 2> /dev/null | egrep -q 'Storage Driver: (btrfs|aufs|zfs|overlay2)$'; then
عندما حاولت لأول مرة إعادة بناء المشغل، تلقيت رسالة تفيد بأن المشغل قد تم تعديله محليًا، وما إذا كنت ترغب في المتابعة في تنزيل الملفات من المصدر.
لذلك اضطررت إلى تركه كما هو، وإجراء إعادة البناء وتغييره لاحقًا لبدء التطبيق.
لكنني حاولت اليوم إجراء إعادة بناء مرة أخرى، ويبدو أنه يكتشف التغيير ولكنه لا يشتكي ويتم الاحتفاظ بالتغيير.
لا أعرف ما إذا كان قد تم تغيير شيء ما مؤخرًا في المشغل، وربما كان لدي في الأصل مشغل قديم لم يقم بإعادة الإنشاء، والآن يقوم بذلك (بعد تحديثه بالأمس).
أنا أختبره باستخدام btrfs ويبدو أن كل شيء يعمل بشكل جيد، يمكنك بدء وإيقاف التطبيق، وإجراء النسخ الاحتياطي، كل شيء يعمل بشكل جيد حتى الآن.
يبدو أن Docker يقوم بإنشاء وحدات فرعية btrfs لبيانات تخزين الحاويات عند اكتشافه أنه يعمل على نظام ملفات btrfs ويستخدم برنامج تشغيل تخزين btrfs.
لذلك يبدو أنه يقوم ببعض التحسينات عند استنساخ الحاويات أو أخذ لقطات عبر أوامر Docker.
لكنني لا أعرف ما إذا كان برنامج التشغيل قد يكون به خلل بأي شكل من الأشكال (لا يبدو أنه برنامج تشغيل تجريبي في Docker، ولا توجد نصائح حول استخدامه في btrfs أو لم أتمكن من العثور عليها) وما إذا كان سيكون من الأفضل (إذا أمكن) تغيير معلومات Docker لتشغيله باستخدام برنامج تشغيل overlay2 كما لو كان يعمل على نظام ملفات قياسي.
من الناحية النظرية، سيكون من الممكن لـ Docker كتابة ملفاته وإجراء العمليات على نظام ملفات btrfs دون مراعاة قدراته (حيث أن btrfs لا يختلف عن أنظمة الملفات الأخرى على مستوى المستخدم، لعمليات إدخال/إخراج الملفات).
نرحب بأي آراء أو تجارب حول استخدام برنامج تشغيل تخزين Docker btrfs أو تكوين برنامج تشغيل overlay2 لاستخدامه عند استخدام Docker على نظام ملفات btrfs.
ليس لدي أي خبرة مباشرة لتقديمها، ولكني أنصح بشدة بعدم إجبار دوكر على السماح باستخدام مشغل overlay2 فوق btrfs. إنه غير مدعوم صراحة وقد يقوم مشغل overlay2 بافتراضات حول نظام الملفات قد تكون صحيحة أو غير صحيحة لـ btrfs، مما قد يؤدي إلى نتائج غير متوقعة. أنت حقًا لا تريد نتائج غير متوقعة على مستوى نظام الملفات.
سيتم التعامل مع عمليات نظام الملفات منخفضة المستوى بواسطة دوكر ومشغل تخزين btrfs. إذا كان هذا مزيجًا ناضجًا ويتم صيانته جيدًا، وليس به أخطاء معروفة كما كان devicemapper، فهناك فرصة جيدة لأنه سيعمل بشكل جيد.
السبب في عدم دعم btrfs في Discourse، على حد فهمي، ليس بسبب أي توقع بأنه سيفشل، بل ببساطة لأنه ليس لديهم معلومات كافية لإخبار الناس بأنه سيعمل.
ليس لديهم أي حافز (أو ما يكفي منه) لتشغيل خوادمهم الخاصة على btrfs، لذا فإن الطريقة الوحيدة لهم للحصول على هذه المعلومات هي من خلال الأشخاص في المجتمع الذين يجربونها في بيئة الإنتاج ويبلغون عن النتائج بعد فترات طويلة. لم يحدث ذلك بعد، لذا يظل غير مدعوم.
إذا وجدت نفسك في هذا الموقف في المستقبل، يمكنك دائمًا إعادة تعيين التغيير، والتحديث، ثم تطبيق التغيير مرة أخرى قبل تشغيل المشغل:
cd /var/discourse
git reset --hard
git pull
sed -i 's/Storage Driver: (/Storage Driver: (btrfs|/' launcher
./launcher rebuild app
لذا، لن أحاول استخدام مشغل تخزين overlay2 الخاص بـ Docker فوق نظام ملفات btrfs، سأدع Docker يستخدم مشغل btrfs متوقعًا أن يعمل بشكل صحيح ودون أي مشاكل.
هنا Docker Storage Drivers | Learn the Different Storage drivers of Docker يقولون إنها الطريقة الموصى بها ومدعومة رسميًا لـ SLE Linux، ولكنها موصى بها في Ubuntu.
يدعم Debian 10 و 11 نظام btrfs في النواة دون تعديلات ويدعم الإقلاع من قسم btrfs (يجب أن يكون قسم UEFI فقط من نوع آخر).
لذا أفترض أنه تم اختباره جيدًا.
يشير الرد من Rafael إلى عدم وجود سبب خاص لعدم استخدامه. كانت المشاكل مع devicemapper ووضعوا طلبًا لاستخدام أنظمة الملفات المعروفة، ربما في وقت لم يكن فيه الكثير من الاهتمام بـ btrfs أو أنظمة COW الأخرى.
سأجرب ذلك.
سأبلغ عن تجربتي (جيدة أو سيئة) في استخدامه.
حتى الآن يعمل بسلاسة ويسمح لي بتغيير حجم نظام الملفات بسهولة، وإضافة أجهزة، وإزالتها، وما إلى ذلك، ويعطيني الثقة في أن البيانات الأساسية صحيحة وستظل خالية من الأخطاء.
الاحتياط الوحيد هو مع مشغل تخزين Docker إذا لم يتم اختباره بما فيه الكفاية، ولكنه يبدو أنه تم استخدامه على نطاق واسع في SLE (الذي يطبق btrfs كنظام ملفات تخزين افتراضي منذ فترة طويلة).
حسنًا، يجب أن أقول إننا نقوم بتشغيل discourse على نظام ملفات btrfs لما يقرب من شهر دون أي مشكلة واحدة.
إنه يعمل بسلاسة.
تبدو برامج تشغيل btrfs الخاصة بـ docker تعمل بشكل مثالي.
سيكون من الرائع لو اختبر أشخاص آخرون تشغيل discourse فوق btrfs وتم دمج دعم btrfs ضمن توزيع discourse.
نتوقف عن المنتدى للحظة، نأخذ لقطة باستخدام btrfs (بضع ثوانٍ) ونعيد تشغيله.
ثم نقوم بعمل نسخة احتياطية خارجية للقطة المأخوذة.
يبدو أنه يعمل بشكل مثالي.
لقد قمت باستعادة النسخة الاحتياطية على جهاز آخر للاختبار وهي تعمل.