ترحيل من استضافة إلى ذاتية: التحميلات السابقة تشير إلى discourse infra

الدعم
1

تم التحقق: https://meta.discourse.org/t/images-lost-when-migrating-to-self-hosting/52643، posts:rebake لا يفعل شيئًا جيدًا.

المشكلة
لقد اتبعنا التعليمات الرسمية وأنشأنا مثيلاً لـ Lightsail، ومن هناك قمنا بتنزيل قاعدة بيانات من واجهة مستخدم Discourse وطبقناها للحصول على 80٪ من الطريق. كانت الفكرة هي الانتقال إلى المثيل المستضاف ذاتيًا مع الاحتفاظ بالنسخة السابقة قيد التشغيل.

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

مع تحميل الصور الجديدة إلى المثيل المستضاف ذاتيًا، سنحتاج فقط إلى التحميل من المثيل المستضاف قبل تاريخ الانتقال. هذا يعني أننا لم نستخدم أبدًا تفريغ قاعدة البيانات الذي جاء مع صورنا وإلغائنا؛ نظرًا لأننا قمنا بالفعل بالترحيل، فقد انتهت صلاحيته الآن.

ألاحظ ثلاثة سلوكيات تتعلق بهذه النقطة الزمنية.

  1. تشير الموارد المشار إليها في النسخ الاحتياطي (تفريغ SQL، على وجه التحديد) إلى البنية التحتية لـ Discourse
  2. الموارد المشار إليها * التي تم إنشاؤها منذ ذلك الحين في النسخة الاحتياطية، على سبيل المثال صور المنشورات الجديدة، تتم الإشارة إليها بشكل صحيح وتوجد على بنيتنا التحتية

نتيجة لذلك، إذا قمت بإعادة تحميل مورد يقيم بنفس التجزئة، فسيرتبط ببنية Discourse التحتية. على سبيل المثال: محاولة إصلاح الأيقونة عن طريق تحميل نفس الأيقونة لا تعمل. ومع ذلك، يمكنني تحميل أي صورة عشوائية أخرى، وستعمل.

الحالة الحالية
حسب فهمي، فإن upload://<X> يمر عبر فك تشفير b62 (و sha1؟) أجزاء لربطها بالمجلد public/uploads. لدينا كل واحدة من هذه الصور:

يحتوي التفريغ الذي قدمه لنا فريق Discourse على ملف مضغوط مع default/original/1X ويمكن رؤيته حاليًا في /var/www/discourse/public/uploads/default/original/1X. يحتوي المجلد الأخير الآن على 329 عنصرًا، واحتوى التفريغ المقدم على 249 عنصرًا - هذا يبدو جيدًا بالنسبة لي.

هذا يعني أن البيانات يجب أن تكون قابلة للاكتشاف، حتى لو لم أتمكن من العثور مباشرة على التحميل في المجلد. أنا أتطلع إلى فهم هذه العلاقة، حتى أتمكن بطريقة ما من إصلاح الربط. في البداية، بدا الأمر وكأنه استبدال بسيط للسلسلة، وقد نجح ذلك في بعض الصور. ومع ذلك، تم استبدال بعضها الآن بـ transparent.png، حيث كانت في السابق مجرد صورة غير قابلة للوصول.

4

إذا فشل إعادة الخبز، فيجب عليك محاولة إعادة تعيين للبحث/استبدال جميع الإشارات إلى البنية التحتية لـ Discourse واستبدالها بروابط نسبية.

5

شكراً لك ريتشارد!

للتوضيح، عن طريق: Replace a string in all posts

باستخدام

rake posts:remap["find","replace","string",true]

قم بـ

rake posts:remap[
  "https://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/",
  "/uploads/default/"
]

المستبدل البديل للنسبي سيكون \"https://forum.everviz.com/uploads/default/\"

هل الرابط النسبي هو ما تفكر فيه؟

هـ: تصحيح الرابط النسبي باستخدام /

سطر واحد:

rake posts:remap["https://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/", "/uploads/default/"]
6

يبدو جيدًا بالنسبة لي! ستحتاج إلى إضافة شرطة مائلة في الأمام
/uploads/default/

7

هل قمت بالتحقق من تضمين جميع التحميلات أثناء أخذ نسخة احتياطية من موقعك المستضاف؟ إذا كنت مستضافًا مع CDCK، فقد كان هناك إعداد مخفي يحتاجون إلى تمكينه قبل أن تتمكن من أخذ نسخة احتياطية مع تضمين جميع التحميلات. لست متأكدًا مما إذا كان ذلك قد تغير الآن، ولكنك بالتأكيد تريد التنسيق مع مزود الاستضافة الخاص بك قبل إجراء النقل للتأكد من أنك تأخذ نسخة احتياطية كاملة (وليس مجرد تفريغ لقاعدة بيانات SQL).

