لقد قمنا ببناء واختبار forum Discourse الخاص بنا مع البحث المتعمد عن الثغرات قبل نشره بالكامل في بيئة الإنتاج. لقد قمت مؤخرًا بنقل منتدى الاختبار الذي كان مفعّلًا فيه رفع الملفات عبر S3 من خادم إلى آخر، وعند الاستعادة، تم إعادة كتابة جميع الروابط الخاصة بأي ملف مرفق إلى رابط المنتدى بدلاً من رابط S3…
لحسن الحظ، هذا منتدى اختباري، لذا لا نهتم كثيرًا بالبيانات، ومع ذلك أود أن:
أ. أصلح هذه المشكلة.
ب. أجد طريقة لتخفيف أو منع حدوث ذلك في بيئة الإنتاج.
لم تكن المشكلة تقتصر على المنشورات فحسب، بل شملت جميع الصور والوسائط والمحتوى والصور الرمزية (وهو أمر مثير للقلق)…
قبل الاستعادة، يمكنك تكوين S3 في موقع الوجهة ضمن ملف app.yml (وليس عبر لوحة التحكم الإدارية). بمجرد التأكد من إعداد ذلك والقدرة على الوصول إلى الدلو الصحيح، يمكنك المضي قدمًا في الاستعادة، وسيتم ربط الوسائط بشكل صحيح.
لقد قمنا فعليًا بذلك، وهذا هو السبب في أننا انتهينا إلى هذا الموقف.
نسخت ملف app.yml كما كان إلى الوجهة، ثم قمت بنسخ احتياطي من الملف الأصلي. كانت المشكلة في عملية الاستعادة، حيث تم إعادة كتابة عناوين URL عند الاستعادة، على الرغم من عدم تغيير أي شيء ولا تزال عمليات تحميل S3 مفعلة.
لقد تم حل هذه المشكلة في النهاية عن طريق إعادة البناء (نعتقد ذلك، فذاكرة التخزين المؤقت في Discourse قاسية جدًا، لذا بين العديد من الحلول التي جربناها، لا نعرف فعليًا ما الذي حل المشكلة)، ومع ذلك تظل الأسئلة دون إجابة حول كيفية إجراء عمليات الترحيل بأقل قدر من المشاكل، أو حتى الاستعادة من نسخة احتياطية إذا اضطررنا إلى ذلك في بيئة الإنتاج.
يبدو أنك قمت بتكوين S3 عبر إعدادات الموقع، وليس عبر متغيرات البيئة كما اقترح كريس. تحتاج عملية الاستعادة إلى معرفة تفاصيل S3، وهذا غير ممكن باستخدام إعدادات الموقع.
يمكنك أيضًا إنشاء نسخة احتياطية دون تضمين الملفات المرفوعة من خلال وحدة التحكم إذا رغبت في ذلك: discourse backup --sql_only
لن تؤدي استعادة مثل هذه النسخة الاحتياطية إلى إعادة كتابة روابط الملفات المرفوعة. لذا، طالما أن الخادم الجديد لديه وصول إلى نفس سلة S3، فإن هذه الطريقة ستنجح.
إعدادات S3 موجودة في ملف app.yml، وليس في إعدادات الموقع.
تعديل:
أدرك أنني لا أقدم شرحًا مفصلاً بما يكفي، وليس قصدي إخفاء التفاصيل.
نحن نستخدم OVH S3 وهو مُهيأ في ملف app.yml.
قمنا بنسخ احتياطي لمنتدى الاختبار لدينا دون تضمين الملفات المرفقة، لكن S3 كان مفعّلًا في تلك المرحلة.
ثم استعدنا النسخة على الموقع الجديد بنفس ملف app.yml تمامًا، وهنا بدأت المشكلة. وللتوضيح، فقد تم حل المشكلة حاليًا، لكنني غير متأكد مما إذا كان السبب هو إعادة خبزها عدة مرات من جانبي أو بسبب التخزين المؤقت العدواني في نظام Discourse. ولهذا السبب أحتاج إلى معرفة الطريقة الصحيحة للقيام بذلك بشكل صحيح من المحاولة الأولى. مخاوفي هي أنه إذا اضطررنا يومًا ما لاستعادة نسخة احتياطية على مثيل الإنتاج الخاص بنا وواجهنا هذه المشكلة، يجب أن أعرف بالضبط كيفية إصلاحها في أسرع وقت ممكن قبل أن يلاحظ المستخدمون ذلك.