استخدام Nginx Proxy Manager لإدارة مواقع متعددة مع Discourse

ويكي المجتمع Sysadmins
1

تحرير: أعاد @pfaffman كتابة هذا المنشور كموضوع مستقل بناءً على ما كتبه @tophee سابقًا. لم أجرب هذا بعد بنفسي، وقد قمت بإعادة ترتيب كلمات Chris، لذا فإن أي أخطاء محتملة هي على الأرجح من @pfaffman.

هل هناك أي أسباب لعدم استخدام NGINX Proxy Manager بدلاً من القيام بذلك يدويًا كما هو موصوف في https://meta.discourse.org/t/running-other-websites-on-the-same-machine-as-discourse/17247؟

أنا أستخدمه بالفعل. لقد كان موجودًا على خادم منزلي لفترة من الوقت، وعندما قمت بنقل مثيل Discourse الخاص بي إلى سحابة جديدة، أدركت أنني نسيت معظم إعدادات الـ NGINX العكسي التي قمت بها قبل 4 سنوات على الخادم القديم، لذا فكرت: لماذا لا أفعل ذلك باستخدام NGINX Proxy Manager؟ وإلى دهشتي، وجدت أنه تم ذكره نادرًا هنا على Meta، لذا بدأت أتساءل عما إذا كانت هناك بعض العيوب التي قد تكون فاتتني…

في الواقع، تطلب ذلك بعض التجربة والخطأ، لكنني نجحت في جعله يعمل على النحو التالي (لا توجد ضمانات بأن هذه هي أفضل طريقة للقيام بذلك - في الواقع، أعرف أنه يجب أن تكون هناك طريقة أفضل - لذا فإن التصحيحات والتحسينات موضع ترحيب كبير):

للبداية، هناك طريقتان للوصول إلى مثيل Discourse: 1. عن طريق تعريض منفذ، 2. عبر Websocket. أعتقد أنني تعلمت في مكان ما على هذا المنتدى أن Websocket أسرع/أكثر كفاءة، لذا هذا ما أستخدمه، لكن تعريض المنفذ يجب أن يكون أسهل بكثير، لذا إذا لم تتمكن من جعل الـ Socket يعمل، جرب تعريض منفذ. لذا، لتجنب الارتباك: للوصول إلى Discourse عبر منفذ، اتبع الخطوات 0، 1، 2، 3، 4، و 8 أدناه. إذا كنت تريد استخدام Websocket، فاتبع الخطوات 0، 1، 5، 6، 7، 8، و 9.

0. نقطة البداية

لنفترض إذن أنك أكملت التثبيت القياسي لمدة 30 دقيقة ولنفترض أنك لم تسمح لـ Discourse بالحصول على شهادة lets encrypt بعد - لأنك لا تحتاج إليها عند استخدام وكيل عكسي. سيتولى NGINX Proxy Manager ذلك. لا يهم، مع ذلك، إذا كان لديك شهادة بالفعل. سيحصل NGINX Proxy Manager ببساطة على واحدة جديدة.

1. تثبيت NGINX Proxy Manager

الخطوة التالية هي تثبيت NGINX Proxy Manager بحيث يكون لديك حاويتا Docker إضافيتان تعملان (NGINX Proxy Manager وحاوية قاعدة البيانات الخاصة به).

التالي هو الجزء الصعب الذي تسأل عنه.

العقبة الأولى هي أن Discourse يعمل على شبكة bridge الافتراضية الخاصة بـ Docker بينما يعمل NGINX Proxy Manager افتراضيًا على شبكة “تم إنشاؤها بواسطة المستخدم” (تسمى npm_default في حالتي)، مما يعني أن NGINX Proxy Manager لا يمكنه رؤية Discourse. :cry:

2. جلب جميع الحاويات إلى شبكة الجسر الافتراضية

لذا، طالما أنني لا أعرف ما إذا كان يمكن نقل Discourse إلى شبكة مخصصة وكيف يمكن ذلك، يجب علينا نقل NGINX Proxy Manager إلى شبكة bridge الافتراضية. يمكننا القيام بذلك عن طريق إضافة network_mode: bridge إلى حاويتي NGINX Proxy Manager في ملف docker compose.

3. استخدام عنوان IP بدلاً من اسم الخدمة

المشكلة التالية هي أن ملف docker compose القياسي لن يعمل بعد الآن إذا قمت بنقله ببساطة إلى شبكة bridge. لن يتمكن NGINX Proxy Manager من العثور على حاوية قاعدة البيانات الخاصة به بعد الآن. وذلك لأن حل أسماء الخدمات الداخلي (الذي يعتمد عليه ملف docker-compose) متاح فقط على الشبكات التي تم إنشاؤها بواسطة المستخدم، وليس على شبكات Docker الافتراضية. لذا يجب أن نلجأ إلى عناوين IP ثابتة (وهو السبب في أن هذا بالتأكيد ليس الحل الأمثل لأنه سينكسر إذا تغيرت عناوين IP الخاصة بحاوياتك). لذا تحتاج إلى بدء الحاوية على الرغم من أنك تعرف أنها لن تعمل، وملاحظة عنوان IP الخاص بحاوية قاعدة بيانات NGINX Proxy Manager، واستبدال DB_MYSQL_HOST: "db" في ملف docker compose الخاص بك بـ DB_MYSQL_HOST: "<db_container_IP>".