8

كان مزود الاستضافة الخاص بي هو Discourse، وكنا على خطة شهرية. تقول واجهة المستخدم المستضافة الاتصال بـ team@discourse.com للحصول على الملفات التي تم تحميلها. كان ردهم هو أنني بحاجة إلى إلغاء الاشتراك للحصول على الملفات.

ولكن نعم، كما ذكرت، تلقيت uploads/original/1X

9

إنها نصيحة جيدة، لكن ربما قمت بها بالفعل:

root@...:/var/www/discourse$ rake posts:remap["//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/","/uploads/default/"]
هل أنت متأكد من أنك تريد استبدال جميع تكرارات السلسلة النصية لـ '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/' بـ '/uploads/default/'؟ (Y/n)
Y
إعادة تعيين
0 مشاركات تمت إعادة تعيينها!

كانت الروابط سابقًا https://europe1.discourse-cdn.com/standard21/uploads/everviz/ في المنتدى المستضاف. هذا بالطبع هو نفس الشيء، فقط يتم تقديمه عبر شبكة توصيل المحتوى (CDN). دعنا نحاول إعادة التعيين.

1 مشاركة تمت إعادة تعيينها.

أجد هذه الصورة مثيرة للاهتمام:

image
image2272×1242 357 KB

بالطبع، كان هذا قبل تشغيل كل هذه الأوامر التي تم إجراؤها اليوم وقبل النشر هنا. تم إرسالها إلى فريق Discourse قبل أن أقوم بتشغيل بعض مهام rake وما إلى ذلك.

10

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

إذا كنت لا ترغب في القيام بذلك بهذه الطريقة، فستحتاج إلى كتابة نص برمجي يقوم بتنزيل الصور من S3 وتحديث قاعدة بيانات Discourse وفقًا لذلك.

11

لقد قمت بالإلغاء واستلمت الملفات. على الرغم من أن النسخة الاحتياطية الأصلية لقاعدة بيانات discourse تشير إلى المسار في S3. في الأساس، لدي كل ما أحتاجه في /var/www/discourse/uploads/original/1X.

لقد استخدمت تفريغ SQL تم تنزيله يدويًا لملء المثيل، وليس الذي تم توفيره مع الملفات. كنت قلقًا من أن الأخير قد يوفر مسارات مصححة للصور، وهو ما تحققت منه الآن ولم يكن كذلك.

للتوضيح:


![](upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif) = 1aec065017da50538fe5866ae91a6396185234e1.gif

https://forum.everviz.com/uploads/default/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif

http://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif

<img src="https://forum.everviz.com/images/transparent.png" alt="" data-orig-src="upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif" role="presentation" width="1" height="1" style="aspect-ratio: 1 / 1;" loading="lazy">

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

12

لذلك أتوقع أن أواجه مشاكل.

في ما أفترض أنه منشور raw قمت بتضمينه، مع قاعدة البيانات المضمنة مع الملفات، أتوقع أن يشير ![](upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif) إلى مساحة التخزين المحلية الخاصة بك، ولكن إذا قام شخص ما بلصق رابط صراحةً لصورة على سطله، فسيتعين القيام بشيء ما لإصلاحه. إذا كانت الصورة موجودة وكان لديك إعداد التنزيل إلى محلي قيد التشغيل، فسيتم تنزيل الصورة من السطل (بالنظر إلى أنها استوفت معايير الإعداد).

لست متأكدًا تمامًا من كيفية إنشاء <img> الأخير في عينتك.

13

التنزيل إلى المحلي ممكّن.

بالنسبة للملف المرتبط، لا يتضمن تفريغ “رسمي” المسارات النسبية.


<img src="https://europe1.discourse-cdn.com/standard21/uploads/everviz/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif" alt="" data-base62-sha1="3Qa5S9sUTcc42dT4EFAbz5K0iJP" ...

يشير هذا المرجع الدقيق للملف أيضًا إلى cdck… في بعض الأماكن.

يبدو هذا جنونيًا بعض الشيء بالنسبة لي، لكن يمكنني إجراء نسخة احتياطية الآن. ثم تجاهل الإشارات إلى بنية Discourse لمسار محلي في تفريغ الملف نفسه، وإعادة تحميله.

قد يشير الملف الأخير إلى transparent.png لأنني قمت بإعادة طهي المنشور، ولم يعد بالإمكان اكتشاف الملف المصدر في بنية Discourse. لا أعتقد أننا ننظر إلى فقدان كامل للبيانات.

14

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

