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
Sto facendo questo per un’applicazione docker-compose e, nonostante esporti la variabile d’ambiente DISCOURSE_REDIS_HOST (come redis), non viene rispettata:
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: Errore di connessione a Redis su 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'
Il mio codice completo è qui se vuoi ispezionarlo. Per qualche motivo, le variabili (che dovrebbero essere rispettate) non lo sono. Per contestualizzare, vorrei davvero aiutare con un plugin, ma le barriere all’ingresso (configurare un ambiente di sviluppo di base senza installare tutto sul mio host!) sono enormi. L’unica volta che sono riuscito a far funzionare Discourse è stata usando l’immagine bitnami, ma mi è stato detto (da qualche altra parte) che non è il modo giusto per procedere. Per favore, aiutatemi: non dovrebbe essere così difficile, soprattutto quando dedico il mio tempo libero perché voglio aiutare
Non sono molto sicuro del motivo per cui tu stia riscontrando quel problema, ma avrai molto meno disagio se procedi in questo modo consigliato: Install Discourse for development using Docker
Questa variabile viene rispettata correttamente in produzione.
Per lo sviluppo, per impostazione predefinita, cerchiamo un’istanza locale, il che funziona perfettamente se segui uno degli ambienti di sviluppo supportati.
Lo sto eseguendo con ‘production’ come variabile d’ambiente, ma non veniva rispettata. Come soluzione temporanea ho modificato la configurazione con sed e questo ha risolto il problema. Ci sono ancora numerosi altri problemi su cui sto lavorando.
Ad esempio, sto iniziando specificando esplicitamente di non eseguire il demone (per mantenere il container in esecuzione):
bundle exec rails s --port 3000 --no-daemon --environment=production --binding 0.0.0.0
ma sembra che decida comunque di farlo! Di conseguenza, il container si chiude.
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
È strano che ci siano argomenti, istruzioni e variabili d’ambiente per gestire queste cose, ma che non vengano effettivamente rispettate. È difficile capire a cosa ci si debba fidare.
Perché non posso eseguire un ambiente di produzione e utilizzarlo per lo sviluppo? E cosa fa Sidekiq? Dovrebbe essere avviato da solo per far partire l’applicazione? Ad esempio, ho un altro container (con la stessa base) con un comando di avvio:
bundle exec sidekiq
E dipende dal container principale di Discourse (migrazione del database, precompilazione delle risorse statiche, ecc.). Sembra che tutto funzioni, ma non c’è l’applicazione web.
Sono felice di dedicare molto (più) tempo a questo, dato che non ho ancora iniziato nulla, ma ho bisogno di una soluzione che non richieda l’installazione di un database sul mio host. Con i container, non dovremmo aver bisogno di farlo. E ancora, l’applicazione compose qui GitHub - vsoch/discourse-compose: docker-compose with discourse · GitHub sembra funzionare (nessun errore in nessun log), eppure non c’è alcuna applicazione.
Ok, mi sono arreso ed eseguito il comando --init. Posso confermare che il container è in esecuzione:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d2254e1374f5 discourse/discourse_dev:release "/sbin/boot" 24 minuti fa Up 24 minuti 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
Tuttavia, non vedo alcun record a nessuna porta. Ho provato due browser, localhost, 127.0.0.1 e 0.0.0.0, ma non c’è alcuna applicazione web. L’errore è ERR_CONNECTION_RESET. Non vedo nulla in iptables che possa bloccare questo:
Grazie a tutti per l’aiuto: il problema era necessario eseguire il comando “unicorn”, e ora ho tutto funzionante. Ho dovuto anche eseguire rake admin:create nel comando di avvio, altrimenti richiede una conferma via email (repository completo qui). Anche discourse_dev funziona.
