Ist das richtig? Wie lange dauert die Installation der Dev-Version?

Ich versuche, die Discourse-Entwicklungsversion auf einem Ubuntu 20.04 Droplet bei DigitalOcean nur für den Zweck zu installieren, ein FluxBB-Forum zu Discourse zu migrieren, zu exportieren und dann in eine Produktionsversion von Discourse zu importieren.

Bei der Installation der Docker-Produktionsversion als Test (ohne Migration von FluxBB) hatte ich keine Probleme.

Wenn ich jedoch versuche, die Entwicklungsversion von Discourse gemäß dieser Anleitung zu installieren:

stelle ich fest, dass der Befehl:

bundle exec rake autospec

niemals abgeschlossen wird.

Nach etwa 30 Minuten Warten auf den Abschluss erhalte ich eine Zeitüberschreitung meiner Remote-Sitzung.

Außerdem erhalte ich eine Flut von Fehlern. Leider habe ich diese nicht zur Hand, aber sie sind alle der Art, dass eine bestimmte Funktion stets „nil

Das bedeutet, dass der Server läuft. Und natürlich wird er weiterlaufen, bis du Strg+C drückst oder das Terminal schließt.

Informationen werden unendlich im Terminal ausgegeben, es sei denn, du stoppst den Server.

Innerhalb weniger Sekunden nach dem Start ist die Webseite in deinem Browser verfügbar.

Verbindest du dich im Browser mit dem richtigen Port? Normalerweise ist das 3000.

Es gibt mehrere How-To-Themen zum Ausführen von Imports auf Produktionsservern. Du kannst eines davon als Anleitung für die Ausführung des gewünschten Skripts verwenden.

Es klingt so, als hättest du die Entwicklungsumgebung installiert und solltest das Skript dort ausführen.

Ich sehe im Browser nichts. Wenn ich im Terminal ‘top’ ausführe, läuft ein Ruby-Prozess.

Wenn die Terminal-Ausgabe nach dem Ausführen von

bundle exec rails server --binding=0.0.0.0

endlos weiterläuft, sollte das dann nicht ausdrücklich in der Dokumentation erwähnt werden? Normalerweise erwarte ich bei einer Schritt-für-Schritt-Anleitung, dass ein Befehl etwas ausführt, abschließt und eine Meldung anzeigt, die bestätigt, dass die Installation erfolgreich war und ich bereit bin.

Es gibt mehrere Anleitungen zum Thema Importe auf Produktions-Servern.

Wo könnten diese zu finden sein? Die einzige, die ich für FluxBB finde, empfiehlt ausdrücklich, dies auf einer Entwicklungsumgebung durchzuführen:

Ich nehme an, es gilt als Selbstverständlichkeit, dass ein Webserver, sobald er gestartet wurde, nicht gestoppt werden soll, es sei denn, der Administrator möchte dies. Webserver sind in der Regel dafür gedacht, Tag für Tag Seiten auszuliefern … aber natürlich könnte man diese Klarstellung hinzufügen. Jeder kann vorgeschlagene Verbesserungen für den Leitfaden über einen PR einreichen.

Aber ist es Allgemeinwissen, dass dieser Befehl einen Webserver startet? Er lautet einfach ‘rails server’, was nicht zwangsläufig einen Webserver bedeutet. Wenn Sie einen Apache-Webserver starten, werden Sie sofort wieder zur Kommandozeile zurückkehren; er wirft nicht endlos Meldungen im Terminal aus…

Rails ist ein Webanwendungsframework. Ich finde es nicht fair, es direkt mit Apache zu vergleichen.

Ich mag es persönlich, dass man sehen kann, wie es fleißig arbeitet. Wenn es aufhört, stimmt meist etwas nicht! Die Ausgabe kann unter bestimmten Umständen nützlich sein, besonders in der Entwicklung. Die Menge der angezeigten Informationen lässt sich über die Umgebungskonfiguration anpassen.

Übrigens: Laut der Dokumentation kann Rails mit dem Schalter -d als Daemon ausgeführt werden. Wenn du möchtest, kannst du herausfinden, warum dies in der Standardinstallation nicht zu funktionieren scheint – möglicherweise gibt es eine Einschränkung, die dadurch eingeführt wird. Das Team ist der beste Ansprechpartner dafür.

Hey @epsteindidnt,

Wenn du dich in die Rails-Entwicklung einarbeitest, wirst du – wenn du so bist wie ich – feststellen, dass das, was du als „endloses Auswerfen von Dingen im Terminal“ beschreibst, zu einem deiner besten Freunde wird.

