أود تعديل ملف app.yml الخاص بي لكي أستطيع تشغيل منصة Discourse أخرى (حاوية منفصلة، قاعدة بيانات منفصلة، وكل شيء يمكن تخيله منفصلًا! - من أجل قابلية النقل) على نفس الجهاز (الذي يعمل خلف nginx).
إذن، إعداداتي الأولى تبدو كالتالي (الأجزاء المهمة):
.. وهذا يعمل بشكل ممتاز - النسخة متصلة بالإنترنت وكل شيء على ما يرام. الآن، أود استضافة منصة Discourse أخرى، وقد قمت بتجهيز الأحجام المشتركة لها كالتالي في ملف app.yml آخر:
@Stephen: nginx ببساطة هي وكيل عكسي (reverse proxy) للمثيلة الأولى من discourse. لا يوجد شيء معقد. في الواقع، الإعداد الذي اتبعته هو نفس الذي تم نشره على meta.discourse لإعداد nginx كخادم واجهة أمامية.
لا توجد خدمات أخرى تعمل على هذه الآلة. في الواقع، ولأنها آلة إنتاجية، قمت بإعداد كل شيء في مجلد مستضاف منفصل تمامًا باسم discourse_site02. هل هذا مفهوم؟
هل ترى أي مشاكل في ملف app.yml الذي وصفته؟ أم تعتقد أن هناك خطأ في إعداداتي؟
هل هناك سبب يمنعك من استخدام تثبيت متعدد المواقع بحاويتين إذن؟ لا أعتقد أنك تفقد الكثير من قابلية النقل هنا، فالطريقة الأسرع لنقل النسخ بين الخوادم هي عن طريق نقل نسخة احتياطية.
في حال احتجت إلى نقل مثيل، ما عليك سوى تشغيل خادم جديد، وعلّم المثيل القديم بأنه للقراءة فقط، وأعد توجيه DNS، واستعد النسخة الاحتياطية. مع خدمة DNS ذات وقت TTL منخفض مثل Cloudflare، يمكن نقل موقع صغير في دقائق. سيشعر المستخدمون بفترة قصيرة من الوصول للقراءة فقط، ولن يُفقد أي محتوى.
من الأكثر كفاءة تقسيم الموارد بهذه الطريقة؛ فلن تنتهي بك الحال بتشغيل خادمين لقواعد البيانات وخادمين للويب في حاويات منفصلة، كما تلغي تمامًا الحاجة إلى وكيل عكسي Nginx.
@Stephen: نعم، لقد رأيت الرابط الذي أشرت إليه، ولكن من أجل بساطة الإعداد (فريق صغير هنا مع خبرة محدودة)، أود أن أفعل الأمر بالطريقة التي وصفتها والتي تؤدي في النهاية إلى وجود قاعدتي بيانات وخادمان ويب وما إلى ذلك. في الواقع، هذا هو بالضبط الإعداد الذي أفضله.
بصرف النظر عن عدم الكفاءة التي أشرت إليها، هل هناك أي مشاكل أخرى محتملة في هذا الشأن؟
هل ملفا app.yml اللذان عرضتهما صحيحان؟
أريد فقط معرفة ما إذا كان من المقبول التشغيل بهذه الطريقة بافتراض عدم وجود مفاجآت قد تلاحقني لاحقًا.