Discourse installation on Azure not reachable

Soutien Installation
9

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 base fonctionne effectivement sans problème sur Azure avec Ubuntu Server.

Voici ce que j’ai fait différemment cette deuxième fois :

  1. 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.

  2. Configuration manuelle de l’espace d’échange (swap) selon ce fil de discussion sur meta.discourse.

    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 :

  1. 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)

  2. 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.)