لذا الآن يجب أن تكون جميع الحاويات على شبكة bridge الافتراضية بحيث يمكن لـ NGINX Proxy Manager رؤية كل من Discourse وقاعدة البيانات الخاصة به.

4. جعل Discourse قابلاً للوصول

لكن “رؤية” Discourse والقدرة على الوصول إليها ليستا نفس الشيء. لذا تحتاج إلى التأكد من أن Discourse سيقبل أي حركة مرور يقوم NGINX Proxy Manager بتوجيهها إليها. إذا لم تكن تهتم باستخدام Websocket، فأعتقد أنه يمكنك ببساطة توجيه NGINX Proxy Manager إلى المنفذ 80 (وليس 443) من عنوان IP الخاص بحاوية Discourse، مثل هذا:

image
image492×541 37.4 KB

لم أختبر هذا، على الرغم من ذلك. كما ذكرت، أنا أستخدم إعداد Websocket، والذي يتطلب بعض الخطوات الإضافية. لاحظ أن اسم المضيف/عنوان IP والمنفذ أعلاه سيتم تجاهلهما عند استخدام Websocket.

5. تكوين app.yml لاستخدام Websocket

هذا موضح في المنشور الأصلي، لذا لن أدخل في التفاصيل.

6. تركيب Websocket في حاوية NGINX Proxy Manager

نحتاج إلى منح NGINX Proxy Manager الوصول إلى Websocket عن طريق تركيبه كحجم: - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock. هذا هو التغيير النهائي على ملف docker compose الافتراضي لـ NGINX Proxy Manager، لذا إليك النسخة النهائية التي تعمل معي:

version: '3'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    network_mode: bridge
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    environment:
      DB_MYSQL_HOST: "172.17.0.6"
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: "npm"
      DB_MYSQL_PASSWORD: "my-super-safe-pwd"
      DB_MYSQL_NAME: "npm"
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
      - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock
  db:
    image: 'jc21/mariadb-aria:latest'
    restart: unless-stopped
    network_mode: bridge
    environment:
      MYSQL_ROOT_PASSWORD: 'my-super-safe-pwd'
      MYSQL_DATABASE: 'npm'
      MYSQL_USER: 'npm'
      MYSQL_PASSWORD: 'my-super-safe-pwd'
    volumes:
      - ./data/mysql:/var/lib/mysql

7. تكوين NGINX Proxy Manager لاستخدام Websocket

الخطوة الأخيرة: أخبر NGINX Proxy Manager باستخدام Websocket. насколько я помню، لم يكن كافيًا مجرد تشغيل “دعم Websockets”، لذا قمت بنسخ موقع NGINX من المنشور الأصلي إلى علامة التبويب “متقدم”، مثل هذا:

image
image490×522 50.3 KB

لم أتمكن من جعل هذا يعمل تحت علامة التبويب “المواقع المخصصة”.

8. لا تنس تفعيل SSL

لم أذكر تكوين SSL في NGINX Proxy Manager لأنه يبدو واضحًا بحد ذاته ولا أعتقد أن الأمر يهم في أي نقطة من العملية تقوم بتفعيله. لذا إذا لم تكن قد فعلت ذلك بعد، فهذا ما يبدو عليه:

image
image501×383 27.5 KB

9. تحذير

tl;dr كلما قمت بإعادة تشغيل حاوية Discourse، تحتاج أيضًا إلى إعادة تشغيل حاوية NGINX Proxy Manager الرئيسية (لا حاجة لإعادة تشغيل قاعدة البيانات).
إذا كنت تصل إلى Discourse عبر Websocket، فيجب أن تدرك أنه عند إعادة بناء حاوية Discourse الخاصة بك (كما هو مطلوب كل بضعة أشهر لتحديث صورة الأساس)، سيتم حذف Websocket السابق وإنشاء واحد جديد. نتيجة لذلك، سيفقد NGINX Proxy Manager الاتصال بمثيل Discourse الخاص بك ويرمي خطأ 502. ربما سيكون تحديث مستقبلي لـ NGINX Proxy Manager قادرًا على العثور على Websocket الجديد تلقائيًا، لكن حاليًا (يناير 2022) لن يجد NGINX Proxy Manager حاوية Discourse المعاد بناؤها الخاصة بك ما لم تقم بإعادة تشغيل NGINX Proxy Manager.

