تغيير مجلد الصورة إلى مجلد مرتبط برابط رمزي

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

لقد اختبرت الإعداد للتو، لكن النتيجة ليست جيدة. نسخت جميع ملفات الصور من /var/discourse/shared/standalone/uploads إلى /var/www/image/uploads
ثم،

  • أنشأت روابط رمزية لمجلد الصور المحمل عبر NFS
  • chmod & chown w/ www-data:www-data و 755 لمجلدات /uploads

يمكنني رؤية الصور على الخادم الأساسي حيث يتم تحميل مجلد الصور محليًا، ولكن ليس على الخادم الثانوي المحمل عبر NFS. الصور مفقودة بحجم الحاوية.

بالإضافة إلى ذلك، حتى على الخادم الأساسي، يمكنني الرؤية، ولكن لا يمكنني تنزيل الصورة بعد الآن.

أعتقد أن السبب هو إذن الملف. أتساءل ما هو الإعداد المثالي.

لست متأكدًا مما إذا كان هذا هو الإعداد الافتراضي أو بسبب عشرات عمليات إعادة البناء، ولكن الصور في المجلد الافتراضي هي 755/644 (مجلد/ملف) و main_id:www-data على خادمي. لقد نسخت نفس الاستراتيجية، لكنها لم تنجح. قد تكون مشكلة ارتباط رمزي أو مشكلة خاصة بـ NFS، لكنني لم أعد أستطيع التتبع.

ماذا لو استخدمت شبكة توصيل محتوى (CDN) للصور بدلاً من ذلك؟

@NateDhaliwal شكراً على الفكرة.

لقد توقفت عن استخدام خدمات CDN مثل S3 منذ فترة طويلة. أنا أستخدم Cloudflare فقط، لكنها لا تخزن الصور فعلياً.

صححني إذا كنت مخطئاً، لكن أعتقد أنك تشير إلى CDN محلي مثل تعيين نطاق Nginx بسيط، واستخدام امتداد CDN الخاص بـ Discourse مثل تمكين CDN لـ Discourse الخاص بك - التوثيق / الاستضافة الذاتية - Discourse Meta

إذا لم يكن هناك حل آخر، فسأفعل ذلك. اعتقدت أن أذونات الملفات هي حل أسهل.

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

بدلاً من الارتباط الرمزي، قم بتغيير تحميل docker ليشير إلى تحميل nfs الخاص بك.

ولكن الحصول على الأذونات داخل الحاوية، وخارج الحاوية، وعلى خادم nfs البعيد بشكل متزامن يمكن أن يكون صعبًا بالتأكيد.

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

كانت هذه محاولتي الأولية. داخل الدوكر، وجدت أن نظام الملفات الخاص بي كان في حالة فوضى إلى حد ما، وهو ما وجدته سابقًا. كان متداخلاً /uploads/uploads/uploads قبل رؤية /default/. لست متأكدًا مما حدث بالفعل، لكنني نسخت جميع الملفات من الداخل إلى مجلد الصورة الخاص بي، وأضفت مجلد التركيب كوحدة تخزين.

هنا، لم يكن الوضع مختلفًا كثيرًا عن الرابط الرمزي. أذونات الملفات تخلق بالفعل نفس المشكلة. بعد فهم أن الملفات مخزنة بالفعل خارج حاوية دوكر، اعتقدت أن الرابط الرمزي يمكن أن يكون حلاً أسهل بكثير.

لكليهما، أنا متأكد تقريبًا من أنها أذونات الملفات، ولكن شبكة توصيل المحتوى المخصصة بواسطة كتلة خادم Nginx تبدو حلاً أبسط بكثير من وحدة تخزين دوكر، طالما أن الرابط الرمزي لا يعمل.

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

هل يدعم Discourse شبكة توصيل محتوى (CDN) مخصصة تعتمد على CNAME؟ أتذكر رؤية تكوين S3 في لوحة الإدارة ومنشورات ميتا لـ Fastly، لكن لا يمكنني تذكر تكوين CDN المخصص تمامًا.

وجدت المنشور. أعتقد أنني بحاجة إلى إعداد نسخة مستضافة ذاتيًا من شبكة توصيل محتوى متوافقة مع S3. مجرد خادم صور Nginx ليس كافيًا.