The entire installation went perfectly, but the instance is not reachable publicly. I have the A record configured to the public IP given by Azure. I also tried using the IP address directly.
I suspect this has something to do with the Docker IP and the Eth0 IP address, but not sure how to solve it.
So essentially I have 3 IPs: the public IP, the eth0 IP on the VPN, and then the docker instance IP. I’m guessing I need to somehow route the public IP:80 port to the docker IP?
Crazy cloud shenanigans likely get in the way – there’s probably some equivalent of AWS’ security groups, or perhaps the networking stack needs an extra kick in the pants.
So I sort of found the problem, but not the cure. As expected it has to do with the port forwarding/mapping/routing issue.
Azure VMs are part of a resource group with a common virtual public IP and a VPN/subnet for individual machines. Then there is a Network Security Group, with which one has to define some NAT rules.
I did setup forwarding for the Docker ports, but to no avail. Now trying to diagnose using Docker documentation. Jeff is right, once Docker works correctly, Discourse will work too.
The Azure classic VM should be better because they allow mapping of specific endpoints (ports). Will try installing in one of those.
Will post my updates. For better or for worse, I’m stuck with Azure at the moment.
Ok. So I discarded the instance of Ubuntu and created a new Ubuntu VM of the classic type. Then I chose a fixed Instance IP address. Then I created two endpoints for TCP/80 and TCP/443 to forward from the public to private network. Also I installed Docker from the instructions for Ubuntu and not the script directly.
I’m not sure which of these steps helped, but now Discourse works on Azure!
I finally switched to digital ocean, where it works out of the box. The VM classic type seems not to be available anymore at Azure? Tried to setup an instance without success…
أعتذر عن إحياء هذا الموضوع، لكنه لا يزال ذا صلة. كل شيء يتم تثبيته بشكل رائع من منظور Discourse، ويبدو أن كل شيء على ما يرام، لكن المنطقتين 80 و443 غير قابلة للوصول من الخارج.
تحديث: التثبيت الأساسييعمل بالفعل دون أي تعديلات على Azure مع Ubuntu Server.
إليك ما فعلته بشكل مختلف في المرة الثانية:
بعد إنشاء الآلة الافتراضية واستدعاء discourse-setup، لم أقوم بإيقاف العملية، بحيث تم تنفيذ كل شيء دفعة واحدة.
في المرة الأولى، أدركت أنني لا أملك مساحة تبادل (swap)، وعلى الرغم من أن سكريبت discourse-setup يقوم بإعدادها إذا كانت مفقودة، إلا أنني خرجت إلى سطر الأوامر للتحقق من بعض الأمور. ثم كانت بعض مطالبات التثبيت مختلفة عما هو موضح في الدليل الأساسي، لذا خرجت مرة أخرى.
+ ما أثار دهشتي كان سؤال Let’s Encrypt عن عنوان بريد إلكتروني لاستقبال الإشعارات المتعلقة به، وكنت تحت الانطباع بأنه سيتعين عليّ إعداد HTTPS يدويًا. في الواقع، يقوم السكريبت بإعداد مثيل Discourse بشهادة SSL من Let’s Encrypt. + أمر آخر كان أقسام اسم مستخدم وكلمة مرور SMTP؛ لا زلت غير متأكد مما إذا كان يمكنني تركها فارغة، لكنني أضفت ببساطة عنوان البريد الإلكتروني للمسؤول وكلمة المرور الخاصة بهذا الحساب.
لا أعتقد أن لهذا علاقة بالمشكلة، لكنني أذكره فقط تحسبًا. في المرة الثانية، قمت بكل شيء كما فعلت في المرة الأولى، باستثناء (1) إعداد مساحة التبادل يدويًا، و(2) السماح لـ discourse-setup بالعمل دون انقطاع.
من الممكن أن يكون من الممكن إنقاذ المثيل الأول، لكن هندسة Discourse لا تزال لغزًا بالنسبة لي، وغير متأكد من كيفية إعادة تشغيل نقاط نهاية HTTP/HTTPS. عند مقارنة مخرجات netstat -tulpn، يتضح أنه في المثيل الأول، يبدو أن جميع الخدمات ذات الصلة تعمل وتستمع على المنافذ الصحيحة (مثل PostgreSQL على المنفذ 5432، وRedis على المنفذ 6379، وما إلى ذلك)، والمنفذين المفقودين فقط هما 80 و443 (مما يشير إلى أن nginx لم يكن يعمل):
المثيل الأول (الفاشل):
$ sudo -s
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
62396a99737c local_discourse/app "/sbin/boot" 14 hours ago Up 14 hours 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp app
# docker exec -it 62396a99737c bash
(docker)# netstat -tulpn
Active Internet connections (only servers)
Proto Local Address Foreign Address State PID/Program name
tcp 127.0.0.1:3000 0.0.0.0:* LISTEN -
tcp 0.0.0.0:5432 0.0.0.0:* LISTEN -
tcp 0.0.0.0:6379 0.0.0.0:* LISTEN -
tcp6 :::5432 :::* LISTEN -
tcp6 :::6379 :::* LISTEN -
المثيل الثاني:
(docker)# netstat -tulpn
Active Internet connections (only servers)
Proto Local Address Foreign Address State PID/Program name
tcp 0.0.0.0:6379 0.0.0.0:* LISTEN -
tcp 0.0.0.0:80 0.0.0.0:* LISTEN 2359/nginx: master
tcp 127.0.0.1:3000 0.0.0.0:* LISTEN -
tcp 0.0.0.0:5432 0.0.0.0:* LISTEN -
tcp 0.0.0.0:443 0.0.0.0:* LISTEN 2359/nginx: master
tcp6 :::6379 :::* LISTEN -
tcp6 :::5432 :::* LISTEN -
بضع ملاحظات لنفسي في المستقبل:
في المرة الأولى، لاحظت عدم وجود منافذ الاستماع 80 و443، لكنني رأيت مقبس 127.0.0.1:3000 (الذي أتذكر أنه مقبس Rails الافتراضي). لم يخطر ببالي بعد أن nginx ربما لم يكن يعمل، ولأسباب ما، ظننت أن تعيينات منافذ Docker هي السبب، لذا قمت بإعادة توجيه بسيطة باستخدام netcat:
داخل Docker: nc -l -p 80 -c "nc 127.0.0.1 3000"
خارج Docker في الآلة الافتراضية: nc -zv localhost 80 و curl localhost:80 (وهذا أكد لي أن Docker كان يعمل بشكل صحيح)
اعتقدت أيضًا أن قواعد منافذ الدخول في Azure مشبوهة، لأن nc -zv كان يعيد باستمرار Connection refused، لكنني أدركت بعد ذلك أن هذا يعني فقط أن المنافذ مفتوحة ولكن لا أحد يستمع على الطرف الآخر. (لو كانت المنافذ محظورة، لكان nc قد توقف عن الاستجابة.)
يجب أن يفشل أمر discourse-setup إذا لم تكن المنافذ 80 و443 مفتوحة لحركة المرور الواردة.
أه، هذا صحيح. تم تغيير بعض الأسئلة المتعلقة بتكوين البريد الإلكتروني منذ فترة ولم يتم تحديثها في الدليل. أعتقد أن معظم الناس يقرأون النصوص المطروحة أثناء التثبيت ولا يقرأون وثيقة التثبيت، لذا لم يشتكِ أحد آخر.
لماذا ظننت ذلك؟ عملية التثبيت تقوم تلقائيًا بإعداد Let’s Encrypt منذ سنوات.
لا أستطيع تحديد ما إذا كنت تقول إن موقعك يعمل أم لا يعمل.
إذا لم يكن يعمل، فمن المرجح أنك نفذت أمر discourse-setup عدة مرات واستنفدت حد معدل الطلبات الخاص بك في letsencrypt.org.