الشرح

إذا كنت تتساءل عن سبب دمج التعليمات أعلاه لـ Websocket مع المنافذ، فإن السبب البسيط هو أنه، بينما كنت أكتب هذا المنشور، خطر لي فجأة أن NGINX Proxy Manager و Discourse ربما لا يحتاجان حتى إلى أن يكونا على نفس شبكة Docker عندما نستخدم Websocket. وعندما تم تأكيد ذلك، لم يشعر أحد بالرغبة في إعادة كتابة التعليمات بالكامل.

هذا هو الجانب الأكثر إثارة للاهتمام في منتديات الدعم: القيام بعمل جيد في وصف مشكلتك غالبًا ما يقودك إلى الحل دون حتى نشر سؤالك. وفي هذه الحالة، كنت أجيب على سؤال شخص آخر ولكن قد يكون أيضًا وجدت الإجابة على سؤالي الخاص. :smiley:

9 إعجابات
Use CloudPanel to manage multiple sites with Discourse
Run other websites on the same machine as Discourse
Discourse-app container starts then silently stops
On one Droplet (Digital ocean) make Discourse, Moodle (edu), DAO (Aragon) work together
Reverse Proxy Into Discourse
Site backup after migration
TOR with CloudFlared Argo Tunnel
Need help setting up discourse using Caddy as rproxy
Run other websites on the same machine as Discourse
Discourse-app container starts then silently stops
Discourse-app container starts then silently stops
Trying to recover an installation
Where to start with coding?
Could the installation docs address more situations?
Adding ssl cert for subdomain after official discourse installation
Sysadmins Index
Anyone have experience running two separate Docker containers instead of the secondsite method?
2

مناقشة أي عكسي بروكسي يجب استخدامه تتجاوز بوضوح مجال الدعم. :wink: ولكن بعد النظر في NGINX Proxy Manager لمدة 12 ثانية أو أكثر، أعتقد أنه سيقوم بالمهمة بشكل جيد. هناك شيء آخر تلقائي لـ NGINX proxy تمت مناقشته سابقاً أيضاً، ولكن مع معرفتي الواسعة بـ NGINX Proxy Manager، أعتقد أنه قد يكون أفضل. قد ألقِ نظرة عليه، فأنا أشعر بخيبة أمل متزايدة تجاه Traefik.

تحرير: الآن لقد نظرت إليه لمدة 3 دقائق. أنا أفضل الأدوات التي تسهل الأتمتة، لذا فإن Traefik و jwilder/nginx-proxy - Docker Image (لقد وجدته) اللذان يسمحان لك بإضافة بعض الملصقات أو متغيرات البيئة إلى حاوية Docker بحيث لا يكون هناك حاجة للنقر في واجهة ويب، هما ما أريده أكثر. ويبدو أن جعل ذلك الشيء يعمل يتطلب استخدام واجهة الويب أو محاولة تحديث قاعدة البيانات يدوياً بالمضيفين الذين تريد إضافتهم. ولكن إذا كنت مستعداً للنقر والتلاعب بواجهة ويب مثل الشخص العادي (بدلاً من “شخص” مدير النظام)، فربما يكون ذلك الشيء هو ما تبحث عنه.

4 إعجابات
ERR_TOO_MANY_REDIRECTS while installing Discourse behing Nginx Proxy Manager
6

لقد حاولت تثبيت Nginx Proxy Manager، لكنني لا أستطيع فهم كيفية “ربط” (هل تقصد التوجيه العكسي؟ آسف، لكنني جديد نسبيًا في إدارة الأنظمة) حاوية Discourse حتى أتمكن من رؤية Discourse عند الدخول عبر الويب. هل يمكنك تقديم بعض التلميحات؟ هل يجب أن تعرض حاوية Discourse المنافذ 80 و443 أم لا، كما يقترح هذا الموضوع في المنتدى؟

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

في الواقع، تطلب هذا الأمر بعض التجربة والخطأ، لكنني تمكنت من جعله يعمل بالطريقة التالية (لا يوجد ضمان أن هذه هي أفضل طريقة للقيام بذلك - في الواقع، أعرف أنه يجب أن تكون هناك طريقة أفضل - لذا فإن التصحيحات والتحسينات موضع ترحيب كبير):

التعليمات التي نقلها @pfaffman إلى المنشور الأصلي

للبداية، هناك طريقتان للوصول إلى مثيل Discourse الخاص بك: 1. عن طريق تعريض منفذ، 2. عبر WebSocket. أعتقد أنني تعلمت في مكان ما على هذا المنتدى أن WebSocket أسرع/أكثر كفاءة، لذا هذا ما أستخدمه، لكن تعريض منفذ يجب أن يكون أسهل بكثير، لذا إذا لم تتمكن من جعل الـ Socket يعمل، جرب تعريض منفذ (مزيد من التفاصيل حول ذلك أدناه).

