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…
Je déteste devoir remonter ce sujet, mais il est toujours d’actualité. Tout s’installe parfaitement du point de vue Discourse, tout semble correct, mais les ports 80 et 443 sont inaccessibles publiquement.
Mise à jour : L’installation de basefonctionne effectivement sans problème sur Azure avec Ubuntu Server.
Voici ce que j’ai fait différemment cette deuxième fois :
Après la création de la VM et l’appel à discourse-setup, je n’ai pas interrompu le processus, afin que tout s’exécute en une seule fois.
La première fois, j’ai réalisé qu’il n’y avait pas d’espace d’échange (swap), et bien que le script discourse-setup le configure s’il est manquant, je suis sorti dans le shell pour vérifier certaines choses. Ensuite, certaines invites d’installation étaient différentes de celles du guide de base, donc je suis sorti une nouvelle fois.
+ Ce qui m’a le plus intrigué, c’était la question de Let’s Encrypt demandant une adresse e-mail pour recevoir des notifications à ce sujet, et j’avais l’impression de devoir configurer HTTPS manuellement. En réalité, le script configure l’instance Discourse avec un certificat SSL Let’s Encrypt.+ Une autre chose concernait les sections nom d’utilisateur et mot de passe SMTP ; je ne suis toujours pas sûr d’avoir pu laisser ces champs vides, mais j’ai simplement ajouté l’adresse e-mail de l’administrateur et le mot de passe de ce compte.
Je ne pense pas que cela ait eu un lien avec le problème, mais je le mentionne au cas où. La deuxième fois, j’ai tout fait comme la première, sauf que (1) j’ai configuré le swap manuellement, et (2) j’ai laissé discourse-setup s’exécuter sans interruption.
Il est possible que la première instance aurait pu être sauvée, mais l’architecture de Discourse reste un mystère pour moi, et je ne sais pas comment redémarrer les points de terminaison HTTP/HTTPS. En comparant les sorties de netstat -tulpn, il est clair que dans la première instance, tous les services pertinents semblent s’exécuter et écouter sur les bons ports (par exemple, PostgreSQL sur 5432, Redis sur 6379, etc.), et les seules deux entrées manquantes sont les ports 80 et 443 (ce qui suggère que nginx ne tournait pas) :
1re instance (échouée) :
$ 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 -
Seconde instance :
(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 -
Quelques notes pour moi-même dans le futur :
La première fois, j’ai remarqué l’absence des ports d’écoute 80 et 443, mais j’ai vu le socket 127.0.0.1:3000 (dont je me souvenais être le port Rails par défaut). Je n’avais pas encore réalisé que peut-être nginx ne tournait pas, et pour une raison quelconque, je soupçonnais toujours les mappages de ports Docker d’être en cause, alors j’ai fait une redirection basique avec netcat :
Dans Docker : nc -l -p 80 -c "nc 127.0.0.1 3000"
Hors Docker dans la VM : nc -zv localhost 80 et curl localhost:80 (cela a confirmé que Docker fonctionnait correctement)
J’ai aussi pensé que les règles de ports entrants Azure étaient suspectes, car nc -zv renvoyait constamment Connection refused, mais j’ai ensuite réalisé que cela signifiait simplement que les ports sont ouverts mais que personne n’écoute de l’autre côté. (Si les ports étaient bloqués, nc resterait simplement en attente.)
discourse-setup devrait échouer si les ports 80 et 443 ne sont pas ouverts au trafic entrant.
Ah, c’est vrai. Certaines questions relatives à la configuration des e-mails ont été modifiées il y a quelque temps et n’ont pas été mises à jour dans le guide. Je pense que la plupart des gens lisent les invites plutôt que le document d’installation, donc personne d’autre ne s’est plaint.
Pourquoi avez-vous pensé cela ? Le processus d’installation configure automatiquement Let’s Encrypt depuis des années.
Je ne sais pas si vous dites que votre site fonctionne ou non.
Si cela ne fonctionne pas, il est fort probable que vous ayez exécuté discourse-setup à plusieurs reprises et que vous ayez épuisé votre limite de taux sur letsencrypt.org.