Discourse não está servindo páginas

Suporte Instalação
1

Estou tendo alguns problemas para executar o Discourse após a instalação.

De acordo com a página a seguir, depois de executar o script discourse-setup, deveria ser possível acessar a URL configurada. Aparentemente, também preciso chamar o seguinte comando:
./launcher start app

Não tenho certeza se se trata de um erro na documentação ou se estou fazendo algo errado? Também notei que, após executar o comando acima, tenho as seguintes observações:

  1. Consigo carregar uma página web ao acessar a URL configurada.
  2. A página ‘Welcome to Nginx’ é carregada em vez da página ‘Congratulations, you installed Discourse!’.
  3. Após um curto período (por exemplo, meio minuto), a página ‘Welcome to Nginx’ deixa de carregar.
  4. Executo ./launcher stop app seguido de ./launcher start app, e percebo que consigo carregar a página ‘Welcome to Nginx’, mas novamente ela para de carregar após um curto período.

Isso foi instalado em uma nova VM dedicada sem o Nginx rodando na máquina, então a página ‘Welcome to Nginx’ está vindo do container que executa o Discourse.

2

Nenhum desses itens é esperado. Parece que você tem outro nginx rodando, talvez? Há algo mais rodando na VM?

3

Isso não é possível porque se trata de uma instalação minimalista e essencial do CentOS. Verifiquei executando o seguinte comando e não há nada escutando nas portas 80 ou 443 sem o contêiner em execução.
lsof -i TCP

4

Minha melhor suposição é que haja algum problema com o CentOS e o discourse-setup. A coisa mais fácil seria tentar o Ubuntu. Caso contrário, você precisará prestar atenção ao que o script faz e tentar depurar o problema.

5

Se você seguiu o seguinte guia de instalação, recomendado por alguém que não deve ser mencionado :smiley:

Você não deve ter nenhum problema.

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

6

Suspiro. Na verdade, tentei, mas descobri que os instaladores do 19 e do 20 LTS travavam pela metade. Ambos diziam que não conseguiam configurar automaticamente a interface. Se eu a deixava desativada, o instalador rodava normalmente, mas se eu definia o IP manualmente, eles travavam.

Se eu desativo a interface para conseguir continuar com a instalação, não consigo instalar as ferramentas de rede para obter o ifconfig, mesmo montando a ISO e usando-a como fonte. Então, estou um pouco preso.

7

Olá @titusc

O que você vê ao executar:

docker ps

?

8

Você está dizendo que o instalador do Ubuntu não funciona?

Ou você está tentando usar o Discourse com um número de IP em vez de um nome de domínio?

9

Não estou usando um endereço IP para a instalação do Discourse. Estou usando um nome de domínio válido que é resolvível no DNS público.

O que quero dizer é que o instalador do Ubuntu sempre trava sempre que tento executá-lo ao inicializar a partir da imagem ISO do Ubuntu durante a criação da máquina. Isso ocorre tanto no Ubuntu Server 19.10 quanto no 20.04 LTS, e durante ambas as instalações, ele relata não conseguir configurar a interface de rede. Se eu deixar como está, a instalação ocorre normalmente, mas não tenho como ativar a interface para fazer qualquer coisa. Executei o seguinte comando com sucesso:
ip address add <ip>/<mask> dev <interface>

Mas então não consigo ativá-la executando o seguinte:
ifup <interface>

Em seguida, montei a ISO como loopback, configurei como repositório e tentei executar o seguinte, mas ele diz que não foi encontrado na ISO:
apt install net-tools

Se tentar configurar a interface manualmente com os detalhes de rede durante a instalação, ambas as versões travam.

Para registro, estou fazendo isso no ESXi 7.0 e usando as seguintes ISOs:
ubuntu-20.04-live-server-amd64.iso
ubuntu-19.10-live-server-amd64.iso

10

Isso mostraria que o container do Discourse está em execução. Cada vez que faço o seguinte:

  1. ./launcher start app
  2. Verifico no navegador e vejo a página ‘Welcome to Nginx’, mas ela desaparece após cerca de meio minuto.
  3. docker ps para confirmar que o container do Discourse está em execução.
  4. ./launcher stop app e ./launcher start app
  5. Verifico no navegador e vejo a página ‘Welcome to Nginx’, mas ela desaparece após cerca de meio minuto.
  6. docker ps para confirmar que o container do Discourse está em execução.

O que também noto é que, ao executar os seguintes comandos, não consigo ver o Nginx em execução, mas isso pode ser porque ele já foi interrompido no momento em que executo o comando:
./launcher enter app
systemctl status nginx

11

@titusc

Você já tentou reconstruir o aplicativo?

/var/discourse/launcher rebuild app

Normalmente, dependendo de quando seu container inicia completamente, pode levar algum tempo (baseado nas especificações do seu sistema) para ficar totalmente operacional.

Mesmo em nossa máquina Linux com 64 GB de RAM e 8 núcleos de CPU, esperamos cerca de um minuto inteiro antes de mudar para o novo container.