لنفترض إذن أنك أكملت التثبيت القياسي لمدة 30 دقيقة ولنفترض أنك لم تسمح لـ Discourse بالحصول على شهادة lets encrypt بعد - لأنك لا تحتاج إليها عند استخدام وكيل عكسي. سيقوم NPM بالاهتمام بذلك. لا يهم، مع ذلك، إذا كان لديك بالفعل شهادة. سيقوم NPM ببساطة بالحصول على شهادة جديدة.

1. تثبيت NPM

الخطوة التالية هي تثبيت NPM بحيث يكون لديك حاويتا Docker إضافيتان تعملان (NPM وحاوية قاعدة البيانات الخاصة به).

الآن يأتي الجزء الصعب الذي تسأل عنه.

العقبة الأولى هي أن Discourse يعمل على شبكة bridge الافتراضية لـ Docker بينما يعمل NPM افتراضيًا على شبكة “تم إنشاؤها بواسطة المستخدم” (تسمى npm_default في حالتي) مما يعني أن NPM لا يمكنه رؤية Discourse. :cry:

2. نقل جميع الحاويات إلى شبكة الـ bridge الافتراضية

لذلك، طالما أنني لا أعرف ما إذا كان يمكن نقل Discourse إلى شبكة مخصصة وكيف يمكن ذلك، يتعين علينا نقل NPM إلى شبكة bridge الافتراضية. يمكننا القيام بذلك عن طريق إضافة network_mode: bridge إلى حاويتي NPM في ملف docker compose الخاص بنا.

3. استخدام عنوان IP بدلاً من اسم الخدمة

المشكلة التالية هي أن ملف docker compose القياسي لن يعمل بعد الآن إذا قمت فقط بنقله إلى شبكة bridge. لن يتمكن NPM من العثور على حاوية قاعدة البيانات الخاصة به بعد الآن. والسبب في ذلك هو أن حل أسماء الخدمات داخليًا عبر DNS (الذي يعتمد عليه ملف docker-compose) متاح فقط على الشبكات التي تم إنشاؤها بواسطة المستخدم، وليس على شبكات Docker الافتراضية. لذا يتعين علينا اللجوء إلى عناوين IP ثابتة (وهو السبب في أن هذا بالتأكيد ليس الحل الأمثل لأنه سيتعطل إذا تغيرت عناوين IP الخاصة بحاوياتك). لذا تحتاج إلى تشغيل الحاوية حتى لو كنت تعلم أنها لن تعمل، ثم ملاحظة عنوان IP الخاص بحاوية قاعدة بيانات NPM، واستبدال DB_MYSQL_HOST: "db" في ملف docker compose الخاص بك بـ DB_MYSQL_HOST: "<db_container_IP>".

الآن يجب أن تكون جميع الحاويات على شبكة bridge الافتراضية بحيث يمكن لـ NPM رؤية كل من Discourse وقاعدة البيانات الخاصة به.

4. جعل Discourse قابلاً للوصول

لكن “رؤية” Discourse والقدرة على الوصول إليه ليسا نفس الشيء. لذا تحتاج إلى التأكد من أن Discourse سيقبل أي حركة مرور يقوم NPM بتوجيهها إليه. إذا لم تكن تهتم باستخدام WebSocket، أعتقد أنه يمكنك ببساطة توجيه NPM إلى المنفذ 80 (وليس 443) لعنوان IP الخاص بحاوية Discourse، مثل هذا:

image
image492×541 37.4 KB

لم أختبر هذا، مع ذلك. كما ذكرت، أنا أستخدم إعداد WebSocket، والذي يتطلب بعض الخطوات الإضافية. لاحظ أن اسم المضيف/عنوان IP والمنفذ أعلاه سيتم تجاهلهما عند استخدام WebSocket.

5. تكوين app.yml لاستخدام WebSocket

هذا موضح في المنشور الأصلي، لذا لن أدخل في التفاصيل.

6. تركيب WebSocket في حاوية NPM

نحتاج إلى منح NPM الوصول إلى WebSocket عن طريق تركيبه كوحدة تخزين: - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock. هذا هو التغيير النهائي على ملف docker compose الافتراضي لـ NPM، لذا إليك النسخة النهائية التي تعمل بالنسبة لي:

version: '3'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    network_mode: bridge
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    environment:
      DB_MYSQL_HOST: "172.17.0.6"
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: "npm"
      DB_MYSQL_PASSWORD: "my-super-safe-pwd"
      DB_MYSQL_NAME: "npm"
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
      - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock
  db:
    image: 'jc21/mariadb-aria:latest'
    restart: unless-stopped
    network_mode: bridge
    environment:
      MYSQL_ROOT_PASSWORD: 'my-super-safe-pwd'
      MYSQL_DATABASE: 'npm'
      MYSQL_USER: 'npm'
      MYSQL_PASSWORD: 'my-super-safe-pwd'
    volumes:
      - ./data/mysql:/var/lib/mysql

