Discourse لا يقدم الصفحات

أواجه بعض المشكلات في تشغيل Discourse بعد التثبيت.

وفقًا للصفحة التالية، بعد تشغيل سكريبت discourse-setup، يجب أن أتمكن من تصفح الرابط المهيأ. يبدو أنني بحاجة إلى استدعاء الأمر التالي أيضًا:
./launcher start app

لست متأكدًا مما إذا كانت هذه مشكلة في التوثيق أو أنني أقوم بشيء خاطئ؟ كما ألاحظ أنه بعد تشغيل الأمر المذكور أعلاه، تظهر الملاحظات التالية:

  1. أستطيع تحميل صفحة ويب عند التوجه إلى الرابط المهيأ.
  2. يتم تحميل صفحة ‘مرحبًا بك في Nginx’ بدلاً من صفحة ‘تهانينا، لقد قمت بتثبيت Discourse!’.
  3. بعد فترة قصيرة (مثل نصف دقيقة)، تتوقف صفحة ‘مرحبًا بك في Nginx’ عن التحميل.
  4. عند تشغيل ./launcher stop app ثم ./launcher start app، ألاحظ أنني أستطيع تحميل صفحة ‘مرحبًا بك في Nginx’، لكن الأمر يتوقف مرة أخرى بعد فترة قصيرة.

تم التثبيت على جهاز افتراضي مخصص جديد دون تشغيل Nginx على الجهاز، لذا فإن صفحة ‘مرحبًا بك في Nginx’ تأتي من الحاوية التي تشغل Discourse.

لا يتوقع حدوث أي من هذه الأمور. يبدو أنك تشغل nginx آخر، ربما؟ هل هناك أي شيء آخر يعمل على الخادم الافتراضي؟

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

هذا غير ممكن لأن التثبيت هو نسخة CentOS أساسية ومبسطة للغاية. لقد تحققت من ذلك بتشغيل الأمر التالي، ولم يكن هناك أي شيء يستمع إلى المنفذ 80 أو 443 دون تشغيل الحاوية.
lsof -i TCP

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

أفضل تخمين لي هو أن هناك مشكلة ما في CentOS و discourse-setup. أسهل حل هو تجربة Ubuntu. وإلا، ستحتاج إلى الانتباه لما يفعله السكربت ومحاولة تصحيح المشكلة.

إذا اتبعت دليل التثبيت التالي، الذي أوصى به شخص لا يُذكر اسمه :smiley:

فإنه لا ينبغي أن تواجه أي مشاكل.

https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md

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

آه، لقد حاولت بالفعل لكنني وجدت أن كلا من مثبتي إصدارات LTS 19 و20 ينهاران في منتصف العملية. كلاهما كانا يقولا إنهما غير قادرين على تكوين الواجهة تلقائيًا. إذا تركتها معطلة، يعمل المثبت بشكل جيد، لكن إذا قمت بتعيين عنوان IP يدويًا، فإنهما ينهاران.

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

مرحبًا @titusc

ماذا ترى عند تنفيذ الأمر:

docker ps 

؟

هل تقصد أن مثبت أوبونتو لا يعمل؟

أم أنك تحاول استخدام ديسكورش المعتاد مع رقم IP بدلاً من اسم النطاق؟

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

أنا لا أستخدم عنوان IP في تثبيت Discourse، بل أستخدم اسم نطاق صحيح قابل للحل على DNS العام.

أقصد أن مثبت Ubuntu ينهار دائمًا عند محاولة تشغيله عن طريق التمهيد من صورة قرص ISO الخاصة بـ Ubuntu أثناء إنشاء الآلة. يحدث هذا مع Ubuntu Server 19.10 و 20.04 LTS على حد سواء، وخلال كلا التثبيتين يُبلغ عن عدم القدرة على إعداد واجهة الشبكة. إذا تركتها كما هي، فسيتم التثبيت بنجاح، لكن لا توجد لدي وسيلة لرفع الواجهة للقيام بأي شيء. لقد نجحت في تشغيل الأمر التالي:
ip address add <ip>/<mask> dev <interface>

