I’m an engineer at Compose/IBM and I’m attempting to setup Discourse using our production-ready, replicated databases. I’d like to run a web_only instance with external Redis & PostgreSQL
I also couldn’t find configuration parameters for failover support:
We supply two URIs “portals” for connection failover. I don’t have a ton of time to dig through the Discourse codebase and see which client driver you are using.
Lastly, we use SSL (using valid LE certs) for both Redis and PostgreSQL. Is your app configured for SSL support?
Thanks!
P.S. I’m reaching out personally, not officially from IBM/Compose. I enjoy Discourse and have been considering writing an article on how to configure Discourse using our services:
You can see all of the possible global vars documented at:
You can pass in config from your environment, all the settings below are available.
Append DISCOURSE_ and upper case the setting in ENV. For example:
to pass in db_timeout of 200 you would use DISCOURSE_DB_TIMEOUT=200
Je le fais pour une application docker-compose, et malgré l’exportation de la variable d’environnement DISCOURSE_REDIS_HOST (en tant que redis), elle n’est pas respectée :
name, 'name', name),\n updated_at,\n created_at,\n updated_at\nFROM facebook_user_infos\n")
discourse_1_9cc0cea436ca | rake aborted!
discourse_1_9cc0cea436ca | Redis::CannotConnectError: Erreur de connexion à Redis sur localhost:6379 (Errno::ECONNREFUSED)
discourse_1_9cc0cea436ca | /usr/local/bundle/gems/redis-4.0.1/lib/redis/client.rb:344:in `rescue in establish_connection'
Mon code complet se trouve ici si vous souhaitez l’examiner. Pour une raison quelconque, les variables (qui devraient être respectées) ne le sont pas. Pour contexte, je souhaite vraiment aider avec un plugin, mais les barrières à l’entrée (configurer un environnement de développement de base sans tout installer sur mon hôte !) sont énormes. La seule fois où j’ai réussi à faire fonctionner Discourse était en utilisant l’image bitnami, dont on m’a dit (ailleurs) que ce n’est pas la bonne méthode. S’il vous plaît, aidez-moi — cela ne devrait pas être aussi difficile, surtout pour donner de mon temps libre car je veux aider
Je ne suis pas tout à fait sûr de la raison pour laquelle vous rencontrez ce problème, mais vous éprouverez beaucoup moins de difficultés si vous suivez cette méthode recommandée : Install Discourse for development using Docker
Pour le développement, nous recherchons par défaut une instance locale, ce qui fonctionne parfaitement si vous suivez l’un des environnements de développement pris en charge.
Je l’exécute avec production comme variable d’environnement, mais elle n’était pas prise en compte. En attendant, j’ai modifié la configuration avec sed, ce qui a résolu le problème. Il reste encore de nombreux autres problèmes sur lesquels je travaille.
Par exemple, je commence par indiquer explicitement de ne pas daemoniser (pour maintenir le conteneur en cours d’exécution) :
bundle exec rails s --port 3000 --no-daemon --environment=production --binding 0.0.0.0
mais il semble décider de le faire quand même ! Et logiquement, le conteneur se termine.
discourse_1_f60e0e3f1186 | [358] Puma starting in cluster mode...
discourse_1_f60e0e3f1186 | [358] * Version 3.12.1 (ruby 2.6.3-p62), codename: Llamas in Pajamas
discourse_1_f60e0e3f1186 | [358] * Min threads: 8, max threads: 32
discourse_1_f60e0e3f1186 | [358] * Environment: production
discourse_1_f60e0e3f1186 | [358] * Process workers: 4
discourse_1_f60e0e3f1186 | [358] * Preloading application
discourse_1_f60e0e3f1186 | [358] * Listening on tcp://0.0.0.0:3000
discourse_1_f60e0e3f1186 | [358] * Daemonizing...
docker-compose-discourse_discourse_1_f60e0e3f1186 exited with code 0
C’est étrange qu’il y ait des arguments, des instructions, des variables d’environnement pour diverses choses, mais qu’ils ne soient pas réellement respectés. Il est difficile de savoir en quoi on est censé avoir confiance.
Pourquoi ne puis-je pas exécuter un environnement de production et l’utiliser pour le développement ? Et que fait Sidekiq ? Faut-il le lancer seul pour démarrer l’application ? Par exemple, j’ai un autre conteneur (même base) avec une commande de démarrage :
bundle exec sidekiq
Il dépend du conteneur Discourse principal (migration de la base de données, précompilation des fichiers statiques, etc.). Tout semble fonctionner, mais il n’y a pas d’application web.
Je suis heureux de consacrer beaucoup (de plus) de temps à cela, étant donné que je n’ai encore rien commencé, mais j’ai besoin d’une solution qui ne nécessite pas l’installation d’une base de données sur mon hébergeur. Avec les conteneurs, nous ne devrions pas avoir à le faire. Et encore une fois, l’application compose ici GitHub - vsoch/discourse-compose: docker-compose with discourse · GitHub semble fonctionner (aucune erreur dans les journaux), mais il n’y a aucune application.
C’est juste, mais supposons que je fasse la précompilation de toute façon (cela prend un certain temps !) et que je veuille démarrer le serveur. Pourquoi cela ne fonctionne-t-il pas ?
D’accord, j’ai cédé et lancé la commande --init. Je peux confirmer que le conteneur est en cours d’exécution :
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d2254e1374f5 discourse/discourse_dev:release "/sbin/boot" 24 minutes ago Up 24 minutes 0.0.0.0:1080->1080/tcp, 0.0.0.0:3000->3000/tcp, 0.0.0.0:9292->9292/tcp, 0.0.0.0:9405->9405/tcp discourse_dev
Cependant, je ne vois aucune trace de celui-ci sur aucun port. J’ai essayé deux navigateurs, localhost, 127.0.0.1 et 0.0.0.0, mais aucune application web n’est accessible. L’erreur est ERR_CONNECTION_RESET. Je ne vois rien dans iptables qui pourrait bloquer cela :
Merci à tous pour votre aide — le problème était la nécessité d’exécuter la commande « unicorn », et maintenant tout fonctionne. J’ai également dû exécuter rake admin:create dans la commande de démarrage, sinon il demandait une confirmation par e-mail (le dépôt complet se trouve ici). discourse_dev fonctionne également.
