Errore durante la compilazione dell'ultima versione

Supporto Installazione
1

Ciao. Ricevo il seguente errore quando eseguo ./installer rebuild web_only sulle ultime versioni di Discourse.

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

Ho disattivato tutti i plugin, ma senza successo. Qualcuno può aiutarmi a capire cosa sta succedendo?

2

Abbiamo giĂ  visto questo altrove.

Puoi provare a eseguire

./launcher cleanup
git pull
./launcher rebuild app

Se ciò non funziona, prova a rimuovere tutti i container e tutte le immagini presenti sulla macchina.

3

Grazie per la risposta veloce, @sam. Proverò.

Una domanda veloce. “git pull”, presumo, scarichi l’ultima versione di discourse-docker, giusto?

In generale, è necessario aggiornare discourse-docker e discourse contemporaneamente?

Attualmente, non ho discourse-docker controllato da git. Invece, scarico una revisione specifica di discourse-docker (come file Zip) durante la configurazione del server e blocco la versione di discourse su un commit specifico durante la distribuzione.

Lo faccio per rendere la build ripetibile, ovvero eseguire lo stesso comando con la stessa configurazione e sorgente in due momenti diversi dovrebbe produrre lo stesso artefatto. In generale, questa è una buona idea e mi ha salvato da molti incubi operativi con altri software nel corso degli anni :wink: Questo perché ti dà la possibilità di tornare a una configurazione nota e funzionante.

Tuttavia, penso di nuotare controcorrente con Discourse, perché sembra voler scaricare le ultime versioni di vari componenti software durante la build. Inizio a chiedermi se i miei tentativi di rendere la build ripetibile mi stiano in realtà facendo un torto?

4

Verissime le tue parole: sei entrato in uno stato completamente insostenibile con questo “hacking” :flushed_face:

Ti consiglio di aggiornare subito all’ultima versione da git.

Le vecchie immagini Docker di Discourse base sono incompatibili con la versione attuale di Discourse e, inoltre, mancano di molte patch di sicurezza.

5

Grazie @sam. L’ho fatto e ora riesco a compilare la nuova versione. Fortunatamente, tutto questo avveniva in beta, quindi non ci sono stati danni :slight_smile: Non sono sicuro che definire “hackeraggio” il desiderio di una build ripetibile sia corretto :thinking:

Ciò che sto cercando di ottenere qui è la possibilità di tornare a una versione nota e funzionante. Supponiamo che a un tempo t1 esegua ./launcher rebuild app e Discourse funzioni. Poi, a un tempo t2, eseguo ./launcher rebuild app e qualcosa non va. Come posso riportare il software alla versione precedente? Potrei accettare il fatto che la build non sia ripetibile, purché possa tornare a uno stato noto e funzionante. Dato che il launcher ha già creato un’immagine Docker funzionante al tempo t1, è possibile istruirlo a utilizzare un’immagine specifica invece di quella difettosa creata al tempo t2?

Qualche idea?

Scusa se mi sono un po’ discusso dall’argomento, posso ripostare se preferisci.

6

Se desideri build ripetibili, devi fissare la versione di Discourse a uno SHA specifico tramite la configurazione del container, così come per ogni plugin.

Questo significa che non riceverai più aggiornamenti per Discourse, aggiornamenti di sicurezza per l’immagine Docker e così via, ma la build sarà abbastanza ripetibile.

Potrebbe essere necessario modificare anche i template per fossilizzare le dipendenze e non ricevere mai aggiornamenti di sicurezza per le dipendenze di apt.

7

Ok, ho già fissato la versione di Discourse a un commit specifico e posso fare lo stesso per i plugin. Ma se non fissiamo anche discourse-docker, non rischiamo di creare una situazione in cui discourse-base viene aggiornato ad ogni build mentre Discourse no? Non porterebbe a una simile incompatibilità, ma al contrario (perché discourse-base si troverebbe in avanti rispetto a Discourse)?

8

Sono confuso, come è apparso questo errore se hai Discourse bloccato su una versione vecchia?

Se NGINX presenta una vulnerabilitĂ  critica, vuoi che venga risolta?

9

L’errore è apparso quando ho aggiornato la versione fissata di Discourse da 2.4.0.beta2 a 2.4.0.beta8

Certo, mi piacerebbe che le vulnerabilitĂ  critiche nei sistemi software dipendenti venissero risolte quando eseguo una nuova build! Sembra fantastico!

Tuttavia, vorrei anche poter eseguire un rollback nel caso in cui la nuova versione sia difettosa :slight_smile:

Lasciate che vi faccia un esempio concreto:

Supponiamo che la mia configurazione sia nello stato attuale:

discourse : 2.4.0beta2 (fissata in web_only.yml)

Eseguo ./launcher rebuild web_only e tutto funziona.

Ora il mio sistema è in questo stato:

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

Quindi ora modifico la mia configurazione in questo stato:

discourse : 2.4.0beta8 (fissata in web_only.yml)

Eseguo ./launcher rebuild web_only e qualcosa si è rotto.

Il mio sistema è ora in questo stato:

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

Quindi ora voglio tornare alla versione precedente per far funzionare di nuovo tutto. Cambio quindi la versione fissata di Discourse in 2.4.0beta2 e ricostruisco. Tuttavia, quando eseguo ./launcher rebuild web_only, il sistema è ora in questo stato:

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

Sebbene la versione fissata di Discourse sia la stessa, la versione di discourse-base (e il resto di discourse-docker, i template, lo stesso ./launcher, ecc.) sarà ora diversa, quindi non tornerò a uno stato noto e funzionante, e temo che potrebbe non compilare affatto.

Scusate se sto facendo il tonto, voglio solo avere la possibilità di tornare alla sicurezza nel caso in cui ci siano problemi durante un aggiornamento. Forse rieseguire ./launcher rebuild web_only non è il modo giusto per eseguire un rollback qui? Per altri sistemi che distribuisco, mi limiterei a ridistribuire una precedente immagine Docker? C’è un modo per dire al launcher di fare questo?

10

Sì, devi ripensare al tuo processo qui. Le nostre migrazioni del database non sono reversibili.

Se vuoi testare un aggiornamento senza impegnarti, devi operare in un ambiente di staging sandbox.

11

Sì, capisco che sia difficile eseguire il rollback di una migrazione del database. Discourse non è ovviamente progettato pensando alla mia strategia di rilascio e gestione delle distribuzioni. Dovrei smettere di nuotare controcorrente.

Ho un ambiente di staging. Quindi abbandonerò qualsiasi idea di build e distribuzione ripetibili, testerò su staging e incrocerò le dita e le dita dei piedi prima di passare alla produzione.

Grazie per il tuo aiuto @sam