أنا حالياً بصدد ترحيل الخادم الخاص بنا من تثبيت قائم على Bitnami (إصدار قديم جداً) إلى التثبيت المدعوم رسمياً في AWS باستخدام أحدث إصدار من Discourse. يحتوي هذا التثبيت الجديد على مثيلات Elasticache و RDS خارجية وسيستخدم أيضاً S3 للنسخ الاحتياطي والتحميلات.
لدي سؤالان:
خادم Discourse القديم يعمل بإصدار قديم جداً - هل سيؤدي إجراء النسخ الاحتياطي/الاستعادة في خادم Discourse الجديد إلى تشغيل جميع أوامر الترقية ذات الصلة؟
إذا قمت بنسخ ملف النسخ الاحتياطي إلى حاوية Docker الخاصة بـ Discourse الجديدة على الخادم الجديد وبدأت الاستعادة عبر سطر الأوامر، فهل سيتم الكتابة فوق قيم الحاوية (bucket) الجديدة التي قمت بتعيينها في التكوين الخاص بي كجزء من الاستعادة أم سيتم استخدام قيمي الجديدة؟ أفترض أنه سيتم ملء قاعدة البيانات الجديدة الخاصة بي من النسخ الاحتياطي، وبعد ذلك عندما أغادر الحاوية وأقوم بتشغيل ./launcher rebuild app سيتم استخدام قيم S3 الجديدة الخاصة بي.
إذا كانت افتراضاتي صحيحة، فقبل أن أقوم بالاستعادة أفترض أنه يجب علي نسخ محتويات حاويات S3 القديمة إلى الحاويات الجديدة؟
هل هناك أي عقبات أخرى للقيام بهذا النوع من الترحيل باستخدام نسخة احتياطية؟
ربما فاتني شيء ما، ولكن لماذا تقومون بإنشاء حاويات جديدة؟ قد يكون إنشاء حاوية نسخ احتياطي جديدة بقواعد دورة حياة مناسبة أمراً جيداً، ولكن إذا كانت نسخة Discourse الحالية لديك تستخدم حاوية تحميل S3، فستواجه بعض المشاكل.
١. لست متأكدًا بنسبة ١٠٠٪ من أن الترحيل من Bitnami سيعمل دون مشاكل، لذلك لا نريد التأثير على أي بيانات موجودة في حال احتجنا إلى إيقاف الترحيل.
٢. لقد قمنا بتغيير طريقة تسمية الحاويات، لذلك اعتقدنا أنه سيكون من الأسهل إنشاء حاويتين جديدتين لهذا الغرض.
النقطة الأولى هي ما يقلقني، لذا أكون حذرًا للغاية.
ما هي المشاكل التي تتوقعها مع حاوية التحميلات الجديدة؟ سيتم وضع خادم Discourse القديم في وضع القراءة فقط. الخطة هي أنه بمجرد تشغيل الخادم الجديد والتحقق من صحته، سنقوم بإيقاف الخادم القديم، وتغيير نظام أسماء النطاقات (DNS) إلى الخادم الجديد، ثم مسح ذاكرة التخزين المؤقت في شبكة توصيل المحتوى (Cloudfront)، ثم فتحه للجمهور.
فاتني أنك ستقوم بنسخ البيانات من الحاويات القديمة. ألقيت نظرة على AWS، ويبدو الأمر بسيطًا. لو كنت مكانك، فلن أعبث بتغيير الحاويات قبل الانتقال إلى AWS أو خادم جديد في مكان آخر.
[quote=“stevejr, post:1, topic:395948”]إلى التثبيت المدعوم رسميًا في AWS باستخدام أحدث إصدار من Discourse.
[/quote]
مدعوم رسميًا؟؟ لست متأكدًا تمامًا من ذلك.
أقترح بشدة أن تقوم بتحديث Discourse قبل الانتقال إلى خادم جديد.
على المثيل القديم، أقترح نقل إعداد S3 إلى ملف app.yml إذا لم يكن موجودًا بالفعل قبل النقل.
أنا فضولي للغاية بشأن كيفية كون القيام بهذا النوع من التثبيت عرضًا ذا قيمة مضافة.
من المنشورات العديدة حول التثبيتات غير المدعومة، يبدو أنه يمثل المزيد من المتاعب بدلاً من الفائدة ما لم يقم الأشخاص بذلك للتعلم/التجريب.
قد يكون هذا الإعداد تثبيتًا غير مدعوم من منظور Discourse، ولكن من منظور مؤسسة تكنولوجيا معلومات للمؤسسات، قد يكون RDS و Elasticache قياسيين، ويكون تثبيت Discourse القياسي هو الغريب.
كما ذكر @RGJ، تستخدم بنيتنا التحتية للمؤسسات خدمات خارجية لأشياء مثل التخزين المؤقت وقاعدة البيانات وما إلى ذلك، ومن هنا جاء استخدام Elasticache و RDS. هذا يعني أنه يمكننا الحصول على نسخة احتياطية كاملة وتكرار لهذه الخدمات، وكذلك المساعدة في الضوابط الأمنية. هذا تثبيت رسمي/مدعوم من منظور Discourse - إنه يستخدم فقط مجموعة مختلفة من القوالب - نحن نستخدم discourse_docker/samples/web_only.yml at main · discourse/discourse_docker · GitHub (ربما كانت كلمة قياسي مضللة بعض الشيء، نعتذر).
لذا، يبدو أنه يجب علينا أولاً تحديث أسماء الحاويات الخاصة بنا للتثبيت الحالي ثم إجراء النقل إلى الخادم الجديد. تحديث التثبيت الحالي إلى أحدث إصدار غير ممكن - واجهنا مشكلات مع ترقية Bitnami سابقًا، ومن هنا جاء التحول إلى طريقة التثبيت الرسمية.
هل يمكنني أن أسأل، ما هي المشكلات التي من المحتمل أن تحدث إذا قمنا بإجراء الاستعادة باستخدام الحاويات الحالية ثم قمنا بتحديث app.yml للإشارة إلى الحاويات الجديدة - ألا تحظى جميع متغيرات البيئة DISCOURSE_ بالأسبقية على أي تكوين في قاعدة البيانات (إذا كان ذلك منطبقًا)؟ أم أن هناك شيئًا آخر يمكن أن يسبب مشكلة؟
لأنه إذا قمت بذلك قبل الترحيل وسارت الأمور بشكل خاطئ، فستواجه المشكلة على مثيل Bitnami الأقدم بدلاً من المثيل القياسي المثبت حديثًا. وبالإضافة إلى الإصدار القديم، حتى ذكر كلمة Bitnami سيجعلك تحصل على دعم أقل بكثير هنا في ميتا.
سؤال آخر إذا سمحت - عندما أقوم بتشغيل الاستعادة من سطر الأوامر داخل حاوية Discourse، هل يستخدم ملف الإعدادات الحالي /var/www/discourse/config/discourse.conf لتفاصيل الاتصال بقاعدة البيانات، واتصال Redis وما إلى ذلك، أم أنه يحل محل هذا الإعداد بما هو موجود في ملف النسخ الاحتياطي؟
يتم إنشاء discourse.conf من app.yml، ولا يتم تضمينه في ملف النسخ الاحتياطي.
بشكل عام، ما هو موجود في discourse.conf يتجاوز إعدادات الموقع.
لذا، إذا كان لديك setting_foo في قاعدة البيانات الخاصة بك، يمكنك تجاوزها عن طريق تحديد DISCOURSE_SETTING_FOO في ملف app.yml الخاص بك والذي سيقوم بعد ذلك بإنشاء setting_foo في discourse.conf.
إن توجيه حاوية Discourse إلى خادم postgresql و redis خارجي باستخدام صورة الحاوية الخاصة بنا مع الأدوات الخاصة بنا هو تثبيت مدعوم.
RDS[1] هو Postgresql، و Elasticache هو Redis، وهذا جيد.
يجب أن يكون هذا جيداً، فنحن نقوم بذلك للأشخاص الذين ينتقلون إلى الاستضافة الخاصة بنا.
أفضل أن أبقي العملية بسيطة قدر الإمكان، لذلك إذا كان بإمكانك تشغيل نسخة احتياطية كاملة (بما في ذلك التحميلات) على الخادم القديم واستعادتها على الخادم الجديد، فهذا يسمح لك باختبار الإعداد الجديد بالكامل دون أي تأثير على الإعداد القديم.
سأقوم بعمل النسخ الاحتياطي/الاستعادة دون تغيير أسماء الحاويات (buckets) كما اقترح @RGJ أيضاً. كما ذكرت، كان قلقي هو عدم التأثير على بيانات الخادم الحالية بأي شكل من الأشكال، ولكن إذا قمت بعمل نسخة احتياطية للحاويات الحالية أولاً وتأكدت من أن الخادم الحالي في وضع القراءة فقط (Read Only) أثناء الترحيل، أعتقد أن سلامة بيانات التحميل في الحاويات محمية بشكل جيد جداً.
