The setup script works only for a standard setup. If you’re doing something more complex you have to edit the yml by hand. That’s much simpler than modifying the script.
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.
I didn’t perform any ‘non-standard’ install! I’ve, as actually described in the documentation, download the whole stuff from Github, changed the exposed ports only and ran the script:
I didn’t change anything in redis configuration, nor postgres.
I didn’t change anything for redis version.
These pieces of software have been installed by the genuine discourse-setup script.
@pfaffman what do you mean by “editing the yml by hand”? Which yml do you talk about? There are plenty of .yml files in “containers”…
By the way, I have actually a reverse proxy on the box, which seems to have a simple config: multiple subdomain.conf files which define the redirection subdomain:80 → port XXX. Is it what’s required?
I’d recommend a standard install on a separate vm to see how things work before trying a very complex setup.
I don’t want a complex setup , just need to run Discourse along some other containers, which is what Docker is designed for…
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.
You edited both the discourse-setup and a file that will be overwritten when you update discourse-docker. Changing anything other than your app.yml is decidedly non-standard.
Why? And whatever it is that you needed to change there, that’s not how to do it. You’ll need to put those changes into your app.yml.
Discourse won’t work on a non-standard port, so this is not a standard install.
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).
wipe all the software that was installed with the modified scripts (hope this will easily reversible).
download the script again. I’ve used git clone https://github.com/discourse/discourse_docker.git /var/discourse for the current installation: is it OK?
change possibly some settings in the file app.yml only, before running ./discourse-setup.
run the installation script for standard install (I do prefer one single container).
setup the nginx proxy to route discourse.example.com:80/443 to the proper container. Does the documentation give hints for this part?
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.
You cannot use ./discourse-setup to set up Discourse if another server is using port 80 or 443. You will need to copy and edit samples/standalone.yml with your favorite text editor.
and I understand that I need to modify app.yml before running discourse-setup, as already said in the preamble
You cannot use ./discourse-setup to set up Discourse if another server is using port 80 or 443. You will need to copy and edit samples/standalone.yml with your favorite text editor.
Can you then please confirm the following process:
download the whole stuff from Github
run discourse-setup once with the option --skip-connection-test → this will create the containers/app.yml
modify app.yml as decribed in the documentation above
update the software with /var/discourse/launcher rebuild app
create the nginx site to point to the Discourse socket and restart nginx
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?
Sorry to bother you, I need to be 100% sure as I’m definitely not an expert :
I run once again./discourse-setup --skip-connection-test --skip-rebuild (previous run was without the --skip-rebuild option). I don’t need to delete what has been installed by the previous run.
Then I edit the existing app.yml file and comment out the ports (they’re already commented out)
You don’t need to run discourse-setup ever again (unless, perhaps, you change the amount of RAM you have and want it to update the memory settings to the default recommended ones).
I’ve setup a DNS entry to have discourse.mydomain.com pointing at the server IP address = OK.
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?
Right! I’ve dumbly applied the config in the page listed above, compared to other nginx config files and couldn’t understand why the proxy wouldn’t listen to 80:443 for discourse…
Here’s what I expected to see:
server {
listen 80;
server_name discourse.mydomain.com;
return 301 https://$host$request_uri; # routing to https
}
server {
listen 443 ssl
listen [::]:443 ssl;
server_name discourse.mydomain.com;
ssl_certificate /etc/letsencrypt/live/discourse.mydomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/discourse.mydomain.com/privkey.pem;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
location / {
proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:; # using socket
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
}
Sorry Stephen for the confusion, I just used the name of the tool which is referenced in the article. I understand that NPM and nginx (as a) proxy manager are different things, this is why I used capital letters…
, just need to run Discourse along some other containers, which is what Docker is designed for…
: