لقد قمت بإعداد Discourse مرتين، مرة في حاوية ومرة حاليًا في جهاز افتراضي. في كلا التثبيتين، لا يمكن الوصول إلى Discourse. لست متأكدًا تمامًا مما قد يكون خطأ.
بمجرد الانتهاء، يمكنني رؤية أن الحاوية قيد التشغيل ولكنها تُرجع 502 Bad Gateway.
كيف قمت بإعداده: Nginx Reverse Proxy (يتضمن SSL) → الجهاز الافتراضي. هذا لا يعمل.
لا يتم تحميله حتى عندما أقوم بإضافته مباشرة في ملف المضيفين الخاص بي.
من الأسطر الأخيرة للتثبيت، يمكنني رؤية أن Docker أنشأ شبكة جديدة:
كيف يمكنني جعله يستخدم عنوان IP الخاص بالجهاز المضيف؟
لا أحتاج إلى شبكة أخرى داخل شبكة. أنا سعيد للسماح لـ Docker باستخدام عنوان IP الخاص بالجهاز المضيف نظرًا لأنه الخدمة الوحيدة على هذا الجهاز الافتراضي.
لا، هذا الجهاز لديه عنوان IP محلي ويتم توجيه حركة المرور إلى عنوان IP المحلي عبر جدار الحماية الخاص بي. هذه ليست المشكلة.
عنوان IP العام لديه سجل A للخادم ويتم توجيهه بشكل صحيح. forum.somedomain.com يشير –\u003e إلى الخادم الصحيح.
نعم، لقد تجاوزت التثبيت. أكملته بنسبة 100٪ (3 مرات) حتى وصلت إلى نقطة تشغيل الحاوية.
لقد تجاوزت جميع فحوصات النطاق/نظام أسماء النطاقات. يذكر أنها صالحة.
لا، لا يمكن تحديد معدل لهذا لأنه يتم إصدار شهادة SSL عبر الوكيل العكسي الخاص بي. لدي الشهادة.
هذا التثبيت مكتمل بنسبة 100٪. المشكلة هي أن Docker ينشئ شبكة جديدة 172.17.0.1 وهي غير ضرورية لأنني أرغب في استخدام عنوان IP المحلي للخادم 192.xx.xx.xx
الحاوية قيد التشغيل ولكن على شبكة مختلفة. لا يمكنني جعلها تعمل على عنوان IP للخادم.
يجب أن يكون عنوان IP لخادم Docker هو عنوان IP للخادم المضيف (192.xxx.xxx.xxx) وليس شبكة جديدة. من المحتمل أنها تعمل ولكن على تلك الشبكة.
كيف أخبر التثبيت باستخدام عنوان IP المحلي الخاص بي وليس 172.17.0.1
هذا أمر تافه للغاية. أنت تسمح بمنفذ http في ملف app.yml حيث يرسل Ngix حركة المرور. وتم تعطيل SSL. هذان هما الشيئان الوحيدان اللذان يجب عليك إصلاحهما. بالطبع، عليك تحديد عنوان IP الحقيقي، ولكن يجب عليك القيام بذلك في كل مرة يكون لديك فيها Discourse أو Moodle أو WordPress في الواجهة الخلفية، بغض النظر عن ماهيتها. يحاول UFW تقييد الوصول فقط بين الواجهة الأمامية والخلفية لأنه لا داعي للسماح بالوصول المباشر إلى الواجهة الخلفية.
إذا كنت أتذكر بشكل صحيح، فهنا توجد وثائق حول كيفية إعداد Apache2. Nginx يفعل الشيء نفسه، ولكن بطريقته الخاصة بالطبع.
لا يمكنني الوصول إلى حاوية docker من المضيف بسبب شبكة docker0. يمكنني ping 172.17.0.2 وهي تعمل ولكن من الجهاز المضيف 192.168.1.10:80/443 لا تمرر حركة المرور إلى الحاوية.
كل ما أريده هو أن تستخدم حاوية docker شبكة المضيف لأن الحاوية لديها منافذ 80 و 443 مكشوفة.
يقوم وكيل Nginx العكسي الأول بالتعامل مع حركة المرور من الخارج ويمررها إلى الجهاز الافتراضي بشكل صحيح. إذا لم يفعل ذلك، فلن يتمكن ./discourse-setup من التقاط اسم النطاق بشكل صحيح ولن يتمكن من استرداد شهادات SSL للحاوية.
في النهاية. أعلم أن الحاوية تعمل بنسبة 100٪، لا يمكنني الوصول إليها إلا بسبب شبكة docker.
هناك طريقة أخرى لمعالجة هذا وهي استخدام صورة discourse الأساسية https://hub.docker.com/r/discourse/base
وإنشاء التنسيق الخاص بك باستخدام docker compose (مع تذكر أنك بحاجة إلى بعض الخدمات الأخرى مثل redis و postgres)
يمكنني القيام بذلك باستخدام Nginx أو Nginx+Varnish لتوجيه Discourse إلى نفس خادم VPS أو خادم VPS بعنوان IP مختلف. أنت لا تخبرني بما تفعله بالفعل باستخدام Nginx الخاص بك الذي يعمل كوكيل عكسي. أمثلتك صعبة بعض الشيء لأنه لا توجد طريقة لمعرفة ما إذا كانت هذه أمثلة أم أنك تحاول بالفعل استخدام شبكة خاصة.
لكن:
بالطبع لا، لأن ذلك يعتني بحركة المرور الواردة. يجب عليك استخدام منفذ آخر للواجهة الخلفية.
شيء مثل هذا (يتم استخدامه بالفعل مع Varnish، ولكن المبدأ هو نفسه تمامًا، وهو مستوى 101 للغاية):
أدناه هو بالضبط كيف تمر شبكة WAN وتوجه حركة المرور من وكيل Nginx العكسي الخاص بي إلى المضيف الصحيح.
map $scheme $hsts_header {
https "max-age=63072000;includeSubDomains; preload";
}
server {
set $forward_scheme https;
set $server "10.10.1.38";
set $port 443;
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name forum.domainname.com;
# Let's Encrypt SSL
include conf.d/include/letsencrypt-acme-challenge.conf;
include conf.d/include/ssl-ciphers.conf;
ssl_certificate /srv/ssl/domainname.pem;
ssl_certificate_key /srv/ssl/domainname-ke.pem;
# Asset Caching
include conf.d/include/assets.conf;
# Block Exploits
include conf.d/include/block-exploits.conf;
# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security $hsts_header always;
# Force SSL
include conf.d/include/force-ssl.conf;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
access_log /var/logs/domainname-access.log proxy;
error_log /var/logs/domainame_error.log warn;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $http_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
location / {
# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security $hsts_header always;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
# Proxy!
include conf.d/include/proxy.conf;
}
}
الغريب، لقد قمت بإعداد حاوية دوكر مرة واحدة لعميل أراد مدير وكيل Nginx العكسي وكان الأمر بسيطًا للغاية.
docker-compose up -d
كان هذا كل شيء. كان بإمكان IP الخاص 192.168.1.3 الوصول إلى منافذ 80/443 المكشوفة للحاويات وتم توجيه حركة المرور الصادرة بشكل صحيح إلى 192.168.1.3.
إنها مربكة لأنها نظام تغليف يلعب في صندوقه الرملي الخاص. في الأساس هذا هو.
لكن فهم دوكر شيء مختلف عن استخدامه (والآن بدأت مجموعة من المطورين في البكاء ) وكيلك العكسي يرسل حركة المرور إلى عنوان IP عبر جدار الحماية وعليك إخبار عنوان IP هذا ومنفذ الاستماع. ولديك Discourse، المعروف أيضًا باسم دوكر، على عنوان IP هذا، والمنفذ الذي تخبره في app.yml. يتولى Nginx الداخلي الذي يعمل مع Discourse نفسه الباقي.
لا ينبغي لـ Discourse الاستماع إلى 443 لأنك أنهيت بالفعل SSL.
وبشكل أساسي لا يمكنك استخدام التخزين المؤقت على الوكيل العكسي. الواجهة الخلفية، Discourse، ليست صفحة ويب. إنها تطبيق ويب يرسل جافاسكريبت وجيسون.
هذا شيء يمكنني الاتفاق عليه. لا أقول بكاء، بل هو عديم الفائدة لمسؤولي الأنظمة والمطورين الذين يعرفون طريقهم في لينكس. إنشاء LxC أو VM معزولة ثم السماح لدوكر بإنشاء بيئة معزولة أخرى هو أمر زائد عن الحاجة ولا طائل منه.
هذا هو الجزء المربك. يكشف app.yml عن 80:80 و 443:443 على 172.17.0.2 وهو على شبكة دوكر 172.17.0.1/16 مع عنوان IP الخاص بالجهاز الظاهري على 10.10.1.38.
كيف أجعل Discourse/docker يسمح لكل حركة المرور الواردة إلى 10.10.1.38 بالمرور إلى 172.17.0.2 ويجب تمرير كل حركة المرور الصادرة إلى 10.10.1.38. هذا كل ما هو مطلوب لحل هذه المشكلة. حرفيًا.
) وكيلك العكسي يرسل حركة المرور إلى عنوان IP عبر جدار الحماية وعليك إخبار عنوان IP هذا ومنفذ الاستماع. ولديك Discourse، المعروف أيضًا باسم دوكر، على عنوان IP هذا، والمنفذ الذي تخبره في 
