The entire installation went perfectly, but the instance is not reachable publicly. I have the A record configured to the public IP given by Azure. I also tried using the IP address directly.
I suspect this has something to do with the Docker IP and the Eth0 IP address, but not sure how to solve it.
So essentially I have 3 IPs: the public IP, the eth0 IP on the VPN, and then the docker instance IP. I’m guessing I need to somehow route the public IP:80 port to the docker IP?
Crazy cloud shenanigans likely get in the way – there’s probably some equivalent of AWS’ security groups, or perhaps the networking stack needs an extra kick in the pants.
So I sort of found the problem, but not the cure. As expected it has to do with the port forwarding/mapping/routing issue.
Azure VMs are part of a resource group with a common virtual public IP and a VPN/subnet for individual machines. Then there is a Network Security Group, with which one has to define some NAT rules.
I did setup forwarding for the Docker ports, but to no avail. Now trying to diagnose using Docker documentation. Jeff is right, once Docker works correctly, Discourse will work too.
The Azure classic VM should be better because they allow mapping of specific endpoints (ports). Will try installing in one of those.
Will post my updates. For better or for worse, I’m stuck with Azure at the moment.
Ok. So I discarded the instance of Ubuntu and created a new Ubuntu VM of the classic type. Then I chose a fixed Instance IP address. Then I created two endpoints for TCP/80 and TCP/443 to forward from the public to private network. Also I installed Docker from the instructions for Ubuntu and not the script directly.
I’m not sure which of these steps helped, but now Discourse works on Azure!
I finally switched to digital ocean, where it works out of the box. The VM classic type seems not to be available anymore at Azure? Tried to setup an instance without success…
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ásicafunciona 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-setup configure 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.
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-setup rodar 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 80 e curl 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 -zv continuava retornando Connection 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, o nc ficaria apenas pendurado.)
O discourse-setup deve falhar se você não tiver as portas 80 e 443 abertas para tráfego de entrada.
Ah. Isso é verdade. Algumas perguntas sobre configuração de e-mail foram alteradas há algum tempo e não foram atualizadas no guia. Acho que a maioria das pessoas lê as perguntas e não o documento de instalação, então ninguém mais reclamou.
Por que você pensou isso? O processo de instalação configura automaticamente o Let’s Encrypt há anos.
Não consigo dizer se você está dizendo que seu site está funcionando ou não.
Se não estiver funcionando, é bem provável que você tenha executado o discourse-setup várias vezes e esgotou seu limite de taxa no letsencrypt.org.