Sou novo no Discourse e fiquei travado durante a instalação. Criei uma máquina virtual com o Ubuntu Server 18.04 e segui, mais ou menos, as instruções de instalação.
Quando digo “mais ou menos”, quero dizer que, em vez de um servidor em nuvem, estou usando o Ubuntu Server. Não instalei o Docker manualmente; deixei que o discourse-setup o instalasse para mim. Além disso, ainda não configurei um servidor de e-mail, embora tenha fornecido respostas razoáveis durante o processo de configuração. Não tenho certeza se isso é o que está impedindo a instalação. O DNS está tudo certo e o servidor tem um endereço IP estático.
Após o processo de inicialização (bootstrapping), quando acessei o FQDN do servidor, apareceu a página “Welcome to nginx!” em vez da página “Congratulations, you installed Discourse!”.
Esta instalação é para um ambiente de laboratório e não estará acessível publicamente.
A única maneira de ver essa página é se você tiver apontado o DNS para o servidor errado ou se o NGINX estiver fora do contêiner, ocupando a porta 80 e impedindo que o contêiner responda.
Se eu apontar meu navegador diretamente para o endereço IP do servidor, também recebo a página de boas-vindas do Nginx.
Ao fazer SSH no servidor Ubuntu: marc@community:~$ locate nginx /var/discourse/image/base/install-nginx marc@community:~$
Além disso, estando no servidor Ubuntu: sudo find / -iname "*nginx*"
…muitos arquivos em /var/lib/docker/overlay2… /var/discourse/image/base/install-nginx /var/discourse/shared/standalone/letsencrypt/deploy/nginx.sh /var/discourse/shared/standalone/log/var-log/nginx
Se o Docker estivesse escutando na :80, o que qualquer instalação bem-sucedida realizaria (e seria necessário para que o nginx dentro do container visse algo), você veria:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
docker-pr 890 root 4u IPv6 961922 0t0 TCP *:http (LISTEN)
Se o nginx não estiver instalado fora do container e o Docker não estiver escutando nessa porta, então a única outra forma de ver a página de boas-vindas do nginx é uma má configuração de rede.
Parece que você está certo. Saída da execução do nmap no meu laptop para o endereço IP do servidor:
Iniciando Nmap 7.01 ( https://nmap.org ) em 2020-04-10 23:34 AEST
Relatório de varredura Nmap para community.aureus-group-sb.com (192.168.12.35)
Host está ativo (latência de 0,0010s).
Portas não mostradas: 999 portas fechadas
PORTA ESTADO SERVIÇO
22/tcp aberto ssh
Endereço MAC: 0C:8B:FD:CD:AF:EB (Intel Corporate)
Nmap concluído: 1 endereço IP (1 host ativo) escaneado em 1,74 segundos
Lembre-se: um problema de rede pode ser, mas não se limita a:
Política na VM bloqueando o acesso (ufw ou similar)
Política no servidor virtual bloqueando o acesso (modo de rede não configurado corretamente)
Política na rede não configurada corretamente (ACLs entre sub-redes)
DNS configurado incorretamente
Só se trata de um problema do Discourse se nenhuma das opções acima for verdadeira. Você está seguindo a instalação padrão, mas, por sua própria admissão, está instalando em um ambiente que de forma alguma é padrão.
Se sua organização puder gastar US$ 5/mês, pode ser mais barato, em termos de tempo, colocar isso na nuvem e limitar o firewall do VPS na nuvem para servir páginas apenas de volta ao seu ambiente.
No momento, estou focado principalmente no aspecto de aprendizado para configurar isso. Assim que dominar a configuração, certamente vamos avaliar as opções de hospedagem.
Analisando os aspectos de rede que você listou:
O ufw está inativo e o iptables está em execução: não fiz alterações na instalação padrão do Ubuntu Server.
** Ao examinar a configuração do iptables, a cadeia de entrada (input) tem uma política de aceitar tudo, o mesmo ocorrendo com a cadeia de saída (output). A cadeia de encaminhamento (forward) possui algumas referências relacionadas ao Docker (veja abaixo).
A única vNIC da VM está configurada no modo Bridge, conectando-se diretamente à rede física.
O laptop que estou usando e a VM estão na mesma sub-rede.
Não tenho certeza sobre os requisitos exatos para o DNS. Tentei encontrar essas especificações, mas não consegui localizar um documento definitivo. No que diz respeito ao DNS, consigo fazer ping no servidor pelo nome, FQDN e endereço IP. Não sei se algo mais precisa ser configurado em relação ao DNS.
Qual política de rede existe entre a VM e o mundo externo?
Se o git pull foi bem-sucedido e você conseguiu executar o discourse-setup, haveria algo que impediria a conexão com o GitHub para baixar o conteúdo do contêiner?
Se o servidor não for acessível via endereço público, o Let’s Encrypt falhará. Então, você alterou o arquivo YML para desativar o HTTPS?
A VM pode se conectar à internet e não há restrições para acessar o GitHub. Ao executar o discourse-setup, deixei em branco a opção E-mail da conta do Let’s Encrypt? (ENTER para pular) [me@example.com]:.
Deixar esse campo em branco significa que você não será alertado sobre problemas de certificado; isso não impede que o container tente ativar o Let’s Encrypt.
Ok, então destacamos alguns problemas maiores, mas eles não se relacionam com a pergunta original (OP). Você tem o nginx em algum lugar da sua rede exibindo uma página, mas, pelos seus testes na máquina virtual, você não tem o nginx instalado nem o Docker ouvindo.
Assim que você descobrir como isso está acontecendo, o segundo passo será configurar corretamente o arquivo YML. Por enquanto, você precisa encontrar a origem dessa página.
Aqui está o que aprendi. Se eu desligar o servidor, não consigo fazer ping nele (endereço IP, nome e FQDN). Quando tento acessar o endereço IP, recebo a página padrão “Não foi possível estabelecer conexão” do Firefox.
Portanto, concluo que não há conflito de endereço IP.
Após ligar a VM, também não consigo mais me conectar pelo navegador, recebendo novamente a página padrão “Não foi possível estabelecer conexão”. O comportamento agora está alinhado com o que esperávamos com base na saída do lsof -i:80.