Neue Installation schlägt auf Ubuntu 20.04.3 LTS fehl

Eine neue Installation auf einer neuen EC2-Instanz mit Standardkonfiguration schlägt fehl. Ich habe eine EC2-Instanz mit Ubuntu 20.04.3 auf AWS gestartet und alle aktuellen Ubuntu-Updates durchgeführt. Anschließend habe ich die einfache Standardinstallation durchgeführt, die hier zu finden ist.

sudo -s
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse

./discourse-setup

Der einzige Unterschied war, dass die Einrichtung fehlgeschlagen ist, weil keine Verbindung zum Server über HTTP(S) hergestellt werden konnte – ich hatte vergessen, die beiden eingehenden Ports auf AWS zu öffnen. Daher habe ich meine app.yml-Datei manuell konfiguriert und nach dem Öffnen der Ports in der AWS-Sicherheitsgruppe ./launcher rebuild app ausgeführt.

Der Browser kann keine Verbindung herstellen, und mein Produktionsprotokoll zeigt Folgendes an:

/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus.rb:729:in `block in new_subscriber_thread'
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:384:in `rescue in establish_connection'

Ich habe eine neue EC2-Instanz gestartet, da ich zuvor einen wiederverwendeten Server mit Ubuntu 20.04.3 verwendet hatte, auf dem beim Installieren von Discourse exakt dasselbe Problem auftrat. Dieselben Fehlermeldungen im Produktionsprotokoll. Daher dachte ich, ich fange einfach von vorne an und mache es so einfach wie möglich.

Hast du schon einen Neustart versucht?

Ja, ich habe die Instanz gestartet und gestoppt und sie über die Kommandozeile neu gestartet. Das hat nicht geholfen.

OK, jetzt bin ich ziemlich überzeugt, dass es ein Problem mit dem Discourse-Installer gibt, wenn Ubuntu 20.04.3 mit den neuesten Updates verwendet wird. Ich habe den Installer gerade erneut durchlaufen und diesmal sicherstellen, dass die Ports geöffnet waren, sodass ich die app.yml-Datei nie manuell konfigurieren musste (damit menschliche Fehler ausgeschlossen sind). Alles schien reibungslos zu verlaufen; der Installer hat die Domain gefunden und so weiter. Allerdings… keine Website. Das Produktionsprotokoll zeigt:

/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus.rb:729:in `block in new_subscriber_thread'
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:384:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:365:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:117:in `block in connect'

Das ist zu einfach, als dass ich dieses Mal etwas falsch gemacht haben könnte, und ich habe lediglich die Skripte ausgeführt.

Hast du eine andere Redis-Installation?
Wie viel RAM hast du? Hat es Swap erstellt?

Ich habe nichts installiert. Es ist eine neue EC2-Instanz vom Typ t2.small mit 2 GB RAM. Ich muss den standardmäßig erstellten Swap-Bereich überprüfen.

Hier sind die Informationen zu RAM und Swap. Es handelt sich um eine unveränderte, frisch gestartete AWS-Instanz mit allen Standard-Updates für Ubuntu. Es ist eine EC2-t2.small-Instanz. Es wurden keine Änderungen vorgenommen, nichts hinzugefügt, konfiguriert oder modifiziert. Die einzigen Befehle, die vor der Installation zum Aktualisieren verwendet wurden, waren die grundlegenden sudo apt update und sudo apt upgrade. Beim dritten Versuch habe ich die Standard-Installation von Discourse auf zwei separaten Instanzen mit demselben Betriebssystem (Ubuntu 20.04.3) durchgeführt. Deshalb bin ich der Ansicht, dass möglicherweise etwas mit dem Installer und der aktuellen Version nicht stimmt.

$ free -h
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       973Mi       131Mi        36Mi       875Mi       855Mi
Swap:         2.0Gi       0.0Ki       2.0Gi

Falls der Speicherplatz von Belang ist:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        39G  7.8G   31G  20% /

Ich habe gerade eine Installation auf einer neuen Digital Ocean Droplet durchgeführt, und sie hat einwandfrei funktioniert. Das Problem liegt also nicht am Installer.

Meine beste Vermutung, auch wenn es nicht ganz schlüssig ist, dass du den Redis-Fehler hast, ist, dass du den Installer oft genug ausgeführt hast, um das Let’s Encrypt-Ratenlimit zu erreichen, und das das eigentliche Problem ist.

Versuche es erneut mit einem anderen Domainnamen (z. B. forum2.example.com).

Bingo! Du hast wieder einmal recht, es hat funktioniert.

OK, ich habe also viel neu aufgebaut, da ich getestet habe, wie man ein Forum von einem alten Server überträgt.

Wie zum Teufel bekomme ich dieses Problem gelöst? Ich verwende Let’s Encrypt gar nicht. Nach der erfolgreichen Installation habe ich die app.yml-Datei aktualisiert, um die Domain zu ändern, und sichergestellt, dass die Let’s Encrypt-Vorlage in der app.yml auskommentiert ist, und dann neu aufgebaut. Das hilft jedoch nicht, und ich bekomme denselben Fehler: Redis-Fehler. Bin ich festgefahren, weil der Aufruf von Let’s Encrypt fest in den Installer eingebaut ist?

Wenn du keinen Reverse Proxy verwendest, um HTTPS bereitzustellen, ist das nicht möglich. Du musst HTTPS haben. Und wenn du Lets Encrypt entfernst, musst du auch das HTTPS-Template (wie auch immer es heißt) entfernen.

Ich verstehe nicht ganz, warum du den Redis-Fehler erhältst; vielleicht hast du Redis auskommentiert, als du Lets Encrypt auskommentiert hast? Das ist meine beste Vermutung.

Du kannst versuchen, unter Set up Let’s Encrypt with multiple domains / redirects nachzulesen, wie man einen zweiten Domainnamen hinzufügt, oder eine Woche warten.

Nun, wenn du den Thread durchliest, wurde eine einfache Installation auf einer brandneuen Instanz durchgeführt, sodass ich nichts auskommentieren konnte, da der Installer basierend auf den gestellten Fragen die app.yml erstellt. Der Redis-Fehler steht also direkt im Zusammenhang mit dem Let’s Encrypt-Ratenlimit. Falls das dem Entwicklungsteam auf irgendeine Weise helfen kann.

Ich verwende einen Proxy, genauer gesagt Cloudflare, um das SSL-Zertifikat bereitzustellen und ausschließlich HTTPS zu verbinden und zu liefern.

Ich habe getestet, indem ich die HTTPS-Vorlage „templates/web.ssl.template.yml" auskommentiert und natürlich launcher rebuild app ausgeführt habe, während auch die Let’s Encrypt-Vorlage auskommentiert war. Das gleiche Ergebnis trat ein: Redis-Fehler. Also bin ich wohl festgefahren, oder? Was für eine schreckliche Entscheidung beim Installer, keine Möglichkeit vorzusehen, die Let’s Encrypt-Aufrufe zu umgehen. Falls du mir nichts anderes zum Ausprobieren bieten kannst, werde ich Geduld als Tugend betrachten. Ich schätze deine Hilfe wirklich sehr. Ich bleibe bescheiden frustriert.

Das macht die Sache deutlich komplizierter, und du wirst später weitere Probleme bekommen, es sei denn, du recherchierst sorgfältig, wie man Cloudflare nutzt, ohne Discourse zu beschädigen.