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…
Odio riprendere questo argomento, ma è ancora rilevante. Tutto si installa splendidamente per quanto riguarda Discourse, sembra tutto a posto, ma le porte 80 e 443 non sono raggiungibili dall’esterno.
Aggiornamento: L’installazione di basefunziona davvero subito su Azure con Ubuntu Server.
Queste sono le cose che ho fatto diversamente la seconda volta:
Dopo la creazione della VM e l’esecuzione di discourse-setup, non ho interrotto il processo, quindi tutto è stato eseguito in un’unica soluzione.
La prima volta ho capito di non avere swap, e anche se lo script discourse-setup lo configura se manca, sono uscito dalla shell per controllare delle cose. Poi alcuni prompt di installazione erano diversi rispetto a la guida di base, quindi sono uscito un’altra volta.
+ Ciò che mi ha sconcertato è stato il passaggio relativo a Let’s Encrypt, che chiedeva un indirizzo email per ricevere notifiche al riguardo, e avevo l’impressione di dover configurare manualmente HTTPS. In realtà, lo script configura l’istanza di Discourse con un certificato SSL di Let’s Encrypt. + Un’altra cosa riguardava le sezioni per nome utente e password SMTP; non sono ancora sicuro se avrei potuto lasciarle vuote, ma ho semplicemente aggiunto l’indirizzo email dell’amministratore e la password per quell’account.
Non credo che questo abbia avuto a che fare con il problema, ma lo menziono per precauzione. La seconda volta ho fatto tutto come la prima, tranne che per (1) la configurazione manuale dello swap e (2) aver lasciato che discourse-setup venisse eseguito senza interruzioni.
È possibile che la prima istanza potesse essere salvata, ma l’architettura di Discourse è ancora un mistero per me e non sono sicuro di come riavviare gli endpoint HTTP/HTTPS. Confrontando gli output di netstat -tulpn, è chiaro che nella prima istanza tutti i servizi rilevanti sembrano essere in esecuzione e in ascolto sulle porte corrette (ad esempio, PostgreSQL sulla 5432, Redis sulla 6379, ecc.) e le uniche due voci mancanti sono le porte 80 e 443 (il che suggerisce che nginx non era in esecuzione):
Prima istanza (fallita):
$ 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 -
Seconda istanza:
(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 -
Alcune note per il mio futuro io:
La prima volta, ho notato la mancanza delle porte in ascolto 80 e 443, ma ho visto il socket 127.0.0.1:3000 (che ricordavo essere quello predefinito di Rails). Non mi era ancora venuto in mente che forse nginx non era in esecuzione e, per qualche motivo, sospettavo ancora che la colpa fosse delle mappature delle porte di Docker, quindi ho fatto un reindirizzamento di base con netcat:
Dentro Docker: nc -l -p 80 -c "nc 127.0.0.1 3000"
Fuori Docker nella VM: nc -zv localhost 80 e curl localhost:80 (questo ha confermato che Docker funzionava)
Ho anche pensato che le regole delle porte in entrata di Azure fossero sospette, perché nc -zv continuava a restituire Connection refused, ma poi ho capito che questo significa solo che le porte sono aperte ma nessuno sta ascoltando dall’altra parte. (Se le porte fossero state bloccate, nc si sarebbe semplicemente bloccato.)
discourse-setup dovrebbe fallire se le porte 80 e 443 non sono aperte al traffico in ingresso.
Ah, è vero. Alcune domande relative alla configurazione della posta sono state modificate tempo fa, ma non aggiornate nella guida. Penso che la maggior parte delle persone legga le domande a schermo e non il documento di installazione, quindi nessuno si è lamentato.
Perché pensavi questo? Il processo di installazione configura automaticamente Let’s Encrypt da anni.
Non riesco a capire se stai dicendo che il tuo sito funziona o meno.
Se non funziona, è molto probabile che tu abbia eseguito discourse-setup diverse volte e abbia esaurito il limite di richieste su letsencrypt.org.