سيتعين عليك إجراء تغييرات يدوية لجعله يعمل خلف الوكيل العكسي. بافتراض أنك تعرف كيفية القيام بذلك وتقوم بذلك بعد إنشاء app.yml باستخدام
قد ينجح هذا:
./launcher destroy app
mv containers/app.yml first_app.yml
./launcher rebuild first_app
./discourse-setup
ثم ستقوم بتحرير app.yml ليكون خلف الوكيل العكسي.
تلقي تحذيرات المحتوى المختلط عند تشغيل discourse على مقبس يونكس. تثبيت جديد.
إذا كنت أتذكر بشكل صحيح، فهذه هي الشعار المخزن مؤقتًا (أفترض أنك قمت بتمكين المعلمة force https). هل يمكنك التحقق من ذلك في أداة مطوري المتصفح/علامة التبويب الشبكة؟
يرجى تمييز هذا على أنه تم حله. اضطررت إلى فرض إعداد https (وأيضًا إجراء بحث واستبدال باستخدام rake لإضافة مسار الدليل الفرعي). يعمل الخادم الرئيسي Apache بالإضافة إلى العديد من المواقع الأخرى. بالنسبة لهذا المثال المحدد example.org، لدينا WordPress مثبت ويعمل كـ Apache reverse proxy للمسار /forums مع Discourse يستمع على websocket.
بدلاً من طريقة @riking في الأعلى؟
هل لديك رابط لدليل إرشادي حول كيفية القيام بذلك بطريقة “NGINX المزدوج”؟
للأسف، لا أعرف شيئًا عن NGINX، لكن الدليل الإرشادي بواسطة @riking يبدو بسيطًا بما فيه الكفاية، ولكن إذا كانت هناك طريقة أفضل، فسأقدر التفاصيل حولها.
مرحباً!
لقد قمنا بتثبيت Discourse عن طريق استنساخ الملفات من مستودع Git وفعلنا ما اقترحته؛ لكننا تعاملنا مع بروتوكول SSL باستخدام Nginx proxy manager (قمنا بالتعليق على جزء كشف المنفذ 443 في app.yml).
نحن نستخدم portainer v2.11.0 حيث يمكننا رؤية حاوية Discourse التي تم إنشاؤها بنجاح ولكن لا يمكننا تشغيل الموقع الإلكتروني ونحصل على خطأ 502 bad gateway.
هل لديك أي فكرة عن كيفية إصلاح الخطأ؟
هل قمت أيضًا بإزالة شهادات SSL و Let’s Encrypt؟
ألن يكون من المنطقي تكوين الوكيل الخارجي للاتصال بـ Discourse مباشرة بدلاً من وكيل Nginx داخل الحاوية (مما يؤدي إلى مضاعفة الوكيل)؟ أم أن وكيل Nginx الداخلي يؤدي مهمة مهمة لا يستطيع الوكيل الخارجي التعامل معها؟
مرحباً، ماذا يمكنني أن أفعل إذا لم يكن هناك ملف nginx.sock؟
❯ ls /var/discourse/shared/standalone/
backups postgres_backup postgres_run state uploads
log postgres_data redis_data tmp
هل قمت بتضمين القالب؟
أحاول تثبيت Discourse على Raspberry Pi 4 الخاص بي باستخدام نظام تشغيل Dietpi وبعض التطبيقات التي تعمل مع nginx مثل Nextcloud. أحاول استخدام خدمة Cloudflared كـ tunnel ولكن بعد اكتمال تثبيت Discourse لا يمكنني العثور على منفذ خدمة Discourse لإنشاء tunnel. عندما أتصل بـ localhost تظهر صفحة بدء تشغيل Nginx. أين يمكنني الوصول إلى موقع Discourse؟
للعلم: لم أقم بتكوين certbot لأنني أريد استخدام خدمة Cloudflared.
مرحباً، أحاول تثبيت Discourse خلف GitHub - nginx-proxy/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen ولكن لا يمكنني معرفة كيفية القيام بذلك.
لقد حاولت كشف مقبس Discourse إلى حاوية nginx-proxy وإضافة تكوين موقع لكل مضيف افتراضي دون نجاح.
لقد قمت بإعداد خدمات أخرى بنجاح خلف هذا الوكيل وأنا أفتقد Discourse فقط. هل لديك بعض النصائح من فضلك؟
بدافع الفضول، ما هي إيجابيات وسلبيات النهجين التاليين؟
لأسباب معينة، يمكنني تشغيل NGINX وتقديم الصفحات وتشغيل Discourse بدون NGINX دون مشاكل. ولكن عندما أستخدم النهج الأول، أحصل دائمًا على الأخطاء التالية.
/var/discourse/shared/web-only/log/rails/production.log
Job exception: Error connecting to Redis on data:6379 (Redis::TimeoutError)
/var/discourse/shared/web-only/log/rails/unicorn.stderr.log
Failed to report error: Error connecting to Redis on data:6379 (Redis::TimeoutError) 3 heartbeat: Error connecting to Redis on data:6379
وعندما أستخدم النهج الثاني، لن يتم بناؤه حتى عند تشغيل ./launcher rebuild <app>. سيعطيني خطأ مثل:
I, [2022-09-12T08:54:16.483648 #1] INFO -- : cd /var/www/discourse & git fetch --depth 1 origin tests-passed
fatal: unable to access 'https://github.com/discourse/discourse.git/': Could not resolve host: github.com
I, [2022-09-12T08:54:56.561225 #1] INFO -- :
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & git fetch --depth 1 origin tests-passed failed with return #<Process::Status: pid 35 exit 128>
اكتب أو الصق الكود هنا
هل تستخدم حاوية web_only ولكن لا تقوم بتشغيل حاوية بيانات؟
لم أفعل، شكراً لك.
لقد قمت بتعديل ملف app.yml الخاص بي بحيث يعمل حاوية discourse في نفس الشبكة المسماة مثل خادم الوكيل الخاص بي.
ثم أضفت التكوين _location كما نصحت به وثائق nginx-proxy مع قيم هذا الموضوع، وجعلت مقبس discourse متاحًا (في نفس المسار كما هو الحال على المضيف للتبسيط).
ومع ذلك، يبدو أن هناك مشكلة في الأذونات في مكان ما ولكنني لا أعرف حقًا ما هي: يتم التقاط التكوين بواسطة nginx، ثم عند إجراء طلب https، أحصل على هذا الخطأ
[crit] 230#230: *21 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (13: Permission denied) while connecting to upstream, client: <ip>, server: <domain>, request: "GET / HTTP/1.1", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"
داخل الحاوية:
# ls -lah /var/discourse/shared/standalone/
total 12K
drwxr-xr-x 3 root root 4.0K Sep 12 10:51 .
drwxr-xr-x 3 root root 4.0K Sep 12 10:51 ..
drwxr-xr-x 2 root root 4.0K Sep 12 09:19 nginx.http.sock
تعديل: كانت هذه مشكلة بسبب بدء الحاويات مع وبدون sudo.
ومع ذلك، لدي الآن هذا:
[error] 219#219: *94 no live upstreams while connecting to upstream, client: <client-ip>, server: <domain>, request: "HEAD / HTTP/2.0", upstream: "http://<domain>/", host: "<domain>", referrer: "http://<domain>"
وخطأ 502 bad gateway
في الواقع كلاهما. يمكنني رؤية كليهما يعملان عند استخدام docker ps. حرفياً الفرق الوحيد هو تمكين أو تعطيل قسم expose على الرغم من أنني الآن أفكر فيما إذا كنت بحاجة إلى التعليق على سطر expose: أيضًا وليس قائمة المنافذ الموجودة بداخله.
عذرًا على النشر المزدوج، لقد ارتبكت سابقًا بسبب مسألة أخرى غير ذات صلة ولم يعد المقبس مستخدمًا بسبب خطأ في التكوين الخاص بي.
إليك ما وصلت إليه:
[crit] 274#274: *7 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.160.1, server: <domain>, request: "GET / HTTP/2.0", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"
لقد قمت بتشغيل chmod 777 shared/standalone/nginx.http.sock كحل مؤقت لهذه المشكلة المتعلقة بالأذونات، والآن حصلت على:
[error] 203#203: *1 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (111: Connection refused) while connecting to upstream, client: 192.168.160.1, server: <domain>, request: "GET / HTTP/2.0", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"
من الواضح أنني أفعل بعض الأشياء بشكل خاطئ ولكنني لا أعرف ما هي. يرجى ملاحظة أنني لا أستخدم NPM ولكن nginx-proxy وهو مختلف قليلاً، وعلى وجه الخصوص، فإنه يكتشف تلقائيًا حاويات Docker التي تحدد VIRTUAL_HOST لإنشاء تكوين لها. وبالتالي، أضفت فقط جزء location / { ... } المتعلق بـ discourse ولم ألمس ملفات sites-available مع توجيهات listen.
لاحظت أن حاوية discourse في حلقة إعادة تشغيل بحالة Restarting (100) 7 seconds ago. هذا لأنه يشتكي من عدم القدرة على حذف المقبس. في الواقع، لم يكن مقبسًا فعليًا بل كان مجلدًا بدلاً من ذلك، وأعتقد أن ذلك بسبب معالجة سيئة لتركيب وحدات التخزين للكشف عنه لـ nginx-proxy container.
لقد قمت بإزالة المجلد، وأعدت تشغيل discourse وهو الآن مقبس. ومع ذلك، لا يمكنني الكشف عنه كوحدة تخزين لـ nginx-proxy
استجابة خطأ من الخادم: فشل إنشاء مهمة الظل: فشل إنشاء تشغيل runc: فشل بدء عملية الحاوية: خطأ أثناء تهيئة الحاوية: خطأ في تركيب “/var/discourse/shared/standalone/nginx.http.sock” إلى rootfs في “/var/discourse/shared/standalone/nginx.http.sock”: تركيب /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock (عبر /proc/self/fd/6)، علامات: 0x5000: ليس مجلدًا: غير معروف: هل تحاول تركيب مجلد على ملف (أو العكس)؟ تحقق مما إذا كان مسار المضيف المحدد موجودًا وهو النوع المتوقع.
اتضح أنني كنت بحاجة فقط إلى تركيب المقبس في /tmp/nginx.http.sock بدلاً من الاحتفاظ بنفس المسار. أخيرًا تمكنت من ذلك على ما يبدو!
تم العثور على المشكلة التي تمنع منفذًا في /var/discourse/containers/web_only.yml كما يلي:
exposé:
# - "443:443"
# - "80:80"
- "8080:80" # https
وفقًا لـ Solve Nginx 13: Permission denied) while connecting to upstream - Programmer All ، كان SELinux هو السبب ويتطلب السماح لـ NGINX بالوصول إلى Discourse عن طريق التشغيل أو تعيين SELinux إلى وضع Permissive.
setsebool -P httpd_can_network_connect 1
الآن، الشيء المثير للاهتمام هو أنه إذا تم تعيين تكوين NGINX إلى المسار الجذر، فإنه يعمل بشكل جيد، ولكن ليس عندما يتم تعيينه إلى مسار غير جذري.
تم تعيين NGINX لإعادة توجيه / إلى Discourse (يعمل)
# Proxy requests to 443/discussions to Discourse listening on 127.0.0.1:8080
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
تم تعيين NGINX لإعادة توجيه /discussions/ إلى Discourse (لا يعمل)
# Proxy requests to 443/discussions to Discourse listening on 127.0.0.1:8080
location /discussions/ {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
في هذه الحالة، أرى ما يلي … حدسي هو أنه على الرغم من أن NGINX قد أعاد توجيه المسار غير الجذري /discussions/ بنجاح إلى حاوية Docker الخاصة بـ Discourse، فإن Discourse نفسه لا يزال يقوم بتحميل الصفحات من نفسه ويتوقع أن تكون الأصول في المسار الجذري /. هل هو شرط لتشغيل Discourse في المسار الجذري فقط؟ @pfaffman هل رأيت هذا من قبل؟
/var/log/nginx/example.com.error.log
2022/10/01 09:33:23 [error] 1954781#1954781: *1 open() "/etc/nginx/html/images/discourse-logo-sketch.png" failed (2: No such file or directory), client: 219.78.157.149, server: uat.example.com, request: "GET /images/discourse-logo-sketch.png HTTP/1.1", host: "uat.example.com", referrer: "https://uat.example.com/discussions/"
2022/10/01 09:33:25 [error] 1954781#1954781: *1 open() "/etc/nginx/html/service-worker.js" failed (2: No such file or directory), client: 219.78.157.149, server: uat.example.com, request: "GET /service-worker.js HTTP/1.1", host: "uat.example.com", referrer: "https://uat.example.com/service-worker.js"
