مواقع متعددة مقابل حاويات متعددة

هل يعرف أحد إيجابيات وسلبيات استخدام الموقع متعدد المواقع (multisite) مقابل حاويات متعددة؟

أنا أدير حاليًا ثلاث نسخ من Discourse كحاويات منفصلة، وأفكر في تحويل منتديين، وربما ثلاثة منتديات أخرى إلى Discourse. ستكون هذه المنتديات على نفس الخادم (ذو ذاكرة وصول عشوائي 64 جيجابايت، وتشغيل أقراص SSD)، لذا أتساءل عن أفضل طريقة للمضي قدمًا.

أفضل أن تكون مستقلة قدر الإمكان، بحيث يمكن ترقية كل منها بشكل منفصل، ونسخها احتياطيًا واستعادتها بشكل منفصل، وأن لا تؤثر المشكلات في واحدة على الأخرى.

ما هو اقتراحك؟ هل هناك إيجابيات وسلبيات يجب الانتباه إليها؟

لن تتمكن من الترقية بشكل منفصل في حالة استخدام الموقع المتعدد، ولن تتمكن أيضًا من فصل الإضافات المستخدمة. فكل ذلك يُحدده الموقع المتعدد الجذري. ومع ذلك، يمكن إجراء الإعدادات، والمواضيع، والنسخ الاحتياطي بشكل منفصل.

عمومًا، ستحتاج إلى وكيل أمامي للمساعدة في شهادات SSL أيضًا.

في الواقع، لقد توصلت إلى طريقة للحصول على شهادات من Let’s Encrypt لعدة نطاقات دون إعادة التوجيه إلى النطاق الأساسي. Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy

@AstonJ، هل تود اختبار دليلي؟ أنا متأكد بنسبة 90% من أنه يعمل، لكن آخر مرة قمت باختباره كانت منذ عدة أسابيع، ولست متأكدًا تمامًا من أن التعليمات “تعمل” لشخص غيري.

إذا كنت تريد أن تحتوي جميع المواقع على نفس الإضافات ويتم ترقية جميعها في نفس الوقت، فإن التكوين متعدد المواقع ممتاز.

يمكنني ببساطة إيقاف أي إضافات غير مستخدمة عبر لوحة التحكم (وأعتقد أن هناك إضافة واحدة فقط لن يحتاجها أحد المنتديات)، لذا أعتقد أن الأمر يعتمد على ما إذا كانت هناك أي فوائد لاستخدام الموقع المتعدد؟ تحديدًا، الأداء و/أو الاستقرار؟

أعتقد أنني قرأت مرة منشورًا من @Blake يقول إنه جنوني عدم تشغيل PG في حاوية منفصلة (هل هذا مختلف عن الموقع المتعدد؟)، ومن هنا كان تفكيري في القيام بذلك. بالمناسبة، لا تأخذوا كلامي حرفيًا عما قاله بلaik، فقد يكون مجرد خيال مني :rofl:

أنا أستخدم HAProxy الذي يتعامل مع شهادات SSL الخاصة بنا، لذا أعتقد أن هذا قد يكون مقبولاً.

أعتقد أن الأمر سيخضع للفوائد يا جاي - إذا لم يكن هناك فرق كبير، فلا بأس لي بالاستمرار كما فعلت، حيث أصبح الإعداد والإدارة أسهل نسبيًا، لكن إذا كانت هناك مزايا كبيرة لاستخدام الموقع المتعدد، فسأكون مهتمًا بالتأكيد :sunglasses:

الميزة الأخرى هي أنك تشغل نسخة واحدة إضافية فقط من Rails و Nginx، لذا فإن الذاكرة العشوائية (RAM) الإضافية المطلوبة أقل بكثير. ومع ذلك، لديك الكثير من الذاكرة العشوائية، لذا فإن الالتزام بما يعمل بالفعل بدأ يبدو كفكرة جيدة.

مرحباً. هل من الممكن دمج المستخدمين من مواقع متعددة بحيث يمكن تسجيل المستخدم في جميع المواقع المتعددة في نفس الوقت عن طريق التسجيل في أحد المواقع (كما في ماجنتو). أو نسخة فائقة من استخدام ديسكورس، مشابهة للاتحاد. بحيث تعمل التنبيهات بشكل متزامن ويمكن لمستخدم الموقع رقم 1 تلقي تنبيهات من الموقع رقم 2؟ وينطبق الشيء نفسه على الدردشة.
لدي 4 مجتمعات في نفس الاتجاه الكبير، ولكن بمواضيع مختلفة، وأود أن تكون هذه المجتمعات متكاملة بشكل وثيق مع بعضها البعض

يمكنك جعل موقع واحد هو خادم مصادقة Discourse Connect وجعل جميع المواقع الأخرى تصادق ضده.

أحاول معرفة ما إذا كنت بحاجة إلى إعداد متعدد المواقع، أو حاويات متعددة، أو شيء آخر.

لدي حاليًا 3 مجتمعات مستقلة، اثنان منها متشابهان (كلاهما عن الرياضات الجامعية ولكن لمدرستين منفصلتين) والثالث عن الطبخ والخبز.

