I’m trying to implement the separate containers, but with a remote database. I’ve followed these instructions above and the howto for setting up a remote postgres DB. The setup works, but I’m wondering why there are two identical references (under web_only and data) to the same database. It makes me believe I’m doing something wrong and the web_only container is not even using the data container.
env:
# ensure locale exists in container, you may need to install it
LANG: en_US.UTF-8
DISCOURSE_DB_USERNAME: REMOVE
DISCOURSE_DB_PASSWORD: REMOVE
DISCOURSE_DB_HOST: REMOVE.ondigitalocean.com
DISCOURSE_DB_NAME: REMOVE
DISCOURSE_DB_PORT: 25060
DISCOURSE_DB_BACKUP_PORT: 25060
If you’re using a remote database, you don’t need to create the data container which has a database in it. Note that you need both postgres and redis (so you might need the data container for that).
I don’t know really what You understand by two containers but if You assume two containers mean two separate discourse instances then You’re looking in the wrong direction.
This article helps one set up a separate application and database container which is useful for advanced users looking for some flexibility.
So which container was running? Assuming it was app then no, You’re running an old version of discourse-setup.
Do a git pull before proceeding to make sure you’re using the latest version of discourse-setup.
If You got data or web-only container running then You should check what caused the other one to not start. Usually, the web-only container fails to start because there is a process (web server) already running on port 80/443
If You just want to run a 2nd standalone container, You will have to modify the yml files to use different directory and port. Possibly also disable the letsencrypt
Just FYI, if You want to benchmark performance, You shouldn’t do that on a production machine. Rather spin up a separate VPS and use that for benchmarking.
Trying to run two separate instances of discourse on the same machine may lead you into a very broken install and that isn’t ideal.
I think I should have left this feature undocumented. And, actually, it’s no help to move to a two container config, so it probably doesn’t belong here at all.
Maybe so. It is a big help, and like discourse-setup, it’s for a very specific purpose, a new installation that’s very standard. My install scripts have used it for quite a while. It can be an easy way to switch to two container if you’re willing to do a backup on the old container and restore on the new one.
My concern has always been that it would be difficult to support, as folks who won’t understand it will try to use it and then not be able to use any documentation, as “rebuild app” won’t work anymore, and knowing when you need to rebuild the database container is also difficult. I had a rebuild fail recently because redis was 3.0 and 4.0 is now required. And then postgres also had to be updated, which required a sequence of steps to be followed, but you had to know when to rebuild the data container and when to rebuild the web container and how to change the path from what’s recommended. It all went off without a hitch – for me, but trying to communicate that to someone who doesn’t know what bash is in a forum would be frustrating for all concerned.
I think that it might be best to keep the barrier to creating a non standard installation rather high, to protect people from themselves.