تثبيت Discourse على Azure غير قابل للوصول

الدعم تثبيت
9

أعتذر عن إحياء هذا الموضوع، لكنه لا يزال ذا صلة. كل شيء يتم تثبيته بشكل رائع من منظور Discourse، ويبدو أن كل شيء على ما يرام، لكن المنطقتين 80 و443 غير قابلة للوصول من الخارج.

تحديث: التثبيت الأساسي يعمل بالفعل دون أي تعديلات على Azure مع Ubuntu Server.

إليك ما فعلته بشكل مختلف في المرة الثانية:

  1. بعد إنشاء الآلة الافتراضية واستدعاء discourse-setup، لم أقوم بإيقاف العملية، بحيث تم تنفيذ كل شيء دفعة واحدة.

    في المرة الأولى، أدركت أنني لا أملك مساحة تبادل (swap)، وعلى الرغم من أن سكريبت discourse-setup يقوم بإعدادها إذا كانت مفقودة، إلا أنني خرجت إلى سطر الأوامر للتحقق من بعض الأمور. ثم كانت بعض مطالبات التثبيت مختلفة عما هو موضح في الدليل الأساسي، لذا خرجت مرة أخرى.

    + ما أثار دهشتي كان سؤال Let’s Encrypt عن عنوان بريد إلكتروني لاستقبال الإشعارات المتعلقة به، وكنت تحت الانطباع بأنه سيتعين عليّ إعداد HTTPS يدويًا. في الواقع، يقوم السكريبت بإعداد مثيل Discourse بشهادة SSL من Let’s Encrypt.
    + أمر آخر كان أقسام اسم مستخدم وكلمة مرور SMTP؛ لا زلت غير متأكد مما إذا كان يمكنني تركها فارغة، لكنني أضفت ببساطة عنوان البريد الإلكتروني للمسؤول وكلمة المرور الخاصة بهذا الحساب.

  2. قمت بإعداد مساحة التبادل (swap) يدويًا وفقًا لـ هذا الموضوع في meta.discourse.

    لا أعتقد أن لهذا علاقة بالمشكلة، لكنني أذكره فقط تحسبًا. في المرة الثانية، قمت بكل شيء كما فعلت في المرة الأولى، باستثناء (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  -

بضع ملاحظات لنفسي في المستقبل:

  1. في المرة الأولى، لاحظت عدم وجود منافذ الاستماع 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 كان يعمل بشكل صحيح)

  2. اعتقدت أيضًا أن قواعد منافذ الدخول في Azure مشبوهة، لأن nc -zv كان يعيد باستمرار Connection refused، لكنني أدركت بعد ذلك أن هذا يعني فقط أن المنافذ مفتوحة ولكن لا أحد يستمع على الطرف الآخر. (لو كانت المنافذ محظورة، لكان nc قد توقف عن الاستجابة.)