7. تكوين NPM لاستخدام WebSocket

الخطوة الأخيرة: أخبر NPM باستخدام WebSocket. بقدر ما أتذكر، لم يكن كافيًا فقط تشغيل “دعم WebSocket”، لذا قمت بنسخ موقع NGINX من المنشور الأصلي إلى تبويب “متقدم”، مثل هذا:

image
image490×522 50.3 KB

لم أتمكن من جعل هذا يعمل تحت تبويب “المواقع المخصصة”.

8. لا تنس تفعيل SSL

لم أذكر تكوين SSL في NPM لأنه يبدو بديهيًا جدًا ولا أعتقد أن الأمر يهم في أي نقطة من العملية تقوم بتفعيله. لذا إذا لم تقم بذلك بعد، فهذا ما يبدو عليه إعداداتي:

image
image501×383 27.5 KB

9. تنويه نهائي

بينما كنت أكتب هذا المنشور، خطر لي فجأة أن NPM و Discourse ربما لا يحتاجان حتى إلى أن يكونا على نفس شبكة Docker عندما نستخدم WebSocket. ليس لدي وقت للتحقق من ذلك في الوقت الحالي، لكن إذا كان هذا صحيحًا، فيمكنك ببساطة نسيان الخطوات 2 و 3 و 4 أعلاه ويجب أن يعمل.

هذا هو الجانب الأكثر إثارة للاهتمام في منتديات الدعم: القيام بعمل جيد في وصف مشكلتك غالبًا ما يقودك إلى الحل دون حتى نشر سؤالك. وفي هذه الحالة، كنت أجيب على سؤال شخص آخر ولكن ربما وجدت أيضًا إجابة لسؤالي الخاص. :smiley:

4 إعجابات
8

شكرًا جزيلاً على الإجابة الرائعة والمفصلة! سأجرب نصائحك في أقرب وقت ممكن. بالمناسبة، هل عناوين IP التي يجب إدخالها في NPM هي عناوين الخادم (أي العنوان الخارجي للوصول إلى الخادم) أم عناوين Docker الداخلية (لاحظت أن Docker يستخدم عناوين تبدأ بـ 172… للحاويات)؟
آسف إذا بدت أسئلتي تافهة، فأنا لا أعرف الكثير في شؤون الشبكات.

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

أوصي باستخدام Websocket. في هذه الحالة، يمكنك إدخال أي عنوان IP لأنه لن يُستخدم. وإلا، فهو العنوان الداخلي للحاوية، وليس العنوان العام للمضيف.

بالمصادفة: يبدو أن ردك عبر البريد الإلكتروني لم يتم عرضه بشكل صحيح. ربما ترغب في تعديل (تقصير) منشورك أعلاه؟

إعجابَين (2)
10

نعم، لقد رأيت ذلك. لقد استخدمت “الرد” من البريد الإلكتروني، وحاول وضع الرسالة الأصلية بالكامل، لكنني لا أستطيع إيجاد طريقة لتعديلها. هل هذا ممكن؟ أنا جديد في Discourse حتى كمستخدم… :pensive:

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

يمكنك تعديل منشوراتك باستخدام أيقونة القلم في أسفل رسالتك. ومع ذلك… مستوى الثقة 1 وما دونه يحصل على 24 ساعة (افتراضي)، بينما مستوى الثقة 2 وما فوق يحصل على 30 يومًا (افتراضي).

يبدو أنك حاليًا على مستوى الثقة 1 الأساسي، لكن يمكنك معرفة المزيد عما يجب عليك فعله لـ “الترقية” في مستويات الثقة. :+1:

إعجابَين (2)
12

