Lors de la mise à jour via l’outil de mise à jour de l’interface utilisateur dans la section d’administration, cela échoue toujours. Cela échoue depuis que j’ai installé Discourse il y a plus d’un an. Je peux facilement me connecter à mon serveur via SSH et mettre à jour manuellement, mais il est frustrant d’avoir une fonctionnalité qui ne fonctionne pas correctement.
Étant donné que Discourse est exécuté avec Docker, et que je ne le connais pas très bien, j’aimerais savoir si d’autres personnes ont rencontré des problèmes similaires et comment je peux les résoudre.
En bref : l’outil de mise à jour de l’interface utilisateur échoue toujours, la ligne de commande fonctionne du premier coup et j’aimerais le corriger afin de ne pas avoir à me connecter au serveur via SSH (aussi souvent).
Je me rends compte après avoir fait quelques recherches que je pourrais utiliser la quantité minimale de RAM recommandée, mais il s’agit d’une installation privée avec moins de 50 utilisateurs, donc je n’ai vraiment pas besoin de dépasser le minimum pour mon cas d’utilisation.
Je pouvais auparavant faire une mise à jour avec 2G de RAM + 2G de swap, mais c’était, je crois, avant Ember, qui est très gourmand. Si vous avez suffisamment d’espace disque pour passer à 4G de swap, cela pourrait fonctionner. Ou, migrez temporairement et avec précaution vers une instance avec plus de RAM, effectuez la mise à jour, puis migrez à nouveau.
Quoi que vous fassiez, faites une sauvegarde et téléchargez-la d’abord.
Je vais examiner l’option d’échange et voir si cela aide. J’ai 2 Go de RAM et 80 Go de disque.
Malheureusement, mon fournisseur ne prend pas en charge les modifications automatiques des ressources système, mais je ne veux pas non plus payer plus de 5 $.
J’avais 2 Go de RAM et 40 Go de disque, en m’appuyant sur .\discourse-setup pour configurer le swap, les mises à jour de l’interface utilisateur web étaient lentes
Sur le marché américain, Contabo et IONOS autorisent tous deux le port 25 entrant, ce qui est essentiel pour les configurations mail-receiver — il n’y a donc pas de limitation fonctionnelle de ce côté-là.
La vraie différence réside dans la fiabilité et la réputation du support :
Contabo (Trustpilot 4,2/5, ~6 700 avis) offre des prix agressifs et des spécifications élevées, mais les utilisateurs basés aux États-Unis signalent souvent une latence élevée, une réponse plus lente du support et une instabilité des performances, en particulier sous charge. Les centres de données américains de Contabo existent, mais ils ne sont pas toujours aussi réactifs que prévu.
IONOS (Trustpilot 4,5/5, ~31 000 avis) obtient de meilleurs résultats aux États-Unis que beaucoup ne le pensent. Il a une meilleure réputation en matière de support et une infrastructure plus fiable, avec moins d’avis 1 étoile (~10 % contre 16 % pour Contabo). Les utilisateurs signalent systématiquement un meilleur temps de disponibilité, un support en direct et une meilleure gestion de compte par rapport à Contabo.
Conclusion (États-Unis) :
Si vous êtes basé aux États-Unis et avez besoin de stabilité, d’un support rapide et d’un faible risque pour les charges de production, IONOS est le choix le plus sûr. Contabo peut encore être envisagé pour les environnements de développement/test ou les déploiements sensibles aux coûts, mais attendez-vous à des compromis en termes de latence et de qualité du support.
Le mien a commencé à faire la même chose, tout allait bien pendant plus de 4 ans et maintenant ça échoue. Bien que parfois il prétende échouer, mais quand je rafraîchis tout est à jour et il n’y a plus rien à mettre à jour. Mais cela se termine presque toujours par
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL La commande a été tuée avec SIGKILL (Terminaison forcée) : ember build -prod /var/www/discourse/script/assemble_ember_build.rb:103:in `system': Command failed with exit 1: pnpm (RuntimeError) from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>' Docker Manager: FAILED TO UPGRADE
Dans presque tous les cas, il serait très utile de voir les 50 à 200 lignes précédentes de la sortie. Il est dommage que les scripts ne le conseillent pas.
C’est ce que je me demandais : si c’était lié à un problème avec le code lui-même et pas tant avec le matériel de mon serveur.
Je suppose que ma prochaine possibilité est d’écrire mon propre plugin avec un script pour me mettre à jour manuellement.
Heureux que d’autres aient le même problème, donc ce n’est pas seulement moi (je sais que c’est nul). Peut-être que quelqu’un qui développe activement avec Discourse peut s’y pencher. J’aimerais aussi qu’il y ait de meilleures informations de débogage, plutôt que cela “échoue” simplement.
Je ne suis ni développeur ni expert en serveurs et tout ce qui s’y rapporte. J’ai choisi Digital Ocean, simplement parce que c’était celui mentionné dans les instructions d’installation officielles, et parce que j’ai vu ce nom mentionné encore et encore au fil des ans.
Pour le moment, je suis sur l’avant-dernier plan, qui coûte 6 par mois pour un serveur qui semble bien plus « lent » que ceux proposés par Contabo ou IONOS. Comme le minimum pour une bonne performance de Discourse est d'au moins 2 Go de RAM, je devrais passer au plan à 12 . Pour le Contabo à 4,95 $ par mois, j’aurais 8 Go… c’est une « petite » différence tant en prix qu’en RAM, sans parler de l’espace disque, etc.
Alors, je vous demande, ainsi qu’à tout autre utilisateur expérimenté, est-ce que cela a du sens de migrer mon Discourse vers Contabo, par exemple, au lieu de rester chez Digital Ocean ? Même si je suis encore en train de construire toute la communauté et tout ça, jusqu’à présent DO a été correct, à part le problème de mise à jour de Discourse sur le web, même avec un fichier swap de 4 Go (car mon espace disque n’est que de 25 Go), mais je ne veux pas tout migrer pour ensuite commencer à remarquer d’autres problèmes.
J’ai trouvé cette page, mais je ne suis pas sûr de la fiabilité de ces tests et s’ils sont suffisants pour me faire changer ?
Vos commentaires seraient grandement appréciés !
Merci !
********************************************************
*** Veuillez patienter, les prochaines étapes peuvent prendre un certain temps ***
********************************************************
Cycling Unicorn, pour libérer de la mémoire
Redémarrage du processus Unicorn : 1580
Attente du rechargement d'Unicorn.
Attente du rechargement d'Unicorn..
Attente du rechargement d'Unicorn...
Attente du rechargement d'Unicorn....
Attente du rechargement d'Unicorn.....
Attente du rechargement d'Unicorn......
Attente du rechargement d'Unicorn.......
Attente du rechargement d'Unicorn........
Attente du rechargement d'Unicorn.........
Attente du rechargement d'Unicorn..........
Attente du rechargement d'Unicorn...........
Attente du rechargement d'Unicorn............
Attente du rechargement d'Unicorn.............
Attente du rechargement d'Unicorn..............
Arrêt de 1 worker(s) Unicorn, pour libérer de la mémoire
Arrêt de la file d'attente des tâches pour récupérer de la mémoire, le processus maître est 1585
$ cd /var/www/discourse && git fetch --tags --prune-tags --prune --force
$ cd /var/www/discourse && git reset --hard HEAD@{upstream}
HEAD est maintenant à 20ff23ed0 DEV : suppression des traductions redondantes pour le bouton de nouveau sujet désactivé (#33929)
$ bundle install --retry 3 --jobs 4
Bundle complète ! 160 dépendances Gemfile, 207 gems installés maintenant.
Les gems dans les groupes 'test' et 'development' n'ont pas été installés.
Les gems groupés sont installés dans `./vendor/bundle`
3 gems installés dont vous dépendez directement recherchent un financement.
Exécutez `bundle fund` pour plus de détails
$ if [ -f yarn.lock ]; then yarn install; else CI=1 pnpm install; fi
Portée : tous les 16 projets de l'espace de travail
Le fichier de verrouillage est à jour, l'étape de résolution est ignorée
Déjà à jour
Terminé en 2.9s en utilisant pnpm v9.15.9
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-custom-wizard est déjà à la dernière version compatible
docker_manager est déjà à la dernière version compatible
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Le migrator multisite s'exécute en utilisant 1 threads
Migration de la valeur par défaut
Initialisation de la valeur par défaut
*** Bundling des actifs. Cela prendra un certain temps ***
$ bundle exec rake themes:update assets:precompile
Mise à jour des thèmes avec une concurrence de 10
[db:default] 'Air Theme' - vérification...
[db:default] 'Air Theme' - à jour
[db:default] 'Modern Category + Group Boxes' - vérification...
[db:default] 'Modern Category + Group Boxes' - à jour
[db:default] 'Clickable Topic' - vérification...
[db:default] 'Clickable Topic' - à jour
[db:default] 'Search Banner' - vérification...
La limite de taille du tas Node.js est inférieure à 2048 Mo. Définition de --max-old-space-size=2048 et CHEAP_SOURCE_MAPS=1
La construction existante n'est pas réutilisable.
- Existant : {"ember_env"=>"production", "core_tree_hash"=>"cd74e4ac33647244c041061633d6ca67f9166e5c"}
- Actuel : {"ember_env"=>"production", "core_tree_hash"=>"7ac67590cc51e22690a2711b593892cd1d266781"}
Exécution de la construction complète du cœur...
Construction
Environnement : production
Le paramètre 'staticAddonTrees' sera défini par défaut sur true dans la prochaine version d'Embroider et ne pourra pas être désactivé. Pour vous y préparer, vous devriez définir 'staticAddonTrees: true' dans votre configuration Embroider.
Le paramètre 'staticAddonTestSupportTrees' sera défini par défaut sur true dans la prochaine version d'Embroider et ne pourra pas être désactivé. Pour vous y préparer, vous devriez définir 'staticAddonTestSupportTrees: true' dans votre configuration Embroider.
construction...
...[ConfigLoader]
...[Babel: @embroider/macros > applyPatches]
...[Babel: @ember/legacy-built-in-components > applyPatches]
...[Babel: ember-source > applyPatches]
[BABEL] Remarque : Le générateur de code a déoptimisé le style de /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js car il dépasse la limite maximale de 500 Ko.
[BABEL] Remarque : Le générateur de code a déoptimisé le style de /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js car il dépasse la limite maximale de 500 Ko.
...[Babel: @glimmer/component > applyPatches]
...[Babel: @ember/test-waiters > applyPatches]
...[Babel: ember-this-fallback > applyPatches]
...[Babel: ember-cache-primitive-polyfill > applyPatches]
...[Babel: select-kit > applyPatches]
...[@embroider/compat/app]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
undefined
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL La commande a été arrêtée avec SIGKILL (Terminaison forcée) : ember build -prod
/var/www/discourse/script/assemble_ember_build.rb:103:in `system': Commande échouée avec le code de sortie 1 : pnpm (RuntimeError)
from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>'
Docker Manager : ÉCHEC DE LA MISE À NIVEAU
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:211:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:112:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:44:in `load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:44:in `block in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2/lib/active_support/execution_wrapper.rb:91:in `wrap'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:70:in `conditional_executor'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/command.rb:28:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command/base.rb:178:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor.rb:538:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command/base.rb:73:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:65:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:143:in `with_argv'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:63:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands.rb:18:in `<main>'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `require'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `block (2 levels) in replace_require'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.18.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
bin/rails:18:in `<main>'
Redémarrage de 1 worker(s) Unicorn qui ont été arrêtés initialement
tant en prix qu’en RAM, sans parler de l’espace disque, etc.