Installer Discourse pour le développement avec Docker

Documentation Guides pour les développeurs
, ,
168

Merci pour le guide.

Cependant, je rencontre des problèmes lors de la création d’une sauvegarde depuis la section d’administration.
L’erreur que je reçois est la suivante :
pg_dump: erreur : échec de la connexion à la base de données "discourse development" : FATAL : échec de l'authentification peer pour l'utilisateur "postgres".

J’ai vérifié le fichier pg_hba.conf et j’ai configuré toutes les options sur « trust ».

Il serait génial de pouvoir bénéficier d’une aide pour faire fonctionner cela.

J’ai essayé sur Ubuntu ainsi que sur macOS. Tout fonctionne parfaitement sur les deux (création de publications, API, etc.), à l’exception de la fonctionnalité de sauvegarde.

169

Merci pour cette excellente solution Docker.

Pour exécuter les spécifications des plugins, cela fonctionne bien :

d/rake plugin:spec["discourse-follow"]

Existe-t-il un moyen de cibler des tests de plugin spécifiques, comme dans un environnement de développement non Docker ? Par exemple :

LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/requests/follow_controller_spec.rb:32

J’ai essayé, par exemple :

d/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:10 LOAD_PLUGINS=1 RAILS_ENV=test

Mais j’obtiens une erreur.

170

LOAD_PLUGINS et RAILS_ENV doivent précéder la commande pour attribuer les variables d’environnement. Après la commande, ils sont traités comme des arguments pour rspec, ce qu’il ne comprend pas.

LOAD_PLUGINS=1 RAILS_ENV=test d/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:10

171

Non, je ne suis pas convaincu que cela fonctionne — l’avez-vous réellement essayé ?

J’obtiens :

NameError:
  uninitialized constant Follow

Je soupçonne que cela soit dû au fait que les variables d’environnement ne sont pas transmises au processus Docker.

C’est d’ailleurs pour cette raison que je les ai rendues accessibles en tant qu’arguments.

172

Désolé, j’ai mal interprété vos deux commandes comme signifiant « la première fonctionne pour cette autre spécification, la seconde ne fonctionne pas pour cette spécification ». Je n’ai pas d’environnement de développement configuré pour tester.

En examinant le fichier rspec sur GitHub, je pense que vous avez raison : les variables d’environnement ne sont pas transmises. Il semble que vous devriez pouvoir exécuter d/shell pour obtenir un shell à l’intérieur du conteneur, puis lancer votre commande rspec depuis là.

1 « J'aime »
173

Simon, c’est plus qu’une excellente solution de contournement utilisable, merci !

Je viens de l’essayer et cela fonctionne, à savoir :

my-blah-machine:~/discourse$ d/shell
discourse@discourse:/src$ LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37

J’ai ajouté cela ainsi que la version complète du plugin sur le Wiki.

1 « J'aime »
174

En examinant de plus près d/exec, que d/shell et d/rspec utilisent tous deux, je pense qu’il peut aussi être raccourci comme suit :

RAILS_ENV=test d/exec LOAD_PLUGINS=1 rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37

d/exec transmet bien RAILS_ENV mais pas LOAD_PLUGINS, d’où leur position de part et d’autre de d/exec.

1 « J'aime »
175

Cela me génère une erreur :

OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "LOAD_PLUGINS=1": executable file not found in $PATH: unknown
176

Ah, je suppose que les variables d’environnement ne peuvent pas être utilisées ainsi avec docker exec. Tant pis, au moins l’ouverture du shell fonctionne d’abord.

1 « J'aime »
177

Je rencontre exactement le même problème que Max. Chaque fois que j’essaie de faire une sauvegarde ou une restauration sur mon installation Docker locale de développement, j’obtiens la même erreur : Peer authentication failed for user "postgres".

Après quelques recherches, j’ai découvert que dans l’environnement de développement, la configuration de la base de données s’affiche comme ceci :

BackupRestore.database_configuration
=> #<struct BackupRestore::DatabaseConfiguration host=nil, port=nil, username="postgres", password=nil, database="discourse_development">

D’une manière ou d’une autre, l’environnement de développement ne définit pas le nom d’utilisateur dans les variables d’environnement, et le module BackupRestore utilise alors la valeur par défaut postgres pour le nom d’utilisateur.

# lib/backup_restore.rb:122

    DatabaseConfiguration.new(
      config["backup_host"] || config["host"],
      config["backup_port"] || config["port"],
      config["username"] || username || ENV["USER"] || "postgres",
      config["password"] || password,
      config["database"]
    )

Où pouvons-nous définir le bon nom d’utilisateur de la base de données ?

1 « J'aime »
178

Comment utiliser Install the Discourse Theme CLI console app to help you build themes ici ?

Nous avons installé avec succès le gem : d/exec sudo gem install discourse_theme … maintenant, le défi consiste à créer un lien symbolique vers le thème local …

@Simon_Manning notez l’utilisation de sudo pour contourner les problèmes de permissions (merci pour le rappel @fzngagan).

179

J’essaie de tester un plugin en utilisant la configuration Docker. De manière aléatoire, l’application cesse de se charger et je ne vois qu’une page blanche jusqu’à ce que je supprime le dossier de données et que je reconstruise tout. Avez-vous des conseils pour déboguer ce problème ?

180

Y a-t-il eu des résultats à ce sujet ? Cela semble toujours être un problème.

181

