Discourse installation on Azure not reachable

Soporte Instalación
9

Odio tener que reactivar este tema, pero sigue siendo relevante. Todo se instala perfectamente en lo que respecta a Discourse; todo parece estar bien, pero los puertos 80 y 443 no son accesibles públicamente.

Actualización: La instalación básica sí funciona sin problemas en Azure con Ubuntu Server.

Estas son las cosas que hice de manera diferente la segunda vez:

  1. Después de crear la máquina virtual y ejecutar discourse-setup, no interrumpí el proceso, por lo que todo se ejecutó de una sola vez.

    La primera vez me di cuenta de que no tenía espacio de intercambio (swap) y, aunque el script discourse-setup lo configura si falta, salí a la terminal para verificar cosas. Luego, algunas de las preguntas del instalador fueron diferentes a las de la guía básica, así que salí una vez más.

    + Lo que más me desconcertó fue la pregunta de Let’s Encrypt, que pedía una dirección de correo electrónico para recibir notificaciones al respecto, y tenía la impresión de que tendría que configurar HTTPS manualmente. En realidad, el script configura la instancia de Discourse con un certificado SSL de Let’s Encrypt.<c/br>+ Otra cosa fueron las secciones de nombre de usuario y contraseña de SMTP; todavía no estoy seguro de si podría haber dejado estos campos en blanco, pero simplemente añadí la dirección de correo electrónico del administrador y la contraseña de esa cuenta.

  2. Configuré el espacio de intercambio (swap) manualmente según este hilo de meta.discourse.

    No creo que esto tuviera nada que ver con el problema, pero lo menciono por si acaso. La segunda vez, hice todo igual que la primera, excepto (1) configurar el swap manualmente y (2) dejar que discourse-setup se ejecutara sin interrupciones.

Es posible que la primera instancia se hubiera podido salvar, pero la arquitectura de Discourse sigue siendo un misterio para mí y no estoy seguro de cómo reiniciar los puntos de conexión HTTP/HTTPS. Al comparar las salidas de netstat -tulpn, es evidente que en la primera instancia, todos los servicios relevantes parecen estar ejecutándose y escuchando en los puertos correctos (por ejemplo, PostgreSQL en 5432, Redis en 6379, etc.) y las únicas dos entradas que faltan son los puertos 80 y 443 (lo que sugiere que nginx no se estaba ejecutando):

Primera instancia (fallida):

$ 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  -

Segunda instancia:

(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  -

Un par de notas para mi futuro yo:

  1. La primera vez, noté la falta de los puertos de escucha 80 y 443, pero vi el socket 127.0.0.1:3000 (que recordaba ser el predeterminado de Rails). No me había dado cuenta aún de que quizás nginx no se estaba ejecutando y, por alguna razón, seguía sospechando que los mapeos de puertos de Docker eran los culpables, así que hice un redireccionamiento básico con netcat:

    Dentro de Docker: nc -l -p 80 -c "nc 127.0.0.1 3000"
    Fuera de Docker en la VM: nc -zv localhost 80 y curl localhost:80 (esto confirmó que Docker estaba bien)

  2. También pensé que las reglas de puertos de entrada de Azure eran sospechosas, porque nc -zv seguía devolviendo Connection refused, pero luego me di cuenta de que esto solo significa que los puertos están abiertos pero nadie está escuchando en el otro lado. (Si los puertos estuvieran bloqueando, nc simplemente se quedaría colgado.)