لكنني لم أستطع رفع الواجهة بتشغيل الأمر التالي:
ifup <interface>

ثم قمت بربط صورة ISO كحلقة وهمية (loopback) وضبطتها كمستودع، وحاولت تشغيل الأمر التالي، لكنه أفاد بعدم وجوده في صورة ISO:
apt install net-tools

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

للتوضيح، أقوم بذلك على ESXi 7.0 وأستخدم صور ISO التالية:
ubuntu-20.04-live-server-amd64.iso
ubuntu-19.10-live-server-amd64.iso

سيُظهر أن حاوية Discourse قيد التشغيل. في كل مرة أقوم فيها بما يلي:

  1. ./launcher start app
  2. أتحقق من المتصفح وأرى صفحة “مرحبًا بك في Nginx”، لكنها تختفي بعد حوالي نصف دقيقة.
  3. docker ps للتأكد من أن حاوية Discourse قيد التشغيل.
  4. ./launcher stop app ثم ./launcher start app
  5. أتحقق من المتصفح وأرى صفحة “مرحبًا بك في Nginx”، لكنها تختفي بعد حوالي نصف دقيقة.
  6. docker ps للتأكد من أن حاوية Discourse قيد التشغيل.

ما لاحظته أيضًا هو أنه عند تشغيل الأوامر التالية، لا أرى Nginx قيد التشغيل، لكن قد يكون ذلك بسبب توقفه بالفعل بحلول الوقت الذي أقوم بتشغيل الأمر فيه.
./launcher enter app
systemctl status nginx

@titusc

هل جربت إعادة بناء التطبيق؟

/var/discourse/launcher rebuild app

عادةً، اعتمادًا على الوقت الذي يستغرقه الحاوية للبدء بالكامل، قد يستغرق الأمر بعض الوقت (بناءً على مواصفات نظامك) حتى يعمل بشكل كامل.

حتى على جهاز Linux الخاص بنا الذي يحتوي على 64 جيجابايت من الذاكرة و8 أنوية معالجة، ننتظر حوالي دقيقة كاملة قبل التبديل إلى الحاوية الجديدة.

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

هل جربت إصدار 18.04؟

يبدو أن المشكلة بيئية، لكننا لا نستطيع تقديم دعم لفرط التمييز (hypervisors) وتوزيعات لينكس هنا. أحد الأسباب التي تجعل DigitalOcean موصى بها هو اتساق نظام التشغيل المثبت فوقه. إذا كنت ترغب في إنشاء آلة افتراضية من الصفر، فستحتاج إلى حل هذه المسألة مسبقًا.

بمجرد توفر نظام تشغيل يعمل، يمكننا مساعدتك في تثبيت جزء Discourse.

مرحبًا @DBHacker، نعم قمت بالتالي بالترتيب:
./launcher rebuild app
./launcher start app

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

@Stephen، نعم أحتاج إلى حل المشكلات المتعلقة بتثبيت Ubuntu أولاً. بصراحة، لست من محبي Ubuntu، وقد كنت أستخدم CentOS / RH خلال الـ 15 عامًا الماضية. لكن ما أود السؤال عنه هو: هل تتوقعون أي إعدادات محددة يجب أن نقوم بها لـ CentOS / RH؟

تم اختبار سكريبت إعداد discourse وإثبات نجاحه على نظام Ubuntu.

قد تضطر إلى تنفيذ بعض الخطوات أو كلها يدويًا على توزيعات أخرى. اطلع على محتويات الملف لتكوين فكرة عن ما يقوم به.

مرحبًا @titusc

نأسف لسماع أنك تواجه مشاكل.

بالمناسبة، لا تحتاج إلى تشغيل:

./launcher start app

بعد تشغيل:

./launcher rebuild app

لأنه عند إعادة بناء التطبيق باستخدام سكريبت الـ launcher (انظر أدناه)، يعيد هذا السكريبت تشغيل الحاوية قبل خروجه.

