ترحيل إلى خادم جديد يحتوي على قاعدة بيانات جديدة ودلاء S3 جديدة للنسخ الاحتياطي والتحميلات

مرحباً،

أنا حالياً بصدد ترحيل الخادم الخاص بنا من تثبيت قائم على Bitnami (إصدار قديم جداً) إلى التثبيت المدعوم رسمياً في AWS باستخدام أحدث إصدار من Discourse. يحتوي هذا التثبيت الجديد على مثيلات Elasticache و RDS خارجية وسيستخدم أيضاً S3 للنسخ الاحتياطي والتحميلات.

لدي سؤالان:

  1. خادم Discourse القديم يعمل بإصدار قديم جداً - هل سيؤدي إجراء النسخ الاحتياطي/الاستعادة في خادم Discourse الجديد إلى تشغيل جميع أوامر الترقية ذات الصلة؟
  2. إذا قمت بنسخ ملف النسخ الاحتياطي إلى حاوية Docker الخاصة بـ Discourse الجديدة على الخادم الجديد وبدأت الاستعادة عبر سطر الأوامر، فهل سيتم الكتابة فوق قيم الحاوية (bucket) الجديدة التي قمت بتعيينها في التكوين الخاص بي كجزء من الاستعادة أم سيتم استخدام قيمي الجديدة؟ أفترض أنه سيتم ملء قاعدة البيانات الجديدة الخاصة بي من النسخ الاحتياطي، وبعد ذلك عندما أغادر الحاوية وأقوم بتشغيل ./launcher rebuild app سيتم استخدام قيم S3 الجديدة الخاصة بي.

إذا كانت افتراضاتي صحيحة، فقبل أن أقوم بالاستعادة أفترض أنه يجب علي نسخ محتويات حاويات S3 القديمة إلى الحاويات الجديدة؟

هل هناك أي عقبات أخرى للقيام بهذا النوع من الترحيل باستخدام نسخة احتياطية؟

شكراً مقدماً.

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

إعجاب واحد (1)

سببين لاحتياجنا إلى حاويات (buckets) جديدة:

١. لست متأكدًا بنسبة ١٠٠٪ من أن الترحيل من Bitnami سيعمل دون مشاكل، لذلك لا نريد التأثير على أي بيانات موجودة في حال احتجنا إلى إيقاف الترحيل.
٢. لقد قمنا بتغيير طريقة تسمية الحاويات، لذلك اعتقدنا أنه سيكون من الأسهل إنشاء حاويتين جديدتين لهذا الغرض.

النقطة الأولى هي ما يقلقني، لذا أكون حذرًا للغاية.

ما هي المشاكل التي تتوقعها مع حاوية التحميلات الجديدة؟ سيتم وضع خادم Discourse القديم في وضع القراءة فقط. الخطة هي أنه بمجرد تشغيل الخادم الجديد والتحقق من صحته، سنقوم بإيقاف الخادم القديم، وتغيير نظام أسماء النطاقات (DNS) إلى الخادم الجديد، ثم مسح ذاكرة التخزين المؤقت في شبكة توصيل المحتوى (Cloudfront)، ثم فتحه للجمهور.

فاتني أنك ستقوم بنسخ البيانات من الحاويات القديمة. ألقيت نظرة على AWS، ويبدو الأمر بسيطًا. لو كنت مكانك، فلن أعبث بتغيير الحاويات قبل الانتقال إلى AWS أو خادم جديد في مكان آخر.

[quote=“stevejr, post:1, topic:395948”]إلى التثبيت المدعوم رسميًا في AWS باستخدام أحدث إصدار من Discourse.
[/quote]
مدعوم رسميًا؟؟ لست متأكدًا تمامًا من ذلك.

أقترح بشدة أن تقوم بتحديث Discourse قبل الانتقال إلى خادم جديد.
على المثيل القديم، أقترح نقل إعداد S3 إلى ملف app.yml إذا لم يكن موجودًا بالفعل قبل النقل.

هذا شيء يمكنك اختباره بسهولة دون التأثير على الإنتاج.

شخصيًا، سأفعل كل ما بوسعي لتجنب القيام بهذين الأمرين في نفس الوقت.

  1. معرفة ما إذا كان بإمكانك تجنب نقل الحاويات على الإطلاق
  2. إذا لم تتمكن من ذلك، فافعل ذلك بعد الترحيل من Bitnami
إعجاب واحد (1)

أنا فضولي للغاية بشأن كيفية كون القيام بهذا النوع من التثبيت عرضًا ذا قيمة مضافة.
من المنشورات العديدة حول التثبيتات غير المدعومة، يبدو أنه يمثل المزيد من المتاعب بدلاً من الفائدة ما لم يقم الأشخاص بذلك للتعلم/التجريب.

قد يكون هذا الإعداد تثبيتًا غير مدعوم من منظور Discourse، ولكن من منظور مؤسسة تكنولوجيا معلومات للمؤسسات، قد يكون RDS و Elasticache قياسيين، ويكون تثبيت Discourse القياسي هو الغريب.