Est-ce correct ? Combien de temps pour installer la version dev ?

J’essaie d’installer la version de développement de Discourse sur un droplet Ubuntu 20.04 chez DigitalOcean, dans le seul but de migrer un forum FluxBB vers Discourse, d’exporter les données, puis de les importer dans une version de production de Discourse.

Je n’ai eu aucun problème à installer la version de production via Docker à titre de test (sans migration depuis FluxBB).

Cependant, lorsque j’essaie d’installer la version de développement de Discourse en suivant ce guide :

Je constate que la commande suivante ne se termine jamais :

bundle exec rake autospec

Après environ 30 minutes d’attente, ma session distante expiré.

De plus, je rencontre de nombreuses erreurs. Malheureusement, je ne les ai pas sous la main, mais elles sont toutes du type « une certaine fonction retourne systématiquement « nil » ».

Puisque je ne sais pas ce que cette commande fait ni si elle est nécessaire (les instructions se contentent de dire « essayez d’exécuter les spécifications » sans expliquer ce que cela implique ni pourquoi le faire), j’ai directement tenté la commande suivante :

bundle exec rails server --binding=0.0.0.0

Et là aussi, cela prend une éternité et déverse une foule d’informations dans le terminal que je ne comprends pas. Ce sont peut-être des erreurs, peut-être pas.

Ma question est donc la suivante : ce comportement est-il normal ou est-ce que je fais quelque chose de mal ? Combien de temps faut-il normalement pour que ces commandes se terminent ?

Est-il possible de migrer le forum FluxBB en utilisant uniquement la version de production/Docker de Discourse, sans avoir besoin de la version de développement ? Pour l’instant, je n’ai même pas encore de site de production, donc je ne m’inquiète pas de le casser ; je peux le détruire et le recréer à volonté.

Cela signifie que le serveur est en cours d’exécution. Bien sûr, il continuera de fonctionner jusqu’à ce que vous appuyiez sur Control C ou que vous fermiez le terminal.

Des informations sont affichées dans le terminal à l’infini, sauf si vous arrêtez le serveur.

Quelques secondes après le démarrage, la page web sera disponible dans votre navigateur.

Connectez-vous-vous au bon port dans votre navigateur ? Habituellement, il s’agit du port 3000.

Il existe plusieurs guides sur l’exécution d’importations sur des serveurs de production. Vous pouvez utiliser l’un d’entre eux comme référence pour exécuter le script que vous souhaitez lancer.

Il semble que vous ayez installé l’environnement de développement et que vous deviez exécuter le script dans celui-ci.

Je ne vois rien dans le navigateur. Je vois un processus Ruby en cours d’exécution si je lance ‘top’ depuis le terminal.

Si la sortie du terminal s’étend à l’infini après avoir exécuté

bundle exec rails server --binding=0.0.0.0

ne devrait-on pas le préciser explicitement dans la documentation ? Habituellement, lorsque je consulte un guide pratique, je m’attends à ce qu’une commande accomplisse une tâche, se termine, puis affiche un message indiquant que l’installation est terminée et que tout est prêt.

Il existe plusieurs sujets de type tutoriel sur l’exécution d’importations sur des serveurs de production.

Où pourraient-ils se trouver ? Le seul que je vois pour FluxBB indique explicitement de le faire sur une installation de développement :

On considère généralement comme allant de soi que, si vous démarrez un serveur web, il n’est pas censé s’arrêter sauf si l’administrateur le souhaite. Les serveurs web sont généralement conçus pour servir des pages jour après jour après jour… mais bien sûr, quelqu’un pourrait ajouter cette précision. N’importe qui peut soumettre des améliorations proposées au guide via une PR.

Mais est-il évident que cette commande lance un serveur web ? Elle indique simplement « rails server », ce qui ne signifie pas nécessairement un serveur web. Lorsque vous démarrez un serveur web Apache, vous êtes immédiatement renvoyé à l’invite de commande ; il ne déverse pas de messages en boucle dans le Terminal…

Rails est un framework d’application web. Je ne pense pas qu’il soit juste de le comparer directement à Apache.

J’aime bien le fait de pouvoir le voir travailler activement. Quand il s’arrête, c’est généralement qu’il y a un problème ! La sortie peut être utile dans certaines situations, surtout en développement. Vous pouvez modifier la quantité d’informations affichées via la configuration de l’environnement.

