Fehler beim Erstellen der neuesten Version

Unterstützung Installation
1

Hallo. Ich erhalte folgenden Fehler, wenn ich ./installer rebuild web_only auf den neuesten Versionen von Discourse ausführe.

fs.js:114
    throw err;
    ^

Error: ENOENT: no such file or directory, open 'root='/assets',url='/assets/vendor-4681e47c140b5a5bea2bfb1fec89365858288a8ea0c21979c0167ad9b570ee3d.js.map''
    at Object.openSync (fs.js:438:3)
    at Object.writeFileSync (fs.js:1189:35)
    at done (/usr/lib/node_modules/uglify-js/bin/uglifyjs:516:20)
    at cb (/usr/lib/node_modules/uglify-js/bin/uglifyjs:324:39)
    at /usr/lib/node_modules/uglify-js/bin/uglifyjs:391:9
    at FSReqWrap.readFileAfterClose [as oncomplete] (internal/fs/read_file_context.js:53:3)
rake aborted!
Errno::ENOENT: No such file or directory @ rb_file_s_size - /var/www/discourse/public/assets/vendor-4681e47c140b5a5bea2bfb1fec89365858288a8ea0c21979c0167ad9b570ee3d.js
/var/www/discourse/lib/tasks/assets.rake:268:in `size'
/var/www/discourse/lib/tasks/assets.rake:268:in `block (4 levels) in <top (required)>'
/var/www/discourse/lib/tasks/assets.rake:159:in `block in concurrent?'
/var/www/discourse/lib/tasks/assets.rake:259:in `block (3 levels) in <top (required)>'
/var/www/discourse/lib/tasks/assets.rake:250:in `each'
/var/www/discourse/lib/tasks/assets.rake:250:in `block (2 levels) in <top (required)>'
/var/www/discourse/lib/tasks/assets.rake:159:in `concurrent?'
/var/www/discourse/lib/tasks/assets.rake:247:in `block in <top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rake-13.0.1/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tasks: TOP => assets:precompile
(See full trace by running task with --trace)
I, [2019-12-11T22:53:15.806396 #18]  INFO -- : Downloading MaxMindDB...
Compressing Javascript and Generating Source Maps



FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake assets:precompile' failed with return #<Process::Status: pid 17151 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"assets_precompile", "cmd"=>["su discourse -c 'bundle exec rake assets:precompile'"]}
f565d457b97d7ff12a258b03a456563a5a0e928c707c70e194ef88ba170aaf3a
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one

Ich habe alle Plugins deaktiviert, aber das Problem besteht weiterhin. Kann mir jemand helfen, die Ursache zu finden?

2

Das haben wir schon mal woanders gesehen.

Kannst du es bitte mit folgendem Befehl versuchen:

./launcher cleanup
git pull
./launcher rebuild app

Wenn das nicht funktioniert, versuche, alle Container und Images auf dem Rechner zu entfernen.

3

Danke für die schnelle Antwort, @sam. Ich werde es versuchen.

Kurze Frage: Ich gehe davon aus, dass “git pull” die neueste Version von discourse-docker zieht, richtig?

Ist es im Allgemeinen notwendig, discourse-docker und discourse gleichzeitig zu aktualisieren?

Derzeit wird discourse-docker nicht von Git verwaltet. Stattdessen lade ich eine bestimmte Revision von discourse-docker (als ZIP) herunter, wenn ich den Server konfiguriere, und lege die Version von discourse während der Bereitstellung auf einen bestimmten Commit fest.

Der Grund dafür ist, den Build wiederholbar zu machen. Das heißt, das Ausführen desselben Befehls mit derselben Konfiguration und denselben Quellen zu zwei verschiedenen Zeitpunkten sollte dasselbe Artefakt erzeugen. Im Allgemeinen ist das eine gute Idee und hat mich im Laufe der Jahre aus vielen Operations-Albträumen mit anderer Software gerettet ;). Das liegt daran, dass es dir die Möglichkeit gibt, zu einer bekannten, funktionierenden Konfiguration zurückzukehren.

Ich habe jedoch das Gefühl, dass ich hier bei Discourse gegen den Strom schwimme, da es scheint, als würde es während des Builds die neuesten Versionen verschiedener Softwarekomponenten ziehen. Ich fange an zu überlegen, ob meine Versuche, den Build wiederholbar zu machen, mir eigentlich ins eigene Fleisch schneiden?

4

Das sind sehr wahre Worte. Du befindest dich mit diesem Hacken in einem absolut nicht unterstützbaren Zustand :flushed_face:

Ich empfehle dir dringend, so schnell wie möglich die neueste Version aus Git zu ziehen.

Alte Docker-Images der Discourse-Basis sind mit dem aktuellen Discourse inkompatibel und enthalten zudem viele fehlende Sicherheitsupdates.

5

