شكرًا لك على الشكر! لقد قمت بالإبلاغ عن ذلك للانتباه من قبل المشرفين لأنني لم أكن أملك حقوق التعديل في ذلك الوقت، لكنني أملكها الآن بفضل المنشور الذي قمت به. من المفارقات كيف تسير الأمور، أليس كذلك؟
ولكن قبل أن أقوم بإنشاء ملخص عام خارج قسم MinIO، هل يمكننا التأكد من أن Discourse ككل لم يعد يدعم المسارات غير المستندة إلى النطاق مثل هذا المنشور الذي بدأت فيه عملية البحث عن التعديل؟
إذا كنا نعلم أن Discourse ككل لا يدعم وضع المسار (أي المسارات minio.server.com/BUCKET/foo/bar/...) وبدلاً من ذلك يدعم فقط مسارات النطاق (أي BUCKET.minio.server.com/foo/bar/...)، فيمكننا جعل ذلك إشعارًا عامًا في الويكي وسأكون سعيدًا بالقيام بذلك - ومع ذلك، أحتاج إلى سماع ذلك من شخص أعلى في السلسلة مني (بصفتي شخصًا عاديًا في المجتمع) بأن هذا هو في الواقع المتطلب لـ Discourse. إذا كان الأمر كذلك، فيمكنني تعديله، وإلا … حسنًا، سأتركه كملخص في متطلبات MinIO.
MinIO هو الوحيد المستنسخ لـ S3 والذي يتمتع بشعبية ولديه سجل في استخدام نمط مسار S3 الذي تم إيقافه الآن، لذلك لا أعتقد أنه يستحق تحذيرًا عامًا، بل يكفي في قسم MinIO فقط.
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets فشل مع العودة #<Process::Status: pid 2064 exit 1>
موقع الفشل: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
فشل التنفيذ مع المعلمات {"cd"=>"$home", "cmd"=>["sudo -E -u discourse bundle exec rake s3:upload_assets"]}
فشل التمهيد برمز خروج 1
** FAILED TO BOOTSTRAP ** يرجى التمرير لأعلى والبحث عن رسائل خطأ سابقة، قد يكون هناك أكثر من واحدة.
قد يساعد ./discourse-doctor في تشخيص المشكلة.
مرحباً @Falco. هل هذا منطقي؟ أنا أراجع الردود للتأكد من التعامل معها حتى نتمكن من تفعيل خاصية الحذف بعد 30 يومًا في هذا الموضوع.
لقد تحققت من بعض التحميلات التي تم وضع علامة عليها كخاصة وكانت في مواضيع عادية، لذلك لم أتمكن من معرفة سبب وضع علامة عليها كآمنة. (هل لم يتم تعيين التحميلات الآمنة؟)
منطقي. لقد قمت بتحديث الجزء العلوي من المنشور الأصلي بهذه المعلومات. هل لديك أي فكرة عن سبب تمييز التحميلات المحلية على أنها آمنة في موقع لم يكن لديه S3 أو تحميلات آمنة ممكّنة؟
أعتقد أن هذه المشكلة المتعلقة بالتحميل إلى Cloudflare R2 قد يتم حلها باستخدام Upload.where(secure: true).update_all(secure: false). سأحاول الوصول إلى ذلك قبل حذف هذه الرسالة (لكنني أضفت ملاحظة إلى OP).
حسنًا، ليس لدينا أي تحميلات آمنة. أعتقد أنني سأجرب Cloudflare R2، حيث أن حدودهم المجانية سخية جدًا ولديهم أداة ترحيل S3 (تجريبية). أعتقد أنني سأكتشف ذلك، ولكن هل رأيت ما إذا كان R2 بخير في النهاية يا @pfaffman؟
لم أعد أتذكر ما إذا كانت المشكلة عند محاولة تحميل الصور أو عند تحميل صورة جديدة للتو. بالتفكير في الأمر مرة أخرى، أعتقد أنني اختبرتها على موقع جديد تمامًا.
الترحيل إلى منصة S3 مختلفة أمر صعب للغاية. هناك بعض المواضيع حول ذلك، ولكن إذا كنت ترغب في استخدام Cloudflare R2، فسأحاول أولاً تجربتها على موقع اختبار؛ هناك فرصة جيدة جدًا ألا تعمل.
إنه يعمل نوعًا ما، ولكنه غير جاهز للاستخدام في بيئة الإنتاج.
كان لدي تثبيت محلي قديم لـ Discourse 2.7 للتطوير معلقًا وكان يعمل بشكل جيد، من حيث تحميل الصور، واستخدام شبكة توصيل المحتوى (CDN)، والنسخ الاحتياطي إلى حاوية خاصة عند إعداده لـ Cloudflare R2. قمت بالتحديث إلى أحدث إصدار 2.9 (مثل الذي يستخدمه منتدانا) ويبدو أنه يفشل في معالجة استدراك Jobs::UpdateGravatar، حيث يستخدم ترميز الحاوية بشكل غير صحيح لـ Cloudflare حيث يحاول تخزين صورة بعيدة لـ Gravatar مؤقتًا في R2. مثال (حيث اسم الحاوية الخاصة بي على R2 هو ‘uploads’):
Upload Update (0.3ms) UPDATE "uploads" SET "url" = '//uploads.123123redact.r2.cloudflarestorage.com/original/1X/123123example.jpeg', "updated_at" = '2022-12-12 20:44:02.929494', "etag" = '9c02b086b2aa5e2088ed44e1017fa63e' WHERE "uploads"."id" = 3
لذلك، سأقوم بتشغيل واجهة المستخدم وستشير الصور الرمزية في إعداد الاختبار/التطوير المحلي الخاص بي إلى:
لذلك، تخميني الأفضل هو أن S3 لا بأس به مع ترميز نقطة الحاوية وأن Cloudflare R2 ليس كذلك، أو ربما يحتاج ذاكرة التخزين المؤقت لـ Gravatar إلى استخدام قيمة شبكة توصيل المحتوى (CDN) الخاصة بـ S3 بدلاً من ذلك؟ إنه لأمر مؤسف لأنه يبدو قريبًا جدًا.
تلقيت ردًا من Cloudflare يفيد بأنه بالنسبة لـ R2، حتى يقوموا بتطبيق ACL الكائن بشكل صحيح، فقد قاموا بتغييره لإرجاع 200 إذا حصلوا على قيم في هذا الخاصية التي لا يدعمونها بعد. هذا السلوك المتغير على R2 حول نهاية نوفمبر على ما يبدو. من الواضح أنه ليس مثاليًا (إنه في حاوية عامة، مع طلب واجهة برمجة التطبيقات أن تكون خاصة) ولكنه يعني أنه بالنسبة لهذه المشكلة، فإنه “يعمل” الآن.
أوه! هذا يبدو واعدًا. أعتقد أنك قد تحتاج إلى حاوية منفصلة للملفات التي تم تحميلها، على الرغم من أنه سيكون تخمينًا كبيرًا للحصول على اسم ملف النسخ الاحتياطي.
أنا أستخدم دلاء تحميل ونسخ احتياطي منفصلة، ويبدو أنها تعمل بشكل جيد، حيث أن دلاء النسخ الاحتياطي لـ R2 غير معدة لتكون عامة، وقام Discourse عبر واجهة المستخدم الإدارية بكتابة نسخة احتياطية مضغوطة هناك بشكل جيد. قمت بتنزيلها وألقيت نظرة عليها وبدت سليمة (ليست مثل الاستعادة الفعلية، ولكنها جيدة بما يكفي ليوم الاثنين). لقد اختبرت دلاء التحميل الخاصة بي بنطاق مخصص لإعداد S3_CDN ويبدو أن هذا يعمل بشكل جيد.
بصراحة، لا يمكنني حقًا معرفة ما يحدث مع نسختي 2.9 التي لا تعرض واجهة مستخدم في ember-cli (تصبح فارغة بالنسبة لي بعد إنشاء المستخدم الإداري)، ولكن من المحتمل أن يكون هناك شيء ستراه خاطئًا بسرعة.
تحرير: أوه، يبدو أنه يحاول تحميل أصول JavaScript الإضافية من Pseudo-S3/R2، على سبيل المثال، الكثير من 404 على أشياء مثل assets/locales/en.br.js.
لا أحصل على أي نجاح مع bundle exec rake s3:upload_assets، لذا هذا هو أفضل دليل لدي حاليًا.
تحرير2: نعم، يتعلق الأمر بالأصول، فإذا قمت بمسح DISCOURSE_S3_CDN_URL الخاص بي، فسيتم تحميل واجهة المستخدم. سأحاول فقط تحميل الأصول يدويًا في مكانها في الوقت الحالي.
تحرير3: تبدو المشكلة ببساطة في أن التطبيق يحتاج إلى تجميع مسبق للأصول والمكان الذي يشير إليه DISCOURSE_S3_CDN_URL، وفي بيئة تطوير محلية، هذا ليس معتادًا. سأكون مهتمًا بما سيجده @pfaffman، حيث أعتقد أن هذا سيعمل في مثيل مستضاف ذاتيًا تم نشره باستخدام Docker، باستخدام خطاف after_assets_precompile لـ R2.
نعم، بالنظر إلى الوراء، ليس من المستغرب في إعداد المطور. أعتقد أن ما لم أكن أتوقعه هو أنه مع تعيين DISCOURSE_S3_CDN_URL إلى Cloudflare CDN لـ R2 ولكن بعد ذلك تم تعيين DISCOURSE_CDN_URL إلى فارغ (أو محلي أو ngrok) ولكن بعد ذلك كان لا يزال يرغب في استخدام عنوان URL لسحب Cloudflare للأصول المترجمة مسبقًا وما إلى ذلك وليس فقط التحميلات/الصور وحدها. أعتقد أنه سيعمل في الإنتاج بشكل جيد في حاوية مناسبة، لذلك قد أجرب ذلك بسرعة. ستكون خطتي شيئًا مثل جعل تحميلات الوسائط TL4 مؤقتًا، وتبديل المعرفات وما إلى ذلك إلى Cloudflare في app.yaml، واختبارها، وإذا كانت جيدة، فتركها لـ R2 ثم استخدام rclone لجميع كائنات S3 الموجودة - بعد ذلك سأعيد خبز المنشورات ونأمل أن يكون كل شيء على ما يرام .
.