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
Estou fazendo isso para uma aplicação docker-compose e, apesar de exportar a variável de ambiente DISCOURSE_REDIS_HOST (como redis), ela não está sendo respeitada:
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: Erro ao conectar ao Redis em 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'
Meu código completo está aqui se quiser inspecionar. Por algum motivo, as variáveis (que deveriam ser respeitadas) não estão. Para contextualizar, realmente quero ajudar com um plugin, mas as barreiras de entrada (configurar um ambiente de desenvolvimento básico sem instalar tudo no meu host!) são enormes. A única vez que consegui fazer o Discourse funcionar foi usando a imagem da Bitnami, mas me disseram (em outro lugar) que não é o caminho certo a seguir. Por favor, ajude — isso não deveria ser tão difícil, especialmente quando estou doando meu tempo livre porque quero ajudar
Não tenho muita certeza do motivo pelo qual você está tendo esse problema, mas você terá muito menos dor de cabeça se seguir essa maneira recomendada: Install Discourse for development using Docker
Essa variável é respeitada sem problemas em produção.
Para desenvolvimento, procuramos por uma instância local por padrão, o que funciona perfeitamente se você seguir um dos ambientes de desenvolvimento suportados.
Estou executando com ‘production’ como variável de ambiente, mas ela não estava sendo respeitada. Como solução alternativa, alterei a configuração com o sed, e isso resolveu o problema. Ainda há diversos outros problemas com os quais estou trabalhando.
Por exemplo, estou começando dizendo explicitamente para não fazer o daemon (para manter o container em execução):
bundle exec rails s --port 3000 --no-daemon --environment=production --binding 0.0.0.0
mas parece que ele decide fazer isso de qualquer maneira! E, logicamente, o container é encerrado.
discourse_1_f60e0e3f1186 | [358] Puma iniciando no modo cluster...
discourse_1_f60e0e3f1186 | [358] * Versão 3.12.1 (ruby 2.6.3-p62), codinome: Llamas em Pijamas
discourse_1_f60e0e3f1186 | [358] * Threads mínimas: 8, máximas: 32
discourse_1_f60e0e3f1186 | [358] * Ambiente: production
discourse_1_f60e0e3f1186 | [358] * Workers de processo: 4
discourse_1_f60e0e3f1186 | [358] * Pré-carregando aplicação
discourse_1_f60e0e3f1186 | [358] * Ouvindo em tcp://0.0.0.0:3000
discourse_1_f60e0e3f1186 | [358] * Daemonizando...
docker-compose-discourse_discourse_1_f60e0e3f1186 saiu com código 0
É estranho que existam argumentos, instruções e variáveis de ambiente para essas coisas, mas elas não são realmente respeitadas. É difícil saber no que devo confiar.
Por que não posso executar um ambiente de produção e usá-lo para desenvolvimento? E o que o Sidekiq faz? Ele deve ser executado isoladamente para iniciar o aplicativo? Por exemplo, tenho outro container (mesma base) com um comando de inicialização:
bundle exec sidekiq
E ele depende do container principal do Discourse (realizando a migração do banco de dados, pré-compilando arquivos estáticos, etc.). Tudo parece funcionar, mas não há aplicativo web.
Estou feliz em dedicar bastante (mais) tempo a isso, considerando que ainda não comecei nada, mas preciso de uma solução que não exija que eu instale um banco de dados no meu servidor. Com containers, não deveríamos precisar fazer isso. E, novamente, a aplicação compose aqui GitHub - vsoch/discourse-compose: docker-compose with discourse · GitHub parece estar funcionando (sem erros em nenhum log), mas não há nenhuma aplicação.
Justo, mas digamos que eu esteja fazendo a pré-compilação de qualquer forma (isso realmente leva um tempo!) e queira iniciar o servidor. Por que isso não funciona?
Ok, cedi e executei o comando --init. Posso confirmar que o container está em execução:
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
Mas não estou vendo nenhum registro dele em nenhuma porta. Testei dois navegadores, localhost, 127.0.0.1 e 0.0.0.0, e não há nenhum aplicativo web. O erro é ERR_CONNECTION_RESET. Não vejo nada no iptables que bloquearia isso:
Obrigado a todos pela ajuda — o problema era a necessidade de executar aquele comando “unicorn”, e agora tudo está funcionando. Também precisei executar rake admin:create no comando de inicialização; caso contrário, ele solicita confirmação por e-mail (repositório completo aqui). O discourse_dev também funciona.