آسف إذا كان قد مر وقت طويل منذ سؤالك السابق، لكنني أضعت الكثير من الوقت في محاولة تنفيذ ما اقترحته دون أي نجاح على الإطلاق. عندما عدّلت ملف app.yml وأعدت بناء التطبيق بتغييراتك، بدأ يظهر في سجلات الأخطاء الرسالة: “config/unicorn_launcher: line 71: kill: (898) - No such process”. لذا، مهما حاولت، لم أستطع إيقاف هذا السلوك. كما جربت إعادة بناء التطبيق في حالته الأصلية (مع فتح المنافذ وبدون WebSockets)، وإيقاف npm، لكن دون جدوى؛ فـ “unicorn” لا يعمل. جربت أيضًا اتباع كل ما يجده جوجل حول هذه المشكلة (يبدو أنها مشكلة شائعة)، لكنني لم أستطع بأي طريقة معرفة كيفية إعادة بناء حاوية discourse عاملة. المشكلة الآن (وهي من أكبر المشاكل، فأنا على وشك الاستسلام مع discourse) أن قاعدة بيانات postgres الداخلية تعيد التشغيل دائمًا لسبب غامض ومربك. لا أعرف السبب؛ لقد طبقت تغييراتك ببساطة وأعدت بناء التطبيق، ومنذ ذلك الحين، “unicorn” :roll_eyes: متوقف تمامًا. هل هناك طريقة لإصلاح مشكلة postgres هذه؟ ولماذا حدث ذلك؟ هل هناك أمل (أخشى أن لا) في عدم فقدان جميع التغييرات التي أجريتها على discourse عندما كان يعمل؟ وبالمناسبة، هل من الطبيعي أن يؤدي كل تغيير بسيط أو محاولة لإصلاح شيء ما إلى تعطيل شيء آخر؟ :rage: لست غاضبًا؛ المشكلة كلها تتعلق بـ discourse وليس بنصائحك؛ لقد قضيت وقتًا طويلاً في محاولة جعل هذا المنتدى “الذي يبدو” رائعًا يعمل، لكن في كل مرة يحدث شيء آخر خطأ، تزداد قنعتي بأن discourse غير موثوق به للغاية.

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

إذا كان لديك تثبيت قياسي يعمل، فيجب أن تتمكن من إعادة الأمور إلى ما كانت عليه والعمل كما كان من قبل.

قد تكون مشكلة PostgreSQL مرتبطة بـ تحديث PostgreSQL 13؟

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

إعجابَين (2)
14

كيف يمكنني معرفة ما إذا كانت مشكلة PostgreSQL مرتبطة بالتحديث 13؟ لم أختار تحديثها، بل اكتفيت بكتابة “./launcher rebuild app”، ثم حدثت كل هذه الأمور.
نعم، الإصدار هو 13، وبعد ساعات من القراءة على الإنترنت عن أشخاص آخرين يعانون من نفس المشكلة، اكتشفت أن هذا قد يكون السبب، لكنني لم أجد طريقة لإحياء Discourse.

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

إذًا، هذه ليست المشكلة. عذرًا.

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

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

أنا آسف، لكنني لست الشخص المناسب لمساعدتك في هذا. ليس لدي خبرة مع postgres أو unicorns. هناك ثلاث طرق أتعامل بها مع سيناريوهات “لا شيء يعمل” مثل هذه: 1. عمل نسخة احتياطية حتى أتمكن دائمًا من العودة إلى الحالة الأصلية. 2. تجربة أو تغيير شيء واحد فقط في كل مرة، وتجربته على جهاز غير منتج (أو منتدى أقل أهمية) أولاً. 3. استثمار المزيد من الساعات لمحاولة فهم الأمور.

بالمناسبة: كتابة وصف تفصيلي للمشاكل/تذاكر الدعم أكثر من مرة ساعدني في حل المشكلة. لم أكن بحاجة حتى إلى إرسال التذكرة. مجرد كتابتها جعلتني أرى الحل.

لذا في حالتك، ما سأحاول فهمه هو: تحت أي ظروف يمكن أن يؤدي تغيير ملف app.yml ثم إعادته إلى حالته الأصلية إلى نتيجة مختلفة عن النتيجة الأصلية. عند النظر في هذا، إما أن تدرك أنك لم تستعد الحالة الأصلية بالضبط، أو أن تفهم ما تحتاج إلى “إعادة ضبطه” لكي يعمل الأمر بشكل صحيح.

5 إعجابات
17

أنا آسف جداً، لكنني لا أفهم: أولاً سألتني عما إذا كانت مشكلة PostgreSQL قد تكون مرتبطة بترقية PostgreSQL 13، وعندما أجبت بـ “نعم، الإصدار هو 13” (أقسم أنني لم أعرف ما كان قبل ذلك، لقد مر وقت طويل منذ أن أعيدت بناء التطبيق)، أجبت بأن هذه ليست المشكلة… إذن، لماذا تكون PostgreSQL دائماً في حالة “بدء التشغيل” ولا يعمل Discourse؟

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

مرحبًا @Wanderer. لا أستطيع تحديد مشكلتك بدقة، لذا كان ترقية PostgreSQL مجرد تخمين. أنا متأكد تقريبًا من أنه إذا كنت تشغّل PostgreSQL 13، فإن المشكلة ليست أنك عالق في الترقية من الإصدار 10 أو 12. لذا، رغم أنه قد تكون هناك مشكلة ما تتعلق بـ PostgreSQL، إلا أنها على الأرجح غير مرتبطة بترقية PostgreSQL 13.

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

إذا كنت ترغب في الحصول على مساعدة أكثر تحديدًا لمشكلتك ولديك ميزانية، يمكنك التواصل معي أو النشر في قناة Marketplace.