Zum Beispiel entwickle ich derzeit eine Rails-Anwendung für einen Kunden, bei der wir die gesamte veraltete Geschäftslogik (von vor vielen Jahrzehnten) in Rails umwandeln. Ich habe mir tatsächlich einen neuen Monitor gekauft, nur damit ich das „endlose Auswerfen von Dingen im Terminal“ (deine Worte) sehen kann, denn diese Informationen sind für einen Entwickler wie glänzendes Gold.

Neben dem erstaunlichen Rails-Server-Log, das detaillierte Einblicke in das Geschehen bietet, gibt es noch einen weiteren „besten Freund des Entwicklers“: die Rails-Konsole!

Wenn ich Code für Rails schreibe, verfasse ich zunächst einen Entwurf in VSC und kopiere dann Code-Snippets in die Rails-Konsole, um sicherzustellen, dass alles wie erwartet funktioniert.

Beim Debuggen füge ich Ruby-Druckanweisungen (p, puts) in den Code ein und beobachte, was in dem „endlosen Strom aus goldener Rails-Server-Log-Information“ auf dem Bildschirm passiert. Fast alle meine Fehler werden auf diese Weise behoben! Wie gesagt, ich habe kürzlich einen neuen, eigenständigen, gebogenen Gaming-Monitor gekauft, nur um die Rails-Server-Log-Informationen zu sehen, die dich gerade ärgern :slight_smile:

Wenn ich deine Beiträge lese, scheint es mir, als wärst du ein bisschen wie ich zu Beginn dieses Jahres, als ich ohne vorherige Rails-Erfahrung zu einer Rails-Anwendung migrierte. Auch ich fühlte mich am Anfang von Rails ein wenig genervt (vielleicht sogar mehr); und jetzt, neun Monate später, entwickle ich ausschließlich täglich in Rails für Kunden (mein Limit ist eine halbe Stelle an Kundenarbeit, da ich semi-pensioniert bin) und habe alle vorherigen PHP-Entwicklungsarbeiten eingestellt. Ehrlich gesagt, ich habe eine neue Leidenschaft für Rails (und Ruby) gefunden, und zwar sehr. Besser spät als nie, wie man so sagt!

Was Apache2 angeht: Apache bietet nicht die detaillierten Einblicke in das, was im Hintergrund einer Anwendung wie Rails passiert. Ich betreibe Apache2 als Reverse-Proxy vor all meinen Rails-Anwendungen, und ganz ehrlich: Ich kann mich nicht mehr daran erinnern, wann ich das letzte Mal eine Apache-Logdatei angesehen habe; denn ich führe das gesamte Debugging mithilfe des Rails-Server-Logs durch, das dich gerade ärgert :slight_smile:

Abschließend hoffe ich aufrichtig, dass eine andere Perspektive von jemandem, der zuvor ein Forum nach Rails migriert hat, dir auf irgendeine kleine Weise hilft. Für mich war es eines der besten „technischen Dinge“, die mir persönlich im Jahr 2020 passiert sind, mich von LAMP-Webanwendungen zu Rails-Webanwendungen bewegen zu müssen.

Frohe Feiertage!

Ich war in letzter Zeit auch ein wenig beunruhigt deswegen. Hier ist, was ich heute festgestellt habe:

Die Ausgabe in einem rails s-Terminal zeigt beim Start eine Menge Abfragen an, aber dann enthält sie auch Ausgaben von Discourse’s Sidekiq-Jobs (zumindest in der Docker-Dev-Einrichtung). Wenn Sie also einen wirklich großen Import durchführen, erhalten Sie eine wirklich große Sidekiq-Warteschlange von Nachbearbeitungsjobs, die danach ewig laufen können. Ich glaube, das sind nicht-essentielle Jobs, z. B. das Laden von Caches, die Sie nicht daran zu hindern scheinen, die Website zu durchsuchen, bevor sie abgeschlossen sind.

Das hat mich total verwirrt, weil ich einen großen Import durchgeführt, ihn dann rückgängig gemacht und die Datenbank neu initialisiert habe, um einen winzigen Testimport durchzuführen, und er immer noch endlos Abfragen im Zusammenhang mit der nicht mehr existierenden großen Datenbank durchführte! Die Lösung war, die Sidekiq-Warteschlangen über eine Rails-Konsole zu leeren.

Zu spät, um Ihnen zu helfen, aber ich dachte, ich teile das mit.