ولكن هذا <img هو منشور مُعالج، أليس كذلك؟ وليس المنشور الخام؟

15

الصورة من تفريغ قاعدة البيانات. أفترض أنها مطبوخة. يشير المنشور الخام إلى upload://
المنشور المطبوخ الحالي هو:

<img src="https://forum.everviz.com/images/transparent.png" alt="" data-orig-src="upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif" ...

حتى الآن لم أكن ناجحًا جدًا مع rake للعثور على الملفات المفقودة وإصلاحها وإعادة تعيينها وإعادة خبز المنشورات.

شكرًا جاي على كل مساعدتك!

16

الملف المشار إليه في المنشور المُعالج يعمل. لا توجد مشكلة في ذلك.

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

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

ماذا ترى في المنشور الخام؟ بعد إعادة خبز هذا المنشور، ماذا يُظهر المنشور المُعالج وهو ليس ما تتوقعه؟

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

17

لقد فعلت ما نصحني الجميع بعدم فعله: العبث بقاعدة البيانات وملف التفريغ الخاص بها. حاليًا، يعمل كل شيء تقريبًا، باستثناء بعض الحالات من:

<img src="https://forum.everviz.com/images/transparent.png"
alt="image" data-orig-src="upload://npqpp5O0wbL89nR9OXtP7Btu4hc.png"
width="517" height="90" style="aspect-ratio: 517 / 90;" loading="lazy">

لنحسب b62 ونأخذ سداسي عشري الخاص به

npqpp5O0wbL89nR9OXtP7Btu4hc = 0x a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba

الآن حاول العثور عليه من /var/www/discourse/public/uploads:

find . -name '*a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba*'
./default/original/1X/a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba.png

نعم!

932×164 18.5 KB

ولكن لماذا هو transparent.png في المنشور؟ لقد قمت بتشغيل rake uploads:recover_from_tombstone و rake posts:rebake

كيف وصلت إلى هنا؟

كان عمود التحميلات في قاعدة البيانات، لجدول url، لا يزال يعرض cdck كجزء من عنوان URL المصدر للصور. لقد دخلت إلى قاعدة البيانات من داخل الحاوية:

postgres psql discourse

ثم

UPDATE uploads
SET url = REPLACE(
           url,
           '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/',
           '/uploads/default/'
         )
WHERE url LIKE '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/%';

أظهر هذا نتائج واعدة، حيث ظهرت معظم الصور الأصلية والصور المصغرة مرة أخرى.

خطوة أخرى: تعديل ملفات التفريغ
الافتراض هو أن Discourse عديم الحالة* وأن الشيء الوحيد الذي نحتاج إلى الاهتمام به هو ما هو موجود داخل قاعدة البيانات. لم أكن متحمسًا للعبث بمهام rake أو ruby لهذا الغرض، حيث أنني لست على دراية كبيرة بأي منهما أو بالداخلية لـ Discourse. أريد فقط النتائج، بسرعة.

*باستثناء مجلد public الذي يحتوي على صورنا. يمكننا مع ذلك التأكيد على أن لدينا كل ما نحتاجه.
لذلك نقوم بتنزيل نسخة من قاعدة البيانات من واجهة المستخدم، ثم نفتحها في VSCode ونستبدل بشكل تدريجي إشارات cdck (الدلو) و europe1 (الدلو من CDN)

بشكل تدريجي أعني أنه في بعض الحالات سترى ‘// …’ وفي حالات أخرى سترى ‘https: //’. لذلك تحتاج إلى المطابقة والاستبدال ‘// …’ أولاً، وإلا سيكون لديك لاحقات https: عبر الملف.

ثم نعيد تحميل ملف التفريغ المعدل. جزء مما جعل كل هذا صعبًا هو خطوة base62، مما يجعل من الصعب قليلاً الانتقال من تمثيل خام إلى عنوان URL الفعلي للصورة.

18

تم إنجاز المهمة

بعد التحقق المزدوج من حجم جدول التحميلات، لاحظت أننا افتقدنا بعض المئات من الإدخالات. لا أعرف من أي خطوة فقدت. قمت بالدمج مع نسخة احتياطية من قاعدة البيانات من الماضي باستخدام انضمام SQL أساسي من جدول مؤقت.

كما ربما أشرت أعلاه، فإن عنوان URL المطلوب للصورة هو الذي تم تخزينه في جدول التحميلات، عمود url. من وحدة تحكم rails، قمت بإعادة تعيين هذه الإشارات إلى شبكة توصيل المحتوى (CDN) إلى نطاقنا المحلي باستخدام SQL عبر جدول التحميلات.

لماذا لم يتم استخدام مهمة rake

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

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

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

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.