سأعمل على تحسين تعليمات Nginx Proxy Manager، لكن تخميني هو أن مشكلتك، رغم أنها ظهرت أثناء محاولة الانتقال إلى هذه الإعدادات المعقدة، على الأرجح ليست بسبب وجود أخطاء في هذه التعليمات. (لا أعرف بالتأكيد، لكن هذا أفضل تخمين لدي.)

إعجابَين (2)
19

إليك نسختي من هذا. كدت أستسلم، لكن @tophee ربطت بمنشور كتبته أنا (!!) وقدم السحر اللازم! أصبح الآن طريقة مباشرة لتكوين Nginx Proxy Manager لـ Discourse. أعتقد أن هذا يجعل الأمر مشابهاً لـ Run other websites on the same machine as Discourse - #396.

تثبيت Nginx Proxy Manager وفقاً لتعليماتهم في

إزالة قوالب SSL و Let’s Encrypt:

تأكد من أن هذه الأسطر في ملف yml الخاص بك قد تم تعليقها أو حذفها:

## قم بإلغاء التعليق عن هذين السطرين إذا كنت ترغب في إضافة Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"

اجعل Discourse يستخدم شبكة npm-default.

إذا اتبعت تعليمات تثبيت Nginx Proxy Manager دون تفكير، فستقوم بإنشاء شبكة Docker تسمى npm_default.

أضف هذا القسم إلى ملف (ملفات) yml الخاص بك. إذا كان لديك حاويات web_only و data منفصلة، فستحتاج إلى إضافة هذا إلى كل منها (لم أختبر حاوية mail-receiver). لا يتم استخدام docker_args مع المسافة البادئة.

docker_args: |
  --network npm_default

لا حاجة لكشف أي منافذ

قم بتعليق أو إزالة هذه الأسطر من ملف yml الخاص بك:

# expose:
#  - "80:80"   # http
#  - "443:443" # https

يمكنك بعد ذلك إعادة بناء الحاوية (الحاويات) الخاصة بك وتكوين Nginx Proxy Manager على النحو التالي:

image

طريقة بسيطة (ولكن ليس بالضرورة موصى بها) لبدء تشغيل موقع Discourse ثانٍ ستكون كالتالي:

cd /var/discourse/containers
cp app.yml othersite.yml
# قم بالتعديل بطريقة ما، على أقل تقدير، اسم المضيف في othersite.yml
./launcher rebuild othersite

ثم أضفه إلى NPM كما هو موضح أعلاه، باستخدام othersite بدلاً من app.

لقد اختبرت هذا مع app.yml بالإضافة إلى حاويتين من نوع web_only وحاوية data واحدة بالإضافة إلى حاوية othersite-redis منفصلة وهي نسخة من حاوية data تحتوي فقط على قوالب redis. (ولكن الحل الأسهل سيكون وضع redis الإضافي داخل حاوية web_only).

إعجابَين (2)
20

إذن، بعد بعض الصعوبات، تمكنت من جعل كل شيء يعمل.

يجب أن أبدأ ببيان: رغم أنني مطور من “الجيل القديم” (منذ الثمانينيات)، إلا أنني دائمًا ما أبحث عن أفضل الطرق الحديثة للتطوير والإدارة، لذا أكره في عام 2021 كتابة أوامر غريبة مليئة بخيارات غامضة مثلما كان الحال مع أنظمة cp/m و DOS القديمة. أنا دائمًا أبحث عن واجهة تجعل حياتي أسهل وأكثر وضوحًا.

لذلك، أستخدم على سبيل المثال Portainer لإدارة الحاويات، حيث يسمح بتشغيل/إيقاف/تعديل/نسخ جميع الحاويات في الوقت الفعلي، دون الحاجة إلى “التجول” في نظام الملفات بحثًا عن ملف نادر الوجود؛ فمثلًا، لتغيير شبكة الحاوية، يكفي اختيار واحدة من قائمة والضغط بلمسة واحدة، وكذلك الأمر عند إضافة بعض المعاملات أو وحدة تخزين كما في المثال الذي كتبه @tophee. لهذا السبب جربت NPM، لأنني أفضل “احتواء” وكيل Nginx الخاص بي، وبما أنه يبدو أنه يمكن ذلك بعد بضع نقرات فقط، مع فهم ما أفعله بوضوح دون الحاجة إلى تذكر مجموعة جديدة من الأوامر والخيارات الغريبة.

بالعودة إلى حاوية Discourse الخاصة بي، اضطررت إلى إعادة تشغيل “discourse-setup” مرة أخرى؛ فكل شيء سار على ما يرام، وتم تثبيت Postgres “الشرير” في الإصدار 13، دون ظهور “الوحش المتوحش” (أعتذر، لكن مجرد التفكير في “وحيد قرن” يركض على خادمي يجعلني أضحك! :laughing:)، باختصار، سار كل شيء على ما يرام. ثم قمت بالتعديلات اللازمة لتشغيل Discourse مع WebSockets: سار كل شيء على ما يرام هذه المرة أيضًا. ولحسن الحظ، كانت الإعدادات السابقة لـ Discourse تقوم بنسخ احتياطي تلقائي، لذا استعدت كل شيء بعد بضع نقرات فقط (كلما استخدمت Discourse أكثر، زاد حبي له!).