Au fait, selon la documentation, Rails peut être « daemonisé » avec l’option -d. N’hésitez pas à creuser pourquoi cela ne semble pas fonctionner dans l’installation de base ; il pourrait y avoir une limitation introduite par cette option. L’équipe est la mieux placée pour en parler.

Salut @epsteindidnt,

Lorsque vous prendrez le rythme du développement avec Rails, vous découvrirez, si vous êtes comme moi, que ce que vous décrivez comme « déverser des tonnes d’informations dans le Terminal sans fin » deviendra l’un de vos meilleurs amis.

Par exemple, je développe actuellement une application Rails pour un client avec qui nous transformons toute leur logique métier héritée (datant de plusieurs décennies) vers Rails. J’ai même acheté un nouvel écran juste pour pouvoir voir ces « tonnes d’informations dans le Terminal sans fin » (tes mots), car ces informations sont de l’or pur pour un développeur.

En plus du journal du serveur Rails, qui fournit des détails précis sur ce qui se passe, il y a aussi un autre « meilleur ami du développeur » : la console Rails !

Lorsque j’écris du code pour Rails, je rédige essentiellement une ébauche dans VS Code, puis je copie-colle des extraits dans la console Rails pour m’assurer que tout fonctionne comme prévu.

Pour le débogage, j’insère des instructions d’impression Ruby (p, puts) dans le code et j’observe ce qui se passe dans le « flux continu d’informations dorées du journal du serveur Rails » à l’écran. Presque toutes mes erreurs sont corrigées de cette manière ! Comme je l’ai dit, j’ai récemment acheté un nouvel écran incurvé dédié au jeu, juste pour pouvoir voir les informations du journal du serveur Rails qui vous agacent :slight_smile:

En lisant vos messages, j’ai l’impression que vous êtes un peu comme moi au début de cette année, en train de migrer vers une application Rails sans expérience préalable du développement avec Rails. Au début, j’étais aussi agacé par Rails (peut-être même un peu plus) ; et neuf mois plus tard, je développe exclusivement en Rails tous les jours pour des clients (je limite mon travail client à mi-temps car je suis semi-retraité) et j’ai arrêté tout développement PHP antérieur. Honnêtement, j’ai trouvé une nouvelle passion pour Rails (et Ruby), et ce, très fortement. Mieux vaut tard que jamais, comme on dit !

Concernant Apache2, Apache ne fournit pas les détails précis de ce qui se passe en coulisses dans une application comme le fait Rails. J’utilise Apache2 comme proxy inverse devant toutes mes applications Rails, et pour être franc, je ne me souviens pas de la dernière fois que j’ai consulté un fichier de journal Apache ; car je fais tout le débogage en utilisant le journal du serveur Rails qui vous agace actuellement :slight_smile:

Pour conclure, j’espère sincèrement qu’un point de vue différent de la part d’une personne ayant déjà « migré un forum vers Rails » pourra vous aider, ne serait-ce que légèrement. Pour moi, avoir été contraint de quitter les applications web LAMP pour passer aux applications web Rails a été l’une des meilleures « choses tech » qui me soient arrivées (personnellement) en 2020.

Joyeuses Fêtes !

J’ai été un peu effrayé par cela dernièrement aussi. Voici ce que j’ai réalisé aujourd’hui :

La sortie dans un terminal rails s montrera beaucoup de requêtes au démarrage, mais elle inclut également la sortie des tâches sidekiq de discourse (du moins, c’est le cas dans la configuration de développement Docker). Donc, si vous effectuez une importation importante, vous obtiendrez une très grande file d’attente sidekiq de tâches de post-traitement qui peuvent s’exécuter pendant longtemps par la suite. Je pense qu’il s’agit de tâches non essentielles, par exemple, le chargement des caches, qui ne semblent pas vous empêcher de naviguer sur le site avant qu’elles ne soient terminées.

Cela me confondait énormément car j’ai effectué une grosse importation, puis je suis revenu en arrière et j’ai réinitialisé la base de données pour effectuer une petite importation de test, et cela continuait de mouliner sans fin en effectuant des requêtes liées à la base de données qui n’existait plus ! La solution a été de vider les files d’attente sidekiq à l’aide d’une console Rails.

Trop tard pour vous aider, mais j’ai pensé partager cela.