Mon « sale » contournement consistait à remplacer le nom d’utilisateur postgres par discourse dans le bloc de code suivant :

# lib/backup_restore.rb:122

    DatabaseConfiguration.new(
      config["backup_host"] || config["host"],
      config["backup_port"] || config["port"],
      config["username"] || username || ENV["USER"] || "postgres",
      config["password"] || password,
      config["database"]
    )
182

J’ai basculé de mon Mac local vers une machine virtuelle Ubuntu en espérant que cela faciliterait l’exécution, mais malheureusement, ce n’est pas encore le cas.

Je me heurte déjà à d’étranges problèmes de permissions dès les premières étapes. La commande d/bundle install indique qu’elle a besoin des droits sudo pour installer certains éléments, et d/rails s renvoie également des erreurs de permission.

Traceback (most recent call last):
        8: from /src/bin/unicorn:70:in `<main>'
        7: from /src/bin/unicorn:38:in `ensure_cache_clean!'
        6: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `mkdir_p'
        5: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `each'
        4: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `block in mkdir_p'
        3: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `reverse_each'
        2: from /usr/local/lib/ruby/2.7.0/fileutils.rb:228:in `block (2 levels) in mkdir_p'
        1: from /usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `fu_mkdir'
/usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `mkdir': Permission denied @ dir_s_mkdir - /src/tmp (Errno::EACCES)

Une idée de ce qui ne va pas ? Cette machine exécutait auparavant un Discourse en production sans aucun problème. J’ai simplement arrêté et supprimé ces conteneurs, puis cloné le dépôt git de développement dans un autre répertoire. Je lance le tout via tmux pour gérer les différentes instances de shell.

183

Je ne suis pas encore sur M1, mais je prévois de passer très bientôt, et je préfère vraiment la commodité de la configuration Docker.

Ce lien vers la PR pointe vers https://github.com/docker/for-mac/issues/5321, où ils indiquent :

la seule solution consiste à passer à des images multi-architectures compatibles arm64. Elles seront également beaucoup plus rapides et généralement plus fiables. Je vous recommande d’examiner quelles images de base vous utilisez et de passer à des versions multi-architectures lorsque cela est possible. Vous pouvez voir quelles architectures sont prises en charge par chaque image sur Docker Hub : […]

Pour construire vous-même une image multi-architecture, je recommande docker buildx. Consultez cet article de blog : https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

L’équipe Discourse est-elle ouverte à l’idée de prendre en charge une image multi-architecture ? Il semble que l’image de base de Discourse soit basée sur debian:buster-slim, qui est déjà multi-architecture, donc il ne devrait pas être démesurément difficile de rendre l’image de base de Discourse multi-architecture. Cela pourrait cependant vous placer dans une situation où il faudrait prendre en charge ARM (en production !). Quelqu’un (l’équipe Discourse ?) devrait exécuter les tests de Discourse à la fois sur x86_64 et ARM, corriger les problèmes lorsqu’ils échouent, etc.

Une PR serait-elle même la bienvenue ici ?

À mon avis, ARM semble être l’architecture de l’avenir, même dans les environnements hébergés dans le cloud.

2 « J'aime »
Install Discourse on Arm-Based Compute
184

Je tente de configurer cela sur WSL2.

J’en suis arrivé au lancement d’ember_cli, mais Chrome affiche l’erreur suivante :

Aucune erreur n’est visible dans le terminal ni dans le journal de développement. Toute suggestion est la bienvenue, s’il vous plaît ?

1 « J'aime »
Trouble setting up dev Discourse on WSL2 with Docker - solved
185

C’est vraiment utile.

186

Salut à tous,

Je rencontre les mêmes problèmes, j’ai donc pensé à le signaler comme un bug. Veuillez trouver ci-dessous.

La restauration de sauvegarde échoue dans un environnement Docker de développement propre : FATAL : l’authentification par pair a échoué pour l’utilisateur « postgres »

Faites-moi savoir si je peux fournir plus d’informations ou si je peux être d’une quelconque aide.

Koen

187

Impossible de faire fonctionner cela sous openSUSE Leap 15. Je suppose que ce n’est pas un système d’exploitation pris en charge, bien que puisque nous utilisons Docker, cela ne devrait pas vraiment avoir d’importance…

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /src/app/assets/javascripts/plugins
/src/lib/plugin/instance.rb:441:in `ensure_directory'
/src/lib/plugin/instance.rb:713:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

J’ai essayé de créer manuellement “app/assets/javascripts/plugins” et cela m’a amené à

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /src/tmp
lib/discourse.rb:94:in `atomic_write_file'
/src/lib/plugin/instance.rb:726:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Donc, je vais faire mkdir tmp dans le dossier source…

Mais ensuite, cela m’amène ici :

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ rb_sysopen - /src/tmp/5ad4443faf817dc922116f8df65ae5c3
lib/discourse.rb:97:in `initialize'
lib/discourse.rb:97:in `open'
lib/discourse.rb:97:in `atomic_write_file'
/src/lib/plugin/instance.rb:726:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Il semble que boot_dev exécute docker exec en tant qu’utilisateur discourse… mais les répertoires appartiennent à un utilisateur 1016 (l’uid de l’utilisateur de mon hôte).

J’imagine que beaucoup de développeurs ne rencontrent pas ce problème sur leurs ordinateurs portables personnels où leur utilisateur a un uid de 1000 et cela coïncide par hasard…

1 « J'aime »