اضطررت إلى تجربة إعدادات NPM عدة مرات، ففي البداية واجهت بعض المشاكل مع الشهادات، لكن في النهاية سار كل شيء على ما يرام.

أضفت وكيلًا ثانٍ يشير إلى حاوية WordPress الخاصة بي (نعم، أنا “أحتوي” كل شيء، أحب فكرة وجود خادم أنظف مع جميع الحزم الرئيسية محصورة في مكان مُدار)، وسار كل شيء على ما يرام أيضًا.

إذن، في النهاية، لدي خادم (VPS) مع خادم البريد الإلكتروني الخاص به (لقد حاولت أيضًا “احتواء” خادم البريد، لكن بعد أسابيع من النضال الشاق، استسلمت)، وDiscourse يشير إليه، وWordPress يعمل في حاوية أخرى، وNPM يدير الاثنين معًا: كل ذلك على خادمي، دون الاعتماد على خدمات أخرى (وأكثر تكلفة بكثير) للنشر أو البريد الإلكتروني، إلخ.

الخطوة التالية: استيراد مئات الآلاف من المشاركات من “PhpBB القديم الجيد”؛ استعدوا لمزيد من منشوراتي! :grinning_face_with_smiling_eyes:

شكرًا كبيرًا لـ @tophee و @pfaffman على المساعدة، أستطيع أن أفهم مدى صعوبة مساعدة الأشخاص عندما يعملون بطريقة غير قياسية مثلما أفعل أنا.

3 إعجابات
21

يسعدنا أنك تمكنت من جعله يعمل مع Websocket. لأي شخص آخر يعاني من ذلك، اتبع تعليمات @pfaffman حول كيفية القيام بذلك دون استخدام websocket أعلاه.

لا أعرف ما الذي تسبب في مشكلتك، لكن يبدو لي أن هذه نقطة تستحق التوضيح لأي شخص جديد نسبيًا في إدارة Discourse: يجب أن تفهم كيف تعمل شهادة Let’s Encrypt في التثبيت الافتراضي (بدون أي وكيل خارجي) مقارنة بكيفية عملها مع NPM (وإذا تساءلت عن سبب تسميته وكيلًا خارجيًا، فستحتاج أيضًا إلى اكتشاف ذلك).

بما أنني قمت بإعداد الوكيل الخارجي يدويًا في البداية، وقمت أيضًا بإعداد Let’s Encrypt يدويًا، فقد كنت أملك فهمًا لكل السحر الذي يقوم به Discourse وكذلك NPM لجعل https يعمل ببساطة، وبالتالي تمكنت من تجنب العديد من الفخاخ عند الانتقال من الشهادات التي يديرها Discourse إلى الشهادات التي يديرها NPM.

لا أرى حقًا سببًا لوضع خادم البريد خلف NPM…

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

لا كريستوف، ليس خلف NPM، بل فقط في حاوية. لقد جربت Zimbra، لكنها كانت فوضى كبيرة. ثم حاولت Postfix “مُحتوى” بسيطًا، لكن دون نجاح أيضًا. كنت في بداية تجربتي مع لينكس (لا أزال مبتدئًا، لكنني أزداد ثقة تدريجيًا على الأقل فيما يتعلق ببعض مفاهيم الإدارة)، لذا استسلمت وحاولت تشغيله مباشرة على الخادم. بدأ العمل دون مشاكل كبيرة، لذا تابعت على هذا النحو، رغم أن إعداد Discourse لاستخدام خادم البريد الخاص بي كان صعبًا إلى حد ما. لكن الآن، يبدو أن كل شيء يعمل بشكل صحيح.

إعجابَين (2)
23

يبدو جيدًا مع التثبيت حتى أتعثر في npm للتواصل مع مضيف discourse؛ تذكر أن تضع عنوان IP لحاوية البيانات داخل مضيف mySQL لملف npm compose

 environment:
      DB_MYSQL_HOST: "db"
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: "npm"
      DB_MYSQL_PASSWORD: "npm"
      DB_MYSQL_NAME: "npm"

ولكن عندما أقوم بتغيير (DB_MYSQL_HOST) إلى حاوية البيانات، يظهر لي “connection refused”.

connect ECONNREFUSED 172.17.0.2:3306 <-- خطأ عندما يكون npm في شبكة discourse (network_mode: bridge).
getaddrinfo ENOTFOUND db <-- خطأ عندما يتم تعريف mySQL في ملف npm compose باسم "db".

أي اقتراحات لجعل الخطوة 3 تعمل معي؟

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