External database ENV VARs not documented (external PG Port, external Redis ENV VARs)

Greetings,

I can’t post in the Sysadmin category.

I can configure an external DB using:

DISCOURSE_DB_USERNAME
DISCOURSE_DB_PASSWORD
DISCOURSE_DB_HOST
DISCOURSE_DB_NAME

But I couldn’t find:

DISCOURSE_DB_PORT (External PostgreSQL Port)
DISCOURSE_REDIS_HOST
DISCOURSE_REDIS_USERNAME
DISCOURSE_REDIS_PASSWORD
DISCOURSE_REDIS_NAME (which database, 0,1,2,3, etc)

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:

5 Likes

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

3 Likes

I’m doing this for a docker-compose application, and despite exporting the environment variable for DISCOURSE_REDIS_HOST (as redis) it is not honoring this variable:

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: Error connecting to Redis on 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'

My complete code is here if you want to inspect. For some reason, the variables (that should be honored) are not. For context, I’m really wanting to help with a plugin but the barriers to entry (setting up a basic development environment without installing everything on my host!) are huge. The only time I’ve ever gotten discourse working was using the bitnami image, which I’ve been told (somewhere else) isn’t the right way to go about it. Please help - this shouldn’t be this hard, especially to give my free time because I want to help :frowning:

I’m not quite sure why you’re having that problem, but you’ll experience considerably less pain if you do it this recommended way: Install Discourse for development using Docker

See also, Can Discourse ship frequent Docker images that do not need to be bootstrapped? - #6 by fbender

2 Likes

Maybe I’m reading the code incorrectly, but the bin/docker/boot_dev --init script is still interacting with a database and dependencies on the host.

For the second thread, what in particular are you pointing me to look at? It has 151 posts. Thanks!

That variable is honored in production just fine.

For development we search for a local instance by default, which works just fine if you follow one of the supported dev environments.

1 Like

I’m running it with production as the environment variable, and it wasn’t being honored. As a workaround I changed the config with sed, and that fixed it. There are still numerous other issues I’m working on.

For example, I’m starting by explicitly saying to not daemonize (to keep the container running):

bundle exec rails s --port 3000 --no-daemon --environment=production --binding 0.0.0.0

but it seems to decide to do it anyway! And then logically the container exits.

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

It’s weird that there are arguments, instructions, envars for things, but they aren’t actually honored. It’s hard to tell what I’m supposed to trust.

Do you want a production environment or a development environment?

Why can’t I run a production environment and use it for development? And what does sidekiq do? Should that be run alone to start the application? E.g., I have another container (same base) with a start command:

bundle exec sidekiq

And it depends on the main discourse container (migrating the db, precompiling static, etc.). Everything seems to work, but there is no web application.

I’m happy to spend lots of (more) time on this, granted that I haven’t started anything yet, but I need a solution that doesn’t require me installing a database on my host. With containers, we shouldn’t need to do that. And again, the compose application here https://github.com/vsoch/discourse-compose seems to be working (no errors in any logs) yet there is no application.

Because it caches and pre-compiles a bunch of stuff that basically makes doing development impossible.

The Install Discourse for development using Docker that I linked above does just that.

Sidekiq queues and processes jobs for later processing.

2 Likes

What am I missing? The command for --init is run on the host:

https://github.com/discourse/discourse/blob/master/bin/docker/boot_dev#L70

Fair enough, but let’s say that I’m doing the precompiling anyway (it does take a while!) and I want to start the server. Why does it not work?

Okay I gave in and ran the --init command. I can confirm the container is running:

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

But I’m not seeing any record of it at any port. I’ve tried two browsers, localhost, 127.0.0.1, and 0.0.0.0 and there is no web application. The error is ERR_CONNECTION_RESET. I don’t see anything in iptables that would block this:

Chain DOCKER (3 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.17.0.2           tcp dpt:9405
ACCEPT     tcp  --  anywhere             172.17.0.2           tcp dpt:9292
ACCEPT     tcp  --  anywhere             172.17.0.2           tcp dpt:3000
ACCEPT     tcp  --  anywhere             172.17.0.2           tcp dpt:socks

Update July 10, 2019

Thanks for everyone’s help - the issue was needing to issue that “unicorn” command, and I now have everything working. I also had to run rake admin:create in the start command, otherwise it wants an email confirmation (full repo here). The discourse_dev works too.