Here’s the PR ![]()
I know; I too have spent too much time debugging docker-sync than I care to admit. This new approach, albeit not as fast, requires zero additional effort to setup and is quite stable from my own experiences!
Here’s the PR ![]()
I know; I too have spent too much time debugging docker-sync than I care to admit. This new approach, albeit not as fast, requires zero additional effort to setup and is quite stable from my own experiences!
لقد قمت أخيرًا بتثبيت Discourse على جهاز Mac الخاص بي… لكنه بطيء بشكل لا يُطاق… مثلما أواجه تأخيرًا هائلاً (20 ثانية لكل صفحة).
إذن سؤالي:
هل يواجه أي شخص آخر نفس المشكلة؟
هذه مشكلة في Docker لـ Mac. إعداد Discourse بشكل أصلي على جهاز Mac الخاص بك للتطوير سيحسن الأداء بشكل كبير.
ربما لا يجب أن يستخدم Discourse Docker على الإطلاق؟ لا أرى أي ميزة. بجدية، إنه مجرد طبقة إضافية وسيصبح تصحيح أخطاء الحاويات أمرًا مؤلمًا. مجرد قول.
يُوحّد Docker البيئة المحيطة بالتطبيق قيد التشغيل ويعزله عن المضيف.
سيكون كابوسًا لفريق Discourse دعم التثبيتات المستضافة ذاتيًا بدون Docker، حيث ستختلف بيئة المضيف والإعدادات اختلافًا كبيرًا بين مثيلات Discourse - خاصة بين Mac وLinux على سبيل المثال.
يتسبب Docker في انخفاض طفيف في الأداء على Linux (مع الاعتراف بأنه أكبر على Mac)، لكن المزايا هائلة لمشروع مفتوح المصدر مثل هذا يضم فريق تطوير موزعًا وآلاف المثيلات المستضافة ذاتيًا.
إذا كنت تريد تشغيل تطبيق على أي نطاق تجاري (مثل استخدام Kubernetes لتنسيق المجموعات)، فيجب عليك تجميع التطبيق في حاويات لعزل جميع تفاصيل التنفيذ بعيدًا عن المنسّق.
لا أستخدم Docker في بيئة التطوير الخاصة بي (على الرغم من أنني أعمل على Ubuntu). في الواقع، من المرجح أن الأمر يتطلب جهدًا أكبر بالطريقة التي أعمل بها، حيث إن إعادة البناء من الصفر أمر مرهق.
أردتُ الرد عليك يا @cmoi،
لقد قمتُ بتثبيت إعداد جديد للتطوير على جهاز ماك (لأغراض التطوير، انظر المنشور رقم #44 أعلاه) وهو يعمل بسرعة فائقة. لا توجد أي مشاكل على الإطلاق.
بشأن سؤالك الآخر
يقول @cmoi…
ربما لا ينبغي لـ Discourse استخدام Docker على الإطلاق؟ لا أرى أي فائدة. بجدية، إنه مجرد طبقة إضافية، وسيتحول تصحيح أخطاء الحاويات إلى كابوس. مجرد قول
نحن نستخدم Discourse في Docker في بيئات الإنتاج والاختبار، وهو رائع. أحد الأسباب هو أن الإعداد في Docker يستغرق جزءًا بسيطًا من الوقت والجهد مقارنة بالإعداد “على الجهاز المادي”. كما أنه أسهل بكثير في الاستعادة في حال حدوث تعطل في الخادم عند استخدام Docker.
لذا، هناك العديد من الأسباب لتشغيل Discourse في Docker (في بيئة الإنتاج)، دون شك.
ومع ذلك، بالنسبة لتطوير الإضافات، قمتُ أخيرًا بالتبديل إلى إعداد “على الجهاز المادي” بدون Docker، ويمكنني بالفعل رؤية أن تحميل وإعادة تحميل الإضافات، وتصحيح الأخطاء وكل هذه الأمور الممتعة ستكون أسرع وأكثر متعة خارج Docker، بالتأكيد.