إليك جزءًا ذا صلة من كود الـ launcher:

  rebuild)
      if [ "$(git symbolic-ref --short HEAD)" == "master" ]; then
        echo "Ensuring launcher is up to date"

        git remote update

        LOCAL=$(git rev-parse HEAD)
        REMOTE=$(git rev-parse @{u})
        BASE=$(git merge-base HEAD @{u})

        if [ $LOCAL = $REMOTE ]; then
          echo "Launcher is up-to-date"

        elif [ $LOCAL = $BASE ]; then
          echo "Updating Launcher..."
          git pull || (echo 'failed to update' && exit 1)

          echo "Launcher updated, restarting..."
          exec "$0" "${SAVED_ARGV[@]}"

        elif [ $REMOTE = $BASE ]; then
          echo "Your version of Launcher is ahead of origin"

        else
          echo "Launcher has diverged source, this is only expected in Dev mode"
        fi

      fi

      set_existing_container

      if [ ! -z $existing ]
        then
          echo "Stopping old container"
          (
            set -x
            $docker_path stop -t 60 $config
          )
      fi

      run_bootstrap

      if [ ! -z $existing ]
        then
          echo "Removing old container"
          (
            set -x
            $docker_path rm $config
          )
      fi

      run_start
      exit 0
      ;;

يمكنك ملاحظة من السكريبت أن طريقة rebuild تحاول تشغيل الحاوية قبل الخروج.

نأمل أن يكون هذا مفيدًا.

@neounix أنت محق. سأختبر مرة أخرى وأتحقق من ذلك. أتمنى أن يكون هذا هو السبب. لست متأكدًا من السلوك إذا بدأ الحاوية ثم قمت بتشغيلها مرة أخرى بتشغيل ./launcher start app

عزيزي @titusc

عذرًا على عدم الرد بتفصيل أكثر، لكن عليّ الانصراف فورًا لرحلة طويلة.

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

قد تفكر في تنظيف (تقليم) صور Docker “المكدّسة” والحاويات غير المستخدمة في وقت ما.

على سبيل المثال (بسرعة ودون تفكير مسبق):

docker ps -a
docker images
docker system prune -a

يجب عليك إيقاف جميع الحاويات “الضالة”، ثم إزالتها وحذف جميع صور Docker القديمة.

يجب أن أرحل الآن…

أتمنى أن يكون ذلك مفيدًا.

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

@neounix وافق على فحص صور Docker. في الواقع، قمت بذلك بالفعل، لكن دعني أريك التفاصيل. كما تلاحظ أدناه، تم بناء Discourse بنجاح وبدأ في العمل داخل حاوية Docker. في النهاية، يمكنك رؤية أن Nginx كان يعمل داخل الحاوية لكنه توقف بعد حوالي 5 ثوانٍ فقط.

قبل بدء كل شيء

[root@uat discourse]# pwd
/var/discourse
[root@uat discourse]# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
[root@uat discourse]# docker container ls -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
[root@uat discourse]# docker image ls
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
discourse/base      2.0.20200724-1815   6ba1506bf822        9 days ago          2.38GB
centos              latest              831691599b88        6 weeks ago         215MB
alpine              latest              a24bb4013296        2 months ago        5.57MB

تأكيد عدم وجود خادم HTTP يعمل على المضيف

[root@uat discourse]# systemctl status nginx
Unit nginx.service could not be found.
[root@uat discourse]# lsof -i TCP
COMMAND  PID    USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
systemd    1    root  181u  IPv4   19283      0t0  TCP *:sunrpc (LISTEN)
systemd    1    root  183u  IPv6   19285      0t0  TCP *:sunrpc (LISTEN)
rpcbind 1070     rpc    4u  IPv4   19283      0t0  TCP *:sunrpc (LISTEN)
rpcbind 1070     rpc    6u  IPv6   19285      0t0  TCP *:sunrpc (LISTEN)
sshd    1234    root    5u  IPv4   26444      0t0  TCP *:ssh (LISTEN)
sshd    1234    root    7u  IPv6   26446      0t0  TCP *:ssh (LISTEN)
cupsd   1240    root    9u  IPv6   27746      0t0  TCP localhost:ipp (LISTEN)
cupsd   1240    root   10u  IPv4   27747      0t0  TCP localhost:ipp (LISTEN)
dnsmasq 2094 dnsmasq    6u  IPv4   37419      0t0  TCP uat:domain (LISTEN)
sshd    7102    root    5u  IPv4 2072827      0t0  TCP uat:ssh->10.1.136.4:52229 (ESTABLISHED)
sshd    7156    tech    5u  IPv4 2072827      0t0  TCP uat:ssh->10.1.136.4:52229 (ESTABLISHED)

