Il n’y a actuellement aucun moyen de dockeriser Discourse sur un Mac avec une puce M1, n’est-ce pas ?
Lorsque j’ai exécuté d/boot_dev --init, j’ai rencontré cette erreur :
ActiveRecord::NoDatabaseError : Nous n'avons pas pu trouver votre base de données : discourse_development. Les configurations de base de données disponibles se trouvent dans config/database.yml. (ActiveRecord::NoDatabaseError)
Je ne suis pas sûr s’il s’agit d’un bug dans le script boot_dev, ou si la base de données discourse_development est censée être créée ailleurs. Quoi qu’il en soit, j’ai pu le corriger avec cette modification :
diff --git a/bin/docker/boot_dev b/bin/docker/boot_dev
index 89fdcf6f65..0e9c5ce7d5 100755
--- a/bin/docker/boot_dev
+++ b/bin/docker/boot_dev
@@ -122,6 +122,7 @@ echo "pnpm install..."
if [ "${initialize}" = "initialize" ]; then
echo "Migrating database..."
+ "${SCRIPTPATH}/rake" db:create
"${SCRIPTPATH}/rake" db:migrate
RAILS_ENV=test "${SCRIPTPATH}/rake" db:migrate
Après cela, le processus d’installation s’est déroulé correctement, en suivant les instructions de l’OP.
Je ne suis pas assez familier avec la base de code de Discourse pour savoir si c’est la bonne correction, mais je suis heureux de soumettre une PR si cela peut aider. 
6 « J'aime »
Oh oui, veuillez créer une PR et la lier ici. Merci !
4 « J'aime »
Terminé !
3 « J'aime »
Avez-vous réussi à le faire fonctionner ?
J’ai eu la même erreur. J’ai exécuté docker rm -f /discourse_dev et relancé d/boot_dev --init et cela a fonctionné cette fois-ci.
Attention :
J’ai remarqué que le dossier est data/postgres au lieu de tmp/postgres, ce qui explique aussi pourquoi la commande « réinitialiser la base de données » vise à supprimer le dossier data 
2 « J'aime »
J’ai pensé revoir l’installation de développement Docker, mais je continue d’obtenir :
Caused by:
PG::ConnectionBad: connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: No such file or directory (PG::ConnectionBad)
Is the server running locally and accepting connections on that socket?
Pourtant, je peux confirmer que le service est actif (et fonctionne lorsque j’utilise mon installation “manuelle” normale de Discourse hors Docker).
~/discourse_docker/discourse$ sudo service postgresql status
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
Active: active (exited) since Mon 2025-03-10 17:26:13 GMT; 6min ago
Process: 2052109 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 2052109 (code=exited, status=0/SUCCESS)
Mar 10 17:26:13 black-knight systemd[1]: Starting PostgreSQL RDBMS...
Mar 10 17:26:13 black-knight systemd[1]: Finished PostgreSQL RDBMS.
Docker Dev a-t-il des besoins de connectivité Postgres spécifiques et différents ?
2 « J'aime »
J’ai trouvé que les niveaux de journalisation :debug par défaut étaient beaucoup trop verbeux - les requêtes SQL noyaient les erreurs importantes. config/environments/development.rb permet de définir DISCOURSE_DEV_LOG_LEVEL, mais je ne sais pas si cela peut être fait via le script d/rails ?
Quoi qu’il en soit, je l’ai juste codé en dur temporairement dans config/environments/development.rb à config.log_level = :info et cela a résolu le problème pour moi. Cela pourrait aider d’autres personnes également.
1 « J'aime »
J’essaie de lancer ceci avec le plugin Data Explorer car j’aimerais examiner l’automatisation du DE.
J’ai réussi à démarrer le conteneur.
Ensuite, j’ai tâtonné pour « installer » le plugin en clonant le dépôt et en le reliant symboliquement dans le répertoire discourse/plugins (est-ce ce que je devais faire ? Le guide pourrait vraiment être beaucoup plus clair sur ce point).
J’ai activé le plugin via l’interface utilisateur. Mais lorsque j’essaie d’y accéder, j’obtiens une erreur.
Tout ce qui apparaît dans le journal est ceci :
Processing by DiscourseDataExplorer::QueryController#index as JSON
Completed 500 Internal Server Error in 62ms (ActiveRecord: 9.8ms (5 queries, 0 cached) | GC: 2.9ms)
Que suis-je censé faire avec ça ? Où sont les détails ?
1 « J'aime »
Avez-vous exécuté les migrations ?
Je n’ai pas eu beaucoup de chance avec la création de liens symboliques vers mon dossier de plugins :
J’ai fini par revenir à un dossier normal en conséquence (voir mon dernier commentaire dans ce fil de discussion).
Je pense qu’il y a actuellement des incompatibilités entre les volumes Docker, les watchers de fichiers et les liens symboliques.
2 « J'aime »
Merci pour votre réponse @Arkshine ! Qu’est-ce qui aurait dû m’alerter sur le fait que c’était nécessaire ? J’ai bien vérifié le tutoriel sur l’installation d’un plugin, mais je suppose que le plugin que le tutoriel utilise comme exemple n’a pas besoin de migrations ?
En attendant, je ne sais pas si cela me permettra de passer le cap car je me suis heurté au besoin d’intégrer le certificat proxy de mon entreprise dans le conteneur Docker et je n’ai pas fait grand-chose avec Docker auparavant :frowning :
Quel problème essayez-vous de résoudre ? Une installation de développement est généralement destinée à n’être accessible que depuis le localhost (c’est-à-dire votre ordinateur) où l’installation s’exécute.
Ou peut-être essayez-vous de déboguer quelque chose qui nécessite un certificat, comme un système d’authentification ?
Lorsque j’ai essayé de relancer mon image hier, elle a voulu télécharger des gems ?
Installation des gems...
Récupération de l'index de la source depuis https://rubygems.org/
Nouvelle tentative du fetcher suite à une erreur (2/4) : Bundler::Fetcher::CertificateFailureError Impossible de vérifier le certificat SSL pour https://rubygems.org/.
Il y a une chance que vous subissiez une attaque de type "man-in-the-middle", mais il est plus probable que votre système n'ait pas les certificats CA nécessaires à la vérification. Pour plus d'informations sur les certificats OpenSSL, consultez https://railsapps.github.io/openssl-certificate-verify-failed.html.
Nouvelle tentative du fetcher suite à une erreur (3/4) : Bundler::Fetcher::CertificateFailureError Impossible de vérifier le certificat SSL pour https://rubygems.org/.
Il y a une chance que vous subissiez une attaque de type "man-in-the-middle", mais il est plus probable que votre système n'ait pas les certificats CA nécessaires à la vérification. Pour plus d'informations sur les certificats OpenSSL, consultez https://railsapps.github.io/openssl-certificate-verify-failed.html.
Nouvelle tentative du fetcher suite à une erreur (4/4) : Bundler::Fetcher::CertificateFailureError Impossible de vérifier le certificat SSL pour https://rubygems.org/.
Il y a une chance que vous subissiez une attaque de type "man-in-the-middle", mais il est plus probable que votre système n'ait pas les certificats CA nécessaires à la vérification. Pour plus d'informations sur les certificats OpenSSL, consultez https://railsapps.github.io/openssl-certificate-verify-failed.html.
Impossible de vérifier le certificat SSL pour https://rubygems.org/.
Il y a une chance que vous subissiez une attaque de type "man-in-the-middle", mais il est plus probable que votre système n'ait pas
les certificats CA nécessaires à la vérification. Pour plus d'informations sur les certificats OpenSSL, consultez
https://railsapps.github.io/openssl-certificate-verify-failed.html.
Hé, alors… que se passe-t-il si vous oubliez le mot de passe du compte administrateur ? Réinstaller tout le développement ?
Aucun e-mail ne peut être envoyé, donc les réinitialisations ne sont pas possibles.
Vous pouvez utiliser la console pour définir un nouveau mot de passe ou créer un nouveau compte administrateur.
1 « J'aime »
Il existe une route pour devenir n’importe quel utilisateur.
http://localhost:4200/session/any-username/become
4 « J'aime »