حاولت أولاً تشغيل Discourse بإعدادات شبه افتراضية وعملت بشكل جيد جدًا، وتمكنت من تحميل الملفات بالإضافة إلى القيام بأشياء أخرى.
ثم أدركت أن المسار في app.yml كان /var/discourse وقمت بتحديثه إلى /var/www/discourse، وأوقفت ودمرت الحاوية، وأزلت المجلد السابق بالكامل. وقمت بتشغيله مرة أخرى… ولكن لاحظت الآن أنني لم أعد أستطيع تحميل الملفات.
ما نوع الأذونات التي يحتاجها مجلد uploads؟ يمكنني إجراء بعض التغييرات يدويًا، ولكن أود أن أعرف بالضبط وما إذا كان ذلك جيدًا بشكل عام (ألا يجب أن يتولى المشغل إعداد الأذونات الصحيحة، خاصة عند تشغيله من البداية؟)
هذا ما هو موصى به.
المسار /var/www/discourse هو المسار لـ discourse داخل الحاوية. /var/discourse هو المسار العادي لـ Discourse_docker خارج الحاوية.
نظرًا لأنك بدأت للتو، أوصي بأن تبدأ من جديد ولا تقم بإعادة تسمية أي شيء هذه المرة.
تخميني هو أنك لم تقم بتحديث المسار في ملف app.yml الخاص بك، ولذلك فهو يحاول الوصول إلى شيء غير موجود.
لدي العديد من المشاريع الأخرى على هذا الخادم وجميعها موجودة بشكل جيد في مجلد /var/www الخاص بي، لذلك أفضل الاحتفاظ بها هكذا ولا يهمني كيف هو الأمر داخل الحاوية.
حسنًا، لم ينجح أي شيء، لذا انتهى بي الأمر بتغيير الأذونات للمجلد uploads إلى 755 وهو يعمل الآن. بعد إعادة البناء، يبدو أن التحميلات نفسها كانت جيدة (من جانب المحرك)، ومع ذلك لم يتمكن nginx من قراءتها.
لا أفهم تمامًا لماذا تفعل كل هذا. إنه اختيارك لوضع حاوية في مسار سيكون مرئيًا عالميًا إذا ارتكبت خطأً بسيطًا، ولكن هذا اختيارك. ولكن كل شيء آخر… لماذا؟
وجود وكيل عكسي أمام Discourse أمر تافه حقًا وبخلاف ذلك سيكون إعدادك تثبيتًا قياسيًا بدون كل هذه المتاعب. بالتأكيد، إذا كنت تريد اللعب وهذا هو هوايتك، ولكن قريبًا جدًا سيظهر شخص ما ويقول إنه يمكنك الحصول على الدعم للتثبيت القياسي فقط وأكبر مشكلة هي أن لا أحد يعرف حقًا ما قمت به. أو لماذا.
أنت تقوم بإصلاح مشكلة واجهتك عند البدء في القيام بشيء آخر، وهو ما يحتاجه الشخص القياسي. حتى مع وجود وكيل عكسي (reverse proxy).
لهذا السبب أنت بعيد جدًا عن المعيار لأنه يوجد خياران:
لديك خطأ في يديك لا يملكه أحد آخر
لقد فعلت شيئًا غريبًا
ربما يكون خطأ. وقد أكدت ذلك من خلال إجراء تثبيت قياسي باستخدام مسار آمن (من نواحٍ عديدة) وفي نفس الوقت توصيل الوكيل العكسي الخاص بك بالطريقة الصحيحة. لأنه إذا كان لا يزال معطلاً، يمكنني المراهنة على أن المشكلة تكمن في المضيف الافتراضي (virtual host) و/أو المنافذ. ولكن إذا كان يعمل… فنحن نعود إلى الخيار “الغريب” - حيث لا أحد يعرف ما الذي فعلته.
هل ترى المشكلة هنا؟
في كلتا الحالتين - استخدام وكيل عكسي (reverse proxy) يؤدي إلى عدم وجود دعم… هذه هي السياسة هنا. ولكن يمكن لمستخدمين آخرين، وغالبًا ما يفعلون، المساعدة.
ولا يهمني كيف هو الأمر داخل الحاوية.
الوضع نفسه مع حاوية docker.
