Discourse가 페이지를 제공하지 않음

[titusc]

설치 후 Discourse를 실행하는 데 문제가 있습니다.

다음 페이지에 따르면 discourse-setup 스크립트를 실행한 후에는 설정된 URL로 브라우저에서 접속할 수 있어야 합니다. 그런데 다음 명령도 실행해야 하는 것 같습니다.
./launcher start app

이것이 문서 오류인지, 아니면 제가 뭔가 잘못하고 있는 것인지 확실하지 않습니다. 또한 위에서 언급한 명령을 실행한 후 다음과 같은 현상을 관찰했습니다:

1. 설정된 URL로 브라우저에서 접속하면 웹페이지가 로드됩니다.
2. ‘Congratulations, you installed Discourse!’ 페이지 대신 ‘Welcome to Nginx’ 페이지가 로드됩니다.
3. 잠시 후(예: 30초 정도) ‘Welcome to Nginx’ 페이지가 더 이상 로드되지 않습니다.
4. ./launcher stop app을 실행한 뒤 ./launcher start app을 실행하면 ‘Welcome to Nginx’ 페이지를 다시 로드할 수 있지만, 잠시 후 다시 로드되지 않습니다.

이것은 Nginx가 실행되지 않는 새로운 전용 VM에 설치된 것이므로, ‘Welcome to Nginx’ 페이지는 Discourse를 실행하는 컨테이너에서 나오는 것입니다.

[pfaffman (Jay Pfaffman)]

그런 것들은 예상된 것이 아닙니다. 다른 nginx가 실행되고 있는 것 같네요? VM에서 다른 것이 실행되고 있나요?

[titusc]

CentOS를 최소한의 기본 구성으로 설치했기 때문에 불가능합니다. 컨테이너를 실행하지 않은 상태에서 다음 명령어를 실행하여 확인해 보았는데, 포트 80 또는 443에서 리스닝 중인 프로세스가 없었습니다.
lsof -i TCP

[pfaffman (Jay Pfaffman)]

제 추측으로는 CentOS와 discourse-setup 사이에 어떤 문제가 있는 것 같습니다. 가장 쉬운 방법은 Ubuntu를 시도해 보는 것입니다. 그렇지 않다면, 스크립트가 어떤 작업을 수행하는지 주의 깊게 살펴보고 문제를 디버깅해 보셔야 합니다.

[IAmGav (Gavin Perch)]

누군가가 추천한 설치 가이드를 따랐다면

문제가 발생하지 않을 것입니다.

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

[titusc]

아쉬운 마음에 한숨이 나옵니다. 실제로 시도해 보았는데, 19과 20 LTS 설치 프로그램 모두 중간쯤에서 충돌했습니다. 두 프로그램 모두 인터페이스를 자동으로 구성할 수 없다고 표시했습니다. 인터페이스를 비활성화 상태로 두면 설치 프로그램이 정상적으로 실행되지만, IP를 수동으로 설정하면 충돌이 발생합니다.

설치를 계속하기 위해 인터페이스를 비활성화하면, ISO를 마운트하여 소스로 사용해도 ifconfig를 포함한 네트워크 도구를 설치할 수 없습니다. 그래서 현재 좀 막혀 있는 상태입니다.

[neounix (Dark Matter)]

안녕하세요 @titusc

다음 명령을 실행하면 어떤 결과가 표시되나요?

docker ps 

?

[pfaffman (Jay Pfaffman)]

@titusc

. 비활성화 상태로 두면 설치 프로그램이 정상적으로 실행되지만, IP를 수동으로 설정하면 충돌이 발생합니다.

Ubuntu 설치 프로그램이 작동하지 않는다는 말씀이신가요?

아니면 도메인 이름 대신 IP 번호를 사용하여 일반적인 discourse를 시도하고 계신 건가요?

[titusc]

Discourse 설치에는 IP 주소를 사용하지 않습니다. 공개 DNS에서 해석 가능한 정식 도메인 이름을 사용하고 있습니다.

기계 생성 중 Ubuntu ISO 디스크 이미지로 부팅하여 설치자를 실행할 때마다 Ubuntu 설치자가 항상 충돌(crash)한다는 것입니다. Ubuntu Server 19.10과 20.04 LTS 모두에서, 두 설치 과정 모두에서 네트워크 인터페이스를 설정할 수 없다는 보고가 나옵니다. 그대로 두면 설치는 정상적으로 완료되지만, 인터페이스를 활성화하여 작업을 수행할 수단이 없습니다. 다음 명령은 성공적으로 실행했습니다.
ip address add <ip>/<mask> dev <interface>

하지만 다음 명령을 실행하여 인터페이스를 활성화하지 못했습니다.
ifup <interface>

이후 ISO를 루프백으로 마운트하고 저장소로 설정한 뒤 다음 명령을 실행해 보았지만, ISO에서 해당 항목을 찾을 수 없다고 표시됩니다.
apt install net-tools

설치 중 네트워크 세부 정보를 수동으로 설정하려고 하면 두 버전 모두 충돌합니다.

참고로 ESXi 7.0에서 이 작업을 수행하고 있으며, 다음 ISO를 사용하고 있습니다.
ubuntu-20.04-live-server-amd64.iso
ubuntu-19.10-live-server-amd64.iso

