هناك حاويات لينكس (LxC). هناك نصوص برمجية للأجهزة الافتراضية (VMs). يمكنك إنشاء مثبت ISO.
حاويات LxC هي حرفياً حاويات.
بالنسبة لمسؤولي الأنظمة، فإن هراء دوكر هذا غير ضروري وعديم الفائدة إذا كان لديك إعداد شبكة بجدران حماية. إلخ.
أتفهم أن هذا تثبيت بسيط لمن لا يعرفون كيفية استخدام لينكس وتأمينه، ولكن بالنسبة لمسؤولي الأنظمة الذين يتعين عليهم تعلم دوكر، فهذا غير مجدٍ. ستكون LxC والأجهزة الافتراضية دائمًا أفضل بكثير من دوكر.
بالنسبة لمسؤولي الأنظمة الذين يديرون الخوادم، نقوم بإنشاء LxC وأجهزة افتراضية في شبكة منفصلة. لذلك قمت بإنشاء جهاز افتراضي مخصص لـ discourse لإنشاء حاوية دوكر. -_-
إذن الآن هناك شبكة داخل شبكة. جهاز افتراضي مخصص ومعزول وفقط لإنشاء حاوية دوكر معزولة عن كل شيء -_-
لا يوجد دليل لتثبيته بدون دوكر، بغض النظر عما إذا كان يأتي مع دعم أم لا. لا يوجد دليل أو مساعدة لكشف عنوان IP الخاص بالمضيف للحاوية.
لأنهم عندما بدأوا في تطوير Discourse، كان أفضل شيء متاح.
لو كانوا سيفعلون ذلك اليوم، أعتقد أن الشيء الوحيد الذي قد يفعلونه بشكل مختلف هو استخدام docker-compose بدلاً من أمر launcher المخصص الخاص بهم الذي يبني ويشغل صور دوكر.
يجب أن تكون على إنترنت مختلف عن الذي أنا عليه. من كل ما أراه، فإن معظم من يديرون البرامج على أكثر من 5 خوادم، على سبيل المثال، يستخدمون نوعًا من الحاويات لإدارة الأشياء. بشكل متزايد، يقوم المطورون بتشغيل الأشياء على أجهزتهم المحمولة في حاويات لرؤية أن إصدارات كل شيء يتم الحفاظ عليها متسقة.
حتى إدارة بيئة تطوير Discourse/rails/ember على جهاز محمول واحد يمثل تحديًا.
هذا صحيح. إذا كنت تريد منتدى يمكنك استخدامه بدون دوكر، فلا يجب عليك استخدام Discourse.
أنا أؤيد هذا. سيكون docker-compose أفضل بنسبة 100٪ حيث شاهدت للتو دورة تدريبية مكثفة حول docker و docker-compose. يبدو أنه إذا استخدم Discourse docker-compose، لكنت قد حللت هذه المشكلة دون الحاجة إلى إنشاء منشور.
يقوم docker-compose بكل العمل الشاق بشكل مشابه لما يفعله المشغل، ولكن مع docker-compose كان بإمكاني بسهولة تكوين الشبكة والجسر.
أتفق. أنا أستخدم الحاويات. فقط حاويات LxC نقية. لا يلزم أي برنامج إضافي. الأمر ليس بهذه البساطة. على سبيل المثال: أحد خوادمي لدي حزمة برونزية وهي أساسًا للمطورين. إعداد رخيص وسهل. في اللحظة التي يتم فيها تأكيد الدفع، يتلقى الخادم الرئيسي طلبًا لإنشاء حاوية lxc أو جهاز افتراضي بناءً على اختيار المستخدم، ومن الواضح أن اسم النطاق مطلوب أو سيتم إصدار اسم نطاق فرعي مخصص للخادم (lxc/vm). كما أنه يطلب من المستخدم تكوين شبكته الخاصة والتي لا يمكن الوصول إليها بعد ذلك بواسطة الشبكة الرئيسية والعكس صحيح. إنه في الأساس AWS صغير.
لل development، سيكون docker استثنائيًا لأجهزة الكمبيوتر المحمولة وأغراض التطوير لفصل ملفات الكمبيوتر الرئيسية وملفات التطوير بما في ذلك الشبكات.
لا يمكنني الموافقة أو الاعتراض لأنني لم أقم بتطوير أي شيء شخصيًا باستخدام Discourse/rails/ember. هذا خارج نطاقي وإذا قال المطورون إنه أسهل، فلا مكان لي للاعتراض على شيء لا أعرفه.
هذه هي مشكلتي، لقد أجريت بحثًا كافيًا على جميع برامج المنتديات المتاحة واستخدمت عددًا قليلاً منها.
خياراتي كلها انحصرت في منتدين:
Discourse
Flarum
اخترت Discourse كأفضل برنامج للمنتديات من جميع النواحي وبسبب خبرتي الوحيدة مع docker والتي كانت Nginx Reverse Proxy Manager.
اعتقدت أن كل ما علي فعله هو إدخال بعض معلوماتي في ملف .yml ثم تشغيل docker-compose up -d. كنت مخطئًا.
المشكلة التي أواجهها حاليًا يمكن حلها، فقط ستستغرق بعض الوقت في اكتشافها.
أرفض استخدام Flarum لأنني استخدمت Discourse على العديد من المنصات وبدون إساءة للمنتديات الجيدة الأخرى الموجودة، لكن Discourse هو أفضل منتدى متاح في السوق.
بعد إجراء بحث سريع وبعض الأدلة السريعة لمدة 5 دقائق بالإضافة إلى بعض مقاطع YouTube.
لا، دوكر ليس سيئًا على الإطلاق. دوكر مثالي للمطورين الذين يستخدمون أجهزتهم الشخصية للتطوير أو حتى أجهزة العمل. نظرًا لأن معظم المطورين لا يستخدمون لينكس كنظام تشغيل أساسي لهم، فإن إنشاء حاويات LxC لن يكون بنفس السهولة. هذا هو المكان الذي يأتي فيه دوكر. إنه يدعم جميع الأنظمة الأساسية الرئيسية مما يسمح للمطورين بالتعاون بسهولة، والميزة الإضافية هي عدم إفساد نظامك بالكامل بملفات غير مخصصة للاستخدام من قبل النظام الأساسي.
يمكنني بالفعل الخوض في بعض التفاصيل الإضافية ولكن أحدث إصدارات docker/docker-compose مثالية للمناقشة حيث أرى أنها تتطلب الكثير من الأجزاء المتحركة ومن السهل جدًا تجميعها باستخدام docker-compose. بهذه الطريقة، إذا حدث خطأ ما، سيعرف المطورون بالضبط ما يجب عليهم فعله.
لدي فكرة لـ Discourse ولكن أولاً سأقوم بحل مشكلة التثبيت الخاصة بي.
استضافة تطبيقات Rails أمر معقد. حتى لو كان لديك بالفعل Postgres و Redis و Ruby مثبتين على خادمك، فلا يزال يتعين عليك القلق بشأن تشغيل ومراقبة عمليات Sidekiq و Rails الخاصة بك، بالإضافة إلى تكوين Nginx. مع Docker، يتوفر لك تكوين Discourse المحسّن بالكامل في حاوية بسيطة، إلى جانب واجهة مستخدم رسومية تستند إلى الويب تجعل الترقية إلى إصدارات جديدة من Discourse سهلة مثل النقر على زر.
لست بحاجة إلى عزل الحاوة؛ يمكنك تشغيلها على جسر موجه أو على جسر يمتلك منفذًا ينتمي إلى شبكتك الداخلية. الأول هو كيف نقوم بتشغيله في بيئة الإنتاج - انظر هنا مقطع فيديو بواسطة @mpalmer يشرح كيفية عمله.
إذا أراد شخص ما حقًا القيام بذلك، فيمكنه اتباع نفس الخطوات التي اتخذها ملف Docker للحصول على الإصدارات الصحيحة لجميع الأدوات التي تستخدمها الصورة المدعومة.
ليس لدينا دليل لأن ذلك سيتطلب من شخص ما صيانته، والغالبية العظمى من الأشخاص الذين يريدون ذلك لديهم إما:
خبرة قليلة في الخوادم
معرفة كافية لأخذ ما نقدمه وتكييفه مع احتياجاتهم
على سبيل المثال، أعرف أن هناك أشخاصًا يستخدمون “launcher” لبناء صورة يتم نشرها من خلال أدواتهم الخاصة (سواء كانت lxc أو kubernetes أو أي شيء آخر) وهذا يعمل معهم.
محاولة دعم (مجاناً) كل شخص يستخدم تثبيته المخصص لبرنامج معقد ستكون كابوساً.
Docker هو حل وسط. نظامنا ليس مثاليًا؛ لقد نما قليلاً بمرور الوقت وبالتأكيد نشعر بألم بعض إعادة الهيكلة المتأخرة. لقد أنشأنا “launcher” قبل أن يوجد docker-compose حتى.
نعتزم إعادة هيكلته و/أو الانتقال إلى docker-compose، ولكن هذا ليس أولوية في الوقت الحالي.
ليس من الصعب جدًا تشغيل المشغل لبدء Discourse باستخدام متغيرات البيئة المطلوبة لكي يعمل وكيل Nginx العكسي. في الغالب، ما عليك سوى إضافة متغير البيئة إلى YML، أو إضافتها إلى ما تحصل عليه من ./launcher start-command app.
لم يكن docker-compose مفيدًا جدًا عندما بدأ Discourse، وربما لم يكن موجودًا على الإطلاق.
أنا أكره Docker (إنه سهل للغاية بالنسبة لي، يمكن لأي طفل القيام به، لذا لا شيء مميز! يا للملل)! وبدلاً من مجرد كتابة الكود بحيث يعمل أيضًا بدون Docker الرسمي… لا أفهمه! حتى الطريقة الرسمية لا تعمل!
