1st issue : despite its complexity, the installation script doesn’t allow for exposed port modification! Ports 80/443 can’t be used on my server, being used by nginx. So I had once again to tweak the setup script to set ports 3080/3443 as the required ports to access Discourse.
Then I managed to have all containers up and running. Looking at the stack with Portainer, I found out that the application starts and silently stops and the logs don’t give much information on the reason. As redis and postgres don’t publish any port, could the discourse app fails because it cannot connect to these components? What did I miss or do wrong?
It seems like you have deviated from the standard install by setting up separate containers for Redis and Postgres, so I’m afraid I don’t have an out of the box answer for you. How did you configure the Redis settings within Discourse?
Another thing - I do see redis:4-alpine. I’m afraid you’ll need to move to a newer version of Redis since Discourse requires version 6.20 or higher. I don’t think this is the cause of your issue though.
If you’re not going to use the provided postgres and redis then you’re on your own figuring out why yours doesn’t work. There are too many things that it could be that we cannot guess or infer. I’d recommend a standard install on a separate vm to see how things work before trying a very complex setup.
In general discourse-setup does not install separate postgres and redis instances and certainly not versions 12 and 4.
Can you please post your configuration and the changes you made to container.yml and the scripts? Make sure to redact any confidential settings.
Also, please let us know which commit of the discourse_docker repository you’re at.
The standard install includes postgres and redis in the single container. As pointed out, you’re using unsupported versions of redis and postgres. You can also do a two container installation as described here Move from standalone container to separate web and data containers (and you can use ./discourse-setup --two-container to have discourse-setup create separate data and web containers, though it’s a bit more complicated to mainain (you have to know when to update the data container).
app.yml gets created by discourse-setup. You can’t run discourse-setup if it can’t access the ports, but if you read the source you’ll see that you can ./discourse-setup --skip-connection-test and run it anyway.
Your nginx will be responsible for let’s encrypt, so you’ll want to comment out the let’s encrypt template. I suspect that’s described in the reverse proxy topic linked above and below.
run discourse-setup once with the option --skip-connection-test : everything went fine until the end, where the script returned
docker: Error response from daemon: driver failed programming external connectivity on endpoint app (784361985c928eb26b149d829f37882056562d9b1e77ef4ce71fbfe30c5d80b1): Error starting userland proxy: listen tcp4 0.0.0.0:443: bind: address already in use.
This looks normal to me, as the container tries to access the same ports than the existing webserver. However, as no discourse container has been created (as returned by docker container ls), I’d like you to confirm this before going further with the nginw config…
You mean “before running discourse-setup”? In that case, which file should I modify, as app.yml doesn’t exist before I run the script? I want to install a 1-container app: should I run the same discourse-setup script again or the /var/discourse/launcher rebuild app command?
Opening a browser to discourse.mydomain.com leads me to… the Nextcloud instance running on the server. Seems the configuration should be fixed, as traffic is not properly routed to the discourse container…
I don’t want to install NPM as I read it’s not a robust tool and the config for discourse involves IP hard-coding: should I anyway?