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…
Ich muss dieses Thema leider wieder nach oben holen, aber es ist immer noch relevant. Alles installiert sich Discourse-seitig einwandfrei, alles scheint in Ordnung zu sein, aber die Ports 80 und 443 sind von außen nicht erreichbar.
Update: Die Basisinstallationfunktioniert auf Azure mit Ubuntu Server problemlos out of the Box.
Das habe ich beim zweiten Mal anders gemacht:
Nach der Erstellung der VM und dem Aufruf von discourse-setup habe ich den Prozess nicht unterbrochen, sodass alles in einem Durchgang ausgeführt wurde.
Beim ersten Mal stellte ich fest, dass ich keinen Swap hatte. Obwohl das discourse-setup-Skript diesen bei Bedarf automatisch einrichtet, bin ich zur Shell gewechselt, um einige Dinge zu überprüfen. Dann waren einige Installationsaufforderungen anders als in dem Basisleitfaden, weshalb ich erneut abgebrochen habe.
+ Was mich verwirrte, war die Let’s Encrypt-Abfrage, bei der nach einer E-Mail-Adresse für Benachrichtigungen gefragt wurde. Ich war der Meinung, HTTPS manuell einrichten zu müssen. Tatsächlich richtet das Skript die Discourse-Instanz jedoch mit einem Let’s Encrypt-SSL-Zertifikat ein. + Eine weitere Sache betraf die Abschnitte für SMTP-Benutzername und Passwort; ich bin mir immer noch nicht sicher, ob ich diese einfach leer lassen hätte können, aber ich habe stattdessen die Admin-E-Mail-Adresse und das Passwort für dieses Konto angegeben.
Ich glaube nicht, dass dies etwas damit zu tun hatte, aber ich erwähne es nur zur Sicherheit. Beim zweiten Mal habe ich alles genauso gemacht wie beim ersten Mal, außer dass ich (1) den Swap manuell eingerichtet und (2) discourse-setup ohne Unterbrechungen laufen ließ.
Es ist möglich, dass die erste Instanz noch gerettet werden könnte, aber die Architektur von Discourse ist mir immer noch ein Rätsel, und ich bin mir nicht sicher, wie ich die HTTP/HTTPS-Endpunkte neu starten soll. Beim Vergleich der Ausgaben von netstat -tulpn ist klar, dass in der ersten Instanz alle relevanten Dienste scheinbar laufen und auf den richtigen Ports lauschen (z. B. PostgreSQL auf 5432, Redis auf 6379 usw.), und die einzigen beiden fehlenden Einträge sind die Ports 80 und 443 (was darauf hindeutet, dass nginx nicht lief):
Instanz (fehlgeschlagen):
$ 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 -
Instanz:
(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 -
Ein paar Notizen für mich selbst für die Zukunft:
Beim ersten Mal fiel mir das Fehlen der Listener-Ports 80 und 443 auf, aber ich sah den Socket 127.0.0.1:3000 (an den ich mich als den Standard-Rails-Port erinnerte). Es ist mir noch nicht aufgefallen, dass vielleicht nginx nicht lief, und aus irgendeinem Grund verdächtigte ich weiterhin die Docker-Port-Mappings, weshalb ich eine einfache Weiterleitung mit netcat durchführte:
Innerhalb von Docker: nc -l -p 80 -c "nc 127.0.0.1 3000"
Außerhalb von Docker in der VM: nc -zv localhost 80 und curl localhost:80 (damit war geklärt, dass Docker in Ordnung war)
Ich hielt auch die Azure-Eingangsportregeln für verdächtig, weil nc -zv weiterhin Connection refused zurückgab. Mir wurde dann jedoch klar, dass dies nur bedeutet, dass die Ports geöffnet sind, aber niemand auf der anderen Seite lauscht. (Wenn die Ports blockiert wären, würde nc einfach hängen bleiben.)
discourse-setup sollte fehlschlagen, wenn die Ports 80 und 443 nicht für eingehenden Verkehr geöffnet sind.
Ah, das stimmt. Einige Fragen zur E-Mail-Konfiguration wurden vor einiger Zeit geändert, aber der Leitfaden wurde nicht aktualisiert. Ich denke, die meisten Leute lesen die Aufforderungen und nicht das Installationsdokument, daher hat sich niemand anderes beschwert.
Warum hast du das gedacht? Der Installationsprozess richtet seit Jahren automatisch Let’s Encrypt ein.
Ich kann nicht feststellen, ob du sagst, dass deine Seite funktioniert oder nicht.
Wenn sie nicht funktioniert, liegt es wahrscheinlich daran, dass du discourse-setup mehrmals ausgeführt hast und dein Limit bei letsencrypt.org erschöpft hast.