اضطررت إلى إيقاف هذا مؤقتًا في الوقت الحالي، حيث بدا أنه سيعمل ولكن بعد ذلك هناك شيء غريب يحدث مع R2 فيما يتعلق بترميز المحتوى مع الأصول إما عند التحميل وعدم تعيين الرأس أو شيء آخر. سيواجه خطأ “رمز غير صالح أو غير متوقع” نظرًا لأصل gz لشيء مثل browser-detect-7af298cd000a967d2bdc01b04807eda2924a388584ea38ad84919b726283c2ed.gz.js. يبدو أن rake s3:upload_assets يعمل ولكن الملفات لا تتم قراءتها بشكل صحيح من جانب المتصفح.
لا أفهم حقًا لماذا مع AWS S3 يكون الأمر جيدًا باستخدام عنوان URL للخادم المحلي للأصول (فهي غير موجودة في حاوية S3 الحالية لدينا للتحميلات) ولكن بالنسبة لاستخدام R2 فإنه يريد استخدام DISCOURSE_S3_CDN_URL للأصول فقط. إذا كان بإمكاني فرض الأصول من عنوان URL للخادم، فربما يعمل كل هذا.
تعديل: الدردشة على CF، يبدو أن هذه هي المشكلة، ومنذ اليوم سبب عدم إمكانية استخدام R2 مع Discourse دون بعض التغييرات. يمكنني كتابة نص برمجي في خطوة ما بعد الربط لإزالة أصول gz ولكنني أشعر أنني بالفعل “خارج المسار” بما فيه الكفاية ليوم واحد:
الملفات التي تضغطها (gzip) لا تتم معالجتها حاليًا بشكل صحيح بواسطة R2. يجب عليك تحميل الملفات غير المضغوطة. لدى Cloudflare ضغط شفاف، فهي تختار الهوية أو gzip أو Brotli بناءً على ما يمكن للعميل التعامل معه. هذا يختلف عن S3.
في هذه الحالة، ستقوم بتعيين DISCOURSE_S3_ENDPOINT=http://minio.mydomain.com:9000 و DISCOURSE_S3_CDN_URL=//assets.minio.mydomain.com:9000، وتعيين ملف /etc/hosts/ المحلي الخاص بك للإشارة إلى اسم النطاق الفرعي إلى localhost.
مرحباً @Falco - هل يشير هذا إلى الطريقة التي يعمل بها رأس Content-Encoding: gzip مع شبكة توصيل المحتوى (CDN) الخاصة بـ Spaces؟ يبدو هذا مشابهاً لـ Cloudflare R2، حيث يتم جعل موقع الأصول هو نفسه شبكة توصيل المحتوى (CDN) الخاصة بالتحميلات، لذا يتوقف gzip عن العمل؟ إليك ما يحدث مع R2 اليوم.
قد يكون من المفيد النظر في تبديل لهذا السلوك، أي تقديم الأصول من المصدر بدلاً من استخدام DISCOURSE_S3_CDN_URL دائماً؟ سأكون سعيداً بالبحث لمعرفة كيفية القيام بذلك، إذا كان سيتم اعتباره كتغيير محتمل في التكوين.
نعم، يمكنني فهم ذلك. إدخال قيمة منطقية جديدة للإعداد العام S3_ORIGIN_ASSETS (أو S3_BROKEN_PROXY_FUDGE ) في هذا المكان تقريبًا، يشبه كيف تسمح نصوص الاختبار غير المضغوطة بتخزين Digital Ocean Spaces و Cloudflare R2 وشبكة توصيل المحتوى (CDN) بالعمل مع Discourse فورًا، وهي ميزة إضافية لطيفة لا تتطلب الكثير من الجهد؟ ربما للنظر فيها في المستقبل على أي حال.
أوه، رأيت في ملاحظات الإصدار 3.0.beta أن هناك شيئًا ما تمت إضافته. سأجربه، إلا إذا أسأت فهم الغرض منه؟ قد يسمح باستخدام Cloudflare R2 و Digital Ocean Spaces مع شبكات توصيل المحتوى الخاصة بهم للقيام بتلك الأشياء الغريبة مع gzip.
أتاحت لي الإعدادات تحديد الموقع المحلي كنقطة انطلاق، للتغلب على الحاجة إلى وجود أصول JavaScript في موقع S3 (في هذه الحالة Cloudflare أو Digital Ocean Spaces مع تمكين CDN). شكرًا لـ @david على التغيير، حتى لو لم يكن هذا هو المقصود.
نحن نقوم بتشغيل منتدى discourse الخاص بنا على discourse.aosus.org مع R2 حاليًا (لم نقم بتشغيل migrate_to_s3 بعد)، ويبدو أن كل شيء على ما يرام! لا توجد مشاكل ملحوظة حتى الآن.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: "us-east-1" # اسم مستعار لـ auto
#DISCOURSE_S3_INSTALL_CORS_RULE: true # يجب أن يكون مدعومًا
DISCOURSE_S3_ENDPOINT: S3_API_URL
DISCOURSE_S3_ACCESS_KEY_ID: xxx
DISCOURSE_S3_SECRET_ACCESS_KEY: xxxx
DISCOURSE_S3_CDN_URL: your cdn url
DISCOURSE_S3_BUCKET: BUCKET_NAME
هل هناك طريقة لتحديد مضيفين منفصلين للنسخ الاحتياطي؟ سيكون من الرائع إذا كان من الممكن ترك R2 لأغراض CDN فقط.
من الغريب أن الإعدادات الموجودة في متغيرات البيئة لا تنعكس في واجهة المسؤول. هل يحدث تجاوز؟ هل ستقوم إعدادات S3 الجديدة في واجهة المسؤول بتجاوز تلك الموجودة في البيئة؟
) في هذا المكان تقريبًا، يشبه كيف تسمح 