12

Você tentou a 18.04?

Parece ser um problema relacionado ao ambiente. No entanto, não podemos oferecer suporte para hipervisores e distribuições Linux aqui. Um dos motivos pelos quais o DigitalOcean é recomendado é a consistência do sistema operacional instalado sobre ele. Se você quiser criar uma VM do zero, precisará resolver isso antes.

Assim que você tiver um sistema operacional funcional, poderemos ajudar a instalar a parte do Discourse.

13

Olá @DBHacker, sim, fiz o seguinte na sequência:
./launcher rebuild app
./launcher start app

Isso foi depois de perceber que o comando abaixo apenas vai até a parte de rebuild do launcher:
./discourse-setup

@Stephen, sim, preciso resolver os problemas com a instalação do Ubuntu primeiro. Para ser honesto, não sou muito fã do Ubuntu e tenho usado CentOS / RH nos últimos 15 anos. O que gostaria de perguntar, no entanto, é: você espera que configuremos algo específico para CentOS / RH?

14

O script discourse-setup foi testado e comprovado no Ubuntu.

Você pode precisar executar alguns ou todos os passos manualmente em outra distribuição. Dê uma olhada no conteúdo do arquivo para ter uma ideia do que ele está fazendo.

15

Olá @titusc

Lamentamos pelos problemas que você está enfrentando.

Apenas para informação, você não precisa executar:

./launcher start app

após executar:

./launcher rebuild app

porque, ao reconstruir o aplicativo com o script do launcher (veja abaixo), esse script reinicia o contêiner antes de sair.

Aqui está uma parte relevante do código do launcher:

  rebuild)
      if [ "$(git symbolic-ref --short HEAD)" == "master" ]; then
        echo "Garantindo que o launcher está atualizado"

        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 está atualizado"

        elif [ $LOCAL = $BASE ]; then
          echo "Atualizando Launcher..."
          git pull || (echo 'falha ao atualizar' && exit 1)

          echo "Launcher atualizado, reiniciando..."
          exec "$0" "${SAVED_ARGV[@]}"

        elif [ $REMOTE = $BASE ]; then
          echo "Sua versão do Launcher está à frente da origem"

        else
          echo "O Launcher divergiu do código-fonte, isso é esperado apenas no modo de Desenvolvimento"
        fi

      fi

      set_existing_container

      if [ ! -z $existing ]
        then
          echo "Parando o contêiner antigo"
          (
            set -x
            $docker_path stop -t 60 $config
          )
      fi

      run_bootstrap

      if [ ! -z $existing ]
        then
          echo "Removendo o contêiner antigo"
          (
            set -x
            $docker_path rm $config
          )
      fi

      run_start
      exit 0
      ;;

Você pode ver no script que o método rebuild tenta iniciar o contêiner antes de sair.

Espero que ajude.

16

@neounix você está certo. Vou testar novamente e verificar isso. Espero que essa tenha sido a causa. Não tenho certeza de qual é o comportamento se ele iniciar o contêiner e eu o iniciar novamente executando ./launcher start app

17

Prezado @titusc,

Peço desculpas por não responder com mais detalhes, mas preciso partir para uma longa viagem de carro.

Muitas pessoas que cometem erros ao criar, reconstruir imagens Docker e contêineres costumam ter problemas.

Você pode considerar limpar (podar) suas imagens Docker “acumuladas” e os contêineres não utilizados em algum momento.

Por exemplo (de cabeça, rapidamente):

docker ps -a

docker images

docker system prune -a

Você deve parar todos os contêineres “rogue”, removê-los e excluir todas as imagens Docker antigas.

Preciso correr…

Espero que ajude.

18

@neounix concordei em verificar as imagens do Docker. Na verdade, eu já fiz isso, mas deixe-me mostrar os detalhes para você. Como você pode ver abaixo, o Discourse foi construído com sucesso e começou a ser executado em um contêiner Docker. No final, você pode ver que o Nginx estava rodando no contêiner, mas saiu após apenas cerca de 5 segundos.

Antes de Tudo Começar

[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

Confirmar que Nenhum Servidor HTTP Está Rodando na Máquina Hospedeira

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

Reconstruir o 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

Confirmar que a Imagem Foi Construída e o Docker Está Rodando

[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

Confirmar que Nada Ainda Está Rodando na Máquina Hospedeira e que o Docker Está Escutando nas Portas 80 e 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)

Reiniciar o Docker e Verificar o Nginx Após o Nginx Ter Parado

[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#
19

Olá @titusc

Obrigado pelo ótimo post e pelas informações abrangentes de solução de problemas. Muito bem feito.

Você verificou os arquivos de log do nginx no aplicativo em busca de pistas?

20

Algo está quebrado na sua configuração. Minha aposta é que o problema que impede a instalação do Ubuntu também está interferindo no CentOS.

Você precisa corrigir isso antes de instalar o Discourse (ou, provavelmente, qualquer outra coisa).