في الواقع، تطلب هذا الأمر بعض التجربة والخطأ، لكنني تمكنت من جعله يعمل بالطريقة التالية (لا يوجد ضمان أن هذه هي أفضل طريقة للقيام بذلك - في الواقع، أعرف أنه يجب أن تكون هناك طريقة أفضل - لذا فإن التصحيحات والتحسينات موضع ترحيب كبير):
التعليمات التي نقلها @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. ![]()
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، مثل هذا:
لم أختبر هذا، مع ذلك. كما ذكرت، أنا أستخدم إعداد 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 من المنشور الأصلي إلى تبويب “متقدم”، مثل هذا:
لم أتمكن من جعل هذا يعمل تحت تبويب “المواقع المخصصة”.
8. لا تنس تفعيل SSL
لم أذكر تكوين SSL في NPM لأنه يبدو بديهيًا جدًا ولا أعتقد أن الأمر يهم في أي نقطة من العملية تقوم بتفعيله. لذا إذا لم تقم بذلك بعد، فهذا ما يبدو عليه إعداداتي:
9. تنويه نهائي
بينما كنت أكتب هذا المنشور، خطر لي فجأة أن NPM و Discourse ربما لا يحتاجان حتى إلى أن يكونا على نفس شبكة Docker عندما نستخدم WebSocket. ليس لدي وقت للتحقق من ذلك في الوقت الحالي، لكن إذا كان هذا صحيحًا، فيمكنك ببساطة نسيان الخطوات 2 و 3 و 4 أعلاه ويجب أن يعمل.
هذا هو الجانب الأكثر إثارة للاهتمام في منتديات الدعم: القيام بعمل جيد في وصف مشكلتك غالبًا ما يقودك إلى الحل دون حتى نشر سؤالك. وفي هذه الحالة، كنت أجيب على سؤال شخص آخر ولكن ربما وجدت أيضًا إجابة لسؤالي الخاص. ![]()