Danke, @sam. Ich habe das erledigt und kann jetzt die neue Version erstellen. Zum Glück war das alles noch im Beta-Stadium, also ist nichts passiert :slight_smile: Ich bin mir jedoch nicht sicher, ob es „Häckelei

6

Wenn du wiederholbare Builds möchtest, musst du deine Discourse-Version über deine Container-Konfiguration an eine spezifische SHA binden – und das gilt auch für jedes Plugin.

Das bedeutet, dass du keine Updates mehr für Discourse, keine Sicherheitsupdates für das Docker-Image und dergleichen mehr erhältst, dafür ist der Build jedoch ziemlich wiederholbar.

Möglicherweise musst du auch Vorlagen anpassen, um bestimmte Dinge einzufrieren und keine Sicherheitsupdates für apt-Abhängigkeiten mehr zu beziehen.

7

Ok, ich habe die Version von Discourse bereits auf einen bestimmten Commit gepinnt und kann dies auch für Plugins tun. Wenn ich jedoch discourse-docker nicht ebenfalls pinne, führt das nicht dazu, dass discourse-base bei jedem Build aktualisiert wird, Discourse jedoch nicht? Führt das nicht zu einer ähnlichen Inkompatibilität, nur umgekehrt (weil discourse-base vor Discourse liegt)?

8

Ich bin verwirrt: Wie kann dieser Fehler aufgetreten sein, wenn Discourse auf eine ältere Version festgelegt ist?

Wenn NGINX eine kritische Sicherheitslücke hat, möchtest du, dass diese behoben wird?

9

Der Fehler trat auf, als ich die festgelegte Version von Discourse von 2.4.0.beta2 auf 2.4.0.beta8 aktualisiert habe.

Ja, natürlich möchte ich, dass kritische Sicherheitslücken in abhängigen Softwaresystemen behoben werden, wenn ich einen neuen Build durchführe! Das klingt fantastisch!

Allerdings möchte ich auch in der Lage sein, einen Rollback durchzuführen, falls die neue Version fehlerhaft ist :slight_smile:

Lassen Sie mich ein konkretes Beispiel nennen:

Angenommen, meine Konfiguration befindet sich im aktuellen Zustand:

discourse: 2.4.0.beta2 (in web_only.yml festgelegt)

Ich führe ./launcher rebuild web_only aus, und alles funktioniert.

Mein System befindet sich nun in diesem Zustand:

discourse: 2.4.0.beta2
discourse-docker: LATEST-AT-TIME-T1

Nun ändere ich meine Konfiguration auf diesen Zustand:

discourse: 2.4.0.beta8 (in web_only.yml festgelegt)

Ich führe ./launcher rebuild web_only aus, und etwas ist kaputt.

Mein System befindet sich nun in diesem Zustand:

discourse: 2.4.0.beta8
discourse-docker: LATEST-AT-TIME-T2

Jetzt möchte ich zur vorherigen Version zurückkehren, damit alles wieder funktioniert. Also ändere ich die festgelegte Version von Discourse auf 2.4.0.beta2 und führe einen neuen Build durch. Wenn ich jedoch ./launcher rebuild web_only ausführe, befindet sich das System nun in diesem Zustand:

discourse: 2.4.0.beta2
discourse-docker: LATEST-AT-TIME-T2

Obwohl die festgelegte Version von Discourse dieselbe ist, wird die Version von discourse-base (und der Rest von discourse-docker, Vorlagen, ./launcher selbst usw.) nun anders sein. Ich kehre also nicht zu einem bekannten funktionierenden Zustand zurück, und ich befürchte, dass der Build möglicherweise gar nicht mehr funktioniert.

Entschuldigen Sie, falls ich hier etwas dumm wirke. Ich möchte lediglich die Möglichkeit haben, im Falle von Problemen während eines Updates wieder auf einen sicheren Zustand zurückzukehren. Vielleicht ist das erneute Ausführen von ./launcher rebuild web_only einfach nicht der richtige Weg, um hier einen Rollback durchzuführen? Bei anderen Systemen, die ich bereitstelle, würde ich einfach ein vorheriges Docker-Image erneut bereitstellen. Gibt es eine Möglichkeit, dem Launcher mitzuteilen, dies zu tun?

10

Ja, du musst deinen Prozess hier überdenken. Unsere Datenbank-Migrationen sind nicht rückgängig zu machen. Wenn du ein Upgrade testen willst, ohne es zu übernehmen, musst du in einer Staging-Sandbox arbeiten.

11

Ja, ich verstehe, dass es schwierig ist, eine Datenbank-Migration zurückzusetzen. Discourse ist offensichtlich nicht für meine Art von Release- und Deployment-Management-Strategie konzipiert. Ich sollte hier aufhören, gegen den Strom zu schwimmen.

Ich habe eine Staging-Umgebung. Also werde ich einfach alle Ideen von wiederholbaren Builds und Deployments aufgeben, in der Staging-Umgebung testen und dann die Daumen drücken, wenn ich zur Produktion übergehe.

Danke für deine Hilfe, @sam