Detesto ter que ressuscitar este tópico, mas ele ainda é relevante. Tudo foi instalado perfeitamente no que diz respeito ao Discourse, tudo parece estar certo, mas as portas 80 e 443 não são acessíveis publicamente.
Atualização: A instalação básica funciona imediatamente no Azure no Ubuntu Server.
Estes são os passos que fiz de forma diferente na segunda tentativa:
-
Após a criação da VM e ao chamar
discourse-setup, não interrompi o processo, então tudo foi executado de uma só vez.Na primeira vez, percebi que não havia swap e, embora o script
discourse-setupconfigure automaticamente caso esteja ausente, saí para o shell para verificar algumas coisas. Então, algumas das solicitações de instalação foram diferentes das do guia básico, então saí mais uma vez.+ O que me deixou confuso foi a etapa do Let’s Encrypt, que pede um endereço de e-mail para receber notificações relacionadas, e eu tinha a impressão de que teria que configurar o HTTPS manualmente. Na realidade, o script configura a instância do Discourse com um certificado SSL do Let’s Encrypt.
+ Outra coisa foram as seções de nome de usuário e senha do SMTP; ainda não tenho certeza se poderia ter deixado esses campos em branco, mas apenas adicionei o e-mail do administrador e a senha dessa conta. -
Configurei o espaço de swap manualmente de acordo com este tópico do meta.discourse.
Não acho que isso tenha tido algo a ver com o problema, mas menciono apenas por precaução. Na segunda vez, fiz tudo da mesma forma que na primeira, exceto (1) configurar o swap manualmente e (2) deixar o
discourse-setuprodar sem interrupções.
É possível que a primeira instância pudesse ter sido salva, mas a arquitetura do Discourse ainda é um mistério para mim, e não sei como reiniciar os endpoints HTTP/HTTPS. Ao comparar as saídas de netstat -tulpn, fica claro que, na primeira instância, todos os serviços relevantes parecem estar rodando e escutando nas portas corretas (por exemplo, PostgreSQL na 5432, Redis na 6379, etc.), e as únicas duas entradas ausentes são as portas 80 e 443 (sugerindo que o nginx não estava rodando):
1ª instância (falha):
$ 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 -
2ª instância:
(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 -
Algumas anotações para minha futura referência:
-
Na primeira vez, notei a falta das portas de escuta 80 e 443, mas vi o socket
127.0.0.1:3000(que eu lembrava ser o padrão do Rails). Ainda não me ocorreu que talvez o nginx não estivesse rodando, e por algum motivo ainda suspeitava que as mapeamentos de portas do Docker fossem os culpados, então fiz um redirecionamento básico com netcat:Dentro do Docker:
nc -l -p 80 -c "nc 127.0.0.1 3000"
Fora do Docker, na VM:nc -zv localhost 80ecurl localhost:80(isso confirmou que o Docker estava ok) -
Também achei que as regras de portas de entrada do Azure fossem suspeitas, porque
nc -zvcontinuava retornandoConnection refused, mas então percebi que isso só significa que as portas estão abertas, mas ninguém está escutando do outro lado. (Se as portas estivessem bloqueadas, oncficaria apenas pendurado.)