أود أن تكون هذه كلها على نفس الخادم (بسبب قيود عنوان IP من قبل مزود خدمة الإنترنت الخاص بي)، ولكن على عناوين URL منفصلة، تشبه إلى حد ما هذا:

foo.bar.com/team1
foo.bar.com/team2
foo.bar.com/cooking

team1.bar.com يعيد التوجيه إلى foo.bar.com/team1، وما إلى ذلك، أو إلى خوادم افتراضية منفصلة، سيكون مقبولاً أيضًا. (أعلم أن Apache يمكنه فعل ذلك، لذا أفترض أن nginx يمكنه أيضًا، إما مباشرة أو مع خادم وكيل في المقدمة.)

من الناحية المثالية، سيكون foo.bar.com نفسه بمثابة بوابة لهذه المجتمعات المستقلة، موضحًا ما هي وكيفية الوصول إليها. قد تكون بعض الفئات في كل مجتمع قابلة للقراءة بشكل عام ويمكن الوصول إليها بواسطة برامج زحف الويب حتى تظهر في عمليات البحث على الويب.

هل هذا إعداد متعدد المواقع أم إعداد حاويات متعددة، أم شيء آخر تمامًا؟

هل هناك أي مشاكل معروفة في تصميم المكونات الإضافية عند تشغيل Multisite؟

يبدو أن Chatbot الخاص بي لا يدعم Multisite (لذا فهي مشكلة معروفة)، ولكن أود أن أفهم السبب: إنه يعمل بشكل جيد في التثبيت القياسي.

على وجه التحديد، يبدو أن هناك مشاكل مع مهمة إعداد قاعدة البيانات وربما هذه المهمة.

أردت أن أقدم تحديثًا عن وضعي.

بعد بعض الدراسة، قررت أنني بحاجة إلى إعداد متعدد المواقع (حاوية واحدة في هذه المرحلة) مع موقع nginx “خارجي” لشرح الإعداد وتوجيه الأشخاص وحركة المرور إلى مواقع discourse المنفصلة. بهذه الطريقة يمكنني جعل كلا الموقعين مفتوحين للقراءة فقط (ولمحركات الويب) دون أن يضطر الأشخاص الموجودون على القائمة 1 إلى التعامل مع المحتوى من القائمة 2. قد أحتاج إلى العبث بملف robots.txt لإرضاء محركات الويب.

كانت أمثلة إعداد المواقع المتعددة مفيدة، لكنني لم أتمكن من جعلها تعمل مع مقبس Unix (خطأ في البوابة)، لذلك انتهى بي الأمر بإعادة توجيهها إلى منفذ آخر وإعادة توجيه هذا المنفذ إلى 443 داخل الحاوية.

في ملف app.yml الخاص بي، قمت بتمكين قالب SSL ولكن ليس قالب letsencrypt.

لقد نجحت في تشغيل موقع الاختبار، والآن أبحث عن أي مشاكل قد تنشأ عند تحويل موقع الإنتاج، على أمل في وقت لاحق من هذا الشهر أو الشهر المقبل.

أنا أهتم بمشكلة الشهادة على جانب الخادم الخارجي، لكنني واجهت مشكلة “غير آمن” التي قمت بإصلاحها عن طريق طلب https داخل الحاوية. لدي مهمة سأقوم بتشغيلها عبر cron لنسخ أحدث شهادة ومفتاح إلى دليل /shared/ssl الخاص بالحاوية (باسم ssl.crt و ssl.key). لست متأكدًا مما إذا كنت سأحتاج إلى فرض إعادة تحميل nginx داخل الحاوية للتأكد من تحميل شهادة جديدة عند تغييرها (في يوليو، أعتقد).

لقد واجهت مشكلة واحدة في discourse:

في ملف الحاوية /etc/nginx/conf.d/discourse.conf يوجد هذا الجزء من التعليمات البرمجية (تم تغيير اسم النطاق):

if ($http_host != 'site1.my.domain') {
   rewrite (.*) https://site1.my.domain$1 permanent
}

كان هذا يتسبب في إعادة توجيه site2.my.domain إلى site1.my.domain، لذلك كان عليّ التعليق عليه.

ملاحظة: إعادة بناء الحاوية تتطلب إعادة القيام بهذا التعديل، هل هناك طريقة لتجنب ذلك؟

وأدى ذلك إلى مشكلة في المتصفح، لأن فايرفوكس قد أشار إلى هذا التوجيه على أنه دائم، لذلك كان عليّ حذف ذاكرة التخزين المؤقت للمتصفح. (لقد استغرق مني ذلك وقتًا طويلاً جدًا لمعرفة ذلك!)

لقد توصلت إلى شيء غريب آخر.

على موقع الاختبار الخاص بي، لم يتم تحديد المعلمة المطلوبة لـ https لكلا الموقعين. على موقع الإنتاج الخاص بي، هذه المعلمة غير موجودة حتى في ملف الإعدادات. أنا أخمن أن هذا له علاقة بالاختلافات بين الموقعين.