أحاول الانتقال من سلة GCP إلى سلة AWS S3. النظام القديم لا يستخدم CDN لـ S3 (يبدو أن الشخص الذي قام بإعداده لم يكن يعرف حقًا ما الذي يفعله).
استخدمت s3cmd لمزامنة سلة GCP القديمة مع نظام ملفات محلي، ثم استخدمتها مرة أخرى لدفع الأصول إلى سلة S3 الجديدة. تم الآن تكوين النظام بشكل صحيح مع S3 و CDNs للموقع كما هو موضح في استخدام التخزين الكائني للرفع (S3 والنسخ المماثلة).
اقترح الموضوع المرتبط بالأعلى استخدام rake posts:remap لتحديث المنشورات (أعتقد أنني يجب أن أعيد خبز جميع المنشورات أيضًا؟ أو على الأقل تلك المطابقة للسلة القديمة؟).
عندما قمت بتشغيل posts:remap، قام بإعادة تعيين منشور واحد فقط.
سأحاول إنجاز ذلك قريبًا جدًا. @Falco، بشكل عام، الأمر يشبه:
إنشاء سلة جديدة وCDN لها، وإعادة بناء الحاوية لاستخدام السلة/CDN الجديدة والتأكد من عملها.
تكوين s3cmd للسلة القديمة ومزامنة البيانات إلى المحلي.
تكوين s3cmd للسلة الجديدة ومزامنة البيانات إلى السلة الجديدة.
تنفيذ discourse remap OLD-BUCKET-DOMAIN-NAME NEW-BUCKET-DOMAIN-NAME.
إعادة الخبز.
هل يبدو ذلك صحيحًا؟
إذا استخدمت نفس CDN للسلة القديمة والجديدة، فقد توفر عليك إعادة الخبز، لكن ضبط التوقيت بدقة يبدو أمرًا معقدًا بعض الشيء (لا يمكن تغيير أصل CDN حتى تكون البيانات في السلة الجديدة، لكنك ستحتاج إلى التأكد من عدم رفع أي شيء إلى السلة القديمة أثناء عملية المزامنة) – ربما نقول فقط أن ذلك ممكن.
ربما يكون استخدام واجهة سطر الأوامر الرسمية من AWS أفضل للدليل؟
استخدم DbHelper.remap هنا.
غير ضروري.
استخدم نفس شبكة CDN وقم بتغيير مصدرها في لوحة التحكم الخاصة بشبكة CDN، أو استخدم شبكة CDN جديدة وقم بإعادة التوجيه باستخدام DbHelper.remap. لا حاجة لإعادة الخَبز في أي من الحالتين.
مرحبًا رافائيل. أنا اقتربت من النهاية. إصداري الحالي من هذا الدليل يشير إلى aws cli و gsutil لمزامنة البيانات من الخادم القديم إلى المحلي ومن المحلي إلى الجديد (أقوم فقط بربط هذه الأدوات وتقديم أمر سطر أوامر مملوء بأسماء الدلاء في عنصر نائب). ثم يستخدم DbHelper لتحديث الجداول. بالنسبة لموقعي ذو الحجم المتوسط، يعمل الأمر بسرعة كبيرة. رائع.
المشكلة الوحيدة التي أواجهها الآن هي أن التكوين القديم لم يكن يحتوي على s3_cdn_url، لذا فإن تلك الصور لا تزال مرتبطة مباشرة بالدلو (وليس CDN) في المنشورات. إعادة الخبز لا تساعد. الروابط الجديدة للصور التي يتم رفعها مرتبطة بشكل صحيح بـ CDN. لا يمكنك إصلاح هذا عن طريق تعيين DISCOURSE_S3_ENDPOINT: '' لأن ذلك لا يؤثر، لذا بعد استعادة قاعدة البيانات، اضطررت إلى مسح إعداد الموقع. هذا ليس سيئًا للغاية، لكنه تطلب مني العديد من عمليات إعادة البناء لاكتشاف ذلك.
لم يكن التكوين القديم يحتوي على تعريف CDN لـ S3. يمكنني إصلاح هذا عن طريق إعادة خبز جميع منشورات الـ 1250 التي تحتوي على عنوان URL/اسم المضيف للدلو، لكن هذا يتسبب في تحميل جميع تلك الصور وتحسينها (الخادم القديم يعمل بإصدار 2.7.0.beta5، لذا اعتقدت أنه سيتم إجراء بعض عمليات إعادة التحسين الحديثة بالفعل؟). هذا يسبب ضغطًا كبيرًا (متوسط الحمل 10-20) على خادمي البسيط الذي تبلغ سعته 2 جيجابايت (مع Postgres و Redis على RDS و Elasticache) لفترة طويلة. أعتقد أنني قد أحتاج إلى خادم EC2 أكبر لهذا الموقع على أي حال، لكنني ما زلت مندهشًا قليلاً من أن إعادة الخبز هذه تجعل الخادم ينهار (أخطاء 500 في واجهة المستخدم).
هل يجب عليّ بدلاً من ذلك محاولة استبدال اسم المضيف للدلو بعنوان URL الخاص بـ CDN في حقل cooked لتلك المنشورات؟
@pfaffman شكرًا لك على توجيهي إلى هنا.
لكن مشكلتي تفاقمت في الخطوتين الأخيرتين.
المشكلة الحالية: بعض الصور الخاصة بي مفقودة وتظهر أيقونات صغيرة مكانها. عند تمرير المؤشر فوقها، تُظهر عنوان “olds3bucket”. ولكن عند النقر عليها، تظهر بشكل صحيح بحجمها الكامل، ويُعرض الآن مسار “news3bucket” في شريط العناوين.
بشكل رئيسي، نصحتم بمزامنة بيانات الدلو القديم إلى الدلو الجديد، وهو ما قمت به بنجاح بالفعل.
ثم إدخال إعدادات الدلو الجديد في واجهة Discourse الويب، والتي أستخدمها منذ عام.
الآن تقولون إنه يجب “إعادة تعيين الخرائط” (remap) عنوان الدلو القديم إلى الجديد، ثم إعادة الخبز. هنا تكمن المشكلة. عندما أقوم بذلك (أو حتى عند إعادة الخبز فقط، أو حتى عند اختيار “إعادة بناء HTML” من قائمة إعدادات المنشور، سواء قمت بخطوة إعادة التعيين أم لا)، فإن الصور التي كانت تظهر كأيقونة فقط تختفي تمامًا. يظهر فقط “مساحة بيضاء” مكانها. لذا أقوم فورًا بإعادة التراجع/الاستعادة.