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 base funziona 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-setuplo 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. -
Ho configurato manualmente lo spazio swap seguendo questo thread su meta.discourse.
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-setupvenisse 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 80ecurl localhost:80(questo ha confermato che Docker funzionava) -
Ho anche pensato che le regole delle porte in entrata di Azure fossero sospette, perché
nc -zvcontinuava a restituireConnection 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,ncsi sarebbe semplicemente bloccato.)