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 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ásicasí funciona sin problemas en Azure con Ubuntu Server.
Estas son las cosas que hice de manera diferente la segunda vez:
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.
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:
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)
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.)
discourse-setup debería fallar si no tienes los puertos 80 y 443 abiertos para el tráfico entrante.
Ah, es cierto. Algunas preguntas sobre la configuración del correo cambiaron hace un tiempo y no se actualizaron en la guía. Creo que la mayoría de la gente lee las preguntas y no el documento de instalación, así que nadie más se ha quejado.
¿Por qué pensabas eso? El proceso de instalación configura automáticamente Let’s Encrypt desde hace años.
No puedo determinar si estás diciendo que tu sitio funciona o no.
Si no funciona, es muy probable que hayas ejecutado discourse-setup varias veces y hayas agotado tu límite de solicitudes en letsencrypt.org.