حاولت تشغيل discourse داخل lxd على خادم أوبونتو على جهاز raspberry pi 4 مع قرص SSD خارجي، وكان الأمر يتوقف ويحدث له انتهاء مهلة أثناء إعادة البناء، وكان التوقف أسوأ/مبكرًا عند استخدام مجمع تخزين btrfs loopback ولاحقًا عند استخدام مجمع تخزين zfs loopback. كانت الذاكرة ثابتة حول 1 جيجابايت مع ذروات 3 جيجابايت. كانت التوقفات تجعل ssh/top مستجيبين ولكن جميع أنشطة الاستخدام تنخفض إلى الحد الأدنى، مما يشير إلى أنه قد استسلم.
في الوقت الحاضر، توثيق lxd يوصي فقط بتعيين security.nesting إلى القيمة النصية true لتمكين استخدام docker، وهو ما فعلته. ومع ذلك، فإن توثيق lxd لديه أيضًا صفحة لتكوين الإنتاج مع حوالي 20 إعدادًا تحتاج إلى تغيير، والتي لم أجربها.
في النهاية، تخلت عن محاولة lxd الخاصة بي لـ discourse، وقمت بتشغيل discourse عبر docker على نفس الجهاز.
تفاصيل جهودي هنا:
من الغريب أن دليل lxd docker أدناه يوصي بـ btrfs على الرغم من أن توثيق lxd يوصي ضده، ولا يبدو أنه يستخدم قسمًا له (ومع ذلك يقومون بتعيين بعض الإعدادات الإضافية، وتثبيت حزم أخرى بدلاً من docker.io، ويربطون وحدة btrfs بـ docker فقط)، لذلك أتساءل لماذا واجهت مثل هذه المشاكل:
@vmsman هل يمكنك مشاركة المزيد من التفاصيل حول إعداد lxd الخاص بك، مثل الملفات الشخصية، ومجمعات التخزين، وأي إعدادات نظام احتاجت إلى تغييرات، حيث يبدو أن لديك الإعداد الأكثر نجاحًا حتى الآن:
بالنسبة لـ lxd، بعض الأشياء التي أتساءل عنها:
- ما إذا كانت الأقسام لمجمعات التخزين بدلاً من ملفات loopback ستحل مشاكل الأداء بما يكفي لاختفاء مشاكل التوقف
- ما إذا كان استخدام microcloud أو مجموعة lxd سيساعد، أو استخدام ceph كمجمع تخزين
بشكل عام، على الرغم من عدم نجاحي في تشغيل discourse في lxd، إلا أنني معجب جدًا بـ lxd وسهولة استخدامه. لقد أمضيت سابقًا أشهرًا في النضال مع hashicorp، حيث يبدو أن hashicorp مهتم فقط بحالات الاستخدام للمؤسسات. بينما يعمل lxd ببساطة ويبدو أن الأشخاص داعمون بما يكفي لتمكين الفرق الصغيرة والمطورين المستقلين من إحراز تقدم.