Ich erstelle gerade eine neue Discourse-Instanz von Grund auf für Entwicklungszwecke und sehe diesen Bootstrap-Fehler erneut:
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1002 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec failed with the params {"cd"=>"$home", "tag"=>"migrate", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
Die Container-Einrichtung erfolgt mit zwei Containern für Web-Only und Data-Only (Redis) und mit einer externen PostgreSQL-Datenbank. Das Auskommentieren der MaxMind-Einstellungen ändert nichts.
Die beste Vermutung ist, dass Sie nicht genügend Speicher haben – in diesem Fall fügen Sie Swap hinzu oder wechseln Sie zu einer Instanz mit mehr RAM. Versuchen Sie free -h.
Hmmm, nope, we have 4 GB RAM and plenty of harddisk space (2 x 32 GB), the overall environment is the same as the other docker machine where builds run without problems.
Wenn dies ein reiner Web-Container ist, warum hat er dann Redis darauf?\n\nKönnen Sie Ihre YML-Containerdefinitionen teilen? Und warum betreiben Sie überhaupt eine Zwei-Container-Installation?
OK, ich habe die Trennung von web_only und redis behoben. Die Fehlermeldung lautet jetzt:
FAILED -------------------- Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' fehlgeschlagen mit Rückgabewert #<Process::Status: pid 981 exit 1> Ort des Fehlers: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn' exec fehlgeschlagen mit den Parametern {\"cd\"=>\"$home\", \"tag\"=>\"migrate\", \"hook\"=>\"db_migrate\", \"cmd\"=>[\"su discourse -c 'bundle exec rake db:migra te'\"]} bootstrap fehlgeschlagen mit Exit-Code 1 ** BOOTSTRAP FEHLGESCHLAGEN ** Bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen, es kann mehr als eine geben. ./discourse-doctor kann bei der Diagnose des Problems helfen. 801049b69a89d38b1ae5c299d356fc5f8dc6a8f518b1260c2dde05e0b6081556
Aber vielleicht ist das ein Missverständnis / mangelndes Wissen meinerseits:
Die Datenbank sollte extern in einem anderen LXC-Container liegen, der eine PostgreSQL-Datenbank hat. Der Datenbankbenutzer und die Datenbank existieren, aber die Datenbank ist vor dem ersten Bootstrap von web_only leer. Erstellt das Skript die Datenbank selbst auf dem Remote-System beim ersten Build? Oder muss ich zuerst den Datenbankcontainer erstellen und dann sein Standardschema und die Daten manuell auf den externen PostgreSQL-Daemon exportieren?
Vielen Dank für das Diagramm. Das ist eine ziemlich ausgeklügelte Einrichtung – das würde man tun, wenn man einen guten Grund hätte und das Gebiet kennen würde.
Wenn Sie immer noch Folgendes sehen, glaube ich, dass dies der Hinweis darauf ist, was falsch ist. Redis kann den Port, auf dem es lauschen soll, nicht öffnen.
Die Fragen drehen sich also darum, ob Redis das tun sollte, in diesem Container, und wenn ja, wo sonst auf der Maschine noch ein Redis läuft. lsof könnte hier ein nützliches Werkzeug sein.
Hallo @Ed_S
danke für den Hinweis auf den fehlenden Port. Ich möchte erst die Antwort von Falco bezüglich meiner Fragen zum allgemeinen Setup von Discourse mit einer externen PostgreSQL-Datenbank abwarten.
Ja, das Setup ist im Vergleich zum Standard mit nur einem App-Container etwas anspruchsvoll. Ich betreibe alles auf einem dedizierten Root-Server mit Proxmox (https://proxmox.com) als Virtualisierungsumgebung bei hetzner.de.
Sie müssen immer noch die vollständigen Protokolle teilen, einschließlich des Teils, in dem die Migration fehlgeschlagen ist. Meine Vermutung (und es ist eine Vermutung, da Sie den Fehler nicht geteilt haben) ist, dass Sie das KI-Plugin verwenden und Ihre Datenbank nicht das erforderliche Add-on hat.
# Verwenden Sie den Schlüssel 'links', um Container miteinander zu verknüpfen, d. h. verwenden Sie das Docker --link Flag. links: - link: name: data alias: data
In meinem Fall ist der Datencontainer ein Redis-Container
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a27999b28a90 local_discourse/redis „/sbin/boot“ 2 Tage her Vor 20 Stunden hoch
Ich denke jetzt, dass der bessere Ansatz darin besteht, zuerst ein Standard-„All-in-One“-Setup zu erstellen (app.yml). Und dann den initialen Schema- und Daten-Dump aus dem Container in eine externe PostgreSQL-Maschine zu exportieren. @Falco, was meinst du?