[titusc]

Discourse 컨테이너가 실행 중임을 확인할 수 있습니다. 다음 단계를 수행할 때마다 동일한 문제가 발생합니다.

1. ./launcher start app
2. 브라우저에서 ‘Welcome to Nginx’ 페이지를 확인하지만, 약 30초 후 더 이상 표시되지 않습니다.
3. docker ps를 실행하여 Discourse 컨테이너가 실행 중임을 확인합니다.
4. ./launcher stop app 및 ./launcher start app 실행
5. 브라우저에서 ‘Welcome to Nginx’ 페이지를 확인하지만, 약 30초 후 더 이상 표시되지 않습니다.
6. docker ps를 실행하여 Discourse 컨테이너가 실행 중임을 확인합니다.

또한, 다음 명령을 실행할 때 Nginx가 실행 중이지 않은 것을 확인할 수 있습니다. 이는 해당 명령을 실행할 시점에 Nginx가 이미 중지되었기 때문일 수 있습니다.
./launcher enter app
systemctl status nginx

[DBHacker]

@titusc

앱을 재빌드해 보셨나요?

/var/discourse/launcher rebuild app

보통 컨테이너가 완전히 시작되는 시점에 따라 시스템 사양에 따라 완전히 운영 가능한 상태가 되는 데 시간이 걸릴 수 있습니다.

64GB RAM, 8개 CPU 코어를 가진 Linux 서버에서도 새 컨테이너로 전환하기 전에 약 1분 정도 기다립니다.

[Stephen]

18.04를 시도해 보셨나요?

환경 관련 문제인 것 같습니다. 다만 여기서는 하이퍼바이저와 리눅스 배포판에 대한 지원을 제공하기 어렵습니다. DigitalOcean이 권장되는 이유 중 하나는 설치되는 운영체제의 일관성입니다. 처음부터 VM을 구축하려는 경우, 이를 사전에 직접 해결해야 합니다.

정상적으로 작동하는 OS를 갖추신 후에는 Discourse 설치 부분에 대해 도움을 드릴 수 있습니다.

[titusc]

안녕하세요 @DBHacker, 네, 다음 명령들을 순서대로 실행했습니다.
./launcher rebuild app
./launcher start app

이것은 제가 다음 사항을 깨달은 후입니다. ./discourse-setup가 실제로 하는 일은 launcher의 rebuild 단계까지만 진행된다는 것입니다.

@Stephen, 네, 먼저 Ubuntu 설치 관련 문제를 해결해야 합니다. 솔직히 저는 Ubuntu를 크게 선호하지 않으며, 지난 15년간 CentOS / RH를 사용해 왔습니다. 다만 질문드리고 싶은 것은 CentOS / RH를 위해 특별히 설정해야 할 사항이 있는지 여부입니다.

[Stephen]

discourse-setup 스크립트는 Ubuntu에서 테스트 및 검증되었습니다.

다른 배포판을 사용하는 경우, 일부 또는 모든 단계를 수동으로 수행해야 할 수 있습니다. 스크립트가 수행하는 작업의 개요를 파악하려면 파일 내용을 확인해 보세요.

[neounix (Dark Matter)]

@titusc

@DBHacker 안녕하세요, 네 다음 순서대로 실행했습니다.
./launcher rebuild app
./launcher start app

@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 메서드는 종료하기 전에 컨테이너를 시작하려고 시도합니다.

도움이 되길 바랍니다.

[titusc]

@neounix 맞습니다. 다시 테스트해서 이 부분을 확인해 보겠습니다. 다행히 이게 원인이었으면 좋겠네요. 컨테이너를 시작하고 나서 ./launcher start app를 다시 실행했을 때의 동작은 정확히 모르겠습니다.

[neounix (Dark Matter)]

titusc 님, 안녕하세요.

자세히 답변드리지 못해 죄송합니다. 긴 장거리 여행을 떠나야 해서요.

Docker 이미지와 컨테이너를 빌드하거나 재빌드하는 과정에서 실수를 하는 사람들이 흔히 문제를 겪곤 합니다.

적당히 쌓인 Docker 이미지와 사용하지 않는 컨테이너를 정리(트림)하는 것을 고려해 보시는 것이 좋겠습니다.

예를 들어(즉석에서 빠르게 작성했습니다)

docker ps -a

docker images

docker system prune -a

모든 “rogue” 컨테이너를 중지하고 제거한 후, 모든 오래된 Docker 이미지를 삭제해야 합니다.

지금 떠나야 해서요…

도움이 되셨길 바랍니다.

[titusc]

@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)

Nginx가停止된 후 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#

[neounix (Dark Matter)]

안녕하세요 @titusc

훌륭한 글과 종합적인 문제 해결 정보를 공유해 주셔서 감사합니다. 정말 잘 정리하셨습니다.

앱의 nginx 로그 파일을 확인해서 단서를 찾았나요?

[pfaffman (Jay Pfaffman)]

설정에서 문제가 발생한 것 같습니다. 제 추측으로는 Ubuntu 설치를 막고 있는 그 문제가 CentOS에도 영향을 주고 있을 가능성이 높습니다.

Discourse(또는 아마 다른 프로그램도)를 설치하기 전에 먼저 그 문제를 해결해야 합니다.