إعادة بناء Discourse

[root@uat discourse]# ./launcher rebuild app
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
cd /pups && git pull && /pups/bin/pups --stdin
Already up to date.
......................................................................
I, [2020-08-03T06:54:22.114365 #1]  INFO -- : > echo "Beginning of custom commands"
I, [2020-08-03T06:54:22.116739 #1]  INFO -- : Beginning of custom commands

I, [2020-08-03T06:54:22.116996 #1]  INFO -- : > echo "End of custom commands"
I, [2020-08-03T06:54:22.119862 #1]  INFO -- : End of custom commands

I, [2020-08-03T06:54:22.119983 #1]  INFO -- : Terminating async processes
I, [2020-08-03T06:54:22.120021 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/12/bin/postmaster -D /etc/postgresql/12/main pid: 49
I, [2020-08-03T06:54:22.120086 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 166
166:signal-handler (1596437662) Received SIGTERM scheduling shutdown...
2020-08-03 06:54:22.120 UTC [49] LOG:  received fast shutdown request
2020-08-03 06:54:22.121 UTC [49] LOG:  aborting any active transactions
2020-08-03 06:54:22.128 UTC [49] LOG:  background worker "logical replication launcher" (PID 58) exited with exit code 1
2020-08-03 06:54:22.128 UTC [53] LOG:  shutting down
2020-08-03 06:54:22.154 UTC [49] LOG:  database system is shut down
166:M 03 Aug 2020 06:54:22.176 # User requested shutdown...
166:M 03 Aug 2020 06:54:22.176 * Saving the final RDB snapshot before exiting.
166:M 03 Aug 2020 06:54:22.184 * DB saved on disk
166:M 03 Aug 2020 06:54:22.184 # Redis is now ready to exit, bye bye...
sha256:7b8e9281c49ba3dc37e0743a765cddc13ab73aae5486bd30722c696c2e1443b1
ce327c6e37246e63331f03b07d64f4882efa68e88cb1516c6343a9dddbbd59df

+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=4 -e UNICORN_SIDEKIQS=1 -e RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_HOSTNAME=uat.xxxxxx.com -e DISCOURSE_DEVELOPER_EMAILS=support@xxxxxx.com -e DISCOURSE_SMTP_ADDRESS=smtp-relay.xxxxxx.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=support@xxxxxx.com -e DISCOURSE_SMTP_PASSWORD=support@xxxxxx.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -h uat-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:fe:39:ba:65:e1 local_discourse/app /sbin/boot
44c604ccbda4bfb4d48722e1cbbf70e3b067531acda41175f6bdaaa013cc6d18

تأكيد بناء الصورة وتشغيل Docker

[root@uat discourse]# docker container ls -a
CONTAINER ID        IMAGE                 COMMAND             CREATED             STATUS              PORTS                                      NAMES
44c604ccbda4        local_discourse/app   "/sbin/boot"        7 minutes ago       Up 7 minutes        0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app
[root@uat discourse]# docker ps
CONTAINER ID        IMAGE                 COMMAND             CREATED             STATUS              PORTS                                      NAMES
44c604ccbda4        local_discourse/app   "/sbin/boot"        7 minutes ago       Up 7 minutes        0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app
[root@uat discourse]# docker image ls
REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE
local_discourse/app   latest              7b8e9281c49b        8 minutes ago       2.66GB
discourse/base        2.0.20200724-1815   6ba1506bf822        9 days ago          2.38GB
centos                latest              831691599b88        6 weeks ago         215MB
alpine                latest              a24bb4013296        2 months ago        5.57MB

تأكيد عدم وجود أي شيء يعمل على المضيف وأن Docker يستمع على المنافذ 80 و 443

[root@uat discourse]# systemctl status nginx
Unit nginx.service could not be found.
[root@uat discourse]#
[root@uat discourse]# lsof -i TCP
COMMAND     PID    USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
systemd       1    root  181u  IPv4   19283      0t0  TCP *:sunrpc (LISTEN)
systemd       1    root  183u  IPv6   19285      0t0  TCP *:sunrpc (LISTEN)
rpcbind    1070     rpc    4u  IPv4   19283      0t0  TCP *:sunrpc (LISTEN)
rpcbind    1070     rpc    6u  IPv6   19285      0t0  TCP *:sunrpc (LISTEN)
sshd       1234    root    5u  IPv4   26444      0t0  TCP *:ssh (LISTEN)
sshd       1234    root    7u  IPv6   26446      0t0  TCP *:ssh (LISTEN)
cupsd      1240    root    9u  IPv6   27746      0t0  TCP localhost:ipp (LISTEN)
cupsd      1240    root   10u  IPv4   27747      0t0  TCP localhost:ipp (LISTEN)
dnsmasq    2094 dnsmasq    6u  IPv4   37419      0t0  TCP uat:domain (LISTEN)
sshd       7102    root    5u  IPv4 2072827      0t0  TCP uat:ssh->10.1.136.4:52229 (ESTABLISHED)
sshd       7156    tech    5u  IPv4 2072827      0t0  TCP uat:ssh->10.1.136.4:52229 (ESTABLISHED)
docker-pr 12991    root    4u  IPv6 2242261      0t0  TCP *:https (LISTEN)
docker-pr 13003    root    4u  IPv6 2242288      0t0  TCP *:http (LISTEN)

إعادة تشغيل Docker والتحقق من Nginx بعد توقفه

[root@uat discourse]# ./launcher stop app
+ /usr/bin/docker stop -t 10 app
app
[root@uat discourse]# ./launcher start app; ./launcher enter app

starting up existing container
+ /usr/bin/docker start app
app
root@uat-app:/var/www/discourse# date; ps -ef | grep nginx
Mon 03 Aug 2020 07:29:47 AM UTC
root        34     1  0 07:29 ?        00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/letsencrypt.conf
www-data    36    34  0 07:29 ?        00:00:00 nginx: worker process
www-data    37    34  0 07:29 ?        00:00:00 nginx: worker process
root      1091   398  0 07:29 pts/1    00:00:00 grep nginx
root@uat-app:/var/www/discourse# date; ps -ef | grep nginx
Mon 03 Aug 2020 07:29:50 AM UTC
root        34     1  0 07:29 ?        00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/letsencrypt.conf
www-data    36    34  0 07:29 ?        00:00:00 nginx: worker process
www-data    37    34  0 07:29 ?        00:00:00 nginx: worker process
root      1854   398  0 07:29 pts/1    00:00:00 grep nginx
root@uat-app:/var/www/discourse# date; ps -ef | grep nginx
Mon 03 Aug 2020 07:29:52 AM UTC
root      2043  2038  0 07:29 ?        00:00:00 runsv nginx
root      2080   398  0 07:29 pts/1    00:00:00 grep nginx
root@uat-app:/var/www/discourse#
إعجاب واحد (1)

مرحبًا @titusc

شكرًا لك على المنشور الممتاز ومعلومات استكشاف الأخطاء وإصلاحها الشاملة. عمل رائع جدًا.

هل قمت بفحص ملفات سجل nginx في التطبيق للبحث عن أدلة؟

هناك خلل في إعداداتك. أظن أن المشكلة التي تمنع تثبيت Ubuntu تتسبب أيضًا في تعارض مع CentOS.

يجب إصلاح ذلك قبل تثبيت Discourse (أو أي شيء آخر على الأرجح).