Erreur lors de la compilation de la dernière version

Soutien Installation
1

Bonjour. Je rencontre l’erreur suivante en exécutant ./installer rebuild web_only sur les dernières versions de 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

J’ai désactivé tous les plugins, mais cela ne résout toujours pas le problème. Quelqu’un pourrait-il m’éclairer ?

2

Nous avons déjà vu cela ailleurs.

Peux-tu essayer :

./launcher cleanup
git pull
./launcher rebuild app

Si cela ne fonctionne pas, essaie de supprimer tous les conteneurs et toutes les images présents sur la machine.

3

Merci pour votre réponse rapide @sam. Je vais essayer cela.

Une petite question. Je suppose que “git pull” récupère la dernière version de discourse-docker, c’est bien ça ?

En général, est-il nécessaire de mettre à jour discourse-docker et discourse en même temps ?

Actuellement, je ne gère pas discourse-docker via git. À la place, je télécharge une révision spécifique de discourse-docker (sous forme de fichier Zip) lors de la configuration du serveur, et je fixe la version de discourse à un commit précis lors du déploiement.

La raison de cette approche est de rendre la construction reproductible, c’est-à-dire que lancer la même commande avec la même configuration et les mêmes sources à deux moments différents devrait produire le même artefact. En général, c’est une bonne pratique qui m’a évité de nombreux cauchemars opérationnels avec d’autres logiciels au fil des ans :wink: Cela permet en effet de revenir à une configuration connue et fonctionnelle.

Cependant, j’ai l’impression de nager à contre-courant avec Discourse, car il semble vouloir récupérer les dernières versions de divers composants logiciels lors de la construction. Je commence à me demander si mes efforts pour rendre la construction reproductible ne me jouent pas des tours ?

4

Très justes paroles : vous êtes entré dans un état totalement insoutenable avec cette bidouille :flushed_face:

Je vous recommande de récupérer la dernière version depuis Git dès que possible.

Les anciennes images Docker de Discourse Base sont incompatibles avec la version actuelle de Discourse, et en plus, elles manquent de nombreuses mises à jour de sécurité.

5

Merci @sam. Je l’ai fait et je parviens maintenant à compiler la nouvelle version. Heureusement, tout cela était en version bêta, donc aucun dommage :slight_smile: Cependant, je ne suis pas sûr que ce soit de la « bidouille » de vouloir une construction reproductible :thinking:

Ce que j’essaie d’obtenir ici, c’est la possibilité de revenir à une version connue et fonctionnelle. Supposons que j’exécute ./launcher rebuild app à l’instant t1 et que Discourse fonctionne. Ensuite, j’exécute ./launcher rebuild app à l’instant t2 et quelque chose ne va plus. Comment puis-je remettre le logiciel à sa version précédente ? Je pense que je pourrais accepter le fait que la construction ne soit pas reproductible si je pouvais revenir à un état connu et fonctionnel. Puisque le launcher a déjà construit une image Docker fonctionnelle à l’instant t1, est-il possible de demander au launcher d’utiliser une image spécifique plutôt que celle défectueuse construite à l’instant t2 ?

Des idées ?

Désolé de m’être un peu éloigné du sujet ici, je peux reposter si tu le souhaites.

6

Si vous souhaitez des builds reproductibles, vous devez figer votre version de Discourse sur un SHA spécifique via la configuration de votre conteneur, ainsi que pour chaque plugin.

Cela signifie que vous ne recevrez plus les correctifs pour Discourse, les correctifs de sécurité pour l’image Docker, etc., mais la build sera très reproductible.

Vous devrez peut-être également modifier les modèles pour figer certains éléments et ne jamais intégrer les correctifs de sécurité des dépendances gérées par apt.

7

Ok, j’ai déjà verrouillé la version de Discourse sur un commit spécifique et je peux faire de même pour les plugins. Mais si je ne verrouille pas aussi discourse-docker, cela ne risque-t-il pas de créer une situation où discourse-base est mis à jour à chaque construction tandis que Discourse ne l’est pas ? Cela ne conduirait-il pas à une incompatibilité similaire, mais dans l’autre sens (car discourse-base avancerait par rapport à Discourse) ?

8

Je suis perplexe : comment cette erreur a-t-elle pu apparaître si vous avez verrouillé Discourse sur une ancienne version ?

Si NGINX présente une vulnérabilité critique, souhaitez-vous qu’elle soit corrigée ?

9

L’erreur est apparue lorsque j’ai fait passer la version épinglée de Discourse de 2.4.0.beta2 à 2.4.0beta8.

Bien sûr, je souhaite que les vulnérabilités critiques dans les logiciels dépendants soient corrigées lorsque je lance une nouvelle compilation ! Cela semble fantastique !

Cependant, je voudrais aussi pouvoir revenir en arrière dans le cas où la nouvelle version serait cassée :slight_smile:

Laissez-moi vous donner un exemple concret :

Supposons que ma configuration soit dans l’état actuel :

discourse : 2.4.0beta2 (épinglé dans web_only.yml)

J’exécute ./launcher rebuild web_only et tout fonctionne.

Maintenant, mon système est dans cet état :

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

Je modifie alors ma configuration pour passer à cet état :

discourse : 2.4.0beta8 (épinglé dans web_only.yml)

J’exécute ./launcher rebuild web_only et quelque chose ne fonctionne plus.

Mon système est maintenant dans cet état :

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

Je veux donc revenir à la version précédente pour que tout fonctionne à nouveau. Je change donc la version épinglée de Discourse pour 2.4.0beta2 et je relance la compilation. Cependant, lorsque j’exécute ./launcher rebuild web_only, le système est maintenant dans cet état :

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

Bien que la version épinglée de Discourse soit la même, la version de discourse-base (et le reste de discourse-docker, les templates, le ./launcher lui-même, etc.) sera différente. Je ne reviendrai donc pas à un état connu et fonctionnel, et je crains que cela ne puisse même pas se compiler.

Désolé si je suis un peu lent ici, tout ce que je veux, c’est avoir la possibilité de revenir en arrière en cas de problème lors d’une mise à jour. Peut-être que relancer ./launcher rebuild web_only n’est tout simplement pas la bonne façon de revenir en arrière ? Pour les autres systèmes que je déploie, je redéploierais simplement une image Docker précédente. Y a-t-il un moyen de dire au launcher de faire cela ?

10

Oui, tu dois repenser ton processus ici. Nos migrations de base de données ne sont pas réversibles.

Si tu veux tester une mise à jour sans l’appliquer définitivement, tu dois opérer dans un bac à sable de préproduction.

11

Oui, je comprends que ce soit difficile de revenir en arrière sur une migration de base de données. Discourse n’est évidemment pas conçu pour ma stratégie de gestion des versions et du déploiement. Je devrais arrêter de lutter contre le courant ici.

J’ai un environnement de staging. Je vais donc abandonner toute idée de construction et de déploiement reproductibles, tester sur le staging, puis croiser les doigts et les orteils lors du passage en production.

